Does Gazebo's world snapshot restore plugin‑internal state such as ROS node handles?

Question

When using Gazebo's world snapshot feature to pause physics, serialize the simulation state to an SDF file, and later restore it, the primary goal is to confirm that all relevant simulation data—including model poses, joint states, and any plugin‑internal information—is accurately recovered.

The default snapshot mechanism captures only SDF‑defined elements such as link poses and joint velocities; plugin‑specific data like ROS node handles, internal counters, or sensor buffers depend on each plugin’s own reset implementation, which may or may not fully reinstate the pre‑pause condition. This leaves uncertainty about whether restored plugins behave identically to their original state, especially when tolerances are applied only to measurable SDF fields. Does the restoration process reliably reinstate plugin‑internal state? Are there known gaps in the snapshot that require plugins to expose additional serialization hooks? What verification methods can detect discrepancies in plugin‑specific data after a restore?

Zoha · Answer

AnswerNo. Gazebo’s world snapshot / restore serializes world state defined in SDF — model and link poses, joint positions and velocities, and similar physics state. It does not capture arbitrary plugin memory. ROS node handles, publishers, subscribers, timers and service connections are runtime resources tied to the process and transport layer, not to SDF. They are never part of a snapshot.Confirmed factsSnapshot output is an SDF file. It contains only SDF-declared fields. Plugin-private data is not written to the file.ROS node handles and ROS communication objects are created at plugin load time and live outside SDF. Restore does not recreate them from a snapshot; plugins must re-establish them on load/reset.Snapshot comparison tolerances apply only to measurable SDF fields such as poses and velocities. A restore can pass validation while plugin behavior diverges.Classic Gazebo and Gazebo Sim/Ignition differ in what entity-component state is serialized, but neither serializes external runtime resources.Likely explanationRestoration fidelity for plugin-specific data — internal counters, sensor buffers, controller integrators, noise seeds — depends entirely on each plugin’s own reset or reinitialization logic. Classic Gazebo exposes hooks such as Reset() and custom update cycles, but there is no general serialization interface that automatically persists plugin internals into the snapshot SDF. Many plugins reinitialize to defaults on reset rather than recovering pre-pause state. Custom data would need bespoke save/restore code in the plugin.Pausing physics alone does not freeze ROS-side state. External ROS nodes continue running and can desynchronize from the simulated clock after a restore.Verification steps for this caseInspect the generated snapshot SDF directly to confirm it contains only SDF-declared fields and no plugin-private data.Instrument the target plugin: log a known internal value before snapshot and immediately after restore, then compare. Example values: counter, buffer size, integrator term.Publish a test message through the plugin’s ROS topics after restore to confirm node handles, publishers and subscriptions are functional and re-established.Run a deterministic scenario with fixed seed and fixed steps to completion twice — once uninterrupted, once with snapshot/restore midway — and diff resulting state and topic outputs.One missing diagnostic detail that changes the recommendation: which Gazebo line and version you are using — Gazebo Classic vs Gazebo Sim/Ignition, and the exact release. Plugin reset semantics and snapshot coverage are version-sensitive.

Does Gazebo's world snapshot restore plugin‑internal state such as ROS node handles?

1 answer

Answer

Confirmed facts

Likely explanation

Verification steps for this case

Your perspective belongs here.

0 question comments