Consider adding friction/restitution coeff, JointLimitOn, self-collision etc. to skel file

[jyf588]

Hello everyone,

Currently in DART there are several parameters and flags that could only be specified in C++ programs. We might want to consider adding them to skel file, in body or world sections (or both).

Reasons include:

1. beginning users usually don't know what they need to set and what they don't. Better to document all settings in https://github.com/dartsim/dart/wiki/SKEL-Version-0.2#skel-file-format.
   (A common mistake is to set joint limit values in skel but forget to turn on them in C++. It should help if skel file will compile only when joint limit section follows explicit EnableLimit flag.)

2. Users don't need to iterate all bodies/joints for these settings.

3. Ideally, all the passive physics settings (with no control involved) can be put in skel file. Users will then be able to start passive simulation with several lines of C++ code. The C++ program could focus more on control and runtime change of settings.

The passive parameters and flags coming to my mind are: friction & restitution coefficients, isJointLimitOn, isSelfCollisionCheckOn, and isAdjacentBodyCheckOn. Mujoco's xml tutorial may serve as a good reference for including more flags: http://www.mujoco.org/book/modeling.html.

Thanks,
Yifeng

[jslee02]

I agree with you. The Mujoco's tutorial is pretty comprehensive. 😅

[mxgrey]

My personal feeling is that the skel format is in need of an overhaul. I completely agree that every single state and property field should be exposed in a file format, but I personally have a strong distaste for xml. I would much rather have a comprehensive yaml format, because I think it would be much cleaner and readable.

Basically, I do think we need to invest effort into making a totally comprehensive file format, but before we put forward that effort, I'd like us to decide if we really want to expand the existing skel format or if we'd be open to offering a more streamlined file format. I already opened a discussion on that matter here #496 although I don't think there was a definitive conclusion. I'd appreciate more opinions from the community before I draw any conclusions on the matter.

[jslee02]

I also prefer having a comprehensive YAML format, but it would take time. The reason I agree on this expansion is that the implementation would be straightforward. If this change is not that time critical, I would also like to put our effort to creating a new format with YAML. But at the same time, I'm not sure if we have enough time to do this shortly, though.

[mxgrey]

That's definitely fair. What this particular pull request is asking for would be very straightforward to put into the existing format. I was thinking more long-term where we may need to keep adding more tags as DART incorporates new features. Also, being able to save to a file (which we currently have zero support for).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.