In the theme of #3914
@JanStaschulat quick question on rclcpp::Timers: if I use the default callback group / executor of the component given by the container, can I simply set the thread priorities in the node's constructor? The velocity smoother [1] is another area where increased priority would be helpful. I believe this is true of subscriptions, which solves the collision monitor case [2].
[1] https://github.com/ros-planning/navigation2/blob/main/nav2_velocity_smoother/src/velocity_smoother.cpp#L145-L147
[2] https://github.com/ros-planning/navigation2/blob/main/nav2_collision_monitor/src/collision_monitor_node.cpp#L66-L68
I went through the real-time workshop slides and all of the examples I found using current tooling involved creating an executor, adding nodes to it, and then spinning it in a separate thread where the priorities were set. When using Composition, which Nav2 extensively uses, we don't create our own executors to be able to control them -- the component container does. I wanted to touch base before I spent too much time on those nodes [1-2] in case there was a significant technical reason why you didn't add them in-line in the code and did so at the main.cpp level with the executor population. I suspect it was just the most general for demonstration without getting into the specifics of the nodes, but just verifying that before putting resources into it.
In the theme of #3914
@JanStaschulat quick question on rclcpp::Timers: if I use the default callback group / executor of the component given by the container, can I simply set the thread priorities in the node's constructor? The velocity smoother [1] is another area where increased priority would be helpful. I believe this is true of subscriptions, which solves the collision monitor case [2].
[1] https://github.com/ros-planning/navigation2/blob/main/nav2_velocity_smoother/src/velocity_smoother.cpp#L145-L147
[2] https://github.com/ros-planning/navigation2/blob/main/nav2_collision_monitor/src/collision_monitor_node.cpp#L66-L68
I went through the real-time workshop slides and all of the examples I found using current tooling involved creating an executor, adding nodes to it, and then spinning it in a separate thread where the priorities were set. When using Composition, which Nav2 extensively uses, we don't create our own executors to be able to control them -- the component container does. I wanted to touch base before I spent too much time on those nodes [1-2] in case there was a significant technical reason why you didn't add them in-line in the code and did so at the main.cpp level with the executor population. I suspect it was just the most general for demonstration without getting into the specifics of the nodes, but just verifying that before putting resources into it.