Save model states when saving the world

[chapulina]

This pull request added the ability of saving the world. However, models are being saved with their initial configuration and keeping no state. For example, if you start fuel.sdf, let it play for a while, then save it, once you load the saved world, the pendulum's arms will be on its initial configuration, not at the pose when saved.

Gazebo-classic

Gazebo-classic used the SDF <state> tag to store this kind of information. Some limitations of this approach:

• Each variable that we want to store needs a corresponding SDF tag under <state>. For example, <state><model><link><velocity>.
• There's duplication with the rest of the spec. For example, the <state><model><pose> tag overrides <model><pose>.

Gazebo-classic also had a separate mechanism for saving models created by the model editor, which would populate all aspects of the <model> tag itself.

🗒️ Side-note: <state> was also used for logging files on Gazebo-classic, but on Ignition we're using Ignition Transport's logging system. So if we don't use state for saving the world, as far as Ignition is concerned, that tag can be deprecated.

Proposal

On Ignition, it would be convenient to handle saving the world states and saving edited models the same way, to reduce duplication. So my suggestion is to implement a mechanism by which a model's SDF is updated based on its components before being saved. Then this mechanism can be used to to save the configuration of a model in the world, as well as saving a model that was edited.

Take the link poses for example:

• The model's initial SDF is being stored in the ModelSdf component.
• Before saving the model, update the pose of each link in the SDF with the pose according to their pose components.

Once we have the ability to change color, size, mass, etc, we should use the same mechanism to update those before saving the model. Kinematic variables don't need to be the only "state" 😉

For variables like velocity and acceleration, which don't have an equivalent within the <model> tag, I have 3 ideas:

• Add them to the SDF spec (less scalable)
• Save them in ign-transport log files alongside the SDF model (less self-contained)
• Create a system that reads custom SDF tags and populates components

This ties into the WIP GUI interactions design: gazebosim/design#2

---

To close this issue, I think it should be enough to save link poses. We can ticket new issues for saving new variables as the need arises.

The code should be organized in such a way that adding support for more component -> SDF conversions should be straight-forward.

[azeey]

For links connected with non-free joints (less than 6 DOF), it would be nice to save the joint positions instead of link positions. Since a lot of robots are controlled by changing joint states, having this capability would be very beneficial for testing and experimenting with many robot controllers. From the physics perspective, depending on the physics engine, it might be difficult to reconstruct a world from just the link poses since the physics engine will have to calculate the joint angles and try to enforce joint constraints.

[chapulina]

From the physics perspective, depending on the physics engine, it might be difficult to reconstruct a world from just the link poses

But this is currently what we do with the existing SDF spec, right?

My main point with this proposal is that we're saving a world that has <link><pose>s, so we might as well keep them up-to-date. Once gazebosim/sdformat#253 is addressed, maybe the joint positions will be defined as part of the SDF spec and then everything else in this document will apply to that as well. This is sort of my first idea above: Add them to the SDF spec.

[azeey]

But this is currently what we do with the existing SDF spec, right?

Do you mean when loading a model from SDF? For that case, yes, but we assume that the joint is at position 0 for the given parent and child link poses. But, what I'm referring to is to be able to save the non-zero joint position (after simulation has run) and then be able to load that back and have the joint position have the value it had (not zero). There is some relevant discussion on a Drake issue related to this.

My main point with this proposal is that we're saving a world that has s, so we might as well keep them up-to-date.

For links not connected by joints, this makes sense. For jointed links, if we want to also keep the joint state (down the road), saving the link poses will be redundant. The physics engine will have to choose whether to use the joint positions to derive the link poses or vice versa. Either way, if the link poses and joint positions are inconsistent, maybe because they were manually edited, then how will the physics engine know which information to use?

/cc @scpeters, @EricCousineau-TRI

[chapulina]

Do you mean when loading a model from SDF?

Yup, reloading the model that was saved.

But, what I'm referring to is to be able to save the non-zero joint position

Yeah if I understand correctly, this is what //joint/axis/initial_position's replacement would do (gazebosim/gazebo-classic#230, gazebosim/sdformat#253). I don't see a proposal on sdf_tutorials yet, but my assumption is that whatever it is, it will be an addition to the SDF spec, and be within <model>, not <state>. In that case, we can load that information into (existing) components and update it with the same mechanism we'll update the link poses.

how will the physics engine know which information to use?

Yeah my assumption is that the SDF proposal mentioned by @EricCousineau-TRI would have recommendations for how to address that, so that it's clear how to use the spec.

---

So just so it is clear:

• I agree that we should eventually store initial joint angles
• I'm looking forward to the SDF proposal coming up and I assume it will add to the spec and have recommendations on how to handle conflicting info

[EricCousineau-TRI]

I'm looking forward to the SDF proposal coming up [...]

Awesome!!!

Only caveat is that we may not get to this proposal until our current "epic" (gazebosim/sdformat#278) has a majority of its work / prototyping fleshed out - that may not be until late August, which may miss Ignition Dome (Sep 2020):
https://github.com/ignitionrobotics/docs/blob/198e1f957195cb38945f352dc136076052f7db82/releases.md#release-list

Is that timeline OK with you?

FYI @joemasterjohn

FTR Ran into gazebosim/docs#28 and gazebosim/docs#29 when trying to see release dates

[chapulina]

Is that timeline OK with you?

Yeah we're ok with that. Our most immediate need is saving models that are edited / constructed through the GUI, so we don't need the physics state for now.