You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Question
compile option to increase the real-time performance on raspberry pi 5 and livox HAP
Existing resources
I am using Livox HAP with Pi5 (Cortex A76 2.4GHZ, bookworm 64bit os). Fast-LIO2 and WAVEMAP 2.0.1 is used.
As the PCD from Livox HAP is larger than MID-360, this leads to large CPU consumption and poor real-time performance.
In my application with slow-moving vehicle, I can exclude the far-away PCD to improve real-time performance, or any method to decrease the update rate of wavemap to decrease the CPU consumption. Thanks!
By default, wavemap allocates as many threads as your system has cores. Given that the Pi only has 4 and you're sharing them with other relatively heavy processes (FastLIO,...), there's probably a lot of task switching going on. You can change wavemap's thread count using the general/num_threads param. Setting it to a lower value might actually improve performance on your Pi and should also make the system more stable overall.
Another thing you could try is to reduce the publishing frequency in the Livox driver. E.g. if you notice that on average wavemap takes 200ms to integrate your pointclouds, you could reduce the rate to 5H…
Hi @YoungCapta1n,
Cool to hear that running wavemap on a Raspberry Pi works! Could you share your wavemap config file? Then I can take a look and give suggestions to improve its performance/efficiency.
What are you using the map for? Obstacle avoidance, traversability estimation, global path planning, or something else?
Hi, Dr. @victorreijgwart , I wonder if there is a method to modify the the number of CPU threads used by Wavemap. On the Raspberry Pi5, the Wavemap will take 4 threads by default. I want to reduce the number of threads, even though the update frequency will decrease. Thanks!
By default, wavemap allocates as many threads as your system has cores. Given that the Pi only has 4 and you're sharing them with other relatively heavy processes (FastLIO,...), there's probably a lot of task switching going on. You can change wavemap's thread count using the general/num_threads param. Setting it to a lower value might actually improve performance on your Pi and should also make the system more stable overall.
Another thing you could try is to reduce the publishing frequency in the Livox driver. E.g. if you notice that on average wavemap takes 200ms to integrate your pointclouds, you could reduce the rate to 5Hz. Assuming the Livox driver behaves similarly for the HAP LiDAR as for the MID360, it will then put more points into each pointcloud msg (instead of deleting points). Wavemap internally converts each cloud into a special kind of range image, keeping the point that's closest to the robot for each pixel. So, if there are a lot of overlapping points, there will be some information loss, but it's still better than dropping entire pointcloud msgs because the CPU can't keep up. I'd expect that FastLIO would also be ok with a lower pointcloud publishing rate, but best to try it out to be sure.
I saw that you publish the map at 5Hz. Is this because you use it for collision avoidance or some other node that requires low latency? Wavemap transmits the map incrementally (only the blocks that changed), but publishing ROS messages is still relatively expensive. If you don't need such a high update rate, I'd recommend lowering it. Alternatively, if your planner updates are relatively fast, you could run them in the same process as wavemap by adding your planner as a custom MapOperation. This would remove all transmission overheads and latency. You can see an example project where we used this feature here.
Finally, Rviz also takes a lot of processing power, so if you can, it's nice to run it on a computer other than your robot (e.g. an operator's laptop).
Thanks!
The livox hap output point cloud at 10Hz, and Fast-LIO2 use 2 threads with OpenMP enabled. The Rviz is disabled.
The config used in Wavemap is used (e.g. num_threads:2 , max_range: 25.0 ), it works well. I will modify the code in Fast-LIO2 and use without ROS1 and docker. I will report the performance later.
Glad to hear it's working well now! In case you'd like to try a lower publishing rate in the Livox driver, you can change it using this param.
Taking out ROS completely would probably take quite some effort, as you'd have to implement the data sharing between the Livox driver, FastLIO, and wavemap yourself. But if you decide to go for this option and have questions when setting up wavemap in non-ROS mode, let me know.
I'll close this discussion as completed for now. Feel free to reopen it if you have follow-up questions :)
This discussion was converted from issue #72 on September 05, 2024 13:04.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Hi @YoungCapta1n
The config you shared looks good in general!
By default, wavemap allocates as many threads as your system has cores. Given that the Pi only has 4 and you're sharing them with other relatively heavy processes (FastLIO,...), there's probably a lot of task switching going on. You can change wavemap's thread count using the
general/num_threadsparam. Setting it to a lower value might actually improve performance on your Pi and should also make the system more stable overall.Another thing you could try is to reduce the publishing frequency in the Livox driver. E.g. if you notice that on average wavemap takes 200ms to integrate your pointclouds, you could reduce the rate to 5H…