[epic] proposal: Should provide better composition behavior

[EricCousineau-TRI]

This is a tracking issue for Model Composition.

Currently at:
http://sdformat.org/tutorials?tut=composition_proposal (permalink)

sub-tasks and tentative dates

• Specification / docs
  • update Pose Frame Semantics proposal with details on implementation of parsing stages SDFormat 1.7 parsing stages: add links to libsdformat9 code sdf_tutorials#28 (Target: June 25)
  • finish proposal for composition interface api Model Composition: Add outline for interface element API sdf_tutorials#12, composition/proposal: Expand on interface-type API sdf_tutorials#3 (Target: July 23 May 28)
  • add parsing stages to Composition proposal proposal: Should add parsing stages to Composition proposal #280 (Target: July 16)
• Implementation
  • allow frames in //joint/child and //joint/parent joint: should support specifying frames in <child> and <parent> #204 (Target: July 16)
  • add Model::GetModel API's and make nested models (issue: Nested models should work via DOM in libsdformat9 #283, pr: [sdf9] Support nested models in DOM and frame semantics #316, Add nested models to SDFormat 1.7 proposal sdf_tutorials#34) (Target: August 13)
  • implement support for (implicit and/or explicit) nested canonical links (composition/proposal: Permit nested canonical links sdf_tutorials#36, issues: Should support nested canonical links for libsdformat (implicit for 9/10, implicit+explicit for 11) #342, Should support nested canonical links for libsdformat11 (with explicit specification) #343, prs: Support implicit nested canonical links #341, Parsing stages for nested canonical links sdf_tutorials#40) (Target: September 17)
  • allow "drilling into" scoped names Should allow "drilling down" into nested model frames #293 (Target: November 5)
    • make include work as nested models Make included models work as nested models via DOM in libsdformat10 #284 (Target: November 5)
    • Handle unnesting design docs composition: Add section for up-converting unflattened models sdf_tutorials#41 (Target: October 1)
  • add support for new composition semantics
    • //include/placement_frame (issue: composition: Should implement //include/placement_frame #319) (August 6)
    • add //model/@placement_frame to composition proposal (issue: Add //model/@placement_frame to composition proposal #335) (Target: September 25)
    • interface api (Jan. 28 - Should implement interface API #430)
• Release Dates
  • libsdformat11
    • Prototype
      • Without interface API: Target: November 26
      • With interface API: Target: Feb. 4
    • Release (Target: Mar. 31)
  • Downstream:
    • Drake: Upgrade Drake SDFormat 1.8 (for Model Composition) RobotLocomotion/drake#14295
      • Prototype (Target: January 28)
      • Release (Target: Mar. 15): Upgrade Drake SDFormat 1.8 (for Model Composition) RobotLocomotion/drake#14295
    • Gazebo Ignition Edifice:
      • Prototype (Target: January 14)
      • Release (Target: Jan 2021 Mar 31, 2021) - actual release
        • Feature Freeze: Mar. 17
        • Code Freeze: Mar. 24
      • Final touches: Support SDFormat 1.8 composition gz-sim#479
    • Gazebo Classic: out of scope

[chapulina]

I noticed that the current proposal is focused on poses. So this may be out of scope for this task, but I'd like to mention that an important aspect of composition is injecting plugins into SDF files.

The proposal says that //include/plugin is generally Gazebo-specific, but this is a concept we've also adopted into Ignition. My immediate use case is to have a model described once, and augment it with simulator-specific plugins as needed. Using the <include> tag, this is already possible for:

• //model/plugin
• //actor/plugin

But not for:

• //model/link/sensor/plugin
• //model/link/visual/plugin

[EricCousineau-TRI]

EDIT: What I said here is wrong. It's already in the proposal. See post below.

---

Using the <include> tag, this is already possible for [...]

Can you (or someone on your team?) file a PR against the legacy Composition tutorial to make this existing contract explicit? (e.g. point out where in Gazebo it's supported, and other downstream applications if applicable?)
http://sdformat.org/tutorials?tut=composition&cat=specification&

---

At a (potentially distracting) "philosophical" level:

It's unclear to me what "adopted into Ignition" really means - can you point to other use cases of //plugin outside of Gazebo / its upstream libraries?

FTR, my understanding of Ignition is that it aims to be individual libraries, but to me it still smells like it's application/framework layers of Gazebo just broken out into separate repos. (At least, that is how it has been working with SDFormat, in both the software library and the specification.)

Totes down for it evolving it to that point, but I just want to make sure that things aren't claimed to be individual libraries if they aren't yet, and that we take the explicit steps to take them away from application layers of Gazebo to actual libraries?

Also, I'm happy to have my point of view corrected; it is naive, in that I've only really dealt with SDFormat in depth.

[EricCousineau-TRI]

Uh oh. I must eat my own words.

I am completely incorrect; it's in the documentation here as @scpeters pointed out:
http://sdformat.org/tutorials?tut=composition&cat=specification&#including-a-model

That being said, I would still love to have this feature be tracked.
Talking with @scpeters, he will open up an issue to track this.

Sorry for the noise!!!

EDIT: FTR, I plan to discuss things more (and read things) before I go on a, uh, ranty mode.

[EricCousineau-TRI]

Talked it more over w/ @scpeters and @azeey, and @scpeters will file an issue about injecting //plugin (and even custom tags) on elements; still dunno if it should be physical or just XML coordinates.

[scpeters]

updating proposal with details on parsing implementation in gazebosim/sdf_tutorials#28

[EricCousineau-TRI]

Posted announcements:

• https://discourse.ros.org/t/sdformat-1-8-composition-proposal/16630/2
• https://community.gazebosim.org/t/sdformat-1-8-composition-proposal-cross-post-with-ros-discourse/667

[chapulina]

I just noticed the follow up questions now and I'm not sure about where the conversation currently stands, so I'll just clarify some things.

It's unclear to me what "adopted into Ignition" really means - can you point to other use cases of //plugin outside of Gazebo / its upstream libraries?

This issue has some examples: #93

my understanding of Ignition is that it aims to be individual libraries, but to me it still smells like it's application/framework layers of Gazebo just broken out into separate repos

The separate libraries are useful on their own without Gazebo. The same way you're using SDF outside Gazebo, there are projects using Ignition Rendering, GUI, Sensors, Math, Common, Math, Transport... Some public examples are tesseract-ignition and ign-rviz.

explicit steps to take them away from application layers of Gazebo to actual libraries?

We're all ears. What explicit steps are needed for them to smell like actual libraries to you? Perhaps this is not the right place to follow up on this discussion, but you're welcome to start a conversation on https://community.gazebosim.org/.

[chapulina]

And the reason I ended up in this issue again was to cross-reference this design proposal for Gazebo, which I think is relevant to this issue. It talks about composition beyond poses, with the addition, removal or modification of included models.

gazebosim/design#5

[EricCousineau-TRI]

\cc @claireyywang

[azeey]

The last PR on this epic has now been merged, so I think we can close this. @EricCousineau-TRI ?

[EricCousineau-TRI]

Sounds great!!!