CodeTheRobot
Course outline

ROS 2 Lyrical Luth · Lesson 72 of 86

Multi-threaded executors and callback groups

Designing concurrency: groups, executors and avoiding deadlocks.

Estimated time · 60–90 min

Learning goals

What you will understand

  • Explain multi-threaded executors and callback groups in your own words
  • Use it in a small robotics example
  • Verify the result instead of assuming it worked

Understand the idea first

The mental model

Concurrency in ROS 2 is decided by two things: the executor (how many threads run callbacks) and callback groups (which callbacks may overlap). A MutuallyExclusive group serializes its callbacks; a Reentrant group lets them run in parallel. Different groups can always run at the same time on a multi-threaded executor.

A common deadlock: a callback that calls a service and waits for the answer in the same group the response needs to run in. Put clients in their own group, or use asynchronous calls. Protect shared data with a mutex, and measure the latency of the critical callbacks before and after.

Guided lesson

Work through these steps

  1. 1.

    Source the ROS 2 Lyrical environment in a fresh terminal.

  2. 2.

    Read the multi-threaded executors and callback groups example and identify what each line does.

  3. 3.

    Build only the affected package, source the workspace overlay, and run the example.

  4. 4.

    Inspect the result from a second terminal with the ros2 CLI or RViz2 and compare it with the expected result.

Worked example

Read it before you run it

auto control_group = create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive);
// Group for the control loop; its callbacks never overlap.
auto io_group = create_callback_group(rclcpp::CallbackGroupType::Reentrant);
// Group for slow I/O; callbacks may run in parallel.
control_timer_ = create_wall_timer(10ms, [this] { control(); }, control_group);
// The 100 Hz control timer belongs to the control group.
rclcpp::SubscriptionOptions opts; opts.callback_group = io_group;
// Put a subscription into the I/O group.
rclcpp::executors::MultiThreadedExecutor exec{rclcpp::ExecutorOptions(), 4};
// Four worker threads.
exec.add_node(node); exec.spin();
// Run the node.

What the example is doing

  1. 1.The ros2 commands query the running graph; they do not prove that a node's internal behavior is correct.
  2. 2.Build from the workspace root, then source install/setup.bash so the shell can discover the new package.
  3. 3.Use a second sourced terminal to inspect nodes and interfaces while the example runs.

Watch it run · Messages between nodes

See what this code does

The terminal types this lesson's practice solution and runs it. The scene shows the kind of robot behaviour that code drives. It plays by itself and loops.

/topicpublishersubscribersubscribermessages delivered: 0MESSAGES BETWEEN NODES

Demo for Multi-threaded executors and callback groups. Expected result: The control timer keeps 10 ms timing while slow work runs

Practice code

Now type it yourself

Copy the starter into your ROS 2 package, replace every TODO, then build with colcon build and run it from a sourced terminal.

auto control_group = create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive);
// TODO: create a 10 ms wall timer whose callback calls control(), assigned to control_group

Expected output

The control timer keeps 10 ms timing while slow work runs
Stuck? Show the full solution (try it yourself first)
auto control_group = create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive);
control_timer_ = create_wall_timer(std::chrono::milliseconds(10), [this] { control(); }, control_group);

Expected result

How you know it worked

  • ROS_DISTRO is lyrical in every terminal used for the exercise.
  • The complete package from the exercise builds and the expected graph entity appears in a second terminal.

Practical exercise

Apply the lesson

Reproduce a service-call deadlock with a single mutually exclusive group, then fix it with a separate group for the client. Measure the control timer's jitter before and after.

Before you continue

  • ROS_DISTRO reports lyrical in every terminal you used
  • The example builds and runs without errors
  • You checked the result with a ros2 command, RViz2 or a test, not just by reading the code

If something goes wrong

ros2 cannot find a package or executable.

Source /opt/ros/lyrical/setup.bash, build from the workspace root, then source install/setup.bash in that terminal.

Nodes run but cannot discover each other.

Confirm both terminals use Lyrical, the same ROS_DOMAIN_ID, and compatible network/discovery settings.