fix: Add useRosConvention flag to output RGBD point clouds w.r.t. ROS frame conventions

[Finn2708]

🦟 Bug fix

Fixes #29
Fixes #545

This adds a new <gz:useRosConvention> tag to URDF/SDF files that allows overriding the point cloud orientation. When the flag is set true, the point cloud is rotated to match the expected coordinate frame convention in ROS (X right, Y down, Z forward / depth):

Since the issue has been up for a couple of years, I maintained backwards compatibility when <gz:useRosConvention> is either set to false or unset (X forward / depth, Y left, Z up):

Snippet how this integrates into URDF:

    <gazebo reference="${name}_link">
      <sensor name="${name}" type="rgbd_camera">
        <gz_frame_id>${name}_optical_link</gz_frame_id>
        <camera name="${name}">
          <gz:use_ros_convention>true</gz:use_ros_convention>
          <...>
        </camera>
      </sensor>
    </gazebo>

I'm not sure if this is the best solution, but I am also not very familiar with URDF/SDF nuances. Consider this perhaps a suggestions, I'm happy to move this around or rename if required.

Backport Policy

I would like to see this backported to older releases. Because some code structure changes, it's not 1:1 compatible, but the logic is transferable. I have a version of this that is compatible with Harmonic locally I could submit.

• This is safe to backport to the following versions:
  • Jetty
  • Ionic
  • Harmonic
  • Fortress
• This should not be backported
• I am not sure
• Other (fill in yourself)

Checklist

• Signed all commits for DCO
• Added a screen capture or video to the PR description that demonstrates the fix (as needed)
• Added tests
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• Updated Bazel files (if adding new files). Created an issue otherwise.
• While waiting for a review on your PR, please help review another open pull request to support the maintainers
• Was GenAI used to generate this PR? If so, make sure to add "Generated-by" to your commits. (See this policy for more info.)

Generated-by: Remove this if GenAI was not used.
I wrote the code myself, but had Claude write the docstrings, review my changes and discussed integration into URDF / SDF.

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by and Generated-by messages.

Backports: If this is a backport, please use Rebase and Merge instead.

[iche033]

there's also been discussions of gz to ROS frame conventions in #488, and as the result, the override_frame_id param was added to ros_gz bridge to allow overriding gz frame ids for ROS: https://github.com/gazebosim/ros_gz/tree/ros2/ros_gz_bridge#gz-to-ros-frame_id-override

Would this solve the problem in your use case?

[Finn2708]

I was not aware of that specific parameter, but the concept of having a different frame for the point cloud is explained in #29 and #545. I am of the opinion that this is more of a workaround than a fix, because it results in different frame ids for image and point cloud.

When processing both simultaneously, you would have to transform one into the frame of the other. In application code, you could not do the cheap approach of just flipping signs and order of axes as done here, because you would need to be able to handle any arbitrary transform between the frames or introduce unexpected limitations within your application.

Additionally, (as far as I understand) the user still has to manually create the static transformer. For my specific use case, I build multiple robots from the same URDF and just apply different configurations to achieve different robot and sensor setups. Using the ros_gz frame override, I'd have to publish the static transform myself which adds coupling from my URDF configuration to my launch file which I would like to avoid.

Perhaps this could better be fixed in ros_gz or specifically ros_gz_bridge, but I would strongly prefer if my simulation gave data comparable to my real-world sensors and would not require extra workarounds.

[iche033]

ok there was a preference for frame transformation to be handled on the ros_gz side at the time but similar requests keep coming back.

If we do decide to add frame transformation here, I would prefer it to be more generic than useRosConvention, e.g. a param takes in a pose and applies the transformation to point clouds xyz values.

but first @azeey, see if you want to weigh in here as well.