add support for lyrical

[christian-rauch]

This adds support for ROS 2 lyrical by mainly replacing ament_target_dependencies with the targets for target_link_libraries.

[christian-rauch]

@ob-yalian Can you have a look at this PR to get the lyrical and rolling support merged?

[christian-rauch]

@ob-yalian @jjiszjj @winf Can you comment on this PR or let me otherwise know, who is maintaining this repo and who I should contact?

[ob-yalian]

@christian-rauch Sorry for the late reply. Thanks for the reminder and for all the work you've put into this PR.

I'll review the changes as soon as possible and get back to you with feedback.

[obshenlanzhou]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 292275b83b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[christian-rauch]

@ob-yalian @obshenlanzhou Can you check the codex review and my responses? I am not sure how much sense they make. Can you comment on your own what the issues with the proposed changes are?

[christian-rauch]

@codex review

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.

[christian-rauch]

@ob-yalian @obshenlanzhou I also addressed the codex comments. Can you please review this again?

[ob-yalian]

@christian-rauch Thanks for your contribution and for working on Lyrical support.

After reviewing this PR, we are not going to merge it as-is. We are already working on Lyrical adaptation internally, and we will use your implementation as an important reference.

[christian-rauch]

After reviewing this PR, we are not going to merge it as-is. We are already working on Lyrical adaptation internally, and we will use your implementation as an important reference.

Is there a reason you cannot use my PR? I am happy to continue working on this and sign an CLA if this eventually results in the lyrical support getting merged.

Do you have an ETA when lyrical support will be available?

[ob-yalian]

@christian-rauch The main reason is that the current PR has a relatively large impact area. Our goal is to support Lyrical while keeping the scope of changes as controlled as possible, and ensuring that the currently supported ROS 2 distributions continue to work as before.
One typical example is that this PR builds successfully in some newer Humble/Jazzy/Lyrical environments, but fails on an older yet still valid Humble patch version that we tested. Therefore, we currently prefer not to merge this PR directly.
Thanks again for your work.

[christian-rauch]

Granted, the changes cover a larger area. But mostly, this is porting from ament macros to target_link_libraries, renaming of headers (h -> hpp), and some API changes around the QoS settings.

I am also adding a CI pipeline, as none existed before, to verify that this builds on the currently supported ROS 2 LTS versions. If it helps, I can propose PRs with a subset of these commits. E.g., you could start by reviewing the CI pipeline in #195.

If there are functional/behaviour issues on humble, I am happy to test this.

I am genuinely interested in getting lyrical support merged. The software support for the Orbbec cameras is always lacking behind. At the moment, it is not really clear from @orbbec, when lyrical will be supported, and how that support will actually differ from my port.

[bmagyar]

@ob-yalian @jjiszjj @winf my advice is to avoid repeating what Realsense did with their drivers and branch the ROS drivers for different ROS releases. It's very hard to keep everything compatible and working all at once, there is no reason to subject your team to that level of stress.

I have a very similar set of changes in my own fork which I'm using now on many robots, @christian-rauch has his fleet running this and probably a few other people are using this branch now instead of your upstream version.

My suggestion is to drop Foxy, branch for Humble, branch for Jazzy and do backporting from rolling/lyrical to them, like everyone else does.

[christian-rauch]

@ob-yalian @jjiszjj @winf @obshenlanzhou Can you, or someone else from Orbbec, please comment on the Orbbec strategy to support newer Ubuntu and ROS 2 versions? Months have passed since the ROS 2 lyrical release, and it is still unclear when this will be supported.

The software support from Orbbec is lacking behind your competitors. It takes a lot of time to get obvious issues, such as wrong calibration data (frames, distortion coefficients, ...), fixed. Even if your customers provide the fixes for your issue, it takes a lot of time to get them merged, or they are not considered at all, like in this case with lyrical support.

I don't expect stellar software support like the original Azure Kinect DK or the RealSense, ... but you do not even have a CI pipeline to detect regressions.

We rely on this software support to use the sensors on robots, run demos, and collect data for papers. It is very frustrating, that the software support for your sensors is so bad.

The hardware is great, but it is difficult to recommend the sensor hardware to someone who does not want to tinker with the driver source code themselves.

Please, improve the software support and accept contributions from the people that actually use your sensors for real work.

[obshenlanzhou]

@christian-rauch We plan to first merge this PR into the new lyrical branch. After internal testing and evaluation, we will consider merging it into the v2-main branch. In the meantime, developers can use the lyrical branch to get ROS 2 Lyrical support.

[christian-rauch]

@christian-rauch We plan to first merge this PR into the new lyrical branch. After internal testing and evaluation, we will consider merging it into the v2-main branch. In the meantime, developers can use the lyrical branch to get ROS 2 Lyrical support.

I can only second @bmagyar here and recommend that you maintain all ROS distros from a single branch (v2-main), using #defines to switch between API. Maintaining three branches (main, v2-main, and lyrical) will be a massive overhead. The required API switches are minimal and only touch message_filters and image_transport in two places. This is far easier to maintain than backporting to two different code bases. This PR also includes a CI pipeline to ensure that the compilation does not break on all currently supported ROS 2 LTS distros.

I just rebased my lyrical branch on top of your HEAD and fixed the merge conflicts. Please consider merging this to v2-main. You have a few customers that test the source builds of your software in between releases. Use them to test the software, if you cannot do this yourselves. I am happy to test beta software, if it means I get good software support in the end.