Changelog for package mrpt_maps

3.1.4 (2026-09-04)

• Merge pull request #1402 from MRPT/fix/restore-cpointsmapxyzirt-serialization-compat Restore CPointsMapXYZIRT as a deserialization-only compat shim

• tests: cover the CPointsMapXYZIRT deserialization compat stub Also silence the expected deprecation warning at the class registration site.

• Restore CPointsMapXYZIRT as a deserialization-only compat shim Removing the class from the RTTI registry (during the mrpt_maps module port) broke loading of any pre-existing .simplemap/.rawlog file that has a CPointsMapXYZIRT point layer: CArchive::ReadObject() throws "Stored object has class 'mrpt::<maps::CPointsMapXYZIRT>' which is not registered!" for any such file, since the class name is still what was written to disk regardless of the deprecation. This class carries no functionality beyond decoding the old binary layout (X,Y,Z + optional intensity/ring/time buffers, unchanged from the original implementation) into a CGenericPointsMap, so anything downstream that reads points via the generic field interface keeps working transparently. New code should use CGenericPointsMap directly; this class is not meant to be constructed for anything but loading old data. Co-Authored-By: Claude Sonnet 5 <<noreply@anthropic.com>> Claude-Session: https://claude.ai/code/session_015w31kEa1kRfKA3rcqDRXyZ

• Merge pull request #1395 from MRPT/test/coverage-2026-08-31 test(slam): raise mrpt_slam coverage to 90% and fix the bugs it uncovered

• fix(slam): report stds_Q_no_odo's heading in degrees, as it is read Addresses review feedback on the new TOptions dumps: CRangeBearingKFSLAM2D loads the third component of stds_Q_no_odo in degrees, so the dump must not print it in radians. Also documents that TMetricMapInitializer::saveToConfigFile() only round-trips the generic map params, since there is no saving counterpart to loadFromConfigFile_map_specific().

• test(slam): raise mrpt_slam coverage to 90% and fix the bugs it uncovered Adds unit tests for the parts of mrpt_slam that had none, all driven by synthetic data (a simulated closed room for 2D scans, a small landmark map for range-bearing readings) so no dataset files are needed:

  • observations_overlap and CLandmarksMap, both previously at 0%

  * CIncrementalMapPartitioner beyond the dataset test: options I/O, the three similarity methods, node removal, origin changes, 3D scene, serialization

  • CMetricMapBuilderICP and its CMetricMapBuilder base
  • CMetricMapBuilderRBPF / CMultiMetricMapPDF, including range-only SLAM
  • CRangeBearingKFSLAM and CRangeBearingKFSLAM2D
  • CMonteCarloLocalization2D/3D over the four particle filter algorithms

  * TSetOfMetricMapInitializers config-file round trip (in mrpt_maps) mrpt_slam goes from 67.9%/45.4% to 90.2%/62.3% lines/branches; the repo-wide figure goes from 72.5%/53.2% to 73.6%/54.4%. Bugs found and fixed along the way:

  * observationsOverlap()'s CSensoryFrame overload ignored its relative-pose argument, so the observation-overlap similarity compared keyframes as if co-located.

  * CIncrementalMapPartitioner::addMapFrame() passed the same relative pose for both directions of its symmetrized similarity; the swapped evaluation needs the inverse. This moves one keyframe between partitions in the existing dataset test, whose expectations are updated.

  * removeSetOfNodes(..., changeCoordsRef=true) composed +p instead of -p, doubling the first node's coordinates instead of moving it to the origin.

  * Two options were loaded with a quoted name passed to MRPT_LOAD_HERE_CONFIG_VAR, which stringifies it again, so they could never be read from a config file.

  • CLandmarksMap was never registered for RTTI and could not be deserialized.

  * TSetOfMetricMapInitializers::saveToConfigFile() wrote a format that loadFromConfigFile() cannot read back.

  * CMultiMetricMapPDF::getLastPose() left its is_valid_pose output untouched on the success path.

  * CMetricMapBuilderICP::saveCurrentEstimationToImage() dereferenced a null gridmap pointer right after null-checking it.

  * The range-only branch of the RBPF optimal proposal never initialized firstEstimateRobotHeading when odometry was present, so it always tripped the assert guarding it; it also printed to std::cout per particle. Both KF-SLAM TOptions::dumpToTextStream() now report the noise parameters they load instead of silently

File truncated at 100 lines see the full file