Computation and the Software Stack

Between the sensor data arriving and the motor command going out, a robot must compute. The hardware that runs those computations and the software layers that organize them are collectively the robot's computational subsystem. Getting this subsystem wrong does not just produce slow code — it produces a robot that misses critical deadlines, behaves unpredictably under load, or fails in ways that are nearly impossible to reproduce or debug. Understanding the computational stack from silicon to middleware is what separates a robot that works on a demo day from one that works reliably in the field.

Onboard Compute Hardware

The right compute hardware depends on the robot's task profile: how much sensor data must be processed, how fast decisions must be made, and how much power is available. Microcontrollers (MCUs) are single-chip computers with a processor, memory, and peripheral interfaces on one die. They run at tens to hundreds of MHz, consume milliwatts to hundreds of milliwatts, and operate without an operating system — code runs in a bare-metal or RTOS (real-time OS) environment. Arduino, STM32, and the Raspberry Pi RP2040 are examples. MCUs are ideal for low-level motor control, sensor reading, and safety-critical tasks that demand deterministic timing. Single-board computers (SBCs) like the Raspberry Pi 5 or NVIDIA Jetson Orin Nano run a full Linux OS on a processor comparable to a mid-range smartphone. They support Python, ROS 2, machine learning inference, and USB/Ethernet connectivity. Power draw ranges from 5 W to 30 W. They are the backbone of most research and mid-range commercial robots. FPGAs (Field-Programmable Gate Arrays) are reconfigurable logic arrays that implement custom digital circuits. They offer deterministic timing down to nanoseconds and can process sensor streams (lidar returns, camera pixels) with far lower latency than any software-based approach. The trade-off is development complexity — FPGA firmware is written in hardware description languages (VHDL, Verilog) and is hard to debug. GPU-equipped edge accelerators (NVIDIA Jetson AGX Orin, Qualcomm Snapdragon) combine a CPU with a powerful GPU or neural-network accelerator on the same board. Running deep-learning perception models (object detection, depth estimation) in real time on a robot requires this class of hardware. Power draw runs 15–60 W, making it feasible only in larger, well-powered robots.

Real-Time Operating Systems

A standard operating system like Linux schedules processes to maximize throughput and fairness — it will pause a running process to give CPU time to another process based on priority policies that are not temporally precise. This is fine for a web server, where a 10 ms scheduling jitter is invisible. It is catastrophic for a motor controller, where a missed 1 ms update deadline can cause a joint to exceed its safe velocity. A real-time operating system (RTOS) provides guaranteed scheduling: a task declared to be highest priority will receive CPU time within a bounded, deterministic latency called the scheduling jitter. FreeRTOS, Zephyr, and VxWorks are widely used RTOSes in robotics. PREEMPT-RT is a Linux kernel patch that converts standard Linux into a soft real-time OS — sufficient for many robotics applications that need near-real-time guarantees without the full complexity of a hard-RTOS. Real-time systems are categorized as hard or soft. A hard real-time system fails if any deadline is missed — automotive airbag controllers, fly-by-wire aircraft systems, and safety monitors on industrial robots are hard real-time. A soft real-time system degrades gracefully when deadlines are occasionally missed — a navigation planner that sometimes takes 12 ms instead of 10 ms produces a slightly jerky trajectory but does not crash the robot.

Robotics Middleware: ROS 2

Writing every communication pathway between a robot's software components from scratch would be a massive engineering burden. Robotics middleware provides a standardized communication infrastructure. ROS 2 (Robot Operating System 2) has become the dominant open-source middleware in research and commercial robotics. In ROS 2, a robot's software is decomposed into nodes — individual processes, each performing a focused task. A lidar driver node reads from the lidar hardware and publishes sensor_msgs/LaserScan messages. A localization node subscribes to those messages and publishes a nav_msgs/Odometry estimate. A path planner subscribes to the odometry and publishes geometry_msgs/Path messages. A motor controller node subscribes to path commands and drives the actuators. Each node can be developed, tested, and restarted independently. Nodes communicate through three mechanisms: Topics are asynchronous publish/subscribe channels (like a news feed). Services are synchronous request/response calls (like a remote function call). Actions are long-running tasks with feedback and cancellation support (like 'navigate to waypoint X and report progress'). ROS 2 is built on top of DDS (Data Distribution Service), an industry-standard middleware protocol also used in autonomous vehicles, submarines, and medical devices. This gives ROS 2 configurable quality-of-service: a safety-critical message can be delivered reliably and in order, while a camera image stream may tolerate some dropped frames.