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

2.9.0 (2026-05-11)

• Merge pull request #143 from MOLAorg/bump-cmake-version bump min req cmake version to 3.22
• bump min req cmake version to 3.22
• Less verbose output: don't print covariance matrix for each geo-referenced solution
• Contributors: Jose Luis Blanco-Claraco

2.8.0 (2026-04-29)

• Merge pull request #140 from MOLAorg/feat/bridge-ros2-qos feat: BridgeROS2 now have configurable QoS

• fix: harden parameter parsing

• feat: BridgeROS2 now have configurable QoS

• Merge pull request #135 from MOLAorg/pr-132 feat(bridge_ros2): align REP-105 TF with Nav2 conventions without regressing direct-publish mode

• feat(bridge_ros2): align REP-105 TF publishing with Nav2 conventions This brings the localization /tf publisher in line with the convention used by AMCL, slam_toolbox, RTAB-Map and Cartographer, addressing three issues observed when MOLA is consumed by Nav2-style downstream nodes:

  1. REP-105 composition bug (fix). The inner factor of map -> odom = (map -> base)(t_scan) * (base -> odom)(t) was sampled at "latest" via waitForTransform(), which only supports tf2::TimePoint{}. The two factors must be sampled at the same instant or the published correction is biased by the odom-frame motion accumulated during the localizer's processing latency. Switch to tf_buffer_->lookupTransform(..., scan_tp). On lookup failure the publish is skipped (an empty default-constructed TransformStamped would inject TF_NO_FRAME_ID into every consumer's tf2 buffer).

  2. transform_tolerance (new param, default 0.1s). The published stamp is now node->now() + transform_tolerance so consumers can do lookupTransform(map, base_link, now()) without ExtrapolationException. Mirrors AMCL's transform_tolerance and RTAB-Map's tf_tolerance. Uses the ROS clock so use_sim_time is honored automatically.

  3. transform_publish_period (new param, default 0.05s = 20 Hz). A wall timer re-broadcasts the cached map -> odom independent of localization update rate, keeping the TF buffer continuously fresh even when the localizer runs slower than the consumer query rate. Set to 0 to disable. Mirrors slam_toolbox's transform_publish_period and RTAB-Map's tf_delay. Backwards compat: to exactly preserve the prior (post-bugfix) stamping behavior set transform_tolerance: 0 and transform_publish_period: 0. publish_in_sim_time retains its meaning for all other publishers (sensor TFs, odom messages, etc.); only the localization /tf stamp source changed.

• Merge branch 'develop' into perf/keyframe-prewarm-global-submap

• Merge pull request #133 from Zeal-Robotics/fix/bridge-ros2-throttle-tf-lookup-errors fix(bridge_ros2): throttle TF lookup error logging

• fix(bridge_ros2): throttle TF lookup error logging Failed sensor TF lookups (e.g. missing static URDF transforms during bring-up) flooded the console with two unthrottled ERROR lines per observation. With a Livox IMU at ~100 Hz this produced ~200 lines/s per affected topic, drowning out other diagnostics.

  - Throttle (5 s) every per-observation "Could not forward ROS2 observation to MOLA due to timeout..." in the PointCloud2, LaserScan, Imu, NavSatFix and gps_msgs paths, plus the "Could not get /tf" path that uses lookupSensorPose, and the REP-105 odom->base_link recompute warning in publishLocalizationTf.

  - Drop the redundant printErrors plumbing from waitForTransform: the inner MRPT_LOG_ERROR(ex.what()) duplicated what callers already print with more context (frames + timestamp). The raw tf2 reason is still emitted at DEBUG for deep diagnostics. Per-callsite throttle state means independent sensors still surface "this stream stopped" promptly; we just stop spamming the same one.

• Contributors: Jose Luis Blanco-Claraco, Robin Van Cauwenbergh

2.7.0 (2026-04-22)

• Merge pull request #131 from MOLAorg/feat/actions-custom-runner CI actions: build for arm64 too
• Merge branch 'Zeal-Robotics-fix/bridge-ros2-skip-empty-tf-on-rep105-failure' into develop

File truncated at 100 lines see the full file