VISION
CART.

A Raspberry Pi 3B with 1 GB RAM and no GPU had to run perception, browser diagnostics, and wheel control. Camera-only sensing kept cost, power, and integration effort manageable for the low-speed indoor prototype. LiDAR and radar were considered, but did not address a V1 failure mode that justified their added complexity.

Camera placement traded reduced chassis occlusion against keeping a nearby person large in the frame. The 640 × 480 calibration gave a 65.9° horizontal field of view and 0.34 px reprojection error; placement was then evaluated physically.

The initial shared supply path reset the Pi when the servos started, turned, or reversed. I separated the 5 V compute rail from dual approximately 6 V servo rails, retaining a common ground through WAGO distribution. The final platform operated stably after this change.

My debugging work also covered PWM jitter, overheating, camera issues, and repeated Pi failures. The dashboard supported camera streaming, manual control, diagnostics, and data collection.

The backward-facing camera estimates distance and bearing. A compact behavior-cloned policy maps that state to left/right wheel commands. Perception, velocity estimation, deadband logic, and wheel actuation remain geometric or rule-based stages; only the policy was learned.

The documented data collection contains 6,748 frames over 449.5 seconds, with 93.5% ArUco lock. Training used 1,296 balanced rows and mirror augmentation for 2,592 samples. Policy inference ran at 5 Hz on the Pi.

These figures describe the collected dataset, calibration, and prototype inference. They do not establish reliable operation across unfamiliar environments.

This is a research prototype for controlled indoor use. The next measurements are servo current, rail voltage, Pi temperature, wheel speed, command-to-motion latency, and tracking loss versus distance and lighting. Those measurements would determine whether to prioritize sensing, state estimation, or hardware reliability.