This is to allow libsdformat parse from other formats without having to convert to SDFormat via user provided hooks.

PR: #3

Potential usage example: RobotLocomotion/drake#13128

Relates gazebosim/docs#31

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

They still mention version 2, but we just released 6!

http://sdformat.org/tutorials?tut=install&cat=get_started

At present (cf72a5a), it's still in "Proposals".

The //gazebo tag and //gazebo/@reference attribute are used extensively by the URDF to SDFormat converter in libsdformat. There are some documentation and examples of this in the following places on gazebosim.org, and we could consider hosting some of that on sdformat.org:

• http://gazebosim.org/tutorials?tut=ros_urdf&cat=connect_ros
• http://gazebosim.org/tutorials?tut=kinematic_loop

The SDFormat 1.7 frame semantics proposal contains two restrictions on the contents of //@name attributes:

• Names of sibling elements must be unique
• Certain reserved values may not be used in a //@name (namely world and __.*__

Should these restrictions apply to a name attribute in a custom namespaced element?

Moved from this comment thread: gazebosim/sdformat#381 (review)

Per this issue: gazebosim/sdformat#267

I was trying to find where //surface//friction lived. I briefly looked at places like //link and //world, and tried a few other places, but gave up after 2min.

In the end, I just went to sdformat/sdf/1.7, searched for "surface", found it in surface.sdf, and then searched for that filename to find in included via "collision.sdf".

At a minimum, there should be a suggestion on how to find things.
Ideally, there's an easy way to add simple search functionality, such that you can easily find a tag and its usage context.

Will make proposal with suggested syntax. Degrees is my main interest, but we can leave space for other stuff.

Came about recently (as well as longer ago) when discussing here:
RobotLocomotion/drake#13036 (review)

Relates: ros/urdfdom#124

• Rename "Roadmap" to "Releases", merge with Downloads somehow?
• Add a link to API Documentation once later versions are included? (or only publish for major versions???)
• API docs for 9.0.0 are broken? http://osrf-distributions.s3.amazonaws.com/sdformat/api/9.0.0/index.html
• API docs for "dev" seem old? http://osrf-distributions.s3.amazonaws.com/sdformat/api/dev/classes.html
• Add a link to Downloads if/when they're in sync with API Docs?
• Use GitHub release page?

joint damping (linear), friction (-sgn(velocity)), joint spring stiffness and spring reference

Per convo on 2019-05-29 on Asana.

Desired behavior

From gazebosim/sdformat#1335 (comment):

We should document on sdf_tutorials that this works by completely replacing the parameters in the link, i.e, the values inside auto_inertia_params of the collision do not "merge" with the ones lin the parent link.

Alternatives considered

Implementation suggestion

Additional context

Per Asana task, 2019-06-25.

Initial draft:
https://github.com/osrf/sdf_tutorials/tree/spec_inertial

\cc @scpeters

Desired behavior

Currently the //inertial/@auto attribute enables automatic computation of inertial properties assuming uniform density based on the shape and a density parameter. Since it can be more straightforward to measure mass by weighing an object than measuring density, center of mass, and moment of inertia, we should consider allowing the user to specify the mass and auto-compute the remaining inertial properties without using the density parameter.

Alternatives considered

Implementation suggestion

Currently automatic inertial calculations can be enabled by setting //inertial/@auto == 'true' and specifying collision geometries in a link:

<link name="link_with_collision_density">
  <inertial auto="true"/>
  <collision name="collision1">
    <density>...</density>
    <geometry>...</geometry>
  </collision>
  <collision name="collision2">
    <density>...</density>
    <geometry>...</geometry>
  </collision>
</link>

Note that when gazebosim/sdformat#1335 is merged, density may also be specified in the //inertial instead of //collision (see the pull request for details on precedence if it is specified in both places):

<link name="link_with_inertial_density">
  <inertial auto="true">
    <density>...</density>
  </inertial>
  <collision name="collision1">
    <geometry>...</geometry>
  </collision>
  <collision name="collision2">
    <geometry>...</geometry>
  </collision>
</link>

If a user sets //inertial/@auto == 'true' and also specifies mass, inertial pose, or moment of inertia values, a warning is thrown and the user specified values are not used.

<link name="link_with_ignored_user_inertial_values">
  <inertial auto="true">
    <mass>...</mass>
    <pose>...</pose>
    <inertia>...</inertia>
  </inertial>
  <collision name="collision1">
    <geometry>...</geometry>
  </collision>
  <collision name="collision2">
    <geometry>...</geometry>
  </collision>
</link>

This feature request is proposing that if a user sets //inertial/@auto == 'true' and specifies //inertial/mass, that the density values should be ignored, and the inertial values calculated according to the density that would result in the user-specified mass:

<link name="link_with_auto_inertial_from_mass_not_density">
  <inertial auto="true">
    <mass>...</mass>
  </inertial>
  <collision name="collision1">
    <geometry>...</geometry>
  </collision>
  <collision name="collision2">
    <geometry>...</geometry>
  </collision>
</link>

Additional context

Per discussion here:
#30 (review)

The spec describes //sensor/imu/orientation_reference_frame/custom_rpy/[@parent_frame] as

Name of parent frame which the custom_rpy transform is defined relative to. It can be any valid fully scoped Gazebo Link name or the special reserved "world" frame. If left empty, use the sensor's own local frame.

The current of pose frame semantics proposal does not include this attribute.

There are several gazebo tutorials related to the parameters in the //physics element:

• http://gazebosim.org/tutorials?tut=physics_params&cat=physics
• http://gazebosim.org/tutorials?tut=preset_manager&cat=physics

We could consider hosting some of this content on sdformat.org

Migrating from Asana task on 2019-04-01
https://osrf-migration.github.io/sdformat-gh-pages/#!/osrf/sdf_tutorials/pull-requests/5/page/1#comment-97161755

Eric Cousineau
The frames on this image look very… imprecise… I will try to touch them up, and possibly suggest an update on the URDF page.
...
Actually, the frames that we have for SDF look much better.
Is there a way that we could make cleanup the URDF version to look similar (as far having lines directly aligned), and submit that change to the URDF doc wiki?

Regarding image:
http://wiki.ros.org/urdf/XML/model

Per f2f today:

• (IMO) Current behavior may be too complex
• //include/static=true should override children
• //include/static=flase will not override children

@azeey's asked if a static model could be a //joint/child.
IMO, yes, because it's analogous to other compatible specifications (e.g. a rope connected at two ends to the world).

Should also re-mention that //joint/child != "world" primarily because of breaking pose encapsulation as our main motivation.

Part of gazebosim/sdformat#278 (but not explicitly included, 'cause it seems simple?)

Motivated by review of gazebosim/sdformat#243

Action Items:

• Add link to sdf_web_app once it's public.
• Fix proposals to not use pose_semantics_docs as its name; currently, the link to the "Proposals" section is http://sdformat.org/tutorials?cat=pose_semantics_docs&

Ambiguities raised by @mitiguy in email thread. Relates #18

Items:

• Update SDFormat specification
• Update URDF XML specification analogously: http://wiki.ros.org/urdf/XML/link
• Fix website rendering for links

No README currently. The new readme should have something like:

• A pointer to sdformat.org
• A pointer to the sdformat repository
• Development tips
  • How to preview branches
  • Contribution guidelines?
    • https://ignitionrobotics.org/docs/all/contributing (currently still catered towards BitBucket)
    • https://index.ros.org/doc/ros2/Contributing/Developer-Guide/#pull-requests

• For previewing branches, need to pass ?repo= as well as ?branch=.

The //plugin tag is used by gazebo and ignition-gazebo, and it would be worth documenting how that tag is used and how it could be used by other software.

• http://sdformat.org/spec?ver=1.7&elem=model#model_plugin
• http://sdformat.org/spec?ver=1.7&elem=sensor#sensor_plugin
• http://sdformat.org/spec?ver=1.7&elem=visual#visual_plugin
• http://sdformat.org/spec?ver=1.7&elem=world#gui_plugin
• http://sdformat.org/spec?ver=1.7&elem=world#world_plugin

The links to the MJCF converters here are broken.

Thanks!

Make joint mobilization diagrams clearer for concrete joints

Ensure the prismatic initial conditions are specified for joint kinematics; make Drake agree
Came about when debugging: RobotLocomotion/drake#12775

In kinematics tutorial: http://sdformat.org/tutorials?tut=spec_model_kinematics&cat=specification&

Would be nice to have concrete rendering of each joint, with pose offsets and small mobilization (with zero offset)

Dear sdf-tutorial contributors,

I am using a Gazebo simulation (11.10.2) with ros-humble-gazebo-plugins and I am trying to instantiate sensors multiple times with adjusted parameters in a nested robot model. Therefore, I want to use the proposed parameter passing as described in your tutorial, but it seems to be difficult to get it runnable.

Assuming the following model.sdf file describes a camera sensor.

<?xml version='1.0'?>
<sdf version='1.7'>
  <model name='my_camera'>
      <link name="link">
        <visual name="visual">
          <geometry>
            <box>
              <size>0.1 0.1 0.1</size>
            </box>
          </geometry>
          <material>
            <ambient>0 1 0 1</ambient>
            <diffuse>0 1 0 1</diffuse>
            <specular>0 1 0 1</specular>
            <emissive>0 1 0 1</emissive>
          </material>
        </visual>
        <sensor name="camera" type="camera">
          <update_rate>10</update_rate>
          <visualize>true</visualize>
          <!-- camera parameters -->
          <camera>
            <model>pinhole</model>
            <intrinsics> 
              <fx>2382.52</fx>
              <fy>2385.37</fy>
              <cx>1095.98</cx>
              <cy>511.137</cy>
              <s>0</s>
            </intrinsics>
            <image>
              <width>2048</width>
              <height>1024</height>
              <format>R8G8B8</format>
            </image>
          </camera>
          <!-- plugin to publish cam topics in ros2 -->
          <plugin name="camera_controller" filename="libgazebo_ros_camera.so">
            <imageTopicName>image_raw</imageTopicName>
            <cameraInfoTopicName>camera_info</cameraInfoTopicName>
            <frameName>camera_link_optical</frameName>
          </plugin>
        </sensor>
      </link>
  </model>
</sdf>  

The aim is to include an instance of the camera with some different parameters in the robot's model.sdf file.
For example, with a different housing color specified within the <material> tag.

<?xml version='1.0'?>
<sdf version='1.7' xmlns:experimental="http://sdformat.org/schemas/experimental">
  <model name='my_robot'>
    <link name='base'>
       <!-- description of my_robot link -->
    </link>
    
    <include>
      <uri>model://my_camera</uri>
      <pose>1.6 0 3.2 0 0.2 0</pose>
      <name>cam_one</name>
      <static>false</static>
      <experimental:params>
        <visual element_id="link::visual">
          <material action="modify">
            <ambient>0 0 255 1</ambient>
            <diffuse>0 0 255 1</diffuse>
            <specular>0 0 255 1</specular>
            <emissive>0 0 255 1</emissive>
          </material>
        </visual>  
      </experimental:params>
    </include>

    <joint name="cam_one_joint" type="fixed">
      <child>cam_one::link</child>
      <parent>base</parent>
      <pose>0 0 0 0 0 0</pose>
      <physics>
        <!-- description of joint physics -->
      </physics>
    </joint>
  </model>
</sdf>

The code of the robot's model.sdf file mentioned above does not change anything. The camera still has its default color.
Now the question is how to get the parameter passing runnable?

Another point to mention is that you specified libsdformat version 10 and sdf version 1.7 in the tutorial.
But the ros-humble-gazebo-plugins are related to libsdformat9-9 if it is installed with apt install.
I described that format problem in a Gazebo Answers post here.
So how can I set up an environment with ros-humble-gazebo-plugins, libsdformat version 10 and sdf version 1.7 to use parameter passing successfully?
Is the parameter passing still a draft, or is it a more robust version?

It would be very nice if you can give me some advice or hints to make progress on this topic.

I look forward to hearing from you.

Best regards.

Citing stuff in gazebosim/sdformat#275 was kinda painful.
It would be nice if this were more explicitly discoverable, rather than having to sleuth.

Ideal outcome:
The current proposal_format.md gets a section below "Status", that has links to the PRs / commits that make the proposal fully "implemented".

The spec describes //sensor/imu/orientation_reference_frame/grav_dir_x/[@parent_frame] as

Name of parent frame in which the grav_dir_x vector is defined. It can be any valid fully scoped Gazebo Link name or the special reserved "world" frame. If left empty, use the sensor's own local frame.

The current of pose frame semantics proposal does not include this attribute.

For worlds that are saved, they may be flattened, and thus will use the reserved delimiter.

Solutions:

• Don't fix it. Just tell users to go back to the world that used //include.
• Fix it with the inverse of libsdformat9's addNestedModels, but call explicitly (e.g. ign sdf convert --unnest)
• Same as above, but implicitly in standard conversion process

Model kinematics have changed quite a bit from a user perspective in SDFormat 1.7, so we should add an SDFormat 1.7 version of the model kinematics tutorial that describes the new way that model kinematics can be defined with //frame, //pose/@relative_to, and //joint/axis/@expressed_in. It should be at a beginner level and oriented to people creating models, rather than the advanced level aimed at software developers intending to parse SDFormat files that was used in the pose frame semantics proposal. Some of the content could be drawn from the 2019 ROSCon presentation, since I think that was oriented towards people writing models in SDFormat.

Users in the community need guidance on how best to use URDF with SDFormat, especially when using URDF with tools in the ROS ecosystem together with Gazebo. This issue is meant to capture some of the questions/requests raised by members of the community and as a place for discussion on how to address them. There is also an ongoing effort to improve the interoperability of SDFormat with tools in the ROS ecosystem. Since there's likely to be overlap between the work there and some of the discussion here, this issue will hopefully serve as a central place for all discussions regarding SDFormat in the ROS ecosystem.

Here's an initial list of questions to address/discuss:

• What are some best practices for mapping SDFormat models (with nested models) to URDF?
  • Is this even the best way to go about this? Should tools like RViz work directly with SDFormat?
• Can we create a tool to replace model:// to package://?
• Do we have examples showing how to use URDF with ROS and the new Gazebo? If so, how can we improve their visibility?
• Would it be possible to only use SDFormat (and not URDF) with Gazebo and the ROS ecosystem?

cc @srmainwaring @quarkytale @bperseghetti

Related to #8 (comment)

Would be nice to have this be more concisely stated. An issue template seems appropriate?

In Proposal:
http://sdformat.org/tutorials?tut=pose_frame_semantics_proposal&cat=pose_semantics_docs&#1-1-parity-with-urdf-using-pose-relative_to

Not in docs:
http://sdformat.org/tutorials?tut=pose_frame_semantics&cat=specification&