Inconsistent LO between mola-lo-gui-kitti 01 and ROS2 launch without /tf

[kjanparvari]

First, thank you for MOLA and the multi-sensor odometry work. it’s really helpful.

When I run:

mola-lo-gui-kitti 01

on KITTI odometry sequence 01, the trajectory looks correct and stable.

But when I run the ROS2 node with the “no /tf” setup:

ros2 launch mola_lidar_odometry ros2-lidar-odometry.launch.py \
   lidar_topic_name:=kitti/velo/pointcloud \
   ignore_lidar_pose_from_tf:=True \
   publish_localization_following_rep105:=False

and publish KITTI Velodyne scans from my own node, the result is weird and unstable.
My publisher:

• Reads sequences/01/velodyne/*.bin + times.txt
• Publishes sensor_msgs/PointCloud2 on kitti/velo/pointcloud
• Uses a fixed LiDAR frame_id velo_link

[jlblancoc]

Mmm... it's hard to tell what's wrong without more details or debug-level logs.

Try adding this to the ros2 launch:

....
  mola_tf_base_link:=velo_link

to rule out it's something to do with /tf conversions to retrieve the sensor pose wrt base_link.

[kjanparvari]

I tested what you suggested, but I still see the unstable behavior.

Specifically, I tried:

• Case 1 – LiDAR frame is MOLA base frame, ignoring TF

mola_tf_base_link:=velo_link 
ignore_lidar_pose_from_tf:=True

• Case 2 – LiDAR frame is velo_link, using TF (base_link -> velo_link)

mola_tf_base_link:=base_link

In both cases, the resulting trajectory is still weird/unstable compared to mola-lo-gui-kitti 01.

One thing I’m trying to rule out: is the ROS 2 node sensitive to the reception time of the sensor_msgs/PointCloud2 messages, or does it only rely on the header.stamp?

My publisher:

Reads sequences/01/velodyne/*.bin and times.txt

Publishes sensor_msgs/PointCloud2 on kitti/velo/pointcloud

Uses a fixed frame_id of velo_link

Sets the timestamps from times.txt into header.stamp

If there are any specific timing assumptions (e.g. real-time playback vs just consistent header stamps), that info would help me debug this further.

[jlblancoc]

Hi @kjanparvari !
Nope, the time of reception is not relevant, only the stamps on header.stamp.

It works with both, stamps generated with "now()" or with "simulated" time, so all stamps are in the past.

You could try running it with all debug traces and attach them zipped here so I can look for any hint of what's wrong...

MOLA_VERBOSITY_MOLA_LO=DEBUG \
MOLA_VERBOSITY_BRIDGE_ROS2=DEBUG \
ros2 launch mola_lidar_odometry ros2-lidar-odometry.launch.py \ ...
... \
> out.log

[kjanparvari]

I converted KITTI odometry sequence 01 into a ROS2 .mcap bag and set the LiDAR frame to base_link.
It works as expected when using the rosbag api:

mola-lo-gui-rosbag2 /home/kamyar/kitti_fixed.mcap

But it doesn’t behave correctly when running through the ROS2 pipeline:

ros2 launch mola_lidar_odometry ros2-lidar-odometry.launch.py \
  lidar_topic_name:=kitti/velo/pointcloud \
  publish_localization_following_rep105:=False

ros2 bag play kitti_fixed.mcap/

Expected: same output as mola-lo-gui-rosbag2
Actual: incorrect behavior via ROS2 (ros2 bag play or a custom publisher).

Logs: I attached the logs from running the ROS2 launch + ros2 bag play. In these runs, the ICP goodness is very low (around [50-60%).]

Logs.txt

[jlblancoc]

Hi, @kjanparvari !
Interesting... Please, share your .mcap's for debugging them locally on my side.

In the meanwhile, I tried this and it worked with ICP quality >95%:

# Terminal 1
KITTI_SEQ=00 mola-cli src/mola/mola_demos/mola-cli-launchs/kitti_just_replay_to_ros2.yaml

# Terminal 2
ros2 launch mola_lidar_odometry ros2-lidar-odometry.launch.py lidar_topic_name:=/lidar_points publish_localization_following_rep105:=False

[jlblancoc]

Any possibility of having mcaps for debugging on my side?