A saved occupancy image is not the same artifact as a serialized mapping session. If a robot can display a LiDAR map but cannot resume mapping from it, first identify what was saved and which consumer will load it. A successful image export does not establish that the mapper’s graph, associated data and required metadata were preserved.
Choose the artifact from the next operation: viewing or image-based localization, continuing a mapping session, or loading a graph into a supported localization mode. Then verify the corresponding save and restore path in the installed software. A file named map is not a sufficient contract, and a success notification alone is not a restore rehearsal.
This guide concerns artifact selection and recovery evidence. It does not diagnose occupancy-cell encoding changes or guarantee compatibility across releases. Preserve original files, record the exact mapper and ROS distribution, and rehearse restoration on separate copies before relying on an archive. Development interfaces below must be checked against the deployed version.
Name the next consumer before saving
Write down the intended application and operation, not just the storage location. Will a map server load a raster map for a navigation stack? Will slam_toolbox restore a mapping session? Will another application consume an occupancy grid? Those questions define different evidence requirements even when the files originate from the same mapping run.
The slam_toolbox project reference distinguishes saving a map image from serializing a pose graph and associated data for supported continued-mapping or localization workflows. It also documents historical serialization changes. Use that distinction to identify the correct deployed interface rather than treating every saved output as interchangeable.
Record whether the next operation is supposed to change the environment model. Localization against an existing artifact and continued mapping are separate modes. A program that loads something and publishes a pose may still be running a different mode from the one the operator intended. Make that intention explicit before selecting launch configuration.
Inventory raster maps and mapping-session artifacts separately
The Nav2 map-server reference for Jazzy describes loading and saving occupancy-grid maps, including the image-and-YAML arrangement. Keep the metadata with the image. An image preview by itself does not capture the resolution, origin and other interpretation settings needed by its consumer.
The OccupancyGrid message represents a two-dimensional grid with metadata and cell data. That is a different representation from the optimizer’s complete mapping-session state. A recognizable occupancy image cannot reconstruct the original trajectory constraints and observation history simply by being renamed or placed beside an empty graph file.
For the deployed mapper, list all files produced by a supported serialization operation and keep them as one identified set. Verify names and companion-file requirements from that release’s documentation and actual output. Do not assume that copying only the largest file, or a familiar extension, is enough. Include permissions, ownership and paths in the archive inventory.
Give each archive a stable revision identifier and record its creation time, software versions and source session. Compute hashes for the complete set and retain an unmodified copy. A second export with the same basename can overwrite only part of an earlier set, leaving a mixed archive whose files individually exist but do not belong together.
Verify the actual save and load interfaces
Inspect the services advertised by the running node and the exact request types in the installed package. The inspected SerializePoseGraph interface accepts a filename and returns a result code. Confirm the resolved destination on the machine or container where the service runs, rather than assuming it writes into the client’s working directory.
The inspected DeserializePoseGraph interface includes a filename, matching mode and initial pose. A restore operation therefore has more context than a path alone. Verify the meaning of those options in the deployed release and use an appropriate initial relationship between the map and robot.
Retain the request, response and relevant diagnostics. Then independently verify that the expected files exist, are complete and are readable in the restore environment. A successful service response and a file on the client laptop are not necessarily evidence about the same filesystem. Container mounts and remote execution can make that distinction especially important.
Keep the raw measurement recording where the project’s storage policy permits it. It can provide a separate route for reproducing a mapping session if serialized compatibility changes. The sensor recording workflow explains why original timestamps and source data should remain available rather than being replaced by a final screenshot.
Pin compatibility and coordinate context
Record the producer and consumer package versions, ROS distribution, relevant dependencies and sensor configuration. Check release notes for documented serialization or reference-frame changes. Do not apply an old conversion utility to the only archive copy without first confirming its applicability and preserving a recoverable original.
Retain the mapper’s configured base, odometry, map and scan-frame names together with the sensor mounting information. An archive can be readable while the restarted system uses different frame identities or geometry. The installation calibration workflow helps identify which physical relationships need a versioned record.
Time configuration belongs in the restore evidence too, particularly for a replay-based rehearsal. Keep simulated versus live time settings explicit and inspect transform availability when new scans arrive. The TF time-coverage diagnostic addresses that separate failure mode. A readable file does not establish a usable live sensor-to-map path.
Run a separate restore rehearsal
| Intended operation | Artifact evidence | Rehearsal question |
|---|---|---|
| Display or image-based navigation input | Image plus matching metadata | Does the selected consumer load the intended map revision? |
| Continue mapping | Complete supported serialized session | Does the restored mapper use the retained session when accepting new scans? |
| Graph-based localization | Compatible graph set and mode configuration | Does the robot relocalize against the intended artifact? |
| Cross-version migration | Original archive and documented compatibility path | Can the result be loaded without destroying the source? |
| Raw-data reconstruction | Original measurements and effective parameters | Can the mapping run be reproduced under recorded assumptions? |
Perform the rehearsal with copied artifacts in an isolated environment. Start from a known state rather than accidentally retaining an already-running mapper’s memory. Record the files actually opened, selected mode, initial pose, received scans and diagnostics. Confirm that the observed output derives from the restored artifact rather than a fresh map silently created at startup.
Separate file loading, relocalization and continued-mapping acceptance into distinct checks. A loaded graph may still need a valid pose relationship and suitable observations. A visually familiar grid may be rendered from another active node. Retain enough source and publisher evidence to distinguish those cases before declaring recovery successful.
If a controlled hardware rehearsal is needed, use the platform’s approved procedure and begin with stationary observations. Define acceptance criteria from the intended operation, not after seeing the result. The restart recovery checklist helps assess whether the complete system, rather than just one file loader, resumes the intended behavior.
Common questions
Can a raster image be converted back into the original pose graph?
The image alone does not preserve the original graph and observation history. Select a supported serialization path when those data are required, and retain raw source evidence where appropriate.
Should both artifact types be archived?
When the project needs both image-based consumers and supported session recovery, document and verify both exports as distinct products of the same identified run. Do not count one successful export as validation of the other.
What should a recovery review contain?
Provide the artifact inventory and hashes, exact versions, save/load evidence, frame configuration and restore rehearsal results. The reproducible support bundle guide organizes those records. State which operation passed and which assumptions remain unverified.
