What you will learn
  • Separate perception from low-level motor control.
  • Use short-lived motion permission.
  • Explain why vision alone is not a collision safeguard.
  • Test loss of camera, communication and distance information.

Before you begin

Complete a motor-driver rover and image detection before combining them.

Let AI advise a controller with its own limits

The first useful AI car is not a miniature self-driving road vehicle. It is a supervised floor robot whose behavior you can describe precisely. Our goal is to move forward briefly in a controlled clear area, and suppress that movement when the computer detects a person in view.

The trained pedestrian detector runs on a laptop or Raspberry Pi. The Arduino independently measures front distance, expires commands and drives the motor-controller inputs. A model cannot override those conditions. This separation lets you replace a detector while preserving the electrical and timing rules that bound motion.

The model is not a human-safety sensor. Missing a person is possible, so no person or pet belongs in the robot's test enclosure. Use printed test images or test detection while the wheels are raised. The AI demonstrates a decision input; the supervised environment, independent switch and distance interlock keep that experiment bounded.

Camera → computer: person detector → motion request
                                        ↓ USB
Distance + stop button → Uno interlocks → driver → motors
                                ↑ repeated sensing

Use the reference rover and test its stop conditions

Use the complete pin map in the rover kit guide and upload rover_bridge.ino, saved in a folder named rover_bridge. This firmware differs from the LED bridge. Download bridge.py alongside the host script. Install pyserial in your Python environment and select the actual USB port.

The Uno R3 connects by USB to the computer or Raspberry Pi. Driver PWMA/AIN1/AIN2 connect to D5/D7/D8; PWMB/BIN1/BIN2 to D6/D9/D10; STBY to D4 with a 10kΩ pull-down. The left motor uses AO1/AO2 and the right uses BO1/BO2. HC-SR04 TRIG/ECHO use A0/A1. A momentary button connects D2 to ground. All grounds join. Driver VCC and the ultrasonic module use Uno 5V; switched motor-pack positive goes only to driver VM.

USB powers logic; an enclosed switched four-AA alkaline pack supplies motors. Never power motors from GPIO or connect the motor pack to Uno 5V. Pi power remains separate. Turn all supplies off while wiring. The reference motors are Pololu low-power 6V #992, paired with carrier #713; substituting a motor requires checking its stall current against the driver's usable current, not merely its voltage.

With wheels raised, verify that FORWARD turns both wheels forward, STOP stops them, and a single movement expires after 250 milliseconds. An invalid or closer-than-25cm range reading prevents motion. The D2 button latches a halt until reset. Confirm each condition and USB disconnection before floor testing. The physical motor-power switch is the independent stop. The front sensor cannot see stairs or side obstacles; use a clear, enclosed floor area and low speed. Measure actual stopping distance before choosing a shorter clearance.

PartRole
Uno R3 + USB cableMotor watchdog and distance interlock
TB6612FNG carrier #713Two motor power channels
Two LP 6V gearmotors #992, wheels, chassis and casterSmall differential-drive rover
HC-SR04, button, 10kΩ resistor, wiresFront distance and stop controls
Switched enclosed four-AA packSeparate low-voltage motor supply
Computer or Pi with suitable USB supplyPerception and decisions

Observe while stopped, then permit a short movement

Download vision.py and install OpenCV in the computer's Python environment. Mount a supported USB webcam securely on the chassis. Keep the original image test working before feeding camera frames to the detector. If a Raspberry Pi rides on the robot, secure its power supply and cables so they cannot fall into a wheel.

The following program stops before each perception pass. That choice avoids continuing to move while a potentially slow model is thinking. A clear model result only permits a short forward pulse, and the Arduino may still reject it if the range sensor sees an obstacle or fails. After a blocked response, investigate the cause; do not bypass the check to make the demo move.

A camera buffer can contain an older frame. The stop-before-observe pattern reduces risk but does not establish a measured freshness guarantee. For an advanced version, record capture timestamps from the camera stack and reject observations outside a tested age budget. Never treat a recent inference-completion time as the image-capture time.

Python
import cv2
from bridge import Bridge
from vision import people

camera = cv2.VideoCapture(0)
try:
    with Bridge('/dev/ttyACM0') as board:
        for step in range(10):
            board.send('STOP')
            ok, frame = camera.read()
            if not ok:
                raise RuntimeError('Camera failed; remain stopped')
            detections = people(frame)
            print('Step', step, 'person boxes:', len(detections))
            if detections:
                break
            board.hold('FORWARD', 0.2)
finally:
    camera.release()

Every iteration begins with STOP. A failed frame raises an error, while a person detection ends the demonstration. Only a valid frame with no accepted detection requests a200ms forward action. hold refreshes short leases and finishes with STOP; the board's independent250ms watchdog remains active. Ten iterations bound the overall experiment.

Expected result: At most ten logged perception checks and short movement pulses. Any person detection, blocked command, camera failure or exception ends motion. Physical travel distance is not specified; measure it on your own chassis.

Evaluate the complete loop

Begin with motors disconnected, then wheels raised, then a clear floor enclosure. At each stage inspect a success case and a failure case. Unplug the host USB cable, remove the front sensor's echo connection with power off before the next test, and press the stop button. These tests have different expected causes but the same expected motor state: off.

Record time spent capturing, inferring and moving. A model with higher benchmark accuracy may make the robot worse if each decision arrives too slowly. Our stop-and-observe behavior is deliberately conservative and may look jerky. Smooth autonomous movement requires a separate design for freshness, scheduling and control; increasing the timeout is not a substitute.

The front sensor does not establish full-body clearance. Turning sweeps the chassis sideways, and no sensor here detects a drop-off. Keep the scope on a level controlled surface. If your measured stopping distance exceeds the available margin, lower speed or increase clearance before any further floor trials.

Important terms

Interlock
A condition that independently prevents an action.
Command lease
A short period during which a movement request remains valid.
Low-level control
The direct management of motor signals and sensor timing.
Freshness
How recently an observation was actually captured.
Stall current
Current drawn when a powered motor cannot turn.

Mini project: Make a stop-condition checklist

  1. Run detection with motor power disconnected.
  2. Test command expiry, obstacle rejection and the halt button with wheels raised.
  3. Measure the distance traveled by one pulse in a clear enclosure.
  4. Log why each test stopped and compare the result with the firmware's intended behavior.

Common mistakes and debugging

  • Sending a command once and expecting continuous safe motion: the lease intentionally expires.
  • Using AI as the only obstacle detector: the model can miss people and objects.
  • Increasing speed before testing stops: physical stopping distance changes with the build.

Independent challenge

Replace the fixed ten iterations with a maximum elapsed-time limit as well, ensuring both limits independently end with STOP.

Check your understanding: 10 questions

  1. Where does image inference run?

  2. Why stop before each inference?

  3. Can a clear vision result override a close obstacle?

  4. Does inference completion prove the camera frame is fresh?

  5. What is the independent physical shutdown?

  6. In your own words, what does “Interlock” mean?

  7. In your own words, what does “Command lease” mean?

  8. In your own words, what does “Low-level control” mean?

  9. In your own words, what does “Freshness” mean?

  10. In your own words, what does “Stall current” mean?

Quiz answers

Reveal all 10 answers after your attempt
  1. On the computer or Pi, while the Uno controls motors and distance interlocks.
  2. The model may be slow, so the rover should not continue moving during that delay.
  3. No. The Arduino's distance check independently blocks motion.
  4. No; the camera may have buffered an older frame.
  5. The switch that disconnects the motor supply.
  6. A condition that independently prevents an action.
  7. A short period during which a movement request remains valid.
  8. The direct management of motor signals and sensor timing.
  9. How recently an observation was actually captured.
  10. Current drawn when a powered motor cannot turn.

Summary

An AI-controlled rover is a layered system. Perception proposes a behavior, but a small controller bounds motion through timing, sensor checks and stop inputs. Test those boundaries before judging the system by how smoothly it moves.

Continue learning

Build a sensor dashboard next to inspect measurements and model behavior before adding more autonomy.

Choose a connected learning path

Sources and further reading

Prepared 2026-09-18. Editorial draft. Primary documentation checked; hardware, camera and audio behavior still require a physical test.