PyTorch and Arduino UNO power an end-to-end self-driving toy car

The system splits work the way a production vehicle does: a heavier AI process runs on a PC (standing in for a vehicle's AI SoC), while a microcontroller (the Arduino UNO, standing in for the vehicle-control MCU) drives the motors. The link between them here is Bluetooth via an HC-05 module rather than automotive CAN or Ethernet. The code ships as four Python files plus one Arduino sketch, and the model is a scaled-down version of NVIDIA's PilotNet that outputs one of three actions: forward, left, or right.

The write-up spends much of its space on pitfalls the author hit. Latency stacks up at every seam — camera, Wi-Fi, inference, Bluetooth, Arduino — and two causes are easy to miss: OpenCV buffering old frames, and the blocking pulseIn() call on the ultrasonic sensor, whose default timeout can stall the whole control loop unless shortened. The PulseIn timeout is set to 25ms. The author also notes that changing room lighting between data collection and driving degrades the model, and that ColorJitter during training helps.

The stakes here are less about this particular toy than about the pattern it demonstrates: pushing AI decisions across a laggy link to physical motors surfaces the same structural difficulty whether the vehicle is palm-sized or full-scale. The author's stated principle is that placing failsafes on a lower-level microcontroller, independent of the AI, holds for both. What this hinges on for anyone replicating it is likely the quality and balance of the collected driving data, since a model can post good accuracy numbers while still failing to steer through a curve. The article states the parts cost a few thousand yen.