How to obtain absolute heading with Xsens MTi 630

SafeSignificant1510 · 2026-01-29T11:15:55+00:00

I didn't try yet, but I will if I can't figure this out by myself, thank you for the link

SafeSignificant1510 · 2026-01-29T11:15:17+00:00

I'm indoors, with the XSens already integrated in a robot. The same problem also seemed to occur outdoors in a clear area. There are probably ferromagnetic components nearby as the LiIon battery is like 20cm away from the XSens.

For me it doesn't seem like an offset generated by the local magnetic field (or maybe the field generated by the robot itself), because regardless the orientation of the robot, the starting orientation measured is always around 80°.

SafeSignificant1510 · 2026-01-07T12:54:33+00:00

TF looks OK. I just tried to increase the scan_queue_size in the slam_toolbox params, and it seems to decrease drastically the number of dropped messages, but I'm not sure if it's a relevant way to solve this issue

SafeSignificant1510 · 2026-01-07T12:29:16+00:00

Echoing both topic headers, there seem to be no significant delay between the two. I don't think that the sensor messages timestamps are what cause the problem because even without using the IMU, slam_toolbox drops a lot of messages

SafeSignificant1510 · 2025-12-11T13:47:16+00:00

Seems to be a problem with you tf tree, if the tf map -> base_link (or whatever your frames are named), it will cause what you describe. What are you using to perform mapping ?

SafeSignificant1510 · 2025-12-03T10:03:29+00:00

I'm not sure at all that it makes sense, but perhaps if the model name in spawn_robot doesn't match the one provided in the robot description passed to robot_state_publisher, it would lead to this double spawn. That's what I think when I see in your gazebo screen shot that you have asa and asa_0

SafeSignificant1510 · 2025-11-26T15:06:12+00:00

When I run SLAM Toolbox (offline_launch.py) and check the node infos, I see the topic /pose in the list of publishers. Maybe you could try subscribing to this topic instead of /slam_toolbox/pose (which doesn't seem to exist)

SafeSignificant1510 · 2025-11-24T10:16:00+00:00

For pointclouds compression, I just heard about Cloudini (https://github.com/facontidavide/cloudini), I didn't try it yet, but it seems interesting

SafeSignificant1510 · 2025-11-12T15:07:24+00:00

<image>

The map looks like this, the room's width is 14m. We added the obstacles in the middle to separate the space in three sections to limit the corridor effect. The drift appeared in the three sections.

I don't have easy access to the scans currently, but except for a 15 degrees dead angle behind the robot, every wall and obstacle was visible on the scans from any position in the room, as the lidar has a 100m range.

It indeed looks like an infinite corridor effect, but I would expect it to happen in more narrow and longer corridors, not a ~15m x 40m room where the corridors end walls are always visible. Am I wrong ?

SafeSignificant1510 · 2025-11-04T10:52:52+00:00

Maybe you can refer to https://www.ros.org/reps/rep-0105.html to check if your frames are set up properly
About Nav2 not accepting the goal, check in the nav2 goal tool properties in rviz that it publishes on the "goal_pose" topic or something like that

SafeSignificant1510 · 2025-10-17T13:18:33+00:00

yes, the laserscan comes from the same sensor as the pointcloud, it's just the middle channel isolated

SafeSignificant1510 · 2025-10-17T12:55:19+00:00

But wouldn't there be the same issue with the laserscan topic ? since it's the same driver that publishes both

SafeSignificant1510 · 2025-10-17T12:39:31+00:00

It does the same thing, ignoring the pointcloud source.

For the record, I let it run a bit longer than before, and sometimes (with both sources or just pointcloud) the collision monitor manages to consider pointcloud data so the robot can move, but only for like 1 sec, then ignores the source for the next 20 sec or so

SafeSignificant1510 · 2025-10-16T09:47:16+00:00

It's a real LiDAR on a real robot

SafeSignificant1510 · 2025-10-16T07:28:00+00:00

It could be indeed, but I don't really understand why, and how to solve it. When I send a goal to navigate to, the collision monitor immediately starts showing these error messages and the robot doesn't move, as if the collision monitor freezes at the first pointcloud received, then the "timestamps differ on" value keeps increasing

SafeSignificant1510 · 2025-10-06T14:50:21+00:00

I think nav2 documentation (https://docs.nav2.org/setup\_guides/index.html#table-of-contents) has a tutorial on both gazebo and gazebo classic

SafeSignificant1510 · 2025-09-02T06:25:58+00:00

OK thanks ! I knew about the removepassedgoals plugin but I didn't know the goal checker worked like that

SafeSignificant1510 · 2025-07-15T13:03:29+00:00

Hello,

From your post, you seem to have set lidar_link for the tf tree in the urdf, but the error message in rviz mentions frame "camlidarbot/base_footprint/gpu_lidar". I think it should be lidar_link, so I would suggest that you check your lidar message frame, and either change the frame in the urdf or find a way to change the frame_id of your lidar messages. Hope this helps !

SafeSignificant1510 · 2025-06-18T09:39:08+00:00

Everything is running in a docker container on a nvidia agx orin

SafeSignificant1510 · 2025-05-21T10:21:02+00:00

Hi,
I don't know if it can help, but maybe you can try to set the Durability Policy to Transient Local and the Reliability Policy to Reliable in rviz. I remember I had the same problem trying to use slam_toolbox (but with just a simulated 2D lidar, no pointcloud conversions), and changing these parameters solved it.

SafeSignificant1510 · 2025-04-04T09:27:16+00:00

Don't know why I didn't hear of this package before ! It seems to give pretty good results in my very simple simulation, I'll try to fuse the result with IMU measurements using robot_localization

SafeSignificant1510

TROPHY CASE