Chapter 4: How ROS 2 Becomes Motion — From Nodes to the Real Controller

Overview

After installing ROS 2, a beginner sees nodes, topics, services, and actions. None of those names makes a robot move by itself. A planner must produce a trajectory goal; a controller interpolates it over time; a hardware interface or vendor driver translates commands into the manufacturer's protocol; and the robot controller checks mode, limits, and safety state before driving motors. In the reverse direction, encoder and controller state cross the network and become joint state and diagnostics. A wrong frame, unit, timestamp, or command owner anywhere in that round trip produces the familiar state in which “ROS is connected, but the robot does not move.”

ROS 2 is valuable because it makes this path separable, inspectable, and recordable. Cameras, planners, grippers, and arm drivers can run in different processes or computers while sharing typed interfaces. Their state can be inspected, visualized, recorded, and replayed. A direct vendor SDK may be simpler for one robot and one vendor-specific experiment. The real design question is not whether ROS 2 is mandatory; it is whether frame, time, limits, watchdogs, logging, ownership, and the vendor safety contract all have explicit owners.

This chapter does not dump raw code. It teaches the exact packet path and a bring-up sequence that validates discovery, QoS, TF, time, drivers, and controllers before enabling drives. Motion planning, IK, and trajectory construction follow in (Chapter 5); rehearsing this sequence with simulation and fake hardware follows in (Chapters 6–7). Product and distribution status is current to 2026-07-14.

After reading this chapter... - You can explain the role of a node, DDS, topic, service, action, executor, and QoS in one motion request. - You can diagnose why a Cartesian command fails or becomes unsafe when TF or timestamps are wrong. - You can draw the planner→MoveIt→trajectory controller→hardware interface→vendor controller→drive path. - You can choose between a ROS 2 stack and direct vendor SDK and identify the responsibilities each architecture leaves to you. - You can write validation gates from drives-disabled networking to one small supervised joint motion.

1. Treat ROS 2 as a responsibility graph, not an operating system

ROS 2 does not replace Linux, a physics simulator, or the robot's certified safety controller. It is a middleware-centered framework for software components that communicate through typed data and discovery. A node is a logical participant containing publishers, subscribers, services, actions, and parameters. One node may occupy one process, or multiple nodes may be composed into one process. An executor schedules callbacks. Seeing a 500 Hz topic does not prove that its callback and downstream control chain meet a 500 Hz deadline ^{[2] [4]}.

Unlike ROS 1's central master, ROS 2 commonly uses DDS-family middleware for discovery and data transport. Applications see rclcpp or rclpy; below them sit rcl, the RMW abstraction, a DDS implementation, and UDP/IP or shared memory. This layering provides shared types and distributed tooling, but behavior depends on middleware, QoS, operating-system scheduling, and network configuration ^[2].

Write the graph as a sentence before installing a driver: “The camera publishes image and calibration; perception publishes an object pose; the planner transforms it into the base frame; MoveIt creates a trajectory for a joint-trajectory action server; Controller Manager writes through a hardware interface and vendor driver; the robot controller applies it to the drive.” Any clock, limit, watchdog, or stop authority absent from that sentence becomes an audit item.

Figure 4.1 — Bidirectional packet flow from object pose to drives with an independent safety boundary. Original synthesis.

2. Match topics, services, and actions to the time scale of motion

ROS 2 topics serve streams, services serve bounded request-response interactions, and actions serve long-running goals with feedback and cancellation. ^{[1] [2]} Images, joint states, and tactile packets naturally use topics. A short query such as reading a configured payload can use a service. A multi-second trajectory that reports progress and supports cancellation belongs on an action. A blocking service for motion leaves timeout and partial execution semantics unclear.

Topics have different delivery contracts. QoS combines reliability, durability, history, depth, deadline, lifespan, and liveliness policies. A high-bandwidth camera may prefer best-effort delivery and a shallow queue when the newest image matters. Sparse configuration data may need reliable delivery. If publisher and subscriber policies are incompatible, the topic name can appear while no sample arrives. Test both endpoint compatibility and acceptable sample age.

Actions also require explicit semantics. Verify goal acceptance, feedback, when cancellation takes effect, and the result on tolerance violation. The ros2_control Joint Trajectory Controller provides action-level completion and tolerance reporting; violation can abort execution and hold, subject to valid feedback and hardware behavior ^[9]. A topic command lacks those action results and is less inspectable for first bring-up.

Interface selection checklist

Choose the interface from the interaction contract before choosing a convenient API. Write whether the consumer needs every sample or only the newest one, a bounded reply, progress, cancellation, and an unambiguous terminal result. Then inject a late sample, a missing responder, and a cancelled goal in simulation. The selected interface passes only when each case produces a visible, bounded state rather than an indefinitely blocked caller or a stale command.

DDS discovery and QoS do not by themselves guarantee hard real-time deadlines or functional safety. ^{[2] [3] [4]} Determinism also depends on callback chains, executor design, allocation, kernel scheduling, CPU interference, the NIC, and vendor-controller timing. A QoS deadline can report a missed contract; it does not enforce a motor deadline as a safety function.

3. TF is a transform graph indexed by time

A manipulation cell includes world, base, arm links, flange, TCP, cameras, objects, and fixtures. A connected TF tree may still contain wrong axes, parent direction, units, optical convention, or calibration. To compose base→camera and camera→object, both transforms must be valid for the observation time.

TF is a time-indexed transform graph, so a frame name without a valid timestamp is insufficient for Cartesian motion. ^[5] A wrist-camera image paired with a later joint state can make an object pose move artificially. Asking for the “latest” transform may conceal synchronization error. Store the image stamp, robot-state stamp, transform stamp, and calibration ID used to form every goal.

A static transform means it does not move during operation, not that it remains correct forever. A bumped camera or changed tool requires a new calibration revision. Do not silently overwrite different calibrations under the same authority. Use one canonical publisher for deployed frames and preserve the configuration hash in logs.

ROS time can mix wall, steady, and simulation clocks. If some simulation nodes consume /clock while another uses wall time, TF extrapolation, timeout, and replay become confusing. In a real cell, document each camera's hardware-clock domain and synchronize hosts. Clock agreement still leaves exposure delay, buffering, and transport latency, so measure both offset and observation age.

TF and time acceptance gates

1. Require one publisher for every dynamic child frame; duplicate authorities are a blocker.
2. Compare base, tool approach, and optical axes with physical markers at home.
3. Observe at least three known fixture points to validate transform direction and scale.
4. Record TF buffer range, joint-state age, camera age, and lookup failures for ten minutes.
5. Test clock jumps and replay in simulation; controller timeouts must fail closed.
6. Store calibration, TF-publisher version, and URDF hash under one configuration ID.

Figure 4.2 — TF is a graph with time history, not merely a list of frame names. Original synthesis.

4. Choose a distribution from the vendor matrix, not the newest name

Treat Ubuntu and ROS 2 distribution as a pair, then verify that the robot driver supports it. A long LTS window does not provide every vendor binary. Replace “supports ROS 2” with a pinned tuple: hardware revision, controller firmware, Ubuntu, kernel, ROS distribution, RMW, driver tag, SDK, and description package.

Jazzy targets Ubuntu 24.04 through May 2029 and Lyrical through May 2031, but vendor matrices still determine the usable ROS distribution. ^{[6] [7] [12] [16]} These dates and matrices are current only at the 2026-07-14 cutoff. A green UR build cell does not test every firmware combination, and an FR3 stack may still require a documented Humble/libfranka tuple.

Installing the OS first and hoping the driver fits is expensive. Read vendor releases, build in a clean image, verify mock hardware, then freeze the workstation image. Different laboratories may qualify different distributions, but each physical cell needs a golden image and rollback path. Test a new distribution away from the operating cell.

5. Validate DDS discovery and robot networking with drives disabled

When nodes cannot see each other, do not edit application code first. Verify physical network, IP, subnet, route, firewall, multicast or configured unicast discovery, ROS_DOMAIN_ID, localhost-only settings, and RMW. VPNs, Wi-Fi isolation, enterprise firewalls, and container networking can block discovery. Domains are useful cell partitions but an accidental mismatch creates a silent split.

Use a dedicated wired link or controlled switch when the vendor recommends one. UR documentation recommends low-latency or PREEMPT_RT and direct PC-to-controller Ethernet, but this is guidance, not a measured latency guarantee ^[13]. Do not mix camera streams, bag uploads, and internet downloads onto the robot-control NIC. With two NICs, verify routes and source addresses.

After discovery, test the data plane: endpoint match, type, QoS, sample freshness, and loss. A successful ping does not prove DDS compatibility. Successful discovery does not mean the robot-side external-control program, controller mode, or drives are ready.

Network, discovery, and time gate

Advance one layer at a time with drives disabled. Preserve the NIC and route snapshot, vendor identity readout, ROS domain and RMW, endpoint/QoS report, message-age trace, and TF authority list under one attempt ID. This makes “the network works” reproducible: a later failure can be localized to physical link, vendor API, discovery, data delivery, or time alignment without weakening firewall, watchdog, or controller safeguards.

Domain IDs and namespaces reduce accidental collisions; they are not authentication or safety boundaries. Restrict command publishers through controlled launches, network policy, physical mode selection, and robot-controller state.

6. Lifecycle, launch, and parameters make bring-up repeatable

Launch files start nodes with parameters, namespaces, and remappings. Ordered spawning is not readiness. Each component must prove required state, interfaces, and transforms. Parameter files should expose robot IP, prefixes, controller name, rate, and frames while separating secrets and environment-specific values.

Lifecycle nodes expose auditable state transitions but do not replace the robot controller safety state machine. ^{[8] [20]} unconfigured→inactive→active is useful for allocation, connection, and publisher activation. An active node does not mean a protective stop is cleared or a sharp tool is safe. Because third-party drivers implement lifecycle unevenly, test the side effects of every transition.

Use the mental model discover → configure → observe → claim → enable → move. Identify hardware and versions. Configure without claiming motion. Observe fresh state and TF. Claim one command interface. A human checks the cell and stop path. Enable through the vendor procedure. Only then request reduced-envelope motion. Save the last successful state and evidence when blocked.

Automatic process restart deserves caution. Restarting perception is not equivalent to restarting a driver. Test whether reconnect replays a previous command, whether controllers return inactive, and whether operator acknowledgment is required. Safety-relevant recovery needs named states, not unconditional restart.

7. ros2_control defines ownership between controllers and hardware

ros2_control hides robot-specific read/write behind hardware components while allowing trajectory or effort controllers to consume standard interfaces. Controller Manager calls hardware read, controller update, and hardware write in a configured cycle. State interfaces expose measured joints; command interfaces expose permitted references ^[10].

ros2_control separates hardware interfaces from controllers and grants or releases command-interface ownership when controllers are activated or switched; the update loop then reads hardware, updates active controllers, and writes commands. ^{[10] [11]} Preventing two controllers from commanding the same joint interface is essential. This is software resource arbitration, not certified motion authority. A plugin with wrong units, signs, or limits remains wrong.

Test controller switching in fake hardware and simulation. Record which interfaces release and claim, plus hold behavior during transition. A listed controller name does not prove the correct joints are claimed. Compare state, required joints, and claimed interfaces.

Joint Trajectory Controller supports combinations of position, velocity, acceleration, and effort subject to available interfaces and tolerances ^[9]. Platform speed scaling can alter execution progress. UR-specific scaling semantics cannot be assumed on another arm ^[14].

Figure 4.3 — Corrected separation of controller-ownership events and the recurring update loop. Original synthesis.

8. The same trajectory meets different contracts on UR and Franka

UR ROS 2 and libfranka or franka_ros2 expose different command contracts, timing requirements, and version matrices. ^{[12] [16] [17]} UR includes robot-side External Control, RTDE state, scaled trajectory behavior, and pendant/remote modes. Franka emphasizes FCI/libfranka real-time constraints, system-image compatibility, and torque/impedance semantics. Similar ROS action names do not imply identical low-level behavior.

For UR, verify exact ur_type, IP, robot-side program, remote/headless mode, speed slider, and safety state. Mock hardware validates interfaces and launch, not dynamics, network jitter, scaling, or protective stops ^[15]. If execution is slower than planned, inspect speed scaling before blaming planning ^[14].

For Franka, pin robot system image, libfranka, franka_ros2, and description versions. Meeting a changelog minimum does not fix an unqualified real-time host or network ^{[16] [17]}. A torque-controller example is not permission to deploy arbitrary generated control.

Read Kinova Kortex or OpenArm CAN stacks the same way: confirm command/state semantics, distribution, namespaces, fake-hardware switches, and exact revision ^{[21] [22]}. “ROS 2 compatible” begins, rather than completes, acceptance.

9. A direct SDK is an architecture that takes responsibilities back

Direct SDK use can be appropriate for one robot, one vendor-specific torque or state API, one process, and little distributed sensing. It can expose a feature not yet wrapped by ROS and reduce dependency and discovery surface. That can simplify measurement, but it does not automatically improve worst-case latency.

A direct SDK can reduce dependency surface but must still implement frames, timing, logging, watchdogs, command ownership, and the vendor safety contract. ^{[12] [17] [19]} No reviewed evidence establishes that direct SDK use is universally faster or safer. Removing ROS 2 may remove TF, bagging, introspection, lifecycle, and standard actions; their responsibilities move into application code and procedure.

ROS 2 becomes attractive when cameras, grippers, planners, visualization, operators, and recorders must cooperate, or simulation and hardware share high-level interfaces. A common hybrid leaves hard servo timing inside the vendor controller or a qualified real-time process and uses ROS 2 for goals and state.

Even a direct path needs a small adapter boundary. Do not spread vendor structs across the application. Wrap timestamped state, explicit units, and bounded commands so a ROS bridge or simulator backend can be added later. OROCOS's still-useful architectural lesson is separation of real-time components from communication and tooling ^[19].

10. How a MoveIt goal becomes a joint command

MoveIt is not a motor controller. move_group uses the robot model, planning scene, current joints, and TF to plan, then sends a trajectory to a controller action. Bad geometry or stale state produces a bad plan; a missing action server prevents execution even if planning succeeds.

MoveIt move_group consumes joint states and TF and sends trajectories through FollowJointTrajectory rather than motor torque. ^[18] A Joint Trajectory Controller or compatible server converts time-parameterized points into command-interface references. Torque control is a separate contract requiring its own controller and safety analysis.

Trace one packet:

1. Perception publishes an object pose in camera with an image timestamp.
2. The task node transforms it into base at that time and records the goal.
3. MoveIt plans against current joints, URDF/SRDF, collision world, and constraints.
4. The reviewed application checks bounds and sends an action goal.
5. The trajectory controller accepts it and updates references.
6. The hardware interface or vendor driver translates references.
7. The robot controller enforces mode, limits, and safety state before driving.
8. Joint state, feedback, scaling, faults, and result return under one attempt ID.

TF failure, stale state, planning failure, goal rejection, tolerance violation, missed cycle, and protective stop are different failures. A single “move failed” log prevents diagnosis and learning.

11. Safe bring-up from first connection to small motion

Only a configuration already tested in simulation and mock hardware proceeds to hardware. The workstation does not own E-stop authority, and successful launch does not establish physical clearance. Apply the cell scope of ISO 10218-2 and local qualified review ^[20].

Staged promotion gates

At G6, move one joint only. The physical observer remains at the stop. State the joint, sign, maximum delta, speed, timeout, and stop reason aloud. Compare controller state with physical pose afterward. (Chapter 7) turns this outline into the full first-motion runbook.

Symptom-driven troubleshooting

12. Ask Codex for verifiable integration artifacts, not “make it move”

Codex can inspect a package tree and official APIs, then produce adapters, tests, and documentation. It must not own a real-time torque loop, safety limit, or E-stop. Generated changes require simulator/fake-hardware tests, diff review, and named human approval.

Codex-generated robot code should be bounded by explicit frames, units, rates, failure behavior, simulator tests, and a human-reviewed done condition. ^{[23] [24]} Code as Policies shows that a language model can compose documented perception and control APIs, while also exposing brittleness when APIs are wrong or programs grow long ^[24]. Terry's related CaP-X note is available in Korean and English.

Prompt A — read-only graph and version audit

Act as a robot-integration auditor. Do not connect to real hardware or modify files.
Read this workspace, manifests, launch/config, and only the official vendor documents
I provide. Build an exact tuple: robot revision, firmware, Ubuntu/kernel, ROS 2,
RMW, vendor SDK, driver tag, description, ros2_control controllers, and MoveIt config.

Draw the expected nodes, topics, services, actions, TF publishers, parameters, and
command owner. For every command path state frame, unit, rate, time source, QoS,
watchdog, and failure behavior. Mark unsupported compatibility UNKNOWN. Do not suggest
real motion or safety bypass. Done means a report with blockers and supplier questions.

Prompt B — fake-hardware integration task

Propose one fake-hardware bring-up and test following this repository's conventions.
Inspect instructions, package tree, and exact interfaces first. Never use a real IP or
real hardware plugin. Read joint names, units, and frames from the robot description;
allow one command owner; test stale state, missing TF, rejection, cancel, and tolerance.

Done when FollowJointTrajectory accept→feedback→cancel/result is tested in fake hardware
and a human can review changed files, commands, expected output, and unverified items.
Do not write a real-robot enable step.

Prompt C — symptom-based diagnostic plan

Classify this symptom and logs into network/discovery, QoS/type, time/TF, lifecycle,
controller ownership, vendor mode, tool/load, or safety state. For each hypothesis,
prioritize a read-only observation that can falsify it.

Do not disable firewalls, relax limits, disable watchdogs, force controller claims, or
allow automatic reconnect motion. Return observed evidence, remaining unknowns, the
next safe test, and the required human owner.

A useful prompt names goal, context, constraints, and a done condition ^[23]. “Move my UR5e with ROS 2” lacks versions, controllers, frames, limits, and tests. Codex returning UNKNOWN is part of safe integration, not a failure.

13. Evidence tiers, disagreements, and limitations

ROS interfaces, lifecycle, ros2_control, MoveIt, and vendor versions in this chapter use primary official software evidence. It supports dated interfaces and matrices, not independent latency or safety rankings. Architecture, TF, response-time, executor, and ros_control papers provide academic evidence. Some describe early ROS 2 or ROS 1 lineage, so current details were rechecked against 2026 documentation ^{[2] [11]}.

ROS 2 versus direct SDK is conditional. “ROS is always slow” and “SDK is always fast” are unsupported. Serialization and executors matter in some loops; when a vendor controller owns deadlines and ROS carries goals, integration visibility may dominate. A single-process low-level experiment may not need DDS. Compare measured worst-case latency with identical hardware and command semantics.

DDS QoS is also distinct from hard real time. Reliable does not mean before a deadline, and deadline notification is not deterministic execution. Functional safety includes hazard analysis, validated functions, physical stopping, and procedure. Lifecycle and command ownership improve auditability without creating a safety rating.

Limitations remain: matrices will change after 2026-07-14; recommended kernels and links do not guarantee installed timing; mock hardware validates packet contracts but not backlash, payload, stops, or cables; and public ISO pages do not replace normative text, local law, or qualified review ^[20].

Manufacturing Cell Checkpoint

For the UR5e+2F cell, write the complete path before motion. The task transforms an object from fixture_A into base, plans a pre-grasp, and executes through the selected scaled trajectory action. The integration owner draws camera, joint state, TF, MoveIt, action server, hardware interface, and UR driver. The network owner separates robot and bulk-data traffic and records domain, RMW, IP, routes, and time sync.

Log attempt_id, version_tuple, calibration_id, goal_frame, goal_stamp, joint_state_age, tf_lookup_age, plan_result, controller_name, action_goal_id, speed_scaling, safety_state, fault_code, cancel/result, operator_intervention. KPIs include stale-state rejection, plan-to-execute latency, cancel latency, missed cycles, protective stops, recovery time, and wrong-owner events.

Close UNKNOWNs through drives-disabled tests, mock hardware, offline logs, or supplier confirmation—not by moving the robot to see what happens. A robot that does not move on day one is not failure. An unexplained layer that allowed or blocked motion is failure.

What to Learn Next

You now know the responsibility boundary from a ROS 2 message to the real controller. (Chapter 5) turns joint and Cartesian goals into trajectories through IK, collision checking, time parameterization, MoveIt 2, and ros2_control. A planner cannot compensate for an incorrect TF, timestamp, or controller contract.

Before continuing, draw your cell on one page. Label every arrow with message or action type, frame, unit, rate, time source, owner, and failure behavior. Draw vendor control and physical safety as separate bold boundaries. That diagram becomes the reference for first motion in (Chapter 7) and teleoperation watchdogs in (Chapter 8).

Annotated research trail

These sources deepen middleware, orchestration, and executable validation. They are grouped by the assumption or experiment to inspect, rather than used as a list of borrowed success rates. Read each result within its platform and protocol.

References

1. Open Robotics (2026a). ROS 2 Jazzy Interfaces: Topics, Services, and Actions. ROS 2 official documentation.
2. Maruyama, Y., Kato, S., & Azumi, T. (2016). The Robot Operating System 2: Design, Architecture, and Uses in the Wild. IEEE/SICE SII. DOI: 10.1109/SII.2016.7847304. [Maruyama et al., 2016]
3. Casini, D., et al. (2019). Response-Time Analysis of ROS 2 Processing Chains under Reservation-Based Scheduling. ECRTS. DOI: 10.4230/LIPIcs.ECRTS.2019.6.
4. Picas, J. M., et al. (2019). ROS 2 Executor: How to Make It Efficient, Real-Time and Deterministic?. ROSCon 2019.
5. Foote, T. (2013). tf: The Transform Library. IEEE TePRA. DOI: 10.1109/TePRA.2013.6556373.
6. Open Robotics (2024). REP-2000 ROS 2 Jazzy Platform and Support Matrix. ROS Enhancement Proposal 2000.
7. Open Robotics (2026b). ROS 2 Lyrical Luth Release. ROS 2 official release documentation.
8. Open Robotics (2026c). ROS 2 Jazzy Managed Node Lifecycle. ROS 2 official package documentation.
9. ros-controls (2026a). Joint Trajectory Controller — Jazzy. ros2_control official documentation.
10. ros-controls (2026b). ros2_control Jazzy Architecture and Getting Started. ros2_control official documentation.
11. Chitta, S., et al. (2017). ros_control: A Generic and Simple Control Framework for ROS. Journal of Open Source Software. DOI: 10.21105/joss.00456.
12. Universal Robots (2026a). Universal Robots ROS 2 Driver Documentation. Official documentation.
13. Universal Robots (2026b). UR ROS 2 Driver Installation and Real-Time Guidance. Official documentation.
14. Universal Robots (2026c). UR ROS 2 Controllers and Speed Scaling. Official documentation.
15. Universal Robots (2026d). UR ROS 2 Driver Startup and Mock Hardware. Official documentation.
16. Franka Robotics (2026a). franka_ros2 Changelog through v2.4.0. Official release history.
17. Franka Robotics (2026b). libfranka Changelog and Packaging through 0.20.x. Official release history.
18. MoveIt (2025). MoveIt 2 move_group Architecture. MoveIt official documentation.
19. Bruyninckx, H. (2001). The OROCOS Project: Flexible Toolchain for Robot Control. IEEE ICRA. DOI: 10.1109/ROBOT.2001.932879.
20. ISO (2025). ISO 10218-2:2025 Robotics — Safety Requirements — Part 2: Industrial Robot Applications and Robot Cells. International Standard, edition 3.
21. Kinova Robotics (2024). KINOVA Gen3 Ultra Lightweight Robot One-Pager 2024. Official product documentation.
22. OpenArm (2026). OpenArm v2.0 Robot Description and ROS Namespacing. Official documentation.
23. OpenAI (2026). Codex Best Practices and Prompting. Official Codex guidance.
24. Liang, J., et al. (2023). Code as Policies: Language Model Programs for Embodied Control. IEEE ICRA. arXiv:2209.07753.