Robot 101 · Chapter 05
The robot software stack: from middleware to motion
In one paragraph: Between the hardware and the AI sits a layer of software that turns sensor data into coordinated motion. As of 2026, almost the entire industry builds this layer on ROS 2, a middleware that gives every sensor and every planning library a common language. A heterogeneous compute stack runs it — a microcontroller for hard real-time control, a GPU-equipped board for perception and planning, and cloud for training and fleet management. Nav2 handles moving the base around a building; MoveIt 2 handles moving an arm to a pose; and a wired fieldbus — CAN FD or EtherCAT — carries the time-critical commands between them, with wireless reserved for everything that isn't safety-critical.
Why ROS 2 became the industry default
ROS 2 (Robot Operating System 2) is not an operating system in the traditional sense — it is middleware and a toolchain that runs on top of Linux, currently distributed as long-term-support releases such as Humble or Jazzy as of 2026. It provides a publish-subscribe messaging layer (topics), a request-response layer (services), a long-running task layer (actions), and a package build and launch system. The reason it is close to non-negotiable for a robotics team today is simple: the global developer ecosystem builds on top of it. Sensor manufacturers ship ROS 2 drivers, robot OEMs with open SDKs publish ROS 2 interfaces, and the standard navigation, manipulation, and simulation libraries all speak ROS 2 natively. Writing a robot stack outside that ecosystem means rebuilding, alone, the integration layer thousands of other engineers already maintain for free.
ROS 2's architectural advance over ROS 1 is DDS (Data Distribution Service) as the transport layer, replacing a single centralized "master" node with fault-tolerant peer-to-peer communication — no single point of failure. On top of that sit real-time-capable execution, lifecycle-managed nodes (a controlled configure → activate → deactivate → shutdown sequence for safe startup), and per-topic quality-of-service policies that trade reliability, message durability, and delivery deadlines against each other. Among DDS implementations, CycloneDDS has often been reported to show lower latency than the default FastDDS for the small, frequent messages a control loop sends — and switching between them is typically a single environment variable.
Compute architecture: three tiers, not one board
A robot's compute has to satisfy three constraints that no single chip handles well at once: hard real-time determinism (a control loop that must run on a fixed period with sub-millisecond jitter), AI inference throughput (running a multi-billion-parameter vision-language model for scene understanding needs GPU or NPU acceleration), and a tight power budget on a battery-powered platform. The common answer is a heterogeneous, three-tier stack.
- Tier 1 — real-time control (MCU): a microcontroller such as an ARM Cortex-M running bare-metal firmware or an RTOS, handling motor current control, interrupt-driven sensor reads, and emergency-stop logic — the layer that must never miss a deadline.
- Tier 2 — main robot computer (SBC/SOM): a GPU- or NPU-equipped board (the Jetson family is a common as-of-2026 example) running Linux and ROS 2, the navigation and manipulation stack, and the perception pipeline.
- Tier 3 — cloud/offboard: used for model training, fleet-wide telemetry and over-the-air update orchestration, and simulation for synthetic data generation. A well-designed robot remains fully functional on Tiers 1 and 2 alone — cloud connectivity is an enhancement, not a dependency, since network availability can't always be guaranteed indoors.
The navigation stack: Nav2
Nav2 is the standard ROS 2 navigation framework for moving a mobile base around a building. A behavior-tree executor coordinates a set of plugins: a global planner (computing a path across the whole known map), a local planner (reactive obstacle avoidance in the next few meters), a costmap (a grid combining a static pre-built map layer, a live obstacle layer from onboard sensors, and an inflation layer that keeps the robot's body clear of walls and furniture), and a set of recovery behaviors — spinning in place, backing up, or clearing the costmap — triggered when the planner can't find a path.
Tuning Nav2 for an indoor service environment is mostly about the costmap and recovery behaviors. A pre-built static map avoids the computational cost — and the risk — of a live map being corrupted by a misclassified moving object turning into a permanent phantom obstacle. A short decay time on the live obstacle layer means someone briefly standing in a corridor doesn't create a lasting blockage. Inflation radius is tuned per space: wider for open corridors, tighter for doorways the robot must pass through closely. And the recovery sequence is chosen for the setting — a "spin in place" recovery that's harmless in a warehouse can be startling around people, so many indoor-service tunings favor "wait, then re-plan" as the default first move.
The manipulation stack: MoveIt 2
MoveIt 2 is the standard ROS 2 framework for arm manipulation. It loads a kinematic model of the robot from a URDF description (link masses, joint limits, collision geometry), solves inverse kinematics to convert a target end-effector pose into joint angles, plans a collision-free motion using sampling-based planners, and checks that a candidate trajectory doesn't intersect anything in the environment.
For everyday manipulation tasks — placing an object, handing something over, operating a door handle — Cartesian planning (specifying the end-effector's path directly in space, rather than only its destination) tends to be preferred over free-form goal-pose planning: the resulting motion is more predictable to people nearby, easier to verify for clearance around known objects, and simpler to describe in task terms. Because real indoor spaces contain chairs, carts, and people moving unpredictably — unlike a fenced factory cell — the planning scene needs to update from the perception pipeline in near real time, turning depth-camera data into collision objects the planner can react to, several times per second.
Networking: CAN FD, EtherCAT, and staying up to date
Joint-level communication between the real-time controller and servo drivers runs over a wired fieldbus, not Wi-Fi — the timing guarantees needed for motor control are not something consumer wireless can promise. CAN FD (Controller Area Network Flexible Data-rate) extends classic CAN's 1 Mbit/s and 8-byte payload to 5–8 Mbit/s with up to 64-byte frames, letting a multi-joint arm report torque, position, velocity, and temperature efficiently at high update rates. EtherCAT trades some simplicity for tighter timing — sub-100-microsecond deterministic cycles across dozens of nodes — by having each device read and rewrite its slice of an Ethernet frame as it passes through, with no central switch. For a robot with a modest number of motor drivers, CAN FD is usually simpler to build and debug; EtherCAT becomes the better fit as node count and precision requirements climb, such as in a full humanoid with dozens of joints.
Wireless (Wi-Fi 6 or 5G, as of 2026) handles the robot's uplink to the building network and the cloud — video, telemetry, and remote commands — kept separate from the internal control loop. That same link is also how a robot stays current: a typical over-the-air update rolls out to a small slice of a fleet first, is monitored before wider release, installs onto an inactive partition so the robot can boot into the new firmware and roll back automatically if it fails, and is scheduled for downtime such as a charging period rather than mid-task. That update pipeline is arguably the single most consequential piece of DevOps for any robot fleet in the field, since it is what lets software improve without a technician visiting every unit.
Sourcing note. Hardware and software meet at the driver. Asaptic-sourced joint modules and components ship with the interface documentation — CAN FD, EtherCAT, and RS-485 specifications, in English — that integration teams need to bring a component into their stack without guesswork. Send an integration sourcing enquiry or see what we source.