Lidar sensor appears detached from USV model in VRX Gazebo (ROS 2 Jazzy)

[Va5k3]

In the VRX Gazebo simulation using Ubuntu 24.04, ROS 2 Jazzy, and Gazebo Harmonic, the lidar sensor visualization appears detached from the vessel model. Instead of being rigidly attached to the USV, the lidar rays are rendered at a fixed offset position in the world (0, 0, 0).

The issue occurs on a clean installation, using the default VRX packages, without any custom modifications.

As a result, the lidar data does not follow the boat pose and is unusable for perception and navigation tasks.

Any guidance or suggestions on how to resolve this issue would be greatly appreciated.

[strangerwhoisharborofdoom]

Hi @Va5k3! I'm a first-year Robotics Engineering student and I'd like to contribute to fixing this lidar sensor attachment issue.

This sounds like a coordinate transform or URDF/SDF link pose problem. The lidar rays being rendered at world origin (0, 0, 0) instead of following the USV suggests the sensor's parent link or transform isn't being properly applied in the simulation.

I'll start by:

1. Examining the USV model's SDF/URDF to check the lidar sensor's parent link and joint definitions
2. Checking if there are any recent changes to the VRX Gazebo integration for ROS 2 Jazzy
3. Verifying the transform tree is being properly published and updated
4. Testing with the default VRX packages to reproduce the issue

I've already contributed to gazebosim/gz-sim with PR #3367 (documenting ECM computational complexity) and am working on a Blender API compatibility fix (issue #2588), so I'm familiar with the Gazebo ecosystem and contribution process.

Could you share which specific USV model exhibits this issue? Is it the WAM-V or another vessel? This will help me focus my investigation.

Thanks!

[strangerwhoisharborofdoom]

Update: I've investigated the VRX lidar model files and identified the potential issue.

Root Cause Analysis

The lidar sensor is defined in vrx_urdf/wamv_gazebo/urdf/components/wamv_3d_lidar.xacro. The issue appears to be that the lidar's parent link or joint transform isn't being properly resolved in Gazebo Harmonic with ROS 2 Jazzy.

Potential Fixes

1. Check Joint Parent Reference: Verify that the joint's <parent> tag correctly references the USV's base_link or the appropriate mounting link.

2. URDF to SDF Conversion: There might be an issue with how urdfdom converts the URDF to SDF in newer Gazebo versions. The <origin> tag in the joint might not be properly translated.

3. Gazebo Plugin Configuration: The lidar sensor plugin might need explicit frame configuration for ROS 2 Jazzy compatibility.

Next Steps

I'd like to:

1. Create a minimal test case to reproduce the issue
2. Compare the SDF output between working and non-working configurations
3. Submit a PR with the fix once identified

Could you confirm which VRX version/commit you're using? Also, does this issue occur with all USV models or just specific ones (WAM-V, etc.)?

@Va5k3

[Ghostzero00018]

I've been debugging this issue on a clean upstream VRX install and want to share findings that distinguish two separate bugs that are likely being conflated in this comment. One of them has a fix I can provide; the other is upstream and out of scope for VRX.

Reproduction:

ros2 launch vrx_gz competition.launch.py world:=sydney_regatta

In the Gazebo GUI the LiDAR rays render at the world origin (0, 0, 0) instead of
following the WAM-V — matching the original report.

There are possibly two separate bugs, not one.

Bug A: The ROS TF tree for the WAM-V is disconnected from the world. This is a VRX
configuration issue with a concrete, one-line fix (details below). It affects any
ROS-side consumer — RViz, SLAM stacks, navigation stacks that need world-anchored sensor
data.

Bug B: Gazebo's own GUI draws the LiDAR rays at the world origin regardless of ROS. This
is independent of the ROS TF tree. Gazebo's 3D viewport renders the sensor
visualization from its internal scene graph, not from ROS TF, so nothing on the ROS
bridge side can affect it. This looks like an upstream gz-sim8/Harmonic rendering issue
and probably belongs in the gz-sim tracker rather than VRX.

I originally tried to fix bug B via ROS-side changes — it cannot be done. The fix below resolves bug A completely and is verified working, but does not affect what the Gazebo GUI draws.

Bug A: root cause — publish_model_pose=false

In vrx_urdf/wamv_gazebo/urdf/wamv_gazebo.urdf.xacro, the gz::sim::systems::PosePublisher
plugin is configured with all model pose broadcasts disabled except sensor poses:

<publish_link_pose>false</publish_link_pose>
<publish_sensor_pose>true</publish_sensor_pose>
<publish_collision_pose>false</publish_collision_pose>
<publish_visual_pose>false</publish_visual_pose>
<publish_nested_model_pose>false</publish_nested_model_pose>
<publish_model_pose>false</publish_model_pose>
<use_pose_vector_msg>true</use_pose_vector_msg>
<static_publisher>false</static_publisher>
<static_update_frequency>1</static_update_frequency>

With publish_model_pose=false, Gazebo never emits the world → wamv root transform into
/model/wamv/pose. The ros_gz_bridge correctly converts what Gazebo emits into
tf2_msgs/msg/TFMessage on /wamv/pose, and vrx_ros/pose_tf_broadcaster correctly
republishes those transforms to /tf — but the model root pose is simply never there to
begin with, so the entire WAM-V TF subtree is left dangling with no world anchor.

Evidence — /wamv/pose stream before the fix

Every tick contains exactly 7 transforms, all of them static sensor-to-link mounting
offsets pulled from the xacro, and none of them have wamv/wamv/base_link as a child:

• frame_id: wamv/wamv/base_link → child_frame_id:
  wamv/wamv/base_link/lidar_wamv_sensor (0.7, 0.0, 1.8)
• frame_id: wamv/wamv/base_link → child_frame_id:
  wamv/wamv/base_link/front_left_camera_sensor
• frame_id: wamv/wamv/base_link → child_frame_id:
  wamv/wamv/base_link/front_right_camera_sensor
• frame_id: wamv/wamv/base_link → child_frame_id:
  wamv/wamv/base_link/middle_right_camera_sensor
• frame_id: wamv/wamv/base_link → child_frame_id:
  wamv/wamv/base_link/contact_sensor
• frame_id: wamv/wamv/imu_wamv_link → child_frame_id:
  wamv/wamv/imu_wamv_link/imu_wamv_sensor
• frame_id: wamv/wamv/gps_wamv_link → child_frame_id: wamv/wamv/gps_wamv_link/navsat

$ ros2 run tf2_ros tf2_echo world wamv/wamv/base_link
Invalid frame ID "world" passed to canTransform argument target_frame - frame does not
exist

$ ros2 run tf2_ros tf2_echo sydney_regatta wamv/wamv/base_link
Could not find a connection between 'sydney_regatta' and 'wamv/wamv/base_link'

view_frames confirms wamv/wamv/base_link is a parent of many frames but a child of
nothing — a floating subtree.

Partial fix — flip publish_model_pose to true

Edit vrx_urdf/wamv_gazebo/urdf/wamv_gazebo.urdf.xacro line 94:

change <publish_model_pose>false</publish_model_pose>
to
<publish_model_pose>true</publish_model_pose>

Rebuild and relaunch:

cd ~/ros2_ws
colcon build --merge-install --packages-select wamv_gazebo
source install/setup.bash
ros2 launch vrx_gz competition.launch.py world:=sydney_regatta

After this, /wamv/pose gains a new transform each tick with the boat's live world pose:

• frame_id: sydney_regatta
  child_frame_id: wamv
  transform:
  translation:
  x: -532.0097056748388
  y: 161.99816583921404
  z: -0.19948035329942276
  rotation: {x: -0.003, y: 0.001, z: 0.479, w: 0.878}

And tf2_echo confirms the anchor is live and updates with boat motion:

$ ros2 run tf2_ros tf2_echo sydney_regatta wamv
At time 97.408: - Translation: [-532.174, 161.972, -0.136] ...
At time 98.000: - Translation: [-532.174, 161.973, -0.133] ...
At time 98.592: - Translation: [-532.174, 161.974, -0.125] ...

This is a partial fix though — the sensors still aren't connected to the boat in the TF
tree. Running tf2_echo wamv wamv/wamv/base_link after the fix reveals a second problem:

$ ros2 run tf2_ros tf2_echo wamv wamv/wamv/base_link
Could not find a connection between 'wamv' and 'wamv/wamv/base_link'
because they are not part of the same tree. Tf has two or more unconnected trees.

Second bug — naming mismatch between model pose and sensor frames

The PosePublisher emits the model root transform using the literal model name wamv as
the child frame. But /wamv/pose publishes all sensor frames using a double-prefixed
wamv/wamv/base_link as their parent — a wamv/ prefix is being prepended somewhere in the
bridge chain (I haven't pinned down where exactly; pose_tf_broadcaster.cc does not
prepend anything itself, so it's upstream of that, likely from a ros_gz_bridge namespace
handling quirk or from gz-sim's Pose_V field formatting).

After flipping the flag, the TF database ends up with two disconnected subtrees:

Tree A: sydney_regatta → wamv (from publish_model_pose=true)
Tree B: wamv/wamv/base_link → {all sensor frames} (from publish_sensor_pose=true)

Nothing bridges wamv to wamv/wamv/base_link.

Manual workaround — static identity transform

Adding a single static transform bridges the gap:

ros2 run tf2_ros static_transform_publisher
--x 0 --y 0 --z 0 --roll 0 --pitch 0 --yaw 0
--frame-id wamv --child-frame-id wamv/wamv/base_link

After which the full chain is live and verified:

$ ros2 run tf2_ros tf2_echo sydney_regatta wamv/wamv/base_link/lidar_wamv_sensor
At time 233.148: - Translation: [-532.059, 162.549, 1.663] ...
At time 233.600: - Translation: [-532.054, 162.552, 1.639] ...
At time 234.720: - Translation: [-532.048, 162.554, 1.630] ...

The translation values match the boat's world position plus the 1.8 m LiDAR mount height
from the xacro, and they update tick-by-tick as the boat drifts. The ROS TF chain is
now complete end-to-end and fully usable for any ROS-side consumer.

This workaround is a hack though — the proper fix is to eliminate the wamv / wamv/wamv/*
naming divergence at its source. Possible approaches maintainers could consider:

1. Set frame_prefix on robot_state_publisher (vrx_gz/src/vrx_gz/launch.py:377) to
   something that matches what the sensor frames actually use
2. Investigate why sensor frames come through with a double-prepended wamv/ — likely in
   how ros_gz_bridge handles frame_ids when the bridge is launched inside a
   PushRosNamespace('wamv') group, or in how gz-sim8's PosePublisher formats Pose_V entries
   for nested/child links
3. Unify on a single prefix scheme in the WAM-V SDF / xacro

Bug B: the Gazebo GUI rendering bug is separate and still present

Even with bug A fully fixed (confirmed via tf2_echo returning live world-anchored
transforms), the Gazebo GUI still draws the LiDAR rays at world origin. This is expected
— Gazebo's 3D viewport doesn't use ROS TF; it renders sensors from its own internal
scene graph.

So the bug reported in the original issue (rays rendered at a fixed offset in Gazebo) is
actually two layered problems:

• The ROS TF tree was also broken (bug A) — and this has almost certainly been silently
  affecting anyone doing RViz-based development, SLAM, or anything that needs the world TF
  chain, but it wasn't the headline symptom because many users are looking at Gazebo GUI,
  not RViz.
• The Gazebo GUI visualization bug (bug B) is still present after bug A is fixed. I
  believe this is an upstream gz-sim8/Harmonic rendering issue and would need to be
  triaged against the gz-sim tracker. It may be a regression from earlier gz-sim versions
  where sensor ray visualization worked correctly for child-link sensors.

Environment

Component	Version
OS	Ubuntu 24.04.4 LTS (Noble Numbat)
Kernel	Linux 6.17.0-20-generic
ROS 2 distro	Jazzy
Gazebo	Harmonic (gz-sim8 8.11.0, gz-harmonic 1.0.0)
VRX version	v3.1.2 on branch jazzy (HEAD 7609d1b)
ros_gz	1.0.18
Platform	Dell Precision 7560 (x86_64)

Summary for maintainers

• Bug A (ROS TF disconnection) has a verified fix: flip publish_model_pose to true in
  vrx_urdf/wamv_gazebo/urdf/wamv_gazebo.urdf.xacro:94, plus either a bridging transform or
  a unified frame naming scheme for the second half of the disconnect.
• Bug B (Gazebo GUI rendering) is upstream of VRX and appears unfixable from VRX's side.
  Probably worth a separate tracker entry in gz-sim or gz-rendering.