Skip to content

ROS 2 Core Communication and Execution

Source: ros2-copilot-skills catalog

Why This Matters

Many ROS 2 problems look like package or parameter mistakes when the real issue is a broken communication contract. If a topic uses the wrong QoS, if a long-running task was implemented as a service instead of an action, or if callbacks are blocked by the executor model, the robot will behave unpredictably even when the code compiles cleanly.

Distilled Takeaways

  • Topics are for streaming data, services are for short request-response work, and actions are for long-running tasks with feedback, cancellation, and result handling.
  • QoS is not an advanced corner case. It is the transport contract, and mismatches can make publishers and subscribers silently ignore each other.
  • Executors and callback groups decide what can run concurrently. A node can deadlock itself if it waits synchronously inside a callback that shares the same execution path.
  • Lifecycle nodes are useful when startup order, controlled activation, and deterministic shutdown matter, which is why Nav2 relies on them heavily.
  • A lot of debugging becomes easier when you treat ROS 2 as a graph of communication contracts instead of a pile of nodes.

Practical Value

  • When a sensor stream appears to vanish, inspect QoS before touching the driver.
  • When a robot task needs progress updates or cancellation, reach for an action instead of inventing ad hoc topics.
  • When a launch sequence is flaky, check whether the involved nodes should be lifecycle-managed.
  • When callbacks interfere with each other, review executor choice and callback-group boundaries before adding threads blindly.

Core Follow-Up Articles

Corroborating References

When to Read the Original Source

Go to the original skills when you want concrete code for Python and C++ nodes, action client and server patterns, callback-group examples, and the practical warning tables around QoS mismatches and executor deadlocks.