mola_bridge_ros2

RawDataSource acting as a bidirectional bridge between ROS2 and MOLA modules.

Can be used to:

• ROS2->MOLA: Interface a real sensor using a ROS driver node and run SLAM with it. See mola_lidar_odometry demos.
• MOLA->ROS2: Expose a dataset as ROS2 topics, from any of the datasets supported by MOLA. Example: kitti
• ROS2<->MOLA: Run SLAM on a live sensor stream, then send back the reconstructed map and trajectory to ROS for further processing or visualization in RViz. See mola_lidar_odometry demos.

If you want to run SLAM on a rosbag, the module mola_input_rosbag2 provides a more convenient interface, e.g. allows fast-forwarding or skipping parts of a bag.

Building this module requires ROS 2 to be installed, and its setup.bash activation script being sourced before invoking CMake to configure and build MOLA.

See package docs for instructions and options to install ROS prerequisites.

Provided MOLA modules:

• BridgeROS2, type RawDataSourceBase.

Build and install

Refer to the root MOLA repository.

Docs and examples

See this package page in the documentation.

License

This package is released under the BSD 3-clause license.

Changelog for package mola_bridge_ros2

3.1.1 (2026-08-10)

• fix build in ros rolling (newer gcc)
• fix format
• mola_bridge_ros2: use tf2_ros .hpp headers instead of deprecated .h Avoids #warning deprecation spam on newer ROS2 distros while building unchanged from Humble to Rolling.
• Contributors: Jose Luis Blanco Claraco, Jose Luis Blanco-Claraco

3.1.0 (2026-08-06)

• Add mola::TransformTreeSource: expose the /tf tree to other MOLA modules (#188) * Add mola::TransformTreeSource: expose the /tf tree to other modules New mola_kernel interface letting a data source publish its tree of coordinate frames, so consumers (e.g. a LiDAR-odometry viewer) can draw a robot's joints as it moves. transform_tree(root) returns the subtree below 'root' with poses already resolved against it. The filtering is done in the source, which is what owns the transform buffer, so a consumer never receives nor walks unrelated subtrees. The interface carries no ROS/tf2 type, keeping mola_kernel ROS-independent. Implemented by Rosbag1Dataset (separate repo), Rosbag2Dataset and BridgeROS2. No locking is added around the subtree walk: tf2::BufferCore guards its own internals, which is also what lets BridgeROS2's TransformListener feed the buffer from its own thread.
  • Address review: depth-first comment, cycle guard in the tf walk
  • No need for include guards inside this same git repo
• Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
• changelog
• fix: ros rolling changed arguments of tf2_ros tf listeners
• fix: GCC error in Rolling due to missing direct rclcpp/Node.hpp include
• totally drop mrpt2 point cloud classes
• Merge pull request #177 from MOLAorg/feat/rep105-loud-stale-odom-warning Make the REP-105 stale-odom fallback loud on first occurrence
• fix(bridge): make the REP-105 stale-odom fallback loud on first occurrence When publish_localization_following_rep105 is on and the exact sensor-stamp odom->base_link transform is unavailable, the bridge composes map->odom against the latest (stale) odom transform. That biases the published TF by the robot's motion over the stamp gap (motion-correlated jitter, worst mid-turn), and it is the normal path whenever the localizer publishes an estimate extrapolated to "now" while odom only exists in the past. The warning was throttled to 60 s, which hid this persistent timing violation. Emit a loud, explanatory warning the first time the fallback fires, naming the consequence and the recommended fix (have the state estimator publish map->odom directly via StateEstimationSmoother's publish_map_to_odom_tf, and route the bridge TF source filter to that /map_odom method), then continue with the throttled steady-state warning so logs are not flooded. No behavior change to the published transform itself.
• Contributors: Jose Luis Blanco-Claraco
• fix: ros rolling changed arguments of tf2_ros tf listeners; fixed GCC error in Rolling due to missing direct rclcpp/Node.hpp include; dropped MRPT2 point cloud classes.
• fix(bridge): REP-105 stale-odom TF fallback now logs a loud, explanatory warning the first time it fires (with the recommended fix), instead of only a throttled one.
• Contributors: Jose Luis Blanco-Claraco

3.0.0 (2026-07-17)

• chore: less verbose warning
• fix: rep105 mode made robust against lagging odom frame
• fix: replace rclcpp deprecated spin_some()
• Merge pull request #153 from Zeal-Robotics/fix/bridge_ros2-relocalize-frame fix(bridge_ros2): transform relocalization pose into reference frame
• fix(bridge_ros2): transform relocalization pose into reference frame The relocalization topic callback and the relocalize_near_pose service fed the incoming PoseWithCovarianceStamped straight to relocalize_near_pose_pdf(), ignoring its header.frame_id. The pose was therefore interpreted in the localization reference_frame regardless of the frame it was actually expressed in. When a tool publishes it in a different frame (e.g. RViz's "2D Pose Estimate" in the fixed frame) that differs from reference_frame, the relocalization lands in the wrong place. Compose reference_frame <- header.frame_id via the tf buffer before relocalizing, in both the topic callback and the service. The covariance is propagated through the rotation by CPose3DPDFGaussian::changeCoordinatesReference(). Requests are skipped (topic) or rejected (service) when the transform is unavailable, instead of silently relocalizing to a wrong pose.
• fix: safer owned_rclcpp flag
• Merge pull request #150 from MOLAorg/fix/bridge-ros2-rclcpp-shutdown-ownership feat: bridge ros2 now autodetects rclpp shutdown ownership
• feat: bridge ros2 now autodetects rclpp shutdown ownership
• Merge pull request #149 from

File truncated at 100 lines see the full file