I’m working on project Reduce ROS2 Nodes and Determinism of OSPP2021 (under the mentor of Steve Macenski).
Currently, i’m trying to create a composition-based navigation package for embedded systems users that need to make optimizations due to harsh resource constraints. ( compose all Nav2 nodes in a single process instead of launching these nodes separately)
- first, i create multiple nodes in a single
- then, i create a multi-threaded executor to spin these nodes.
- in addition, i also use
option.use_intra_process_comms(true)to get efficient intra-process communication.
There were some problems when i tried to implement these.
- The first problem: some QoS isn’t supported (for example
transient-local), so some nodes which use
transient-localcouldn’t enable intra-process communication.
- The second problem: it consumes higher cpu usage (increase 50%), which confuses me.
For the first problem, i noticed that intra-process comms of rclcpp are still kind of under development, you could find more details:
For the second problem, i made some experiments for performance (memory and cpu usage), and python library
psutil was used to collect data.
- try a bunch of single threaded executors instead of 1 large multithreaded executor
- try to disable intra-process comms (
in this table, the case
Manual composition with multiple single-threaded executors looks good, it consumes lower cpu(saves ~20%) and lower memory(saves ~70%) than
Normal multi-process . you could find source code here (https://github.com/gezp/navigation2/blob/nav2_composition/nav2_composition/src/main.cpp)
we could look the cpu usage of these cases:
- Manual composition with multiple single-threaded executors : use a bunch of single-threaded executors for these nodes
- Manual composition with a multi-threaded executor: use a large multi-threaded executor for these nodes
It’s obvious that
a large multi-threaded executor consumes higher cpu(increase 30%-50%) than
a bunch of single-threaded executors , and i don’t know why, any discussion is welcome!