When a recorded map appears for a subscriber started before rosbag2 playback but not for one started later, investigate the playback publisher’s durability and lifetime. First confirm that the bag actually contains the intended map message. A successful live mapping session does not prove that the recorder captured a one-shot publication, and a topic name in metadata is not evidence that usable messages are present.
Keep three observations separate: what was stored, what the player offers, and what the receiving endpoint requests. The original publisher’s configuration can influence recorded metadata, but the player creates a new publisher during replay. Its effective settings and the moment when a subscriber joins determine whether the recorded publication can reach that subscriber.
The ROS 2 QoS compatibility workflow provides the endpoint foundation. This diagnostic narrows the question to recorded map delivery and late subscribers. It does not assume that changing a QoS file can recreate missing bag contents, preserve a publisher after its process ends, or correct an unrelated map frame and origin.
Prove the map was recorded before changing playback
Inspect the actual bag with the tools provided by the installed release. The Jazzy rosbag2 reference describes recording, inspection and playback options. Record the storage format, topic name, message type, message count and the playback command. Inspect a bounded message when a nonzero count still does not establish that the intended map was saved.
A recorder can join after a map’s initial publication. Whether it receives historical data depends on the relevant endpoints and the original publisher’s retained history. Do not replace a missing-message diagnosis with a playback adjustment. If the intended map was never stored, obtain it through an authorized reproducible capture or another appropriate artifact rather than manufacturing a message count.
Preserve the original bag while investigating. A copy used for experiments should retain its metadata and storage files together. The recording contract checklist explains why a recording must preserve more than a familiar topic name. Here the required evidence includes the map contents and offered-profile information relevant to replay.
| Boundary | Evidence | What it establishes |
|---|---|---|
| Stored bag | Map count, type and inspected contents | The intended data exists |
| Playback publisher | Effective QoS and resolved topic | What the player actually offers |
| Receiving subscription | Requested QoS and creation time | Compatibility and joining condition |
| Publisher lifetime | Endpoint present or process exited | Whether retained delivery can be tested |
| Delivered map | Frame, origin, dimensions and cell data | The correct map reached the receiver |
Inspect the publisher created by this player
The reviewed Jazzy player implementation checks topic-specific QoS overrides before adapting a profile from recorded offered profiles. It also has a fallback when those profiles are absent. Read this as version-qualified behavior, then inspect the endpoint created by the binary actually running. A source branch alone cannot establish an installed package’s exact behavior.
Capture the resolved topic and namespace as well as the offered reliability, durability and history settings. Record the override path and the command line without exposing unrelated private paths or credentials. A file existing on disk does not prove that the player loaded it, or that its topic key matches the fully resolved name after remapping.
Compare the player endpoint with the receiving application, not just a diagnostic subscriber using different defaults. The cross-host discovery diagnostic is useful when the endpoint is absent on another computer. Discovery failure and missing retained delivery are different boundaries; establish that both processes can see the intended graph before interpreting startup order.
Test a subscriber before and after publication
The official Jazzy QoS documentation distinguishes transient-local durability from volatile delivery and describes compatibility between requested and offered policies. A late-joining test needs the receiving subscription’s effective policy as well as the publisher’s policy. A map visible to an already-connected subscriber is not by itself proof of historical delivery.
Use two controlled runs with the same bag and playback settings. In one run, establish the subscriber before the map publication. In the other, create it after that publication while the relevant publisher remains present. Record the arrival event and message identity. Keep other conditions fixed so that a changed namespace, playback range or discovery delay does not masquerade as a durability result.
Do not use a filter callback as the sole delivery signal. A message may arrive at one subscription without completing a multi-input processing condition. The synchronizer boundary workflow separates reception from later callback conditions. For a map test, inspect direct receipt before attributing a silent downstream algorithm to the bag player.
Respect history depth and publisher lifetime
The reviewed rosbag2 QoS adaptation code helps explain how recorded offers are interpreted in this release. Do not assume that several original publishers, mixed recorded profiles or missing metadata produce the offer you intended. Preserve those inputs and confirm the resulting endpoint rather than editing metadata until a viewer happens to work.
Transient-local delivery is associated with a publisher’s retained data; it is not an independent permanent map server. If the playback process exits, a subscriber started afterward cannot rely on that departed publisher to serve history. Record when playback ends and when the endpoint disappears. Do not diagnose a post-exit test as equivalent to joining a live retained publisher.
Choose a deployment mechanism that matches the intended lifetime. If a saved map must be available independently of a short replay, evaluate the supported map-serving path and its artifact requirements separately. Do not keep a test player running indefinitely and report that as a verified production architecture. The diagnostic result should name exactly which publisher was present during receipt.
Validate the delivered map rather than its thumbnail
The Jazzy OccupancyGrid definition identifies the message’s header, metadata and data array. Compare the delivered frame, dimensions, resolution, origin and cell data with the intended stored map. Receiving any map-shaped image is insufficient when several bags, namespaces or map servers are active in the same workspace.
Save a concise timeline showing subscriber creation, player endpoint creation, recorded-map publication, receipt and player termination. Include the exact release and supported override syntax. An observation made with one version should remain attached to that version, especially when an online example describes a newer option that the installed command does not expose.
If the result remains inconsistent, build a reproducible support record containing the smallest nonprivate bag, metadata, effective endpoint settings and startup sequence. Preserve failed observations as well as successful ones. This allows another engineer to distinguish an adaptation issue, a missing stored message and an application subscription mismatch without recreating an entire robot session.
Frequently asked questions
Can a playback override recover a map that was not recorded?
No. An override changes supported playback endpoint behavior; it does not add a missing map to the original recording. Confirm actual bag contents before investigating how an existing message is delivered.
Why does an early subscriber work while a late one fails?
Startup order can expose a retained-delivery difference, but first hold topic names, discovery, playback range and the subscriber profile constant. Test the late subscriber while the relevant publisher still exists, then inspect both endpoints.
Does transient-local durability make a permanent map service?
No. Do not assume historical data remains available after the publishing process exits. Separate a live-player experiment from a persistent map-serving deployment and verify the lifetime required by the actual application.
