Two brains, two jobs, one robot
Real robot architectures are rarely built around a single computer doing everything, they're built around a deliberate split between 'high-level' and 'low-level' compute, and understanding this split is the key to understanding why the MCU and SBC discussed earlier coexist rather than compete. High-level compute, typically an SBC running Linux (often with ROS on top), handles perception, planning, and decision-making: processing camera and lidar data, running SLAM or object detection, planning a path, deciding what the robot should do next. These tasks are computationally heavy, benefit from a rich software ecosystem, and can tolerate small timing variances without real consequence.
Low-level compute, typically one or more MCUs, handles motor control, encoder reading, and safety interlocks: the things that must happen on a strict, unwavering schedule and that must keep functioning correctly even if the high-level computer crashes, hangs, or is busy running a slow neural network. This is a deliberate redundancy, not an oversight. If the SBC locks up mid-inference, a well-designed low-level MCU should still be able to notice a missing heartbeat message and safely stop the motors, rather than the robot continuing to execute the last command it received forever.