robotics//ROS 2

ROS 2 is a robotics middleware framework, a set of libraries, tools and conventions (despite its name, not an operating system) with which the processes of a robot exchange typed messages, and it is what most research robots and a growing number of products use so that a team writes the robot and reuses the plumbing. Underneath it runs DDS, whose quality-of-service policies it exposes.

ROS 2 is a robotics middleware framework, a set of libraries, tools and conventions (despite its name, not an operating system) with which the processes of a robot exchange typed messages, and it is what most research robots and a growing number of products use so that a team writes the robot and reuses the plumbing. Underneath it runs DDS, whose quality-of-service policies it exposes.

Its vocabulary has four nouns. A node is a process, typically one per driver, estimator or planner. A topic is a named publish-subscribe stream (lidar scans, the estimated pose, velocity commands). A service is request-reply for short queries. An action is a long task with progress feedback and cancellation, such as drive to the loading dock. A warehouse robot shows how they fit: the lidar driver publishes scans, a SLAM node publishes the map, Nav2 plans and publishes velocities, and the wheel controller executes them.

The tools save months. rosbag records every topic for replay in the office (log replay); tf2 keeps track of coordinate frames and their transforms over time; RViz visualizes it all; Nav2 is the navigation stack with A*-family global planners (A* search); MoveIt plans arm motion with OMPL's sampling planners, RRT variants among them (RRT); Gazebo simulates robots, and PX4 and ArduPilot are developed against it in software-in-the-loop.

ROS 2 is not hard real time. It allows real-time code, but on Linux and DDS its latencies are not bounded tightly enough for a current or attitude loop. The rule is that fast loops live on the microcontroller or in the drive and ROS 2 coordinates at 10 to 100 Hz; micro-ROS brings a ROS 2 client to the microcontroller so it can join the graph.

End-to-end latency through middleware adds up hop by hop: from sensor to actuator it is the sum of queueing and computation in each node plus the transport of each link, and every hop adds jitter to the loop's delay.

Tend-to-end=∑nodes(Tqueue+Tcompute)+∑linksTtransportT_{\text{end-to-end}}=\sum_{\text{nodes}}\big(T_{\text{queue}}+T_{\text{compute}}\big)+\sum_{\text{links}}T_{\text{transport}}Tend-to-end​=nodes∑​(Tqueue​+Tcompute​)+links∑​Ttransport​

A pipeline of five nodes at a few milliseconds each easily reaches tens of milliseconds, which is fine for planning and fatal for stabilization.

Every message header carries a timestamp; fill it with the time of acquisition, never the time of publication, or every fusion downstream inherits the transport delay as error (time synchronization).

A robot with one microcontroller and two sensors does not need ROS; it pays off once there are several processes, complex sensors and a team that wants to reuse navigation, visualization and tooling (middleware).