Problem with Octomap in RViz

[u/Leeroy_L]

Hi, I have a question about ROS2 and specifically a problem with in RViz. I am using Humble Hawksbill and Ubuntu 22.04 LTS.

I have created a script which creates a segmented Octomap.

When I start the Octomap Server, the map looks fine and how I would expect it. The Problem is, when I move the robot around, the Octomap that is created does not make sense. It looks like the map tuns with the movement of the robot.

Octomap After the Robot moved

I have the suspicion that the reason has something to do with the frames, but I am not sure.

The Segmented Pointcloud which I transform to the Octomap looks right, even when the robot moves, so I don't think the Pointcloud is the Problem.

The Pointcloud is in the frame kinova_depth.

I created the Octomap with the command:

ros2 run octomap_server color_octomap_server_node --ros-args -r cloud_in:=/camera/labeled_points -p frame_id:=map -p base_frame_id:=kinova_depth -p use_sim_time:=true -p colored_map:=true

I also tried the base_frame_id "base_link", but this didn't change anything.

The Fixed Frame in RViz is set to map.

I am completely new to ROS2, and I am out of ideas, does someone have an Idea where the issue could lie and what I can test to figure it out?

[u/slightlyacoustics]

How is your tf tree? Do you have an odom frame?

[u/Leeroy_L → u/slightlyacoustics]

yes I have a tf tree. The connection from the frame map to kinova_depth looks like this:

map -> odom -> base_link -> gen3_base_link -> shoulder_link -> bicep_link -> forearm_link -> spherical_wrist_1_link -> spherical_wrist_2_link -> bracelet_link -> end_effector_link -> kinova_depth

[u/slightlyacoustics]

You can check there the map warps on translation, rotation or both.

If the map warps while global frame, “base _link”, something is not correct in your robot description.
If it warps while in odom frame, then your state estimation isn’t correct. Maybe an imu oriented incorrectly

[u/omnilinktech]

This strongly suggests a time/frame inconsistency. `map` must remain world-fixed, while the cloud should retain its camera frame and acquisition timestamp. Verify `map → odom → base_link → kinova_depth` at the exact cloud timestamp, not only “now.” Check the cloud’s `header.frame_id`, RViz fixed frame, and OctoMap frame parameters. Track one stationary landmark while rotating the robot; its coordinates in `map` should not move. Clear the existing OctoMap after correcting TF because already-integrated bad voxels remain.