Archive
Robot modelling formats for simulation
Several XML-based formats have surfaced over the years that can be used to describe a robot.
Apart from URDF (and SRDF) of ROS origin, the Gazebo simulator has been promoting SDF (an evolution of URDF with emphasis on physics simulation), while MJCF apart from being available as URDF extensions, also has its own format with an XML schema for validation and more advanced simulation features (e.g. tendons).
URDF (ROS)
http://wiki.ros.org/urdf/XML/joint
http://wiki.ros.org/urdf/XML/link
Also related, units of measurement in ROS: http://www.ros.org/reps/rep-0103.html
Can find some well-known robots (like Boston Dynamics’ Atlas) in URDF format at the data subfolder in: https://github.com/bulletphysics/pybullet_robots
SRDF format http://wiki.ros.org/srdf that is mentioned at http://wiki.ros.org/robot_model is also related (adds Semantics like kinematic chain definition etc). As explained there it is combined with URDF in describing a robot:
This does not replace URDF, and is not an extension of URDF.
This is a format for representing semantic information about the robot structure.
A URDF file must exist for this robot as well, where the joints and the links that are referenced are defined
SDF (Gazebo)
http://gazebosim.org/tutorials?tut=build_model
http://sdformat.org
http://sdformat.org/spec
https://bitbucket.org/osrf/gazebo_models/src (various SDF models in XML)
http://gazebosim.org/tutorials/?tut=ros_urdf (Converting from URDF to Gazebo)
http://gazebosim.org/tutorials?tut=simple_gripper (tutorial for simple gripper in SDF)
Gazebo seems to be using ODE (Open Dynamics Engine), so these are related too:
http://www.ode.org/ode-latest-userguide.html#sec_7_3_0 (see images for Joint types)
http://www.ode.org/ode-latest-userguide.html#sec_3_6_0 (ERP & CFM constraint parameters)
MJCF (MuJoCo)
http://www.mujoco.org/ (MuJoCo 1.50 was released on April 23, 2017. Student licenses are now free)
http://www.mujoco.org/book/modeling.html
http://www.mujoco.org/book/modeling.html#CURDF (MJCF is an advanced format but some of its functionality is also available as URDF extensions)
http://www.mujoco.org/book/computation.html#Constraint (MuJoCo has constraints like Connect/Weld/Joint/Tendon/Distance)
https://homes.cs.washington.edu/~todorov/papers/TodorovIROS12.pdf (see paragraph «B. Elements of a MuJoCo model»)
URDF to MJCF conversion is possible (related sample available for MuJoCo):
http://www.mujoco.org/forum/index.php?threads/urdf-mjcf-conversion.3429/
There is ongoing work at Bullet Physics engine to import MJCF, as mentioned at:
https://github.com/bulletphysics/bullet3/releases
Thus, they have collected various MJCF models (XML):
https://github.com/bulletphysics/bullet3/tree/master/data/mjcf
Suggestion: on Duck Typing and C#/.NET
My comment at:
It would be nice indeed if one could define at the client object’s side a static interface that is a subset of the methods of a server (or serving if you prefer) object (it is only the view of the server that the client has gained knowledge of) that has been passed on to the client
Then there could be a service (a facility I mean) that accepts the server object instance and the interface the client has defined (the duck type) and case the server object to that interface by CHECKING that the duck interface is indeed a subset of the methods the server object implements
the check if our duck interface is indeed covered by what the object to be duck-typed offers can be implemented via reflection already
the implementation could be hacked by spitting out a new object (bytecode generation) that wraps each property/method of the object to be duck-typed and calls into the original object, but it would be much better if there was support in the compiler for that (viewing an object via an interface that is compatible to it in functionality, not in strong typing concept)
…when I say support in the compiler, I mean to avoid the proxying layer (of course security should also be considered carefully when implementing such a thing, in case there are pitfalls)
A very interesting article on the subject showing how to do DuckTyping in .NET is:
http://www.codeproject.com/Articles/122827/DynamicObjects-Duck-Typing-in-NET
Not sure if in the time that has passed (5 years) there have been any DuckTyping-specific additions at C#/.NET
Suggestion: Add support for constants in C# (and VB.net etc.) interfaces
It is rather unfortunate that C# doesn’t support constants in interfaces, whereas Java does.
If IL (intermediate language) that C# usually compiles to (when not using AOT that is like in .NET Native or Xamarin iOS) doesn’t support this, then the compiler could create a special sealed class to carry the constants.
Then, wherever they’re used via the interface it could get them via that class. This would happen internally without the programmer noticing. The programmer should be able to access the constants using:
ISomeInterface.SomeConstant
SomeClass.SomeConstant, where SomeClass implements ISomeInterface
just SomeConstant when the code is inside the body of SomeClass that implements the ISomeInterface
just SomeConstant when there is a “using static” statement (that newer C# has introduced) like “using static ISomeInteface” or “using static ISomeClass”
You can vote up this suggestion at:
http://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10724265-add-support-for-constants-in-c-and-vb-net-etc
George Birbilis @zoomicon 