Why Does This Robot Need Two Brains?

A genuine question I had before I understood the answer: the Pi already runs Linux and ROS2. Why bolt on a whole separate microcontroller too?

Here's the question I actually had, unfiltered, the first time I looked at MentorPi's internals: the Raspberry Pi 5 is already running full Linux and a complete ROS2 stack — it's a genuinely capable computer. Why does this robot also need a separate STM32-based controller board sitting right next to it? Doesn't the Pi already have more than enough horsepower to just... handle the motors and servos directly too? It felt, honestly, like redundant hardware — two computers where one seemed like it should do.

Trying the Thought Experiment: What If the Pi Just Did It All?

The way I actually worked through this wasn't by reading an architecture explanation first — it was by imagining what would actually happen if the Raspberry Pi read motor encoder pulses directly and computed PID corrections itself, on its own schedule, the way I'd naively first assumed it could.

Linux, running on the Pi, is not a real-time operating system. It's an excellent general-purpose OS, but its scheduler is fundamentally designed around fairness and throughput across many competing processes, not around guaranteeing that any specific task runs at a specific moment with sub-millisecond precision, every single time, no exceptions. Now imagine that same Pi trying to read motor encoder pulses at high frequency and recompute a PID correction every 10 milliseconds, while also running ROS2 nodes, processing camera frames, and doing whatever else the robot's higher-level logic needs at that exact moment. If some other process — a camera frame decode, a filesystem operation, anything — happens to grab the CPU for even a few extra milliseconds right when the motor control loop needed to run, that loop simply doesn't run on time. The result, if you actually let this happen in practice, is exactly what you'd predict once you think it through: jerky, inconsistent motor behavior, not because the PID math is wrong, but because the timing around it isn't guaranteed by anything.

What RRC Lite Is Actually For

This is the point where the separate STM32F407 board stopped looking redundant and started looking like the obvious answer to a problem I'd just talked myself into understanding. RRC Lite isn't running Linux, and it isn't running anything resembling a general-purpose, multi-tasking operating system at all — it's running a dedicated real-time loop with exactly one job: read encoders, compute PID, output PWM to motors and servos, every 10 milliseconds, with nothing else on the entire chip competing for that timing slot. No other process can interrupt it, because there is no "other process" in the sense a Linux system has one — there's just this one loop, running on schedule, every time, because nothing else on this chip is asking for the CPU's attention at the same moment.

That's the actual answer to my original question: the Pi could theoretically do the motor math. It could never guarantee doing it on time, consistently, while also doing everything else it's asked to do — and for a physical motor spinning a real wheel, "the correction usually arrives close to on time" is a meaningfully worse guarantee than "the correction arrives exactly on schedule, always."

Two Brains, Two Genuinely Different Jobs

Once this clicked, the division of labor stopped looking like redundant hardware and started looking like an actual, sensible split of two genuinely different kinds of work. The Raspberry Pi 5 handles the "slow but complicated" side — running the full ROS2 stack, processing camera frames, running a YOLOv5 model for perception, making higher-level decisions about where the robot should go and what it should do next. RRC Lite handles the "fast but simple" side — keeping a motor at the correct commanded speed, holding a servo at the correct angle, reading the onboard IMU on a strict, dependable schedule — and reporting the results back up to the Pi over exactly the serial protocol I'd spent an earlier evening typing by hand, byte by byte: the same 0xAA 0x55-prefixed packet structure, quietly doing this job continuously in the background every time a ROS2 node on the Pi calls a clean service interface without a second thought.

"Slow but complicated" and "fast but simple" aren't just two convenient phrases — they map onto two genuinely different technical requirements that are difficult to satisfy well on the same piece of hardware at the same time. Complicated, flexible, general-purpose computation and hard real-time, unbreakable timing guarantees pull in different architectural directions, and splitting them onto two purpose-built pieces of hardware is a considerably more honest solution than trying to force one chip to be excellent at both simultaneously.

The Power Port That Suddenly Made a Different Kind of Sense

This is also the point where a detail from an earlier teardown afternoon — RRC Lite's dedicated 5V/5A power port, wired specifically to feed power back to the Raspberry Pi — stopped being just an interesting quirk and started looking like confirmation of the whole architecture. These two boards aren't loosely bolted together as two independent, coincidentally-adjacent computers. RRC Lite is quietly part of keeping the Pi powered in the first place, on top of everything else it's doing — which tells you these two pieces of hardware were designed from the start as genuinely interdependent halves of one system, not as a convenient way to have "extra compute lying around."

Two brains, deliberately built to be bad at each other's job — the Pi is not built for hard real-time guarantees, and RRC Lite is not built for running a full perception stack — and precisely because of that mismatch, put together, they cover the entire problem a robot like this actually has to solve. I walked in assuming one of the two boards was probably unnecessary. I walked out understanding that the robot doesn't really have two computers doing overlapping jobs at all. It has exactly one system, split cleanly down the middle between the part of the problem that needs to think carefully and the part that needs to never, ever be late.