Add support for frame semantics with nested models in SDFormat 1.7

[azeey]

Support for nested models is going to be added to SDFormat 1.7 in gazebosim/sdformat#316. This PR adds support in Gazebo for using nested models that utilize the frame semantics features of SDFormat 1.7. Note, however, that since SDFormat 1.7 does not support referencing entities inside nested models, SDFormat 1.7 files that use frame semantics as well as nested references will not be supported.
For example, the following SDFormat file will emit an error because joint J1 references M2::L2.

<sdf version="1.7">
  <model name="M1">
    <link name="L1">
      <pose>0.1 0 0 0 0 0</pose>
    </link>
    <model name="M2">
      <pose>0 0 0.1 0 0 0</pose>
      <link name="L2"/>
    </model>
    <joint name="J1" type="revolute">
      <pose relative_to="L1">0 0 0.1 0 0 0</pose>
      <parent>L1</parent>
      <child>M2::L2</child>
      <axis><xyz>0 0 1</xyz></axis>
    </joint>
  </model>
</sdf>

If such a model is loaded, Gazebo will resolve poses with frame semantics wherever it can and revert to the semantics of SDFormat 1.6 where it can't. In the above example, all the poses except J1's will be resolved with SDFormat 1.7 semantics.

[scpeters]

this needs the sdformat 9.3 prerelease; the following will enable it in CI: gazebo-tooling/gzdev#18

[EricCousineau-TRI]

Relates #2817

[scpeters]

@osrf-jenkins run tests please

[scpeters]

@osrf-jenkins run tests please

[scpeters]

nit: if you store the result of boost::dynamic_pointer_cast<Model> before the if statement, then you can avoid calling it a second time here

[azeey]

cbd9853

[azeey]

Gazebo has a feature where a model can be edited/updated during simulation via a msgs::Factory message using the edit_name field. The feature is not well documented, but I think it allows a user to send an SDF string that gets "merged" with the existing model's SDF. Since an incomplete SDF can be sent when using this feature, it's difficult to ensure the validity of the model's frame graph. Thus, I think it's best not to support frame semantics when using edit_name. I left a comment at #1954 saying it's not supported..

[azeey]

@osrf-jenkins run tests please

[azeey]

I have compared the failing Ubuntu and Homebrew builds with the non-PR CIs (Ubuntu and Homebrew) and I don't think any of the failures are caused by this PR. Most of the failures have occurred on the non-PR CI jobs at some point. The only ones I'm not sure about are:

• UNIT_Visual_TEST.test_ran on Ubuntu
• INTEGRATION_factory.test_ran on Homebrew
• INTEGRATION_pr2 on Homebrew

[scpeters]

I have compared the failing Ubuntu and Homebrew builds with the non-PR CIs (Ubuntu and Homebrew) and I don't think any of the failures are caused by this PR. Most of the failures have occurred on the non-PR CI jobs at some point. The only ones I'm not sure about are:

• UNIT_Visual_TEST.test_ran on Ubuntu
• INTEGRATION_factory.test_ran on Homebrew
• INTEGRATION_pr2 on Homebrew

the INTEGRATION_factory and INTEGRATION_pr2 test failures seems to happen with the pr2 and the simbody engine. the only weird thing is I see a lot of these messages before the failure:

[Wrn] [SystemPaths.cc:459] �File or path does not exist "/Users/jenkins/.gazebo/models/pr2/__default__"�

I'm not sure what that's about

[scpeters]

I have compared the failing Ubuntu and Homebrew builds with the non-PR CIs (Ubuntu and Homebrew) and I don't think any of the failures are caused by this PR. Most of the failures have occurred on the non-PR CI jobs at some point. The only ones I'm not sure about are:

• UNIT_Visual_TEST.test_ran on Ubuntu
• INTEGRATION_factory.test_ran on Homebrew
• INTEGRATION_pr2 on Homebrew

the INTEGRATION_factory and INTEGRATION_pr2 test failures seems to happen with the pr2 and the simbody engine. the only weird thing is I see a lot of these messages before the failure:

[Wrn] [SystemPaths.cc:459] �File or path does not exist "/Users/jenkins/.gazebo/models/pr2/__default__"�

I'm not sure what that's about

I'll try reproducing it locally

[scpeters]

I have compared the failing Ubuntu and Homebrew builds with the non-PR CIs (Ubuntu and Homebrew) and I don't think any of the failures are caused by this PR. Most of the failures have occurred on the non-PR CI jobs at some point. The only ones I'm not sure about are:

• UNIT_Visual_TEST.test_ran on Ubuntu
• INTEGRATION_factory.test_ran on Homebrew
• INTEGRATION_pr2 on Homebrew

the INTEGRATION_factory and INTEGRATION_pr2 test failures seems to happen with the pr2 and the simbody engine. the only weird thing is I see a lot of these messages before the failure:

[Wrn] [SystemPaths.cc:459] �File or path does not exist "/Users/jenkins/.gazebo/models/pr2/__default__"�

I'm not sure what that's about

I'll try reproducing it locally

I can't reproduce the test failures; I think it's safe to merge