Robot software architecture

A working robot is a software system long before it is a mechanical one. A warehouse robot that picks totes may run eighty processes on three computers, talk to a dozen microcontrollers, log several gigabytes an hour and receive updates from a fleet server. Almost every hard problem a robotics team faces after the first demonstration is a software problem: making that system reliable, testable, changeable and safe as it grows. This course is about the engineering discipline that makes robot software dependable, from architecture and requirements to testing, simulation, continuous integration, field operations and security.

ROB-110 introduced the tools: Linux, Python, Git and the ROS 2 graph of nodes, topics, services and actions, with launch files and lifecycle nodes. This course assumes that toolkit and asks the next question: how should a whole robot's software be organized so that a team of people can build it, test it and keep it working for years? This first lesson looks at architecture, the set of high-level decisions about how the system is divided into parts, how those parts communicate and which part is responsible for what.

What architecture is and why robots need it

Software architecture is the structure of a system: its components, the interfaces between them, and the rules that govern how they interact and evolve. It is the set of decisions that are expensive to change later. Choosing a variable name is not architecture; choosing whether perception and planning run in one process or two, whether the controller talks to motors through a hardware abstraction layer or directly, and whether the robot can keep driving when it loses its network connection, are architecture.

Robots make architecture especially important for four reasons. First, they combine many disciplines (perception, estimation, planning, control, user interface, fleet management), each with its own experts, so clear boundaries let specialists work in parallel. Second, they have mixed timing needs: a current loop must run every 50 µs while a route planner may take a second, and these cannot share a thread. Third, they act in the physical world, so a software fault can injure someone; the architecture must contain faults and make the safe behaviour easy to guarantee. Fourth, robots live a long time and change constantly: sensors are replaced, algorithms improve, customers ask for features. A good architecture lets a team change one part without breaking the rest.

Layered architectures

The oldest and still most common organizing idea is layering. Each layer provides services to the layer above and uses services from the layer below, and dependencies point in one direction only. A typical robot stack has a hardware layer (motors, encoders, cameras), a driver and hardware abstraction layer that presents those devices through standard interfaces, a control layer that closes fast feedback loops, a functional layer of perception, estimation and planning, an executive or behaviour layer that sequences tasks and handles failures, and an application or mission layer that talks to people and fleet systems.

Layering gives two big benefits. Lower layers can be tested and reused without the upper ones, and upper layers can be developed against a stable interface while the hardware is still changing. The classic three-layer architecture from the 1990s, with a deliberative planner on top, an executive in the middle and reactive skills at the bottom, captures the same idea at a coarser grain. The weakness of strict layering is latency: forcing every sensor reading to climb through every layer before an action is chosen is too slow for reflexes, so real robots also have short paths, such as a bumper wired straight to the motor controller or a safety scanner that cuts power on its own.

Component-based and message-based design

Within the layers, modern robot software is built from components: separately developed units with well-defined inputs, outputs and parameters, connected at run time. ROS 2 nodes are components; so are the plugins of a navigation stack and the controllers of ros2_control. Components communicate through messages with defined types, which decouples them in three ways. In space, a publisher does not know which subscribers exist. In time, with suitable quality-of-service settings a late subscriber can still receive the last message. In implementation, a component written in C++ can talk to one written in Python.

Message-based design has costs as well. Every message is copied or at least serialized, which adds latency and CPU load. The graph of topics can grow until nobody understands it, and the system's real behaviour emerges from timing interactions that no single component controls. Good architectures keep the graph legible: a modest number of well-named topics with documented rates and units, clear ownership of each topic, and as few cycles as possible.

Nodes, processes and composition

An architecture must also decide how components map onto operating-system processes and computers. Running every node in its own process gives isolation: a crash in perception does not kill the controller, and each process can be restarted separately. But inter-process messages cost serialization and copying, which matters for large data such as point clouds and images. ROS 2 composition lets several nodes be loaded into one container process, where messages can be passed by pointer with zero copies. The usual pattern is to compose tightly coupled, high-bandwidth pipelines, such as a camera driver, rectification and a detector, and to keep safety-relevant and independently restartable parts in separate processes.

Lifecycle (managed) nodes, introduced in ROB-110, add a standard state machine of unconfigured, inactive, active and finalized states. Their architectural value is orchestration: a system manager can configure every node, check that all are ready, and only then activate them together, and it can deactivate a misbehaving node without destroying it. Navigation stacks use a lifecycle manager in exactly this way.

Hardware abstraction and ros2_control

A hardware abstraction layer (HAL) hides the details of particular devices behind standard interfaces, so that higher layers ask for 'joint 3 velocity' rather than 'write 0x2A to register 0x60FF of the drive on CAN node 7'. Abstraction lets the same controller run on the real robot, on a different motor drive, or in simulation. It also gives one place to enforce limits and convert units.

In ROS 2 the standard framework for this is ros2_control. A hardware interface plugin, written once per robot, exposes state interfaces (such as position and velocity of each joint) and command interfaces (such as effort or velocity commands). A controller manager loads controller plugins, for example a joint trajectory controller or a differential drive controller, and runs them in a real-time loop at a fixed rate, reading states, computing commands and writing them back. Swapping the hardware interface for a simulation interface, such as the one provided with Gazebo, lets the identical controller configuration run against a simulated robot, which is a foundation of the simulation and testing workflows later in this course.

# controllers.yaml for ros2_control (listing)
controller_manager:
  ros__parameters:
    update_rate: 500            # Hz, the real-time loop
    joint_state_broadcaster:
      type: joint_state_broadcaster/JointStateBroadcaster
    diff_drive_controller:
      type: diff_drive_controller/DiffDriveController
diff_drive_controller:
  ros__parameters:
    left_wheel_names: ["left_wheel_joint"]
    right_wheel_names: ["right_wheel_joint"]
    wheel_separation: 0.42      # m
    wheel_radius: 0.08          # m
    linear.x.max_velocity: 1.2  # m/s
    cmd_vel_timeout: 0.5        # s: stop if commands go stale

Separating concerns: safety, timing and data

Three cross-cutting concerns deserve their own architectural decisions. The first is safety. Safety functions such as emergency stop, speed and separation monitoring and safe torque off should be as simple and independent as possible, often running on separate certified hardware, so that the complex software above them cannot defeat them. The rest of the software is designed on the assumption that it can fail, and the safety layer catches the failure. The second is timing. Components with hard deadlines, such as current and joint control, run on real-time cores or microcontrollers (ROB-320), while best-effort components run on general-purpose computers; the interface between them must be designed so that late or missing commands are handled safely, for example by a command timeout that stops the motors. The third is data: decide early which data is logged, at what rate, with what timestamps, because diagnosing field failures depends entirely on it.

Architectural styles in practice

Several patterns recur in robot software. Pipelines (sense, then estimate, then plan, then act) are easy to reason about but can hide latency. Blackboards share a common world model that components read and write, which simplifies coordination but needs careful locking and ownership rules. Behaviour trees, used by many navigation and manipulation executives, organize task logic as a tree of sequences, fallbacks and conditions that is easy to read and extend; state machines are simpler for small, well-bounded tasks. Client and server patterns connect robots to fleet managers, usually through a gateway that translates between the robot's internal messages and an external API, so that network problems never block the robot's internal loops.

A useful test for any architecture is the 'what if' list. What if the network drops for a minute? What if a camera stops publishing? What if the planner takes ten times longer than usual? What if a new sensor is added next year? An architecture that has a clear answer to each question, ideally one the team has tested, is in good shape. Lesson 2 shows how to record these decisions so that they survive staff changes, and lesson 4 shows how to test the answers.

Documenting the architecture

An architecture that exists only in the lead developer's head is fragile. Teams document it with a small set of views: a context diagram showing the robot and the external systems and people it interacts with; a component diagram showing major components and their interfaces; a deployment view showing which processes run on which computers; and, for key scenarios such as 'robot receives a delivery goal', a sequence diagram showing the messages exchanged. The C4 model (context, containers, components and code) is a popular, lightweight way to organize these views. For ROS 2 systems, tools that draw the live node graph are useful for checking that the running system matches the intended design, but they are not a substitute for an intentional diagram.