Fast Robots: Sensor Fusion and Autonomous Navigation

Problem

Make a small, cheap robot do fast, precise autonomous maneuvers — the regime where you can't just drive slowly and average the sensor noise away. The robot has to sense, estimate, decide, and act on a microcontroller, with sensors that update slower than the dynamics it's trying to control.

Constraints

• All onboard compute is a SparkFun Artemis (Cortex-M4F) — no companion computer during runs.
• Time-of-flight distance sensors sample far slower than the robot closes distance at speed; the IMU drifts.
• BLE is the only telemetry channel, so debugging means designing your own logging protocol.
• Consumer RC-car hardware: motor deadbands, battery sag, and real friction, not simulation.

Approach

The build progressed as an integrated stack rather than isolated demos: BLE communication and onboard telemetry first, then sensor characterization, then PID control on orientation and wall-approach, then a Kalman filter fusing the ToF readings with a fitted dynamics model — which lets the robot predict distance between slow sensor samples and brake later than raw sensing would allow. On top of that: high-speed stunts (a drift turn and a flip), an inverted-pendulum balance, and grid-based Bayes-filter localization from ToF scans feeding waypoint navigation.

Tuning that PID is the part people picture as turning three knobs until it looks right. It is really a chain of trades. Raise Kp and the steady-state error shrinks but never closes — drop Ki to zero and push Kp to the top to see the gap that is left. Add Ki and it closes, at the price of overshoot. And because a real actuator runs out of authority, Ki also buys windup: the integral keeps accumulating error the motor cannot act on, so the loop sails past the target before it recovers. Turn anti-windup off, put Ki near 20, and watch the overshoot go from a few percent to roughly a third.

That plant is a generic first-order lag — the shape a motor loop takes — not this robot's measured dynamics. I am not going to publish numbers I did not fit. What carries over is the shape of the trade, which is the one I tuned against on hardware, where battery sag and motor deadband move it run to run.

Why it's technically hard

The interesting problems are all about acting faster than you can sense. The Kalman filter isn't academic here — without it, the robot literally cannot stop in time. The Bayes filter has to work with a coarse pose grid and a noisy beam sensor model, and every gain was tuned on real hardware where latency, noise, and battery state change run to run.

Result

Full lab-by-lab reports with data and video live on the Fast Robots report site.