Add free-floating joint at the root of metapodfromudf-generated models

[thomas-moulard]

Dear all, I tried to use metapodfromurdf with the HRP-4 model and so far it works quite well.

One slight addition that would have helped me is the possibility to add the root free-floating joint automatically.

I see two main reasons to this:

1. I prefer to not have the free-floating joint in my URDF models. Mainly because I would like to have a CAO-like model, close to the mechanical design without any computation artefacts such as the free-floating joint inside. Then the software loading/parsing the model can do the appropriate modification to obtain a workable computation model.
2. Free-floating joints are unfortunately deprecated in URDF. They probably will not go away anywhere soon but still it does not harm to be future-proof. Especially because in our use case, the free-floating joint has only sense as a root joint.

Sorry, I am a bit lacking time to directly open a pull request right now, but something like an additional optional argument called --add-root-floating-joint to metapodfromurdf would be IMHO a nice addition.

[olivier-stasse]

Dear Thomas, Sébastien, a while ago, created a config file which add some semantic to the parsing of URDF file to keep the compliance with the standard. You can specify the link between the joint ID and the name of the joints in the URDF files using this file. From this file, the joint with ID 0 is the root of the kinematic chain. Starting from this, could you elaborate your suggestion ?

Best, Olivier.

[thomas-moulard]

Yes, I have seen this option but it cannot be used to actually "add" a joint, right?

[aelkhour]

FYI, the PR2, HRP-2 and Romeo URDF files do not have a free-flyer joint in the kinematic tree, it is added later on by the various parsers (for rviz, kineo, jrl-dynamics, etc).

On Wed, Apr 24, 2013 at 10:04 AM, Thomas Moulard notifications@github.comwrote:

Yes, I have seen this option but it cannot be used to actually "add" a joint, right?

— Reply to this email directly or view it on GitHubhttps://github.com/laas/metapod/issues/65#issuecomment-16912994 .

[sbarthelemy]

@thomas: no you cannot add a joint using this option.

Regarding your motivations, the first one does not convince me much since the urdf already forces you to choose a particular kinematic tree (a opposed to an undirected kinematic graph) which rules the problem parametrization.

But anyway, relying on deprecated feature is not wise, I'm very favourable to adding this option.

I wonder, if there is a way in urdf to tell apart a model with a free floating base from a fixed one without resorting to the (urdf) floating joint? In such a case, maybe the option is not necessary and we can properly detect when adding the (metapod) floating joint is needed.

Note also that metapod supports simulating several robot (nobody ever tested it though), potentially with and without a floating joint. The --add-root-floating-joint option could take an argument to name which root joint is targeted.

As a side note, I have a urdf_filter.py script (based on xml.sax) which I use for these sort of things (adding and removing joints and links, etc.). I can share it.

[sbarthelemy]

it turns out the floating joints are not deprecated in the end. Ioan Sucan clarified that yesterday. I'm still not aware of any way to guess when a floating joint is needed if the original urdf file lacks one. This is probably not possible.

So, let go for an option.

[thomas-moulard]

Well I guess it really depends on your use case and the kind of robot you consider.

But AFAIK I have never seen a free-floating joint as a root joint for any model from Willow so I would consider this as a mistake to add one directly in the URDF file. Actually I think if you do so, many nodes that are making assumption on the root body being the base link will fail.

The idea is, if you do IK you probably don't want a FF, if you do dynamics computation you probably want one to get forces on your root body. The fact that that you exclude it from your model has two advantages, it does not force the user to consider the FF and it is consistent with the robot "real" hardware.

[sbarthelemy]

But AFAIK I have never seen a free-floating joint as a root joint for any model from Willow

I've been told MoveIt uses (requires?) the floating/planar joint. I do not know if they add it on the fly or not.

[...] it is consistent with the robot "real" hardware [...]

Not with a melding arm robot fixed on the ground.

We have three choices:

1. add a floating joint automatically when needed
2. add the floating joint by default and provide an option to disable it
3. do not add add the floating joint by default but provide an option to do so

I do not think option 1 is possible. Option 2 looks like misinterpreting the input file to me, so I'd go with 3, as you first suggested.

ok?

[olivier-stasse]

I strongly agree with your point.

However, should we make the free-floating free to specify to any joint or used directly the root of the kinematic tree ? If we let the user to choose freely his joint then we have to reorganize the tree to make it the root for metapod.

[sbarthelemy]

(beware: longest post ever)

However, should we make the free-floating free to specify to any joint

just to be clear: the root of the metapod robot is not necessarily a free-floating joint. It can handle models containing both a fixed robot and a free-floating one. For example a world with a scara and an (headless) humanoid would be modelled with

Galilean frame-----------+
 | revolute z joint      | floating joint
scara0                  torso-----------------+-------------------+-------------------+
 | revolute z joint      | revolute joint     | revolute joint    | revolute joint    | revolute joint
scara1                   left arm             right arm           left leg            right leg
 | transl z joint
scara2

The URDF can follow this representation (with a massless link for the Galilean frame).

But the URDF can also be written with two disjoints tree like this

Galilean frame
 | revolute z joint
scara0
 | revolute z joint
scara1
 | transl z joint
scara2

torso-----------------+-------------------+-------------------+
 | revolute joint     | revolute joint    | revolute joint    | revolute joint
left arm             right arm           left leg            right leg

In this second case we need a way to tell metapodfromurdf to prepend a floating joint to torso and not to Galilean frame.

If we let the user to choose freely his joint then we have to reorganize the tree to make it the root for metapod.

Reorganizing the tree would be out of the scope of metapodfromurdf I think. Such a kinematic library could be implemented as a preprocessing tool which takes an urdf/collada/wathever file as an input and produces another one as an output. I would probably be useful beyond the metapod case.

I was willing to let the user choose which link will be the free-floating joint child among the urdf roots and not among all the links. It is much easier to implement and can be done directly in metapodfromurdf. Something like

--add-root-floating-joint link-name floating-joint-name

where link-name is an existing root link in the urdf and floating-joint-name is the name of the new floating joint.

In the above case, it would be --add-root-floating-joint torso MyFreeFlyerJoint

--add-root-floating-joint "left leg" MyFreeFlyerJoint would lead to an error.

But now I realize that most users won't use such mutli-robots models. And the one who do will probably assemble them from several URDF files anyway, they can add the floating joint explicitly at this step.

So we could restrict the option to URDF files with a single root. It would then be

--add-root-floating-joint floating-joint-name

Thoughts?

[aelkhour]

On Fri, Apr 26, 2013 at 12:22 PM, Sébastien BARTHÉLÉMY < notifications@github.com> wrote:

(beware: longest post ever)

However, should we make the free-floating free to specify to any joint

just to be clear: the root of the metapod robot is not necessarily a free-floating joint. It can handle models containing both a fixed robot and a free-floating one. For example a world with a scara and an (headless) humanoid would be modelled with

Galilean frame-----------+ | revolute z joint | floating joint scara0 torso-----------------+-------------------+-------------------+ | revolute z joint | revolute joint | revolute joint | revolute joint | revolute joint scara1 left arm right arm left leg right leg | transl z joint scara2

The URDF can follow this representation (with a massless link for the Galilean frame).

But the URDF can also be written with two disjoints tree like this

Galilean frame | revolute z joint scara0 | revolute z joint scara1 | transl z joint scara2

torso-----------------+-------------------+-------------------+ | revolute joint | revolute joint | revolute joint | revolute joint left arm right arm left leg right leg

In this second case we need a way to tell metapodfromurdf to prepend a floating joint to torso and not to Galilean frame.

If we let the user to choose freely his joint then we have to reorganize the tree to make it the root for metapod.

Reorganizing the tree would be out of the scope of metapodfromurdf I think. Such a kinematic library could be implemented as a preprocessing tool which takes an urdf/collada/wathever file as an input and produces another one as an output. I would probably be useful beyond the metapod case.

I was willing to let the user choose which link will be the free-floating joint child among the urdf roots and not among all the links. It is much easier to implement and can be done directly in metapodfromurdf. Something like

--add-root-floating-joint link-name floating-joint-name

where link-name is an existing root link in the urdf and floating-joint-name is the name of the new floating joint.

In the above case, it would be --add-root-floating-joint torso MyFreeFlyerJoint

--add-root-floating-joint "left leg" MyFreeFlyerJoint would lead to an error.

But now I realize that most users won't use such mutli-robots models. And the one who do will probably assemble them from several URDF files anyway, they can add the floating joint explicitly at this step.

So we could restrict the option to URDF files with a single root. It would then be

--add-root-floating-joint floating-joint-name

Thoughts?

In this case, would we still be able to add floating joints for multiple floating-base robots in one same metapod file?

— Reply to this email directly or view it on GitHubhttps://github.com/laas/metapod/issues/65#issuecomment-17065745 .

[sbarthelemy]

In this case, would we still be able to add floating joints for multiple floating-base robots in one same metapod file?

if your URDF has several trees and already has the necessary floating joints, you won't use the option and it will work.

if your URDF has several trees but not the floating joints, you cannot use the option, so it won't work. You should provide a proper urdf file.

Note that a single option

--add-root-floating-joints

(note the s) would not allow us to name the newly created joints.

[thomas-moulard]

Sorry I just realized that I did not answer to this. Yes, an option is fine IMHO. Not being able to name the joint is also ok for now at least.

In the context of multi-robot, I think you need multiple URDF files and you should not try to combine them into one model. The natural way to handle this in ROS is to push topics and parameters into a namespace (/robot1/model_description, /model2/robot_description, etc.).

On the metapod side then, if I were to support multirobot then the first thing I would do would be to extend metapodfromurdf to accept several URDF files as input.

[sbarthelemy]

In this case, would we still be able to add floating joints for multiple floating-base robots in one same metapod file? if your URDF has several trees and already has the necessary floating joints, you won't use the option and it will work.

Well it turns out that URDF does not support having several trees. I'll send a pull request with the fix quite soon.