How to Build a Raspberry Pi RC Car with OpenClaw Navigation

Hiwonder's Hackster.io project for the ROSOrin Pro demonstrates OpenClaw controlling a wheeled robot through SLAM-based navigation, dynamic path planning with TEB, and LiDAR-based obstacle avoidance. The full ROSOrin Pro kit runs over $400 with a TOF LiDAR, depth camera, and Mecanum wheels. Most hobbyists building a Raspberry Pi RC car do not need that level of hardware. They need two motors, a camera, and a control layer smarter than a hardcoded Python script.

The typical Pi RC car tutorial follows a pattern: wire an L298N motor driver to the GPIO pins, write a Python script with functions like forward(), backward(), turn_left(), and turn_right(), then control the car from a phone app or keyboard over WiFi. That approach works for remote control. It breaks the moment you want the car to do anything on its own.

OpenClaw replaces the hardcoded script with an AI agent that accepts natural-language commands and translates them into motor control sequences. Instead of writing a new function for every driving pattern, you describe what you want: "drive forward until you see an obstacle, then turn right." The agent generates the Python code, executes it on the Pi through shell commands, and can adjust its approach based on camera feedback.

This is not autonomous driving in the self-driving-car sense. There is no neural network processing video at 30fps. The camera captures a frame, the agent reasons about what it sees, and then issues motor commands. Response times depend on the LLM you use. Cloud models like Claude or GPT-4 add network latency. A local model through Ollama on the Pi 5 responds faster but with less reasoning depth. For a hobby car navigating a living room obstacle course at low speed, either approach works.

The real advantage is flexibility. A scripted car needs a rewrite for every new behavior. An agent-controlled car needs a new instruction.

The build uses seven main components. Prices reflect June 2026 retail availability.

Raspberry Pi 5 (4 GB): $70

The Pi 5 is the brain. Its quad-core ARM Cortex-A76 at 2.4 GHz handles the camera processing, agent runtime, and GPIO control with room to spare. The 4 GB model is sufficient. The 8 GB version ($130 after the 2026 DRAM price increases) gives more headroom if you plan to run a local LLM through Ollama alongside the motor control scripts. A Pi 4 (4 GB) also works, though the slower processor means longer camera processing times.

2WD Robot Car Chassis Kit: $12 to $18

A standard kit includes an acrylic or aluminum chassis plate, two geared DC motors (typically 3V to 6V), two wheels, one caster wheel, a battery box, and mounting hardware. These are widely available on Amazon and AliExpress. The two-motor design simplifies wiring since you only need one L298N channel per side, and differential steering (one motor forward, one motor reversed) handles turns.

L298N Dual Motor Driver Board: $5

The L298N is a dual H-bridge driver that controls two DC motors independently. SparkFun sells the breakout board for $4.95. Generic versions on Amazon run $3 to $5 in multi-packs. The board accepts 7V to 12V input, provides a regulated 5V output (useful for powering the Pi in some configurations), and handles up to 2A per channel, which covers most hobby DC motors.

Raspberry Pi Camera Module 3: $25

The standard version captures 1080p video with autofocus, which the agent uses for obstacle detection and scene understanding. The wide-angle version ($35) gives a broader field of view that helps in tight spaces. Mount it at the front of the chassis, angled slightly downward to see the ground 30 to 60 centimeters ahead.

32 GB MicroSD Card: $8 to $10

High-endurance cards (Samsung PRO Endurance, SanDisk MAX Endurance) handle the frequent small writes from logging better than standard cards. A USB SSD is more reliable for long-term use but adds bulk to a small car.

Power: $10 to $15

Two options work well. A 7.4V LiPo battery pack (2S, 1800 mAh or higher) powers both the motors through the L298N and the Pi through the L298N's 5V regulator. Alternatively, use four AA batteries in the chassis kit's battery box for the motors and a separate USB-C power bank for the Pi. The split approach is heavier but avoids voltage regulation issues.

Jumper Wires and Standoffs: $5 to $8

Female-to-female jumper wires connect the L298N to the Pi's GPIO header. M3 standoffs and screws mount the Pi and camera to the chassis.

Total cost: $135 to $150 with a new Pi 5, or $65 to $80 if you already own one.

Start by assembling the chassis kit according to its instructions. Mount the two DC motors on opposite sides, attach the wheels, and screw the caster wheel to the front or rear. The chassis plate should have mounting holes for the Pi and motor driver. If it does not, use adhesive standoffs or double-sided tape as a temporary mount.

L298N wiring to the Raspberry Pi 5:

The L298N has three connection groups: motor outputs, power input, and logic inputs.

For Motor A (left wheel), connect the motor leads to the OUT1 and OUT2 screw terminals. For Motor B (right wheel), connect to OUT3 and OUT4. If a motor spins the wrong direction during testing, swap its two wires at the screw terminal.

Power connections: connect the battery positive to the L298N 12V terminal and the battery negative to the GND terminal. If using the L298N's onboard 5V regulator to power the Pi, connect the 5V output to the Pi's 5V GPIO pin (pin 2 or 4). Remove the 5V enable jumper on the L298N only if your input voltage exceeds 12V.

Logic connections (L298N to Pi GPIO):

• ENA to GPIO 18 (pin 12), a hardware PWM pin for Motor A speed control
• IN1 to GPIO 27 (pin 13) for Motor A direction
• IN2 to GPIO 22 (pin 15) for Motor A direction
• IN3 to GPIO 23 (pin 16) for Motor B direction
• IN4 to GPIO 24 (pin 18) for Motor B direction
• ENB to GPIO 13 (pin 33), a hardware PWM pin for Motor B speed control
• GND on the L298N to any Pi GND pin (pin 6, 9, 14, 20, 25, 30, 34, or 39)

Testing the motors:

Before adding the agent layer, verify the wiring with a simple Python script using the gpiozero library, which comes pre-installed on Raspberry Pi OS.

from gpiozero import Motor
from time import sleep

motor_a = Motor(forward=27, backward=22, enable=18)
motor_b = Motor(forward=23, backward=24, enable=13)

motor_a.forward(0.5)
motor_b.forward(0.5)
sleep(2)
motor_a.stop()
motor_b.stop()

This runs both motors at 50% speed for two seconds. If one wheel spins backward, swap the forward and backward pin numbers in the code (or swap the motor wires at the L298N). Test all four movement patterns: both forward, both backward, left turn (Motor A stopped, Motor B forward), right turn (Motor A forward, Motor B stopped).

Store your RC car's drive logs and camera frames in one searchable workspace

50 GB free storage, no credit card, with built-in AI search across your session data, obstacle detection frames, and configuration files.

Sign Up Free

Mount the Camera Module 3 at the front of the chassis using a camera mount bracket or a 3D-printed holder. Angle it 15 to 30 degrees downward so the field of view covers the ground ahead of the car. Connect the ribbon cable to the Pi's CSI port (the connector between the HDMI ports on the Pi 5).

Verify the camera works with rpicam-still -o test.jpg. If the image is rotated, add rotation settings in /boot/firmware/config.txt.

Installing OpenClaw:

OpenClaw runs on Raspberry Pi OS Lite (64-bit) or the full desktop version. The official installation is a single command that sets up Node.js, configures a systemd service, and runs an onboarding wizard where you provide your LLM API key. OpenClaw supports cloud models (Claude, GPT-4, Gemini) and local models through Ollama.

During setup, the wizard asks which messaging platform to connect. For RC car control, Telegram works well because you can send text commands from your phone and receive camera snapshots in reply. Discord, Slack, WhatsApp, and direct terminal access are also options.

Installing the robot skill:

OpenClaw's skill system extends the agent's capabilities. The robot skill, available on ClawHub, provides structured guidance for motor control, sensor integration, and safety constraints. It helps the agent generate proper PWM code, avoid flash GPIO pins, and follow simulation-first workflows for physical hardware.

Creating a motor control helper:

Rather than having the agent generate motor control code from scratch every time, write a Python helper script that wraps the basic movement functions. Save it on the Pi where OpenClaw can execute it.

import sys
from gpiozero import Motor
from time import sleep

motor_a = Motor(forward=27, backward=22, enable=18)
motor_b = Motor(forward=23, backward=24, enable=13)

commands = {
    "forward": lambda s, d: (motor_a.forward(s), motor_b.forward(s), sleep(d)),
    "backward": lambda s, d: (motor_a.backward(s), motor_b.backward(s), sleep(d)),
    "left": lambda s, d: (motor_a.backward(s/2), motor_b.forward(s), sleep(d)),
    "right": lambda s, d: (motor_a.forward(s), motor_b.backward(s/2), sleep(d)),
    "stop": lambda s, d: (motor_a.stop(), motor_b.stop()),
}

cmd = sys.argv[1] if len(sys.argv) > 1 else "stop"
speed = float(sys.argv[2]) if len(sys.argv) > 2 else 0.5
duration = float(sys.argv[3]) if len(sys.argv) > 3 else 1.0
commands.get(cmd, commands["stop"])(speed, duration)
motor_a.stop()
motor_b.stop()

OpenClaw can call this as python3 drive.py forward 0.7 2.0 to drive forward at 70% speed for 2 seconds. The agent chains these calls to execute complex maneuvers without regenerating motor code each time.

With the hardware wired and the software installed, the workflow becomes conversational. Send a message to OpenClaw through your chosen platform: "drive forward slowly for three seconds, then stop." The agent translates that into a shell command using your helper script, executes it, and reports the result.

Adding camera-based obstacle detection:

The camera turns the car from remote-controlled to semi-autonomous. Write a second helper script that captures a frame with rpicam-still, runs basic obstacle detection using OpenCV's edge detection or color thresholding, and prints a simple output like "clear" or "obstacle at 40cm."

import subprocess
import cv2
import numpy as np

subprocess.run(["rpicam-still", "-o", "/tmp/frame.jpg", "--width", "640",
                 "--height", "480", "-t", "500", "--nopreview"], check=True)
img = cv2.imread("/tmp/frame.jpg")
gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)
edges = cv2.Canny(gray, 50, 150)

bottom_half = edges[240:, :]
edge_density = np.count_nonzero(bottom_half) / bottom_half.size

if edge_density > 0.15:
    print("obstacle_detected")
else:
    print("path_clear")

This is a rough heuristic, not production computer vision. Edge density in the bottom half of the frame increases when objects are close. For a living room obstacle course, it distinguishes between open floor and chair legs well enough to be useful.

OpenClaw ties the two helpers together. Tell the agent: "drive forward, but check for obstacles every second. If you detect an obstacle, stop and turn right, then continue forward." The agent writes a loop that alternates between the camera check and the drive command, creating behavior that would require 30 to 50 lines of custom Python if you scripted it yourself.

What the agent handles well:

• Sequential driving patterns: "drive a square" becomes four forward-then-turn sequences
• Conditional behavior: "if the path is clear, keep going; otherwise back up and try a different direction"
• Speed adjustments: "drive slowly near walls, faster in open areas"

Where the agent hits limits:

Real-time responsiveness depends on the LLM round-trip time. A cloud model adds 1 to 3 seconds per decision. A local model on the Pi 5 responds in under a second but reasons less effectively about complex sequences. For a car moving at walking speed through an obstacle course, cloud latency is acceptable. For anything faster, local models or pre-scripted fallback behaviors work better.

Ultrasonic sensors (HC-SR04, around $3 each) can supplement the camera for reliable distance measurements. Mount one at the front and the agent gets a numeric distance reading instead of relying solely on image analysis.

Every OpenClaw command execution produces logs: the instruction, the generated code, the execution output, and any errors. For a physical project like an RC car, these logs become your debugging tool and your project history.

What to log:

• Drive commands and their results (did the car actually turn, or did a motor stall?)
• Camera frames captured during obstacle detection
• Sensor readings if you added ultrasonic modules
• Agent reasoning traces that show why it chose to turn left instead of right

Local storage options:

The simplest approach stores everything on the Pi's SD card or USB drive. Create a dated directory for each session and dump logs and images there. This works for solo projects but creates problems when you want to review sessions from another device, share results with a collaborator, or compare runs across different days.

Cloud storage for collaboration:

For team projects, classrooms, or builds you want to document publicly, cloud storage makes the data accessible from anywhere.

Google Drive and Dropbox handle file uploads but provide no way to search inside log files or ask questions about past sessions. S3 is cheap and durable but requires custom tooling to be useful beyond raw file storage.

Fast.io workspaces handle both storage and querying. Upload drive logs, camera frames, and configuration files through the MCP server or REST API. Enable Intelligence Mode on the workspace and every file gets indexed automatically. You can search by content ("show me all sessions where the car detected an obstacle on the left side") or ask questions about your data with cited answers pointing to specific log files and images.

The free tier includes 50 GB of storage and 5,000 AI credits per month, no credit card required. That covers thousands of drive sessions worth of logs and camera frames. Five workspaces let you organize by project, vehicle, or experiment type.

For classroom or team settings, the ownership transfer feature is practical. A student or team member builds the car configuration, runs test sessions, and stores everything in a workspace. When the project is complete, they transfer ownership to the instructor or team lead while keeping access for reference.

Alternatives worth considering:

• GitHub repositories work well for code and small config files but handle binary images poorly
• Self-hosted Nextcloud gives full control but requires server maintenance
• A local NAS (Synology, TrueNAS) keeps data on your network without cloud dependencies

For a single car on your desk, a USB drive is fine. For a robotics club with five cars, a team iterating on obstacle avoidance algorithms, or a classroom comparing student builds, a searchable workspace saves the time you would spend hunting through folders of timestamped log files.