dartsim: fdir1 expressed_in frame from SDFormat

[scpeters]

🎉 New feature

Summary

There is a new API in dartsim 6.10 that allows specifying the frame in which the first friction direction (fdir1) vector is expressed. This is not yet part of the SDFormat specification, but for now, set this frame if a link name (body node) matches the value of this namespaced //fdir1/@gazebo:expressed_in attribute.

Test it

I use this feature in a model of a vehicle with Mecanum wheels and will submit it to ignition-gazebo shortly.

Checklist

• Signed all commits for DCO
• Added tests
• Added example and/or tutorial
• Updated documentation (as needed)
• Updated migration guide (as needed)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge

[chapulina]

Thanks for the PR!

This is not yet part of the SDFormat specification

Should we consider adding it there? Once this PR is released, users will start creating models with //fdir1/@gazebo:expressed_in, and we'll need to support that for a long time.

[scpeters]

Thanks for the PR!

This is not yet part of the SDFormat specification

Should we consider adding it there? Once this PR is released, users will start creating models with //fdir1/@gazebo:expressed_in, and we'll need to support that for a long time.

what do you think @azeey? should we add //surface/friction/ode/fdir1/@expressed_in to the spec?

[azeey]

Thanks for the PR!

This is not yet part of the SDFormat specification

Should we consider adding it there? Once this PR is released, users will start creating models with //fdir1/@gazebo:expressed_in, and we'll need to support that for a long time.

what do you think @azeey? should we add //surface/friction/ode/fdir1/@expressed_in to the spec?

This capability seems very powerful and would be great to have, but a concern I have is that the allowed values of expressed_in are only the BodyNodes in DART. This usage of expressed_in would be different form //joint/axis/xyz/@expressed_in because the latter can reference any frame in the scope. For this to be fully functional, DART needs to know about SDFormat frames.

[scpeters]

a concern I have is that the allowed values of expressed_in are only the BodyNodes in DART. This usage of expressed_in would be different form //joint/axis/xyz/@expressed_in because the latter can reference any frame in the scope. For this to be fully functional, DART needs to know about SDFormat frames.

so it sounds like it would be preferable to keep it in a custom xml namespace at this time? is gazebo a suitable xmlns?

[chapulina]

is gazebo a suitable xmlns?

the allowed values of expressed_in are only the BodyNodes in DART.

Maybe dart is more appropriate?

[azeey]

so it sounds like it would be preferable to keep it in a custom xml namespace at this time? is gazebo a suitable xmlns?

I would say gazebo since we already use it for levels and I would think we only need one namespace for all gazebo specific elements/attributes. If we want to be further specific about DART, maybe gazebo:dart_expressed_in?

A totally different approach, one that would take a lot more time, would be to create a feature in ign-physics for setting the friction direction frame and have the mecanum system send a command to the physics system via a FrictionDirectionFrameCmd component set on the collision entity of interest. Then we can keep the expressed_in element out of //surface and put it in the mecanum system configuration SDFormat element.

[chapulina]

My main reservation about using gazebo is that ign-physics isn't Gazebo-specific. Nowadays other simulators need to support <gazebo> tags in URDF because that became the de-facto standard. I'd rather start off being other-simulators-friendly if we can.

I would think we only need one namespace for all gazebo specific elements/attributes.

Is there a downside to using various namespaces side-by-side?

[azeey]

My main reservation about using gazebo is that ign-physics isn't Gazebo-specific. Nowadays other simulators need to support tags in URDF because that became the de-facto standard. I'd rather start off being other-simulators-friendly if we can.

Yes, having to read a gazebo specific attribute in ign-physics creates a coupling between gazebo and ign-physics, which we probably want to avoid. So if we think if it's not gazebo-specific, then we should look into adding it to SDFormat. But it's always possible that other simulators implement gazebo specific tags. For example, another simulator may implement levels and choose to use the gazebo:level tag because there are SDF files out there that already have the tag.

Is there a downside to using various namespaces side-by-side?

My thought for the future was we that could keep all gazebo specific additions in one namespace and document them in a separate website that is dedicated to extensions to SDFormat. It would also allow us to have one schema file that we would use to validate the xml if we want to do that down the road.

[scpeters]

remember we are still planning to redo the friction parameters at some point: gazebosim/sdformat#31

also, this friction attribute is embedded in an <ode> element, which dart is using. things are already a bit messy

[chapulina]

could keep all gazebo specific additions in one namespace and document them in a separate website that is dedicated to extensions to SDFormat.

Got it. So my final suggestion: use the ignition namespace instead of gazebo.

But I don't feel too strongly either way. As @scpeters reminded, all the friction parameters should be reworked eventually.

[scpeters]

my final suggestion: use the ignition namespace instead of gazebo.

I don't really care which namespace we use. Any preferences @azeey ?

[azeey]

ignition sounds good.

[chapulina]

@scpeters , are you planning to make any more changes before opening this for review? Or just waiting for the ign-gazebo demo to be fully functional?

[scpeters]

@scpeters , are you planning to make any more changes before opening this for review? Or just waiting for the ign-gazebo demo to be fully functional?

this doesn't need any more changes; it's just ign-gazebo that needs them. I've marked this ready for review

[chapulina]

Thanks, this looks good to me. I think we just need to find a good place to document this so it doesn't get forgotten.

[scpeters]

Thanks, this looks good to me. I think we just need to find a good place to document this so it doesn't get forgotten.

I think we could mention it in gazebosim/sdformat#31