ros2 / ros2/examples

set the priority of callback to high introduces some delay compared to simple MultiThreadedExecutor

Open
#427 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
970
Forks
365
Avg merge
12d 20h
Merged PRs (30d)
1

Description

hi, I try to set one callback higher priority following the example cbg_executor . But It seems it introduces some delay compared to using MultiThreadedExecutor.

I publish on the topic "high_pong" at rate 100Hz. In the pong_node.cpp, I set the parameter "high_busyloop" to 1.0, and print the timestamp when receiving the msg.
Use the code in pong.cpp (setting high_prio_executor to ThreadPriority::HIGH), the output is (msg receiving interval is 1050ms):

Image

But if I simply use MultiThreadedExecutor and add the pong node:

  auto pong_node = std::make_shared<PongNode>();
  rclcpp::executors::MultiThreadedExecutor multi_executor1;
  multi_executor1.add_node(pong_node);
  multi_executor1.spin();
  rclcpp::shutdown();
  return 0;

the output is (msg receiving interval is 1000ms):

Image

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the cbg_executor example, then compare pong_node.cpp and pong.cpp where high_busyloop is set to 1.0 and high_prio_executor uses ThreadPriority::HIGH. Reproduce the high_pong timing with both that setup and MultiThreadedExecutor, then trace the callback scheduling and thread-priority behavior to identify the source of the delay. Done means the cause is explained and the priority-based executor no longer adds the reported interval delay.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
operating-systems, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.