It would be excellent if the specification permitted using frames. Per #200, if a link creates an implicit frame, then this change will be backwards-compatible at a specification level.
Motivation
When specifying a world in SDF, it would be nice to specify joints with more semantics than just a link and an offset; e.g. if I want to weld a mug to the top of a table, I can specify two frames (completely invariant of the model frames) on the mug and table, and then just weld those two frames together. For a robot with revolute joints, you can embed better semantics when assembling the robot.
I am willing to provide a draft change to the spec, and possibly to the API as well to accommodate this change while considering backwards compatibility.
Describe alternatives you've considered
TTBOMK, the alternative is to use the present state, which is to manually compute the kinematics; while feasible, this is brittle due to numerics. Xacros / ruby templates shouldn't be necessary for conveniently joining things.
Original report (archived issue) by Eric Cousineau (Bitbucket: eacousineau, GitHub: EricCousineau-TRI).
Summary
At present, the
<child>
and<parent>
elements of<joint>
are constrained to be links: http://sdformat.org/spec?ver=1.6&elem=joint#joint_parentIt would be excellent if the specification permitted using frames. Per #200, if a link creates an implicit frame, then this change will be backwards-compatible at a specification level.
Motivation
When specifying a world in SDF, it would be nice to specify joints with more semantics than just a link and an offset; e.g. if I want to weld a mug to the top of a table, I can specify two frames (completely invariant of the model frames) on the mug and table, and then just weld those two frames together. For a robot with revolute joints, you can embed better semantics when assembling the robot.
I am willing to provide a draft change to the spec, and possibly to the API as well to accommodate this change while considering backwards compatibility.
Describe alternatives you've considered
TTBOMK, the alternative is to use the present state, which is to manually compute the kinematics; while feasible, this is brittle due to numerics. Xacros / ruby templates shouldn't be necessary for conveniently joining things.
Additional context
If this proposal is accepted, I would like to ensure that this feature is implemented in Drake here: https://drake.mit.edu/doxygen_cxx/namespacedrake_1_1multibody_1_1parsing.html#a3e9bff0197c6c7f86f9ff6f8854def53 https://drake.mit.edu/pydrake/pydrake.multibody.multibody_tree.parsing.html#pydrake.multibody.multibody_tree.parsing.AddModelFromSdfFile Downstream issue: https://github.com/RobotLocomotion/drake/issues/9910
\cc @nkoenig