BuzzRacer V2 — LiDAR Vehicle Control Board

A chassis-mounted control board for an autonomous RC car, integrating four LiDAR sensors, motor and steering control, power management, and Wi-Fi telemetry.

Technologies Used

Autonomous VehiclesArduinoLiDARAltiumPCB DesignEmbedded Systems
flowchart TB
    Battery["2S LiPo<br/>6.5–8.4 V"] --> Power["Power management<br/>5 V sensor rail"]
    Power --> Arduino["Arduino Nano 33 IoT"]
    Power --> Front["Front TF-Mini S"]
    Power --> Rear["Rear TF-Mini S"]
    Power --> Left["Left TF-Mini S"]
    Power --> Right["Right TF-Mini S"]

    Arduino --> Bus["Shared I²C bus<br/>400 kHz"]
    Bus --> Front
    Bus --> Rear
    Bus --> Left
    Bus --> Right

    Arduino --> Driver["TB67H451FNG<br/>3 A current limit"]
    Driver --> Motor["130 brushed motor"]
    Arduino --> Servo["Steering servo"]
    Arduino <--> WiFi["Wi-Fi / UDP telemetry"]
    WiFi <--> Host["Host computer"]

    classDef controller fill:#eef2f6,stroke:#8795a8,color:#263451
    classDef sensor fill:#edf4f4,stroke:#7f9999,color:#263451
    classDef power fill:#faf4e8,stroke:#b99a61,color:#263451
    classDef actuator fill:#f1eef5,stroke:#978aa7,color:#263451
    class Arduino,Bus,WiFi,Host controller
    class Front,Rear,Left,Right sensor
    class Battery,Power power
    class Driver,Motor,Servo actuator
⋮⋮

Table of Contents

Why I joined the project

I had wanted to design a small vehicle of my own for a long time. Through Nick and the DCSL lab, I finally had a real chassis, a research objective, and a set of constraints that could not be solved with loose breakout boards.

BuzzRacer V2 is a hardware platform for testing onboard localization on a closed track. Four one-dimensional LiDAR sensors face forward, backward, left, and right. The longer-term goal is to combine those distance measurements with a particle filter and sampling-based control methods.

What is on the board

An Arduino Nano 33 IoT reads the sensors and coordinates the car. Four Benewake TF-Mini S LiDAR modules share a 400 kHz I²C bus. A TB67H451FNG driver controls the brushed 130-size motor, with the high-current path designed for a 3 A limit, while a hobby servo controls steering. Wi-Fi and UDP carry commands and synchronized sensor data between the car and a host computer.

The board also replaces the Atomic AMZ chassis’s upper carbon-fiber deck, so its outline and mounting holes are structural constraints rather than decoration. The design had to clear the wheels, suspension, gears, and steering travel while staying below 100 × 100 mm.

Power and serviceability

The main source is a two-cell LiPo battery operating from about 6.5 to 8.4 V. Onboard conversion supplies the 5 V sensor rail, and voltage sensing exposes battery state to the control software. I also designed an alternative wired input for long debugging sessions. The intention is to switch between bench power and the battery without resetting the Arduino when the car is unplugged and placed on the track.

I used mostly 0805 components so the board could remain compact without becoming unreasonable to assemble or rework by hand. Early prototypes used two layers; after review, I moved the design from Eagle to Altium and produced a four-layer revision for more robust routing and grounding.

Design and fabrication log

The first summer board was useful for checking the chassis outline and through-hole placement. By September 9, I had rerouted the board, poured the ground planes, reviewed electrical-rule warnings, added reference labels, and prepared the design for fabrication. The October revision improved screw clearance and power routing and was ordered with assembly.

The first assembled tests were not clean. I resoldered the buck converter and several I²C connections, repaired the fourth LiDAR line, and labeled failed sensors instead of pretending every module worked. Those repairs confirmed that the car’s shared I²C bus and basic drive firmware were functional.

LiDAR configuration and measured rates

Each TF-Mini S needed a unique slave address before it could share the bus. The setup sequence was easy to get wrong: send the address command, switch the interface mode, save the setting, and wait one second for the save to take effect. A quick hardware check was to look for the sensor’s faint red emitter through its lens.

I wrote timing tests around the read loop and measured the aggregate read throughput under different sensor counts:

Active sensorsMeasured read rate
1697 Hz
2349 Hz
3232 Hz
4174 Hz

These are loop-level measurements from the prototype, not claims about the LiDAR’s independent ranging frequency. They were still useful: the near-inverse scaling showed the cost of sequential reads on one bus and helped set a practical synchronized update period. The running firmware currently takes a four-sensor snapshot every 20 ms, marks it invalid if any read fails, and applies a communication failsafe that stops the motor and centers steering after 100 ms without a valid command packet.

Next phase

The hardware work established a repeatable platform, but the research goal is not finished. The next phase is to improve connector and sensor reliability, validate current draw and motor limits, finish the embedded firmware, and use the four-direction range data for particle-filter localization. After that, the car can be evaluated by completed laps, lap time, and collisions rather than by whether individual components respond on a bench.

The lab source repository is not currently public, so I removed the old broken GitHub link. This page is based on my design notes, firmware tests, fabrication record, and the DCSL project brief.