Robot Software Architecture
The layers of robot software, sense-plan-act, what runs on a microcontroller and what on a computer, and how to budget compute and timing.
On this page
- The layers of robot software
- Sense-plan-act, reactive and hybrid designs
- What runs where: microcontroller, computer, cloud
- Timing and compute budgets
- Choosing the computer
- The link between computer and microcontroller
- Behavior: state machines and behavior trees
- Designing for failure
- Organizing the code
- FAQ
The layers of robot software
| Layer | What it does | Typical tools |
|---|---|---|
| Firmware | Reads encoders and sensors, drives motors, runs the fast control loops (1 kHz or more) and the safety limits | C/C++ on a microcontroller: Arduino, STM32, Pico, micro-ROS (see Embedded Systems) |
| Middleware | Connects programs, passes messages, logs data, manages time and coordinate frames | ROS 2 (see ROS 2 in Practice) |
| Perception | Turns sensor data into information: objects, maps, position | OpenCV, Point Cloud Library, neural detectors, SLAM (see Perception) |
| Planning and navigation | Decides where and how to move | Nav2 (mobile robots), MoveIt 2 (arms) |
| Control | Makes the robot follow commands accurately | ros2_control, PID, model-based controllers (see Motor Control) |
| Simulation | Tests all of the above without hardware | Gazebo, Webots, CoppeliaSim, Isaac Sim, MuJoCo (see Simulation) |
| Tools | Visualize, record and debug | RViz, rqt, rosbag, Foxglove, PlotJuggler |
- Languages: C++ for performance and Python for speed of writing: ROS 2 supports both and they mix. See Programming Languages.
- Operating system: ROS 2 runs mainly on Ubuntu Linux (also Windows and macOS with limits). A small robot usually has a single-board computer running Linux and a microcontroller for the motors.
- Industrial robot makers supply their own tools (ABB RobotStudio, FANUC ROBOGUIDE, KUKA.Sim, RoboDK): offline programmers that simulate a specific arm and export its own language (see Industrial Robotics).
Sense-plan-act, reactive and hybrid designs
| Design | Idea | Strengths | Weaknesses |
|---|---|---|---|
| Sense-plan-act | Build a model of the world, plan a complete action, execute it | Optimal, explainable plans; good for arms and known environments | Slow to react; a plan built on a stale model fails |
| Reactive (behavior-based) | Simple behaviors (avoid, follow wall) react directly to sensors; an arbiter picks one | Fast, robust, little computing | No foresight; hard to give it goals |
| Hybrid (three-layer) | A reactive layer under a planner under a goal layer | Quick reflexes with long-term goals | Layers must be coordinated |
| Learning-based | A trained network maps sensors to actions | Handles messy perception; learns from data | Opaque; needs data and testing (see Machine Learning) |
Most real robots are hybrid: the planner sets a goal every second or so, a local controller follows it at 10 to 50 Hz, and a reflex layer (stop when a bump switch closes, slow when the lidar sees a person) runs in the firmware at a kilohertz and cannot be overruled by the layers above.
What runs where: microcontroller, computer, cloud
| Run on… | Good for | Because |
|---|---|---|
| A microcontroller (MCU) | Motor loops, encoder counting, IMU sampling, current limits, the watchdog, the emergency-stop logic | Hard real-time timing, microsecond control, low power, survives an operating-system crash |
| An on-board computer (SBC, Linux) | ROS 2, cameras, lidar processing, SLAM, navigation, the network | Memory, an operating system, libraries and tools; not hard real-time |
| A GPU module or accelerator | Neural networks, dense depth, visual odometry | Parallel arithmetic at a few watts |
| An off-board PC or the cloud | Monitoring, mapping, fleet management, training | Large compute, but depends on a link: never put safety or control there |
The rule: anything that must happen on time, every time, or keep the robot safe when the computer fails, belongs on the microcontroller; anything that needs lots of memory, libraries or compute belongs on the computer.
Timing and compute budgets
Worked example: a 1 kHz motor loop on a microcontroller
A 168 MHz Cortex-M4 running a 1 kHz control loop has 168 000 000 ÷ 1 000 = 168 000 cycles per loop. Two PID loops (400 cycles each), two encoder reads (300 each) and a serial exchange (1 500) use about 2 900 cycles, a load of 1.73 %. There is ample room, which is the point of putting the loop on a microcontroller: the margin keeps the timing exact.
Worked example: the latency of seeing and stopping
| Stage | Time (ms) |
|---|---|
| Camera exposure and readout (30 fps) | 33 |
| USB transfer and driver | 10 |
| Object detection | 40 |
| Planner and costmap update | 20 |
| Command over serial to the MCU | 10 |
| Motor and drive response | 30 |
| Total, sensor to motor | 143 |
At 1.5 m/s the robot travels 1.5 × 143 ÷ 1 000 = 0.21 m before the motors react, and then needs v² ÷ (2a) = 1.5² ÷ (2 × 1.0) = 1.13 m to stop at 1.0 m/s²: a total of 1.34 m. Obstacle detection must therefore reach further than that, or the speed must come down. Latency, not frame rate, sets how fast a robot can safely go.
- Budget every stage and measure it (time stamps in the messages): the slowest stage and the queues between stages set the real latency.
- Image data is large: a 640 × 480 color image at 30 frames per second is 28 MB/s of raw data; compress, crop, or process it where it was captured.
- Keep control loops short and fixed-rate; run heavy perception at a lower rate and use the latest result.
Choosing the computer
| Computer | Typical use | Notes |
|---|---|---|
| Raspberry Pi 4 / 5 | Small mobile robots, ROS 2, a camera, a lidar | Cheap, huge community; CPU-only vision is slow; 3 to 8 W |
| NVIDIA Jetson (Orin Nano, Orin NX, AGX Orin) | Neural networks, visual SLAM, multiple cameras | GPU for deep learning at 10 to 60 W; JetPack software |
| Intel NUC or mini PC | Heavier navigation, larger robots, x86 software | Strong CPU; more power and mass |
| Microcontroller with micro-ROS | A node on the ROS 2 graph on a small board | Needs a serial or UDP link to an agent on the computer |
| Industrial PC / real-time controller | Production robots and machines | Real-time Linux or a PLC runtime; certified for the environment |
Worked example: power budget and runtime
A 50 Wh battery runs a 5 W computer for 50 ÷ 5 = 10 hours on the computer alone, but only about 2.0 h once the motors, lidar and cameras add 20 W. A microcontroller-only design (0.5 W) would last 100 hours. The computer is the largest steady drain on a small robot: power it down or slow it when idle (see Building, Testing and Safety).
The link between computer and microcontroller
Whatever carries commands and data between the two must be fast enough, framed and checked, and must stop the robot when it fails.
Worked example: a serial link
- The microcontroller sends a 32-byte state message (wheel speeds, encoder counts, IMU, battery) 50 times a second: 32 × 10 bits × 50 = 16 000 baud. That is 14 % of a 115 200 baud link but only 1.7 % of 921 600: use a fast link, or the receiver’s buffer and the latency suffer.
- Framing: a start byte, a length, the 24-byte payload and a 16-bit CRC make a 28-byte frame; a receiver that loses sync looks for the next start byte and checks the CRC before it accepts the data (see Embedded Systems).
- Heartbeat: commands arrive at 20 Hz, every 50 ms. If none arrives for three periods (150 ms) the firmware sets the speed to zero. Choose the timeout to be a few periods long: too short and a late message stops the robot, too long and a dead computer leaves it running.
- micro-ROS puts a ROS 2 node on the microcontroller itself, over serial or UDP, so the same topics appear on both sides; it is convenient, but the custom frame above is simpler, smaller and easier to make deterministic.
Behavior: state machines and behavior trees
- State machines are clear for sequences with few states (idle, drive, dock, charge, fault) and are easy to test (see Embedded Systems: Architecture); they get tangled as states multiply.
- Behavior trees (BehaviorTree.CPP, the default for Nav2) build a mission from reusable actions and conditions in a tree: sequences, fallbacks (try this, else that) and decorators (retry, timeout). They scale better and make failure handling explicit: “navigate, and if blocked, clear the costmap, and if still blocked, ask for help”.
- Keep behavior apart from motion: the behavior layer chooses goals and recovery; it does not command motors.
- Log every decision so that a strange behavior can be explained afterwards.
Designing for failure
| Failure | What happens | Defense |
|---|---|---|
| The computer crashes or the link drops | The motors keep their last command | A heartbeat timeout in the firmware stops the robot |
| A sensor fails or freezes | The robot acts on stale or wrong data | Time stamps, plausibility checks, a second sensor, and a timeout on every input |
| The planner finds no path | The robot stops, or oscillates | Recovery behaviors (back up, rotate, clear the costmap), then ask for help |
| Localization is lost | The robot thinks it is somewhere else | Monitor the filter’s uncertainty; stop or re-localize when it is too large |
| Low battery | Brown-outs and resets | Return and dock at a threshold; cut loads before the voltage collapses |
| Software bug | Unexpected motion | Limits in the firmware (speed, acceleration, workspace) that no upper layer can exceed, and a hardware emergency stop |
Organizing the code
- One node, one job, with clear inputs and outputs; replace a node without touching the others.
- Parameters and launch files for everything you might change: gains, limits, frame names, topics.
- A workspace per robot, with packages for the description (URDF), the bring-up, the drivers, the behavior and the simulation, kept in Git (see Software Practice).
- Same interfaces in simulation and on hardware, so the code is unchanged between them.
- Test the math without ROS: keep kinematics, filters and planners in plain libraries, with unit tests, and wrap them in thin nodes.
- Record every test run as a bag, with the software version, and keep it.
Related
- Robotics Tools: the overview of this guide.
- ROS 2 in Practice: the middleware in detail.
- Building, Testing and Safety: power, safety and testing.
- Embedded Systems: firmware for the microcontroller layer.
- Industrial Robotics: how factory robots are architected and made safe.
FAQ
Do I need a computer and a microcontroller?
For anything beyond a toy, yes: the microcontroller guarantees timing and safety, the computer does the heavy thinking. A single board can do both on a very simple robot.
Where should the safety logic live?
In hardware (a hard-wired emergency stop) and in the microcontroller firmware, independent of the computer and the network. Never rely on a message arriving from ROS to stop the robot.
Is ROS 2 real-time?
Not by default. On a tuned real-time Linux kernel with careful design its executors can meet deadlines in the millisecond range, but hard real-time loops (kilohertz motor control) belong on a microcontroller or a real-time controller.
Should I use behavior trees or state machines?
State machines for a handful of states; behavior trees when the mission has many steps, fallbacks and recovery behaviors. Both are fine if you keep behavior apart from motion.
References
- Siegwart, R., Nourbakhsh, I. and Scaramuzza, D., Introduction to Autonomous Mobile Robots; Murphy, R., Introduction to AI Robotics (paradigms).
- ROS 2 design documentation (docs.ros.org); micro-ROS documentation; Nav2 and BehaviorTree.CPP documentation.
- Colledanchise, M. and Ögren, P., Behavior Trees in Robotics and AI.
Last reviewed: October 2026. Timings and power figures are illustrative: measure on your own robot.