Engineering Deep-Dive · Competition Line Following
RoboRaptor: The Engineering Behind a Modular Competition Line-Follower
A configurable platform is only as good as the engineering you can do with it. In this deep-dive we get into the maths — how sliding the sensor changes the robot's dynamics, how motor RPM maps to real ground speed, why the bus you choose (SPI vs I²C vs UART) decides your top speed, and which control algorithms actually win races.
RoboRaptor was built to be reconfigured rather than replaced: the same chassis introduces a student to PID control and, piece by piece, becomes a podium-grade competition machine. But modularity is more than a marketing word — each axis is a real engineering lever with measurable effects on how the robot behaves. This article is for the teams, instructors, and researchers who want to understand why, not just what. We'll keep the assumptions explicit and the maths honest.
Axis 1 · The Brain
One socket, two worlds
A single swappable socket accepts two very different controllers. The Kypruino / Robo Core+ (ATmega328P) is Arduino-compatible and ideal for teaching fundamentals — it comfortably runs a weighted-centroid estimator and a PD loop at a few hundred Hz. The ESP32-S3 RoboBlocks brain is a dual-core step-change in compute with Wi-Fi for live telemetry, enough headroom for kilohertz control loops, gain scheduling, track-learning, and even model-predictive control. Same mechanics, two completely different ceilings.
Axis 2 · The Motor-Driver Bay
Three drivers — and three different control philosophies
The driver lives on a swappable module, and the three options aren't just "more current" — they represent three different ways of talking to the motors, which matters enormously at speed (more on buses below).
- DRV8830 — included. A compact, I²C-controlled brushed driver. Simple, low pin-count, and perfect for learning and moderate speeds: you set a voltage/direction over two wires and go.
- DRV8874 — upgrade. A rugged, high-current PWM-driven driver with integrated current sense. When you need raw power delivered with minimal latency, direct PWM is hard to beat.
- TB9053FTG — top tier. An automotive-grade, SPI-controlled driver with full diagnostics, current sensing, and protection. The brain can both command and interrogate the motor stage every control cycle — the foundation for fast, self-protecting closed-loop control.
Notice the progression: I²C → PWM → SPI. As you climb the competition ladder, you literally move the motor stage onto faster, more deterministic interfaces. We'll quantify why that matters shortly.
Axis 3 · Motors & Tyres
Trade torque for speed — then add grip to use it
Replaceable N20 6 V gear motors come in 300, 500, and 1000 RPM. Lower RPM means higher torque and control (tight technical tracks); higher RPM means top speed (open layouts). Pair them with optional silicon-grip tyres — and as we'll show in the cornering maths below, grip (the friction coefficient μ) sets a hard ceiling on how fast you can take a corner regardless of motor power.
Axis 4 · Sensor Geometry — the maths
Sliding the sensor changes the robot's physics, not just its code
RoboRaptor's front sensor PCB slides forward and back along the chassis, changing the distance d between the reflective array and the drive axle. This isn't a cosmetic adjustment — it directly reshapes the closed-loop dynamics. Here's the derivation.
Setup. Model the robot as a differential drive moving at constant forward speed v. Let y be the lateral offset of the axle from the line and θ the heading error (robot heading vs. the line's tangent). For small angles:
The sensor sits a distance d ahead of the axle, so the lateral error it actually measures is the axle offset plus a heading term:
This is the key insight: the sensor naturally blends position (y) with heading (θ), and the weight on heading is exactly d. Now apply simple proportional steering on the sensor error, ω = −K·e, and substitute:
The characteristic equation of this second-order system is:
Matching the standard form s2 + 2ζωns + ωn2 gives the two numbers that govern the whole response — the natural frequency and the damping ratio:
What this tells you:
- Damping is linear in d. Slide the sensor out and ζ rises proportionally — the robot becomes smoother and more stable (more "lookahead"). Slide it in and ζ falls — sharper, more reactive, but prone to oscillation. Concretely: if at d = 50 mm your robot tracks at ζ ≈ 0.35 (visibly oscillatory), moving the array to d = 100 mm doubles it to ζ ≈ 0.70 — the textbook well-damped response — with no code change.
- Speed fights damping. Since ζ ∝ 1/√v, doubling speed (e.g. 1.3 → 2.6 m/s) cuts ζ by √2. To recover the same damping you increase d by √2 (≈ +41%). That's the engineering rule behind "push the sensor forward as you go faster."
- Critical damping target. Setting ζ = 1 gives the required lookahead d = 2√(v/K) — useful as a starting point before fine PID tuning.
- Preview time. A complementary view: the sensor previews the track by τ = d/v seconds. Holding preview time constant means scaling d with v. Either way, the conclusion is the same — faster tracks want the sensor further out.
Assumptions: small-angle, constant speed, no wheel slip, pure proportional steering. Real robots add sensor lag, discrete sampling, and actuator limits — but the scaling laws (ζ ∝ d, ζ ∝ 1/√v) hold remarkably well in practice and make the adjustable sensor a genuine, repeatable tuning knob.
Speed
From RPM to metres per second
Ground speed is just the wheel's circumference times its rotational rate. With wheel diameter D and output speed N (RPM):
Worked example assuming a 50 mm wheel (free-running, no slip — real on-track speed is a little lower under load):
| Motor | Ground speed | ≈ km/h | Best for |
|---|---|---|---|
| 300 RPM | 0.79 m/s | 2.8 | tight, technical tracks |
| 500 RPM | 1.31 m/s | 4.7 | balanced / mixed |
| 1000 RPM | 2.62 m/s | 9.4 | fast, open layouts |
Speed scales linearly with wheel diameter: fit a larger wheel and top speed rises proportionally — but torque at the contact patch (and thus acceleration) falls by the same factor. Yet another trade-off the modular chassis lets you make. (Swap in your exact wheel diameter to get precise figures.)
The Technology · Communication
Why the bus you choose sets your top speed
At competition pace your control loop is racing the track. The spatial resolution of your control — how far the robot travels between corrections — is simply speed divided by loop rate:
At 2.62 m/s, a 1 kHz loop corrects every 2.6 mm; a sluggish 200 Hz loop only every 13 mm — an eternity when you're trying to stay centred on a line a few millimetres wide. High speed demands a high loop rate, and a high loop rate demands that sensor acquisition and motor commands cost almost nothing. That is where the bus matters.
Reading the 8-sensor array. RoboRaptor digitises all eight QRE1113 sensors through an MCP3008 SPI ADC. SPI is full-duplex with a dedicated clock and chip-select — no addressing overhead. Each channel is ~18 clock cycles; at a 1.35 MHz SPI clock that's roughly 13 µs per channel, so the entire array reads in about 0.1 ms (and well under 50 µs near the converter's clock ceiling). The same eight channels on a typical 400 kHz I²C ADC — with start/stop, 7-bit addressing, and per-byte ACKs — run on the order of 0.8–1 ms. That's a 10× difference, and it's the difference between a sensor read that fits inside a 1 kHz loop and one that consumes the entire budget.
| Bus | Typical clock | Duplex | Overhead | Role on RoboRaptor |
|---|---|---|---|---|
| SPI | 1–20+ MHz | Full | None (CS line) | Sensor array (MCP3008) & TB9053FTG motor control — the hot path |
| I²C | 0.1–1 MHz | Half | Address + ACKs, clock-stretch | Config & low-rate sensors (ToF via TCA9548A mux); DRV8830 basic driver |
| UART | ~0.1–1 Mbps | Full (async) | Framing, no shared clock | Debug, logging, telemetry — never the control loop |
Two more reasons SPI wins the hot path. First, determinism: SPI's shared clock means fixed, jitter-free timing, whereas I²C clock-stretching/arbitration and UART async framing add jitter that corrupts your derivative term. Second, diagnostics: an SPI driver like the TB9053FTG returns fault and current data in the same transaction it receives commands — so the brain can run torque-aware, self-protecting control within microseconds. UART is fine for streaming logs to your laptop; I²C is ideal for one-time configuration and low-rate distance sensing; but the tight loop that keeps you on the line at 2.6 m/s belongs on SPI.
The Software
The algorithms that actually win line-following races
1 · Estimate the line position (weighted centroid). Don't treat the eight sensors as on/off. Compute a continuous position as a weighted average of the active sensors, giving sub-sensor resolution:
where xi is each sensor's fixed position and wi its (calibrated, background-subtracted) reading. When all sensors read "no line," hold the last sign of e to recover gracefully.
2 · PID — and usually just PD. The workhorse. Steering command:
For line following the integral term is usually tiny or zero (there's little steady-state error and it invites windup). Most fast robots run a clean PD loop with the derivative computed on the measurement and low-pass filtered to reject sensor noise. Remember the geometry section: your physical sensor distance d already injects heading (a derivative-like term), so hardware and Kd work together.
3 · Speed profiling & feedforward. The single biggest lap-time win after PD: don't drive at constant speed. Slow into curvature, accelerate on straights. A simple, effective law scales base speed by the tracking error or estimated curvature:
4 · Respect the friction limit. No controller beats physics. The maximum speed through a corner of radius r is set by tyre grip μ:
For a 0.30 m-radius corner: standard tyres at μ ≈ 0.9 cap you at ≈ 1.63 m/s; grippier silicon tyres at μ ≈ 1.2 raise that to ≈ 1.88 m/s — about 15% faster through every corner, compounding over a lap. This is the direct, quantified payoff of the silicon-grip upgrade.
5 · Gain scheduling & look-ahead (pure pursuit). From our dynamics result, the ideal gains and sensor lookahead depend on speed. Schedule Kp/Kd (or physically reposition the sensor) as v changes to hold a target ζ. Pure-pursuit steering toward a look-ahead point is the algorithmic twin of moving the sensor forward.
6 · Track learning (the championship move). On lap one, log encoder distance and heading to build a curvature map of the track. Then compute an optimal speed profile — full vmax on straights, friction-limited through each corner — and replay it on subsequent laps. This two-pass approach, plus a Kalman/complementary filter fusing encoders and the sensor array for robust state estimation, is what separates the podium from the pack. It needs compute and memory — which is exactly what the ESP32-S3 brain brings, optionally extended to full model-predictive control.
Rule of thumb by brain: ATmega328P → centroid + PD + simple speed scaling; ESP32-S3 → add gain scheduling, track-learning, Kalman estimation, telemetry-based tuning, and MPC.
Power & ecosystem
Headroom to perform, room to grow
RoboRaptor runs on a 2S Li-ion system with USB-C charging, protection, and a regulated buck rail. The extra headroom over a single cell keeps motor and logic voltage stable under hard, sustained load — and voltage sag mid-run is a hidden cause of inconsistent lap times. On the electronics side, RoboRaptor is designed around the upcoming RoboBlocks ecosystem (launching 2026), our snap-together modular hardware platform, which will unlock even more configurable ways to extend the robot.
Its own interactive web app
RoboRaptor ships with a dedicated browser-based app — guided projects, live sensor visualisation, and tuning tools. Watch your centroid estimate and PD response in real time, calibrate the array, and progress from a first line-follow to a learned, speed-profiled competition run.
RoboRaptor at a glance
| Axis | Included (default) | Options |
|---|---|---|
| Brain | Kypruino / Robo Core+ (ATmega328P) | ESP32-S3 RoboBlocks brain |
| Motor driver | DRV8830 (I²C) | DRV8874 (PWM) · TB9053FTG (automotive SPI) |
| Motor RPM | N20 6 V (choose at checkout) | 300 · 500 · 1000 RPM |
| Tyres | Standard | Custom silicon-grip |
| Sensor geometry | Adjustable front sensor PCB | Slide forward / neutral / back |
Pre-order RoboRaptor — and see it in person
The RoboRaptor Basic Kit is open for pre-order now at €299.99, with €50 off for early supporters. First units ship late summer 2026; pre-order buyers get priority from the first production run.
We'll also be showing RoboRaptor live at Robotex Cyprus 2026 — come watch it run and talk through the build that suits your team.
Pre-Order RoboRaptor →Engineering figures use stated assumptions (e.g. 50 mm wheel, small-angle dynamics, representative bus clocks) and are intended to illustrate the relationships; substitute your exact parameters for precise values. RoboRaptor is shown as a pre-production preview; specifications may change. The RoboBlocks ecosystem is in development and scheduled to launch in 2026.