specify friction parameters in odephysics engine

[rdiankov]

Nick: http://www.ode.org/ode-latest-userguide.html#const_dContactApprox1

our variation of the ode plugin is essentially the same as yours, but with more xml tag options 22:49 I think just a contact model tag in the xml would suffice for most people :) so users can decide what they want for themselves 自分: ok, do you have a preferable way you want to specify it? or should i decide? ..within the xml field 22:50 Nick: apologies: contact[i].surface.mode = 0 specifies friction force is constant and capped to mu (default in oderave is 1N) 22:51 You can decide - we use multiple tags and just "|" them eg:

dContactApprox1 dContactSoftCFM dContactSoftERP

and somehting like: fricmodel = fricmodel | dContactApprox1; in our xml parser 22:53 自分: ok, what do you think about this way:

Approx1|SoftCFM|SoftERP

basically remove the dContact stuff furthermore, if you want to narrow it down to two bodies only you would do Nick: sounds good 自分: Approx1|SoftCFM|SoftERP 22:54 Nick: that would be good functionality 自分: i guess we can also add regular expressions ie: 22:55 Approx1|SoftCFM|SoftERP Nick: at the moment a typical spec limited between two bodies for us looks like this:

terrain front_right_wheel 0.6 dContactApprox1 dContactSoftCFM dContactSoftERP 0.0001 0.95

[rdiankov]

Given the number of other properties that can be set for a given contact collision, I'm going to try to modify our implementation to something like this:

<contact body="ground" body="car">

    <mu>0.6</mu>
    <cfm>0.0001</cfm>
    <erp>0.95</erp>
    <model>Approx1|SoftCFM|SoftERP</model>

</contact>

Comments?

[rdiankov]

The xml reader doesn't like the dual definition of the body attribute in the contact tag:

[xmlreaders.h:155] XML Parse error: Attribute body redefined

so I am defining them as body1, body2.

[rdiankov]

An example as I've implemented it:

<physicsengine type="custom_ode">

    <custom_odeproperties>

        <contact body1="mug">

            <mu>300</mu>

        </contact>
        <contact body1="terrain" body2="front_left_wheel">

            <mu>0.6</mu>
            <cfm>0.0001</cfm>
            <erp>0.95</erp>
            <model>Approx1 SoftCFM SoftERP</model>

        </contact>
        <contact>

            <mu>0.5</mu>
            <model>Approx1</model>

        </contact>
        <gravity>0 0 -9.81</gravity>
        <SelfCollision?>on</SelfCollision>
        <autodisable>on</autodisable>
        <linearthreshold>0.1</linearthreshold>
        <angularthreshold>0.5</angularthreshold>
        <disabletime>0.05</disabletime>
        <solver>QuickStep?</solver>

    </custom_odeproperties>

    </physicsengine>

Comments welcome.

[rdiankov]

A couple of comments:

rename body1 and body2 to body0 and body1

in order to be consistent with other openrave xml conventions, turning on options are either "0"/"1" or "true"/"false", adding a third "on"/"off" is not necessary.

I'm sure if someone read the ode docs, "mu, cfm, erp" would make sense. But they are easy to forget. Perhaps have a longer tag name for al of them. Your others like "disabletime" "angularthreshold" are awesome.

..i'm not sure what "autodisable" is....?

why do we need angular/linear thresholds

[rdiankov]

Replying to rdiankov:

rename body1 and body2 to body0 and body1

Done

in order to be consistent with other openrave xml conventions, turning on options are either "0"/"1" or "true"/"false", adding a third "on"/"off" is not necessary.

Done for the selfcollision and autodisable options. I think that is all there are.

I'm sure if someone read the ode docs, "mu, cfm, erp" would make sense. But they are easy to forget. Perhaps have a longer tag name for al of them. Your others like "disabletime" "angularthreshold" are awesome.

changed "mu" to "friction" to be more consistent with your implementation. "erp" stands for "elastic reduction parameter" and "cfm" stands for "constraint force mixing". They are terms particular to the way the physics is implemented (in both bullet and ode) and control how the simulation trades springy-ness and spongey-ness for stability in the numerical solution. I don't know what else to call them - if you are changing them then I would assume that you know what they are. They are useful to have exposed if you find your simulated collisions are too soft (e.g. the joints in the arm of a robot) or too hard (e.g. the tyres of a vehicle) or if it keeps crashing due to numerical stability issues.

..i'm not sure what "autodisable" is....?
why do we need angular/linear thresholds

"autodisable" allows for the physics engine to stop computing the dynamics of objects (and treat them as kinematic objects only) if they are not doing anything and so can save significant computational resources if you are simulating lots of things.

A typical example is a cube sitting still and by itself on a flat plane. The dynamics are reactivated if something happens to the disabled object like it gets hit by a ball or has a force applied to it. The angular/linear thresholds determine at what minimum angular/linear velocity should the physics engine assume that it's "close-enough" to being stopped to treat it as a kinematic object from then on.

Whilst it's good to have autodisable turned on most of the time, there are issues with the reactivation algorithms that mean if you have a tall tower of many cubes and remove the bottom cube, sometimes the top few will remain deactivated and just float in space whilst the others all tumble to the ground.

[rdiankov]

and it is then ;0) is mu (friction), coloumb friction? if so, then ?