When integrating a new robot with our Karelics Brain, we sometimes wish to equip it with our own Karelics payload to provide extra sensors and/or computation power for the Brain. One common component of this payload is a lidar sensor, which we use for long-range vision during mapping, localization and navigation. We predominantly use Ouster lidars, more specifically, the OS-0 32 series.
Ever since we migrated to ROS 2 in 2021, there has been a lack of an official ROS 2 driver for the Ouster lidars. Hence, we have relied on the community-developed driver. But, since the inception of ROS 2 Humble and even before, we have been aware that an officially supported driver is on its way and that it should eventually replace the community driver in our system. During the migration of our Karelics Brain to Humble, we also decided to try the now-available official Ouster driver.
Table of Contents
First impressions: Promising, yet not enough
We first tried the official driver in the early summer of 2023. Our first impressions at this point were two-fold. On the one hand, the driver looked mostly ready and also included some nice-looking improvements to the community version. For example, the driver node was split into different components (sensor, cloud and image), making it easy to completely leave out some parts that one doesn’t need. It also had some configuration options that were not available on the community version. Moreover, it fixed some incorrect frame settings in the community version, which would cause some changes to our robot configurations but was still something we were happy about.
On the other hand, the driver still looked like somewhat of a work in progress. The documentation of the ROS 2 version was lacking, especially for the parameters. This meant that a big part of the migration was taken up by the need to browse the older ROS 1 documentation and compare it to the available configurations of the ROS 2 version to get some of the basic parameters right and get the driver running. The lack of binaries was also a minor surprise, though it did not pose any problems: building the driver from source was a breeze when following the package readme. Still, it is worth mentioning that the way of building described in the readme seems to be still the only “easy” way of installing the driver, with any deviations from it likely requiring more or less manual dependency management.
All of this was, of course, not blocking. So, we gave the driver a try, and it seemed to work well. However, we noticed one necessary feature missing: the driver did not provide a 2D laser scan. While most robots running Karelics Brain with Ouster lidars use only data from the 3D point cloud, some require the 2D scan instead. Thus, we could not fully migrate to the official driver without this feature. Luckily, this and many other problems mentioned above would be quickly addressed.
New updates, new hope
Fast forward a couple of weeks spent on other tasks, and we were ready to start planning for implementing the 2D laser scan feature ourselves, possibly also contributing to the driver. However, it turned out that this was no longer necessary because the feature had just been added in a recent PR. What a pleasant surprise!
Fast forward a bit more to early August due to vacations and other pressing tasks, and we finally got to give the driver a second chance. By this time, the package had received a few more updates, some of which included descriptions of all parameters in the example parameter file! This was very helpful when configuring the driver for the second try.
So, we fired up the driver and started playing around with its configuration. In no time, the lidar and driver provided us with all the data we wanted. Our Humble migration test robot (Robauta Sampo) also operated normally after changing the driver. Everything looked good, but there was still one more test before we could fully approve switching the driver: a side-by-side comparison against the trusty old community version that we had learned to work with.
Comparison to the community version
When comparing the two drivers, we focused on three main categories: features, stability and performance. Based on the configuration phase, we were already quite confident that all the features of the community driver were also present on the official one, but double-checking never hurts. Still, stability and performance were the topics that we were primarily interested in at this stage.
Regarding the features, the official driver delivers all that the community driver does and more. Below is a table of features that we currently require and some others that are new in the official driver.
| Feature | Official driver | Community driver |
| Sensor and client IP configuration | ✅ | ✅ |
| UDP profile options | ✅ | ❌ |
| Lidar mode (horizontal resolution & frequency) selection | ✅ | ✅ |
| Time synchronization/stamping from PTP | ✅ | ✅ |
| Laser and IMU port selection | ✅ | ✅ |
| Frame name configuration | ✅ | ✅ |
| Reference frame selection | ✅ | ❌ |
| Disable/enable different outputs (point cloud, scan, imu, image) | ✅ | ✅ |
| Selection of ring used for LaserScan | ✅ | ❌ |
| QoS selection | ✅ | ✅ |
In addition to the table above, we reviewed all the channels and features of point clouds and scans. All was good there, except for one issue that exists in both drivers: misalignment of the scan and point cloud. The scan seems to be rotated counterclockwise by about 2-3 degrees compared to the point cloud. This issue has been known in the community driver for a while but appears also to affect the official driver.
Stability-wise, the only notable find was something that also exists in both drivers: the node crashes if activated without connection to the device. At the time of writing this, there are plans for a fix in the official driver’s repository, so here’s hoping that the issue will not persist for much longer.
The performance-side results were essentially a saw-off: Both drivers provided point cloud, scan and IMU data with close to identical latencies. The official driver seems to take a bit more CPU, but not so much that it would be in any way problematic. In our test system (Robauta Sampo running – except for the lidar driver – identical full Karelics Brain & Robauta software on an Intel NUC in a docker container), we got the following results.
Measurement | Official driver | Community driver |
Point cloud latency (min, max, avg) ms | 113, 116, 114 | 113, 116, 114 |
Scan latency (min, max, avg) ms | 112, 113, 114 | 112, 112, 114 |
IMU latency (min, max, avg) ms | 0.2, 0.6, 4.3 | 0.2, 0.6, 4.1 |
CPU usage | 8-9 % | 4-5 % |
One last comparison to make was the support and maintenance of the software. This comparison goes to the official driver by a clear margin, as it has received many updates in recent weeks, while the community driver’s main branch had its last update in April of 2023. This trend is also likely to continue. Combining this with more features, practically equal performance and mostly the same issues (that we have existing workarounds for), we could happily decide to switch to using the official driver!
Other observations
During the investigations for the migration, we also ended up taking a look into some other parts of the system related to the Ouster lidars. Perhaps the most notable of these is the firmware, the updates of which we had not been following that keenly. As a result, our devices of various hardware revisions were (and some still are) running various firmware versions, starting from version 2.0.0. Since the latest firmware version is 2.5.2, we decided to try updating to that on one of our oldest devices.
On the surface, it doesn’t look like this changed much. This is good since it means all our devices should still function the same regardless of when they were last updated. But, we did notice one notable difference: in the newer firmware version, the default UDP profile of the lidar seems to have changed from LEGACY to RNG19_RFL8_SIG16_NIR16. This should be a good thing, especially considering that the LEGACY mode is marked as “not recommended” in the driver repository. All in all, we now plan to update all our devices to the latest firmware version as soon as we have gotten a couple of good stress tests done with the shiny new setup.
Final remarks
Summing up our experience with the official ROS 2 Ouster driver thus far, we can highly recommend migrating over from the community version. One will have to spend some time remapping the configurations, but for the most part, this has been made very easy by keeping most parameter names the same as in the community driver. Once the switch is done, the new driver offers the same performance with extra features and much more active support than the community version.
We at Karelics will now continue onward with the official driver, and look forward to some of the next promising updates. We believe that they will solve some of the last more significant annoyances and thus lift the quality and stability of the official driver well and permanently above those of the community version.
