Karelics share their experience on "Migrating to the official ROS 2 Ouster driver from the community version"

[Samahu]

Karelics a company that builds fleet management solutions for robots and a user of Ouster sensors have recently authored an article that documents their experience and some of the findings they observed when migrating from the ouster driver for ros2 developed by the community and their transition to the official ros2 driver by Ouster.

Quite interesting read, please check it out here: https://karelics.fi/migrating-to-the-official-ros-2-ouster-driver-from-the-community-version

Here I share some of my thoughts and reflections about the article:

• Yes, we do lack sufficient documentation. The documentation as of now is very minimal and there are many details that needs to be added. Plus there are some features that are unique to the official driver that is not well publicized. User will only learn about these features if they dig into the source code or ask questions through Github or contact our support team.
• Binary distribution: All I need to say It is in progress and should happen very soon 🤞
• The ros2 official driver (like the ros1 version) also supports recording and replay of raw packets, The feature has been migrated from the ROS 1 branch, maintained and improved.
• Another feature available in the official driver but not publicized is the support sensor reconfiguration on the fly. Either directly through the sensor configuration page or through invoking the /ouster/set_config ros service.
• The only part that I disagree with in the Karelics article is their take on CPU utilization.
  • Yes, it appears on the surface as if we are using more CPU than the current community version, and this was the same observation I had when comparing the two on my own computer; In the chart below notice how the community driver represented in red uses less CPU than the official driver represented in blue especially as you use higher resolution lidar modes:
    
  • This really took me by surprise 👀 initially, however, my surprise immediately went away when comparing the publish frequency of generated point clouds:
    
    What this chart shows is that the official driver is able to match the sensor publish rate, meaning if the sensor is configured to run 1024x10 then the driver generates ~10 point clouds/seconds, if it was configured at 1024x20 we get about 20 Hz for the point cloud. Meanwhile, the community version generates point clouds at much lower rate.
• Another thing the article brought up, is an issue that was reported to us last week about the misalignment between the generated PointCloud and the LaserScan (for more details refer to Laser scan from ROS 2 driver is not properly aligned with point cloud #196). As it happens, I did investigate this issue earlier this week and yes it is true 😞 . The reason why this issue exists because we destagger the point cloud which is an operation that applies varying amounts of shifts to different rows in the PointCloud for correction. However, for things to be in place we need to apply the same operation to the LaserScan. Luckily, I had the fix for the issue implemented yesterday and pushed it to GH this morning Foxy PR and Humble/Iron
  • I had the fix ready and pushed out to GH before I was notified of the article .. I swear. 😸

Last but not least, I would like take a moment to thank everyone who developed and contributed to the community driver. It definitely filled the gap when Ouster didn't have provide an official support for ROS2. And also many thanks for everyone who downloaded the official driver and contributed either by reporting an issue, suggesting a feature or asking questions. A special thanks also goes to the developers who took time to submit a PR for a fix or adding new functionality (this has been great help and much appreciated!).

[tanelikor]

Thanks a lot for the response @Samahu! We are very happy to see such quick feedback. Below are some comments on your thoughts above, and some additional details from our look at the driver.

Thanks for reminding about some of the features available in the official driver! I did find the possibilities of packet recording/playback and the dynamic reconfiguration when looking through the package for our investigations. However, since we had relied on the community driver for quite a while and thus not learned to yearn for these features, I did not end up giving them a proper try (my focus was on checking the features important for us). Hence, they also weren't specifically mentioned in the blog post. We definitely intend to check them out in the future though, as I think they could be useful for us!

Your charts and findings about the CPU usages and point cloud frequencies look very interesting! 🤔 During our driver migration, I simply checked the couple modes that we primarily use (512x10/20 on OS-0 32) to check that everything was okay for us there. Since everything was fine, I didn't investigate any further, but did take note of the surprising difference in CPU usage. My apologies that I forgot to mention the modes used in the blog, this detail definitely should have been mentioned! Seeing these charts, I think we will want to take a deeper look at maybe starting to use the higher resolution modes on some of our devices that could benefit from them. Thanks a lot for the extra info!

About your comment on the LaserScan vs PointCloud misalignment: I can verify to all that you indeed were at least working on it before the blog was posted, because you had already replied to the issue I posted about it byt the time that I was sketching the blog text! 😁 It also looks like the issue will soon be fixed, which is great. Thanks for the quick action on the matter!

Finally, I also wish to extend our thanks - from myself and others at Karelics - to all who have helped with or contributed to the development of both the community driver and the official one! Without these packages and their continued support, we certainly would have had our work cut out for us for the past couple years. 😅 Here's to many more improvements to come! We will continue using the driver and helping to improve it where we can!

[Samahu]

By all means, please double check the results. I did my due diligence when comparing the performance but I could definitely stand corrected.