mola_kernel

MOLA kernel library, providing the definition of essential virtual interfaces and data types.

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 GNU GPL v3 license. Other options available upon request.

Changelog for package mola_kernel

3.3.0 (2026-09-23)

• Port to MRPT 3.x (#220)
• Contributors: Jose Luis Blanco-Claraco

3.2.1 (2026-09-15)

• mola_viz_imgui: show "???" for an unknown dataset duration (#203)
• mola_viz_imgui: show dataset playback time in the dataset UI panel (#202)
• Contributors: Jose Luis Blanco-Claraco

3.2.0 (2026-08-21)

• Merge pull request #192 from MOLAorg/feat/map-frame-gauge-change Support re-expressing estimator and pose-list state in a new frame

• Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change

• mola_kernel: declare transform_frame() last; test SearchablePoseList frame change Appending the new optional virtual only grows the vtable, whereas the previous mid-list position shifted the slot index of the three virtuals after it, breaking any prebuilt NavStateFilter plugin. A note asks that future optional virtuals also go at the end. Adds regression coverage for SearchablePoseList::transform_left_multiply() in both storage modes: that the kd-tree follows the transformed poses (verified to fail if the spatial index is left stale), that the empty and identity cases are no-ops, and that the id-keyed lookup survives.

• Merge branch 'develop' into feat/map-frame-gauge-change

• Support re-expressing estimator and pose-list state in a new frame Adds the two pieces a one-off gauge change of the map frame needs, so that leveling the frame once gravity is known does not have to throw state away:

  - NavStateFilter::transform_frame(), an optional virtual returning false by default, so existing estimators are unaffected and a caller that gets false falls back to reset(). Guarded by a feature macro for downstream detection.

  - SearchablePoseList::transform_left_multiply(), so keyframe-density bookkeeping moves with the frame instead of being invalidated by it. Both are pure left-multiplications, p -> b + p. Note that relative motion, and hence any velocity expressed in the vehicle's own frame, is invariant under this and must NOT be rotated.

• Contributors: Jose Luis Blanco-Claraco

3.1.1 (2026-08-10)

• Fix C++20 build: keep TransformTree/TransformTreeNode aggregates by dropping their defaulted default constructors, which made brace initialization stop compiling on ROS 2 Lyrical (C++20).
• Contributors: 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
• fix formatting
• mola_kernel: don't flood ERROR logs when GUI preview has no viz module A launch YAML can populate gui_preview_sensors for a sensor without gating that entry behind MOLA_WITH_GUI (several mola_lidar_odometry launch files did exactly this). In that case every observation for that sensor label enqueued a task that threw and caught "Could not find a running MolaViz module" -- thousands of ERROR-level log lines per headless run, found via SLAM quality-eval sweeps producing 20k+ of them on a single KITTI sequence. Check once, outside the per-observation lambda, whether a VizInterface is actually running; if not, log a single throttled warning and skip enqueueing entirely instead of relying on every launch file getting its own MOLA_WITH_GUI gate right.
• Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake

File truncated at 100 lines see the full file