This repository holds the documentation located at https://sdformat.org/tutorials.
gazebosim / sdf_tutorials Goto Github PK
View Code? Open in Web Editor NEWSDFormat documentation and proposals.
Home Page: http://sdformat.org
SDFormat documentation and proposals.
Home Page: http://sdformat.org
This repository holds the documentation located at https://sdformat.org/tutorials.
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!
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:
The SDFormat 1.7 frame semantics proposal contains two restrictions on the contents of //@name
attributes:
//@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
joint damping (linear), friction (-sgn(velocity)), joint spring stiffness and spring reference
Per convo on 2019-05-29 on Asana.
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.
Per Asana task, 2019-06-25.
Initial draft:
https://github.com/osrf/sdf_tutorials/tree/spec_inertial
\cc @scpeters
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.
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>
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:
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:
//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:
sdf_web_app
once it's public.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:
No README currently. The new readme should have something like:
sdformat.org
sdformat
repository?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.
The links to the MJCF converters here are broken.
Thanks!
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:
//include
.addNestedModels
, but call explicitly (e.g. ign sdf convert --unnest
)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:
model://
to package://
?Related to #8 (comment)
Would be nice to have this be more concisely stated. An issue template seems appropriate?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.