Robotics testbed
WYZECAR
A browser-operated perception-to-control platform for vision autonomy experiments.
YOLOv8 perception
ROS2 control graph
ESP32 motor bridge
Browser operator UI
01 / Scope
What I owned
System architecture, ROS2 nodes, perception integration, browser controls, embedded motor interface, and tuning.
Problem
Turn a small RC platform into a controllable autonomy testbed with live video and person-following behavior.
Built
Integrated YOLOv8 perception, ROS2 control plumbing, browser-based WASD control, live video, an ESP32 motor interface, and a visual-servoing controller.
Outcome
A robotics platform that makes the full perception-to-control loop inspectable and tunable from a browser.
Engineering constraints
The conditions that
shaped the system.
Perception, video, and controls share limited edge-compute resources.
Loss of detection or browser connectivity must not leave stale drive commands active.
The platform needs a manual mode for safe tuning before autonomous behavior is enabled.
02 / Key decisions
Tradeoffs made explicit
Manual control first
Browser WASD control provides a safe commissioning path before closing the person-following loop.
Separated ROS2 responsibilities
Perception, following, motor control, and web presentation remain independent nodes with inspectable boundaries.
Embedded bridge
The Linux compute module owns autonomy while the ESP32 handles deterministic motor and steering commands.
03 / Under the surface
Architecture
- Camera and YOLOv8 perception node
- Visual-servoing follower with smoothing and velocity feedforward
- Browser video and WASD command surface
- I2C bridge to ESP32 motor control
Validation
- Published source reviewed at commit d669b88 on September 4, 2026
- Firmware includes a command watchdog and motor-stop handler
- Browser implements WASD, key-release, and focus-loss handling
- Source inspection is not a measured field trial or safety certification
- Python
- YOLOv8
- ROS2
- DART-MX95
- ESP32
- OpenCV
04 / Result
Shows the robotics loop end-to-end: perception, control, hardware interface, operator UI, and field iteration.
Inspect the sourceEVIDENCE & BOUNDARIES
What this work demonstrates.
Published commit d669b88 exposes the complete software path: person detection, visual servoing, motor-command translation, and firmware. Each boundary can be inspected independently.
One tightly coupled loop, or separate perception and control nodes?
- Decision
- Use separate ROS2 responsibilities for detection, following, web controls, and the motor bridge.
- Tradeoff
- Independent nodes make the pipeline inspectable, but require explicit command freshness, loss-of-target handling, and careful end-to-end commissioning.
Scope & limitations
No published field benchmark or automated test result is available. The firmware motor-stop flag is cleared by a subsequent drive command; it is not a latched safety interlock. The image is a CAD rendering, not proof of an autonomous run.
- System architecture
The boundaries between perception, following, motor control, and firmware.
- Visual-servoing controller
Proportional control, smoothing, and velocity feedforward—not a full PID controller.
- Firmware command handling
Watchdog and stop-command implementation, including its non-latching behavior.