The current version of the URDF specification has no separation between the concept of a frame of reference (i.e. a point and orientation uniquely defined in the 3D space) and of link (a physical rigid body that has a mass and a shape). In my limited experience I found that this distinction is desirable, especially in application that take into account the dynamics of a multibody system.
In URDF there is only one concept, model by the <link> xml element, that is used to model a rigid body with a frame of reference rigidly attached to it. The common practice is then to model additional “frame of references” in a link as <link> xml elements without any mass or shape, attached to a “real” link with a fixed joint.
While this “ambiguity” between link and frames is convenient for software dealing just with kinematics, because reducing the number of concepts in a representation helps to reduce complexity, it is inconvenient for software dealing with dynamics, either for simulation, estimation or control. The typical pattern is that dynamics software try to understand if a URDF <link> is a real link or just a frame using heuristics, but unfortunately this heuristics are typically different from software to software. I’ll try to make some examples related to this topic.
While converting an URDF to an SDF, Gazebo automatically removes all the links connected to their parent with a “Fixed” joint, lumping their inertial properties and collision/visual meshes in the parent. This techniques revealed several shortcomings:
- The implementation of such a converter is quite complex, and consequently the robustness is low. For example if several fixed joint are connected one to another the converter fails [8] .
- All the information about the “lumped” fake links is lost: but that information could be still necessary [7] .
On the other hand several dynamics libraries (such Drake [3][4], Pinocchio [1] [2] or iDynTree [5] [6] ) separate the concept of frame and link, but they extract the distinction between an actual link and a fake link from the URDF in different ways. Consequently is quite difficult to write a URDF file that contains information about “real” link and “fake” links that are instead just additional frame in a way that can be parsed well by all this libraries .
It would then be desirable for the new generation of *RDF to provide a clear and unambiguous way to define an additional frame for a given link.
P.s @jackie I never used discourse, let me know if a discussion on this is suited to this category or not.
References (apparently discourse is preventing me to paste more then two links, I moved them to a gist for convenience):