ROS 2 Development Guide

ROS 2 Development Guide — Building Modern Robot Software

The Robot Operating System has become the de facto standard for robotics software development, and ROS 2 represents a fundamental rearchitecture that addresses the limitations that kept ROS 1 out of production and safety-critical systems. With DDS-based communication replacing the fragile roscore-dependent architecture, lifecycle-managed nodes providing deterministic startup and shutdown behavior, and real-time execution support enabling hard control loops, ROS 2 is now a serious platform for commercial robotics products — not just research prototypes.

At ESS ENN Associates, our embedded systems team builds ROS 2-based robotic software for industrial, agricultural, and service robotics applications. This guide covers the core architecture of ROS 2, the key frameworks that robotics engineers work with daily — DDS middleware, Nav2 navigation, MoveIt2 manipulation, ros2_control, and Micro-ROS — and the practical engineering decisions that determine whether a ROS 2 system performs reliably in production.

DDS: The Communication Backbone

The most significant architectural change in ROS 2 is the adoption of DDS (Data Distribution Service) as the communication middleware. Where ROS 1 used a custom transport layer that depended on a central roscore process, ROS 2 uses DDS, an OMG standard originally developed for military and aerospace systems where reliability and determinism are non-negotiable.

Discovery without a master is the first practical benefit. DDS uses a decentralized discovery protocol where nodes find each other automatically on the network. There is no single point of failure equivalent to roscore. If one node crashes, other nodes continue operating normally. This is essential for production robotic systems where uptime matters and a single process failure should not bring down the entire system.

Quality of Service (QoS) policies give developers fine-grained control over communication behavior. Reliability can be set to RELIABLE (guaranteed delivery with retransmission) or BEST_EFFORT (lowest latency, acceptable for sensor streams where occasional dropped messages are tolerable). Durability can be TRANSIENT_LOCAL (late-joining subscribers receive the last published message) or VOLATILE (only receive messages published after subscription). History depth controls how many messages are buffered. These policies allow the same ROS 2 infrastructure to handle both high-frequency sensor data (best-effort, small history) and critical command messages (reliable, transient-local) appropriately.

DDS vendor selection matters more than many teams realize. ROS 2 supports multiple DDS implementations: eProsima Fast-DDS (the default), Eclipse Cyclone DDS (excellent performance, simpler configuration), RTI Connext DDS (commercial, widely used in defense and aerospace), and GurumNetworks GurumDDS. Each has different performance characteristics, memory footprints, and real-time behavior. For resource-constrained robotic platforms, Cyclone DDS often provides the best balance of performance and memory usage. For systems requiring safety certification, RTI Connext offers the most mature certification path.

Configuring DDS properly is one of the most impactful things a ROS 2 developer can do for system performance. Setting appropriate QoS profiles, configuring discovery to avoid network flooding in multi-robot deployments, tuning shared memory transport for intra-process communication, and choosing the right DDS vendor for the hardware platform are all decisions that directly affect system reliability and latency.

Lifecycle Nodes: Deterministic Startup and Shutdown

ROS 2 lifecycle nodes (managed nodes) provide a state machine that controls the initialization, activation, deactivation, and cleanup of node resources. This seemingly simple feature solves one of ROS 1's most frustrating problems: non-deterministic system startup where nodes would race to initialize and create unpredictable behavior depending on timing.

The lifecycle state machine includes Unconfigured, Inactive, Active, and Finalized states with well-defined transitions between them. The on_configure callback allocates resources and sets parameters. The on_activate callback starts processing. The on_deactivate callback pauses processing without releasing resources. The on_cleanup callback releases resources and returns to Unconfigured. The on_shutdown callback handles emergency shutdown from any state.

For production robotic systems, lifecycle management enables a launch orchestrator to bring up the system in a defined sequence — configure all nodes, verify that configuration succeeded, then activate them in the correct order. If any node fails to configure, the system can handle the failure gracefully rather than running in a partially initialized state. This is particularly important for safety-critical systems where undefined system states are unacceptable.

Nav2: Autonomous Navigation

Nav2 is the ROS 2 navigation framework that gives mobile robots the ability to navigate autonomously from point A to point B while avoiding obstacles. It is the successor to the ROS 1 navigation stack but with a fundamentally better architecture based on behavior trees and plugin-based extensibility.

The behavior tree architecture replaces the rigid state machine of the ROS 1 navigation stack. Nav2 uses BehaviorTree.CPP to define the navigation logic as a tree of actions, conditions, and control nodes. The default behavior tree handles the standard navigate-to-pose workflow: compute a global path, follow it with a local controller, recover if the robot gets stuck, and retry or abort if recovery fails. Teams can customize this behavior tree extensively — adding custom recovery behaviors, changing the retry logic, or implementing entirely different navigation strategies — without modifying any Nav2 source code.

Global planners compute the overall path from start to goal. Nav2 provides NavFn (Dijkstra/A* on a 2D costmap), Smac Planner (supports 2D, Hybrid-A*, and State Lattice planning for non-circular robots), and Theta* (any-angle planning for smoother paths). The Smac Hybrid-A* planner is particularly important for car-like robots with Ackermann steering that cannot rotate in place, as it plans kinematically feasible paths that the robot can actually follow.

Local controllers generate velocity commands that follow the global path while avoiding dynamic obstacles. DWB (Dynamic Window Based) is the most commonly used controller, computing candidate velocity trajectories and scoring them against multiple criteria (path following, obstacle distance, goal alignment). The MPPI (Model Predictive Path Integral) controller uses a sampling-based model predictive control approach that handles complex dynamics and constraints more gracefully. The Regulated Pure Pursuit controller provides simpler, more predictable path following behavior suitable for slower robots in structured environments.

Costmap generation builds the 2D occupancy grids that planners and controllers use for obstacle avoidance. The costmap is layered: a static layer from the pre-built map, an obstacle layer from real-time sensor data (LiDAR, depth cameras), an inflation layer that adds safety margins around obstacles, and optional custom layers for application-specific zones (speed limits, keep-out areas). Configuring costmap parameters — obstacle detection range, inflation radius, update frequency, and sensor fusion — is where much of the Nav2 tuning effort goes. Our AI engineering team has developed custom costmap layers for dynamic obstacle prediction using learned motion models.

MoveIt2: Robotic Manipulation

MoveIt2 is the ROS 2 framework for robotic arm motion planning and manipulation. It provides kinematics solvers, motion planners, collision checking, and integration with perception systems in a cohesive package that dramatically reduces the development time for manipulation applications.

Motion planning in MoveIt2 is handled through the OMPL (Open Motion Planning Library) integration, which provides sampling-based planners like RRT, RRT*, PRM, and their variants. These planners search the robot's configuration space for collision-free paths between start and goal configurations. For most industrial manipulation tasks, RRTConnect provides a good balance of planning speed and path quality. For applications requiring optimal or near-optimal paths, planners like RRT* or BIT* can be configured with appropriate planning time budgets.

The planning scene maintains the robot's model of its environment — the robot's own geometry (from URDF/SRDF), attached objects (a part being held by the gripper), and collision objects in the workspace (tables, fixtures, bins). Keeping the planning scene accurate and up-to-date is essential for collision-free motion planning. MoveIt2 can incorporate point clouds or depth images from perception systems to add observed obstacles to the planning scene automatically using the occupancy map (OctoMap) updater.

Grasp generation and execution integrates perception, planning, and control. MoveIt2's pick-and-place pipeline defines approach motions, grasp poses, retreat motions, and place poses as a sequence. The MoveIt Task Constructor provides a more flexible way to define complex manipulation tasks as hierarchies of planning stages, allowing the planner to search over different grasp strategies and motion alternatives. Integration with computer vision-based pose estimation provides the object poses that drive the grasp generation pipeline.

ros2_control: The Hardware Abstraction Layer

The ros2_control framework provides a standardized interface between control algorithms and robot hardware. It separates the controller logic (PID loops, trajectory following, impedance control) from the hardware interface (how commands are sent to actuators and how sensor data is read), allowing both to be developed and tested independently.

The control loop runs at a fixed rate (typically 100 Hz to 1 kHz depending on the application). At each cycle, the controller manager reads the current state from all hardware interfaces, updates all active controllers, and writes the computed commands back to the hardware. This deterministic loop is the foundation for precise robot control and must run with minimal jitter to avoid instability.

Hardware interfaces are plugins that abstract specific robot hardware. A hardware interface for a servo motor might provide position, velocity, and effort state interfaces and accept position or velocity command interfaces. For commercial robots, hardware interface plugins are often provided by the manufacturer (Universal Robots, KUKA, Franka Emika all have ros2_control interfaces). For custom robots, developing a hardware interface plugin is one of the first tasks in a ROS 2 integration project.

Controllers are also plugins, which means they can be loaded, started, stopped, and swapped at runtime. Standard controllers include JointTrajectoryController (for following joint-space trajectories, the workhorse of manipulator control), DiffDriveController (for differential-drive mobile robots), and ForwardCommandController (for direct command passthrough). Custom controllers can implement application-specific control logic while still benefiting from the ros2_control infrastructure for timing, hardware abstraction, and lifecycle management.

Micro-ROS: ROS 2 on Microcontrollers

Micro-ROS extends the ROS 2 ecosystem to microcontrollers running real-time operating systems. This bridges the gap between the high-level robot software running on Linux and the low-level hardware interfaces that interact with sensors and actuators at the electrical level.

Architecture — Micro-ROS runs a minimal ROS 2 stack (based on rcl and a micro XRCE-DDS client) on the microcontroller. It communicates with the main ROS 2 system through a micro-ROS agent running on the host computer. The agent translates between the micro XRCE-DDS protocol (optimized for constrained devices) and the full DDS protocol used by other ROS 2 nodes. Communication between the microcontroller and the agent can use serial UART, USB, UDP over WiFi or Ethernet, or other transports.

Supported platforms include ESP32 (popular for WiFi-connected sensors), STM32 series (widely used in motor control and industrial applications), Teensy 4.x (high-performance ARM Cortex-M7), and Arduino-compatible boards. The real-time operating systems supported include FreeRTOS, Zephyr, and NuttX. The choice of RTOS affects available features and the determinism of execution timing.

Practical applications of Micro-ROS include motor controllers that receive velocity commands and publish encoder feedback as ROS 2 topics, IMU drivers that publish sensor_msgs/Imu data directly, proximity sensor arrays that publish range data, LED and actuator controllers that subscribe to command topics, and battery monitoring systems. By making these low-level components native ROS 2 participants, the entire system becomes easier to debug, monitor, and reconfigure. Our IoT and embedded systems team specializes in Micro-ROS development for custom robotic hardware.

Real-Time Performance in ROS 2

Achieving real-time performance in ROS 2 requires attention to every layer of the software stack, from the operating system kernel to the application code. Real-time in this context means bounded, predictable latency — the control loop executes within a guaranteed time window every cycle.

Operating system configuration starts with an RT-PREEMPT patched Linux kernel, which makes the kernel fully preemptible and provides bounded interrupt latency. Setting CPU affinity to pin real-time threads to dedicated cores, configuring memory locking to prevent page faults, and disabling CPU frequency scaling to avoid timing variations are essential system-level steps. For the most demanding applications, Xenomai or a dedicated RTOS provides stronger real-time guarantees than Linux can offer.

Application-level practices for real-time ROS 2 code include pre-allocating all memory during the configuration phase (never allocating in the control loop), using lock-free data structures for inter-thread communication, avoiding standard library containers that may allocate internally, and using fixed-size message types where possible. The rclcpp real-time utilities provide tools like RealtimePublisher and RealtimeBuffer that are safe to use in real-time contexts.

Testing real-time performance uses tools like cyclictest to measure scheduling latency, trace-cmd and LTTng (through ros2_tracing) to identify latency sources, and custom timing instrumentation within the control loop. A well-configured ROS 2 real-time system on RT-PREEMPT Linux can achieve consistent sub-100-microsecond control loop jitter, which is sufficient for most robotic applications.

Frequently Asked Questions

For a deep dive into using ROS 2 with robotic manipulation, see our robotic arm programming and control guide. To understand how to test ROS 2 systems before deployment, our robot simulation and digital twins guide covers Gazebo and Isaac Sim integration. And for multi-robot ROS 2 deployments, our multi-robot coordination guide addresses the fleet management challenges.

At ESS ENN Associates, our embedded systems team builds production-grade ROS 2 software for industrial and commercial robotic products. From DDS configuration and real-time control to Nav2 navigation and Micro-ROS firmware, contact us for a free technical consultation.