feat(Ouster): implement nebula's Ouster port as a submodule

[Samahu]

PR Type

• New Feature

Related Links

Closes #212
Related #433

• Applying maintainers feedback

Description

The PR adds support for all current generation Ouster Lidars running FW 2.2 through 3.2
The PR imports OusterSDK as a submodule in contrast to #433

Review Procedure

• Run the vcs import command to clone ouster-sdk into the nebula main folder

vcs import < build_depends-${ROS_DISTRO}.repos

• You can build the branch using the following command:

colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=1 --packages-up-to nebula_ouster

• Edit the provided sensor_model.param.yaml and set the sensor_ip and dest_ip to match your environment
• Launch the sensor using the command

ros2 launch nebula_ouster ouster_launch_all_hw.xml sensor_model:=ouster_sensor

Remarks

Pre-Review Checklist for the PR Author

PR Author should check the checkboxes below when creating the PR.

• Assign PR to reviewer

Checklist for the PR Reviewer

Reviewers should check the checkboxes below before approval.

• Commits are properly organized and messages are according to the guideline
• (Optional) Unit tests have been written for new behavior
• PR title describes the changes

Post-Review Checklist for the PR Author

PR Author should check the checkboxes below before merging.

• All open points are addressed and tracked via issues or tickets

CI Checks

• Build and test for PR: Required to pass before the merge.

[Samahu]

Hi, I have attached a rosbag file showing a pre-recorded pointcloud osdome128.bag.zip. Once you unpack the zip file you may view its content as follows:

• Play the bag file

ros2 bag play osdome128.bag --loop

• Run RVIZ

ros2 run rviz2 rviz2

• Modify RVIZ config to:
  • frame: ouster_lidar
  • add pointcloud topic and set the reliability policy to "Best Effort"

Once you complete these steps you should get the following output:

[Samahu]

I noticed the build is failing due to the error:

CMake Error at CMakeLists.txt:9 (message):
  nebula_ouster_decoders: bundled ouster-sdk is missing
  (/__w/nebula/nebula/src/nebula_ouster/nebula_ouster_decoders/../../../ouster-sdk)

Does the gitflow build actions run the command: vcs import < build_depends-${ROS_DISTRO}.repos before trying to build?

[mojomex]

@Samahu I see.
The CI is importing the repos: https://github.com/tier4/nebula/actions/runs/24354784720/job/71604103565?pr=436#step:10:92

It seems that none of the nebula_ouster* packages have a <depend> on the SDK, causing Colcon to skip building and linking it.

I have no experience with package.xml dependencies on non-ROS (normal CMake) projects, so it might be enough to add the <depend>, or it could be necessary to add the SDK into the source tree of nebula_ouster_decoders as a git submodule.

[codecov]

Codecov Report

❌ Patch coverage is 8.56423% with 363 lines in your changes missing coverage. Please review.
✅ Project coverage is 38.93%. Comparing base (9cb61cc) to head (f2810f3).

❌ Your patch check has failed because the patch coverage (62.96%) is below the target coverage (90.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #436      +/-   ##
==========================================
- Coverage   40.23%   38.93%   -1.30%     
==========================================
  Files         131      139       +8     
  Lines       10280    10677     +397     
  Branches     5393     5478      +85     
==========================================
+ Hits         4136     4157      +21     
- Misses       3793     4206     +413     
+ Partials     2351     2314      -37     

Flag	Coverage Δ
nebula_ouster	8.56% <8.56%> (?)
nebula_ouster_common	8.56% <8.56%> (?)
nebula_ouster_decoders	8.56% <8.56%> (?)
nebula_ouster_hw_interfaces	8.56% <8.56%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Samahu]

Codecov Report

❌ Patch coverage is 0% with 398 lines in your changes missing coverage. Please review. ✅ Project coverage is 38.72%. Comparing base (9cb61cc) to head (22ed451).

I did add code coverage the HW module, can we run code coverage again. Thanks

[guthabharadwaj]

Hi team, thanks for the work on this PR.

I've been working on a parallel effort that adds Ouster support (OS-0/OS-1/OS-2, any beam count including 128) without requiring the Ouster SDK, to keep Nebula's dependency footprint minimal and consistent with the existing Hesai/Velodyne/Robosense vendor integrations. Packet parsing, per-beam XYZ projection, and metadata handling are all implemented natively.

I've opened it here: #440
It's been tested against a physical OS-128 running through the full Autoware Lidar pipeline on ROS 2 Humble.

I'm open to combining efforts if that would be useful, happy to collaborate with @Samahu on aligning the two designs. Please let me know what else I'd need to do to get this ready for the codebase.

[Samahu]

Hi team, thanks for the work on this PR.

I've been working on a parallel effort that adds Ouster support (OS-0/OS-1/OS-2, any beam count including 128) without requiring the Ouster SDK, to keep Nebula's dependency footprint minimal and consistent with the existing Hesai/Velodyne/Robosense vendor integrations. Packet parsing, per-beam XYZ projection, and metadata handling are all implemented natively.

I've opened it here: #440 It's been tested against a physical OS-128 running through the full Autoware Lidar pipeline on ROS 2 Humble.

I'm open to combining efforts if that would be useful, happy to collaborate with @Samahu on aligning the two designs. Please let me know what else I'd need to do to get this ready for the codebase.

Thanks @guthabharadwaj for your contribution .. I understand the appeal to not use ouster-sdk due to its size. I can't decide what path nebula team could take but not depending on the ouster-sdk could mean a lot more effort will be needed (from nebula team) to maintain support for newer iterations of Ouster FW and HW revisions.

(also note this PR already supports OS0, OS1, OS2 and OSDOME, with any beam count 32/64/128. I haven't created launch files for any of these configurations thought as I am not sure whether it is necessary since the main launch file works for all)

[drwnz]

@guthabharadwaj @Samahu
Thank you both for your contributions!
One important consideration: we are now releasing Nebula binaries via ROS2 buildfarm. I think adding a git submodule will most likely break bloom-release.
Therefore, @guthabharadwaj 's approach has a strong advantage in this area. @Samahu how much do Ouster FW updates change the sensor interface? Up until now, it has not been much of an issue on production devices and new FW features are added as required. But if you have many FW updates that are breaking changes (that the SDK can absorb) then this is also an important consideration.

[mojomex]

@drwnz @Samahu The concern is valid - and the ROS 2 buildfarm docs (that I found) don't specify what happens with submodules. However, the official Ouster driver ouster_ros has the SDK as a submodule. I'm not sure if Ouster is doing any trickery to get it to work, so that would be interesting to know before continuing the discussion.

As for whether we generally want to use vendor SDKs, I'd personally answer that with a definite yes in high quality cases like Ouster's SDK. As pointed out by @Samahu, maintenance overhead per vendor can be significant, especially when the sensor docs don't document everything.

[Samahu]

For ouster-ros I do have a separate branch that directly embeds the required files from ouster-sdk rather than using the submodule when I want to release the package via bloom-release.

I guess we have 3 approaches each with its out specific:

• This PR which uses submodules offering a low maintenance but will hinder the bloom release process.
• The original MR Add support for Ouster Lidars #433 embeds the sdk but adds a lot of files.
• feat(ouster): add native Ouster lidar driver #440 has minimal dependency but likely is not up to date with the FW features and support and will incur maintenance overhead (In a way it is diverged implementation from the SDK, that Ouster isn't going to support). I still welcome the contribution from @guthabharadwaj but my concern is the long term support plan. Currently, we do have a FW update every 6-18 months.

There are two further takes I would like us to consider:

• Get back to Add support for Ouster Lidars #433 and trim the files further .. with minimal divergence.
• Work with the SDK team to publish a debian package which we can reference directly from package system.

I can get back to you on these two options in the next week.

[guthabharadwaj]

Thanks @Samahu for the breakdown, and the FW-support concern is completely fair coming from your vantage point. I agree a path that stays close to the SDK is the stronger long-term bet for Nebula.

I'd be genuinely happy to help move this forward by contributing to trimming #433 further. Just let me know where I can be useful.

[Samahu]

Thanks @Samahu for the breakdown, and the FW-support concern is completely fair coming from your vantage point. I agree a path that stays close to the SDK is the stronger long-term bet for Nebula.

I'd be genuinely happy to help move this forward by contributing to trimming #433 further. Just let me know where I can be useful.

Thanks @guthabharadwaj , I think did drop few unnecessary dependencies on that branch but haven't pushed my changes. Let me push these changes and copy some of the changes I did here for coverage and then we restart that branch .. the biggest contender in terms of number of added files was libjsoncons .. the issue is this library is only available via vcpkg install .. no apt install and is not available on the rosdep.

There are multiple pathways to go about how we trim this dependency but let me restart the branch by the end of the week.