Contact friction (i.e. mu)

[limbryan]

Hi,

I was wondering if there were any existing simple functions or ways to define the friction between the robot and the floor (or for contact friction in general). This is pretty important for legged robots as the friction can heavily affect learnt behavior especially.

I have looked through robot_dart and only found set_cfriction_coeffs and some similar functions but there was little documentation and examples surrounding it so it was unclear what it was actually for - also noticed it used the DoF to implement the friction so likely that it could have been joint friction. I ended up implementing this myself using dart functions (setFrictionCoeff) like below:

but does not seem very elegant to be selecting all the nodes of the floor and setting the coeff of friction. Would it be worth implementing a simple function that comes with robot_dart which just takes in a coeff of friction between 0 and 1 and automatically applying them to the contacts between robot and floor?

[costashatz]

Hello @limbryan,

Thanks for using our library!

Indeed you are right, we do not have any function for this. Let me fix this as soon as possible (I'll try to do this, this week).

[limbryan]

Hi @costashatz ,

Thank you for the quick response and for this great tool. Great, I will check back in next week. Thank you again!

[costashatz]

@limbryan I found some time today and here's the PR #117...

One important thing to note is that the default FrictionDirection is a zero vector and thus the friction coefficients are ignored! So one needs to set this at least for one BodyNode involved in the collisions! I will attempt to create an automatic way of doing this for the floor, so that at least everything that interacts with the floor gets the default friction coefficients instead of collision without coefficients. We should definitely put this in the docs (speaking to myself, no worries).

Let me know if this works for you..

[limbryan]

Thanks @costashatz! That was really fast! I went through the commit changes quickly and noticed that the python wrappers for these changes might have been missed out as well. Might be worth to keep this in mind for consistency.

I did not know that about the FrictionDirection. This likely means that my implementation did not really work as I did not set the direction - though I did see a change in the behaviors learnt which is weird and the coverage of the map. What is the definition of friction direction (realistically, we would have the same friction coefficient applied in all directions no?) does this end up meaning the friction cone? and I guess the big question is should this direction be determined by the user for generic purpose, or is this what you meant by this should automatically be taken care of included once it is done for the floor?

Thanks again btw!

[costashatz]

noticed that the python wrappers for these changes might have been missed out as well. Might be worth to keep this in mind for consistency.

I'll do this. Do not worry. Thanks for noticing though.

though I did see a change in the behaviors learnt which is weird and the coverage of the map

Are you sure there was a difference? Which version of DART are you using?

What is the definition of friction direction (realistically, we would have the same friction coefficient applied in all directions no?) does this end up meaning the friction cone?

To be honest I am not sure. You can check the ContactConstraint if you like. The default one should the UnitZ direction.

I guess the big question is should this direction be determined by the user for generic purpose, or is this what you meant by this should automatically be taken care of included once it is done for the floor?

I meant to do this only for the floor. But I can put their default direction to all our created robots. It could make sense.

I also believe that they have a small bug in their current implementation, because they assume no friction coefficients by default, whereas previously this wasn't the case.

[costashatz]

@limbryan Quick comment: DART does not ignore the friction. It just assumes the default friction direction. No idea how this direction can influence the results. But I am not going to search more for it. I hope the API is good for you. In theory DART allows changing all the ShapeNodes of a BodyNode, but I am assuming that we set all ShapeNodes of a BodyNode with the same values. In most cases, one BodyNode has one ShapeNode with dynamics aspect.

[limbryan]

@costashatz Great! Thank you again for being so quick. I will test it out today. Just to clarify once again about the FrictionDirection, do I need to set it for my robot and the floor - or as you mentioned, there is a default direction that is probably fine? Because if I have to set it, it is unclear to me what this value should be and I would most likely just use a 1,1,1 vector .

Are you sure there was a difference? Which version of DART are you using? I am using dart 6.9.4. well, I am running MAP Elites using a simple x-y 2D behavioral descriptor for a hexapod. The first evidence after I added the friction (my implementation) was that the coverage of the map clearly decreased as the robot could not easily slide everywhere like skiing. Second is I also visually viewed the behavior and the sliding behavior did stop (although then it just ended up moving its feet really fast/vibration. So I definitely did notice some difference.

[costashatz]

Just to clarify once again about the FrictionDirection, do I need to set it for my robot and the floor - or as you mentioned, there is a default direction that is probably fine? Because if I have to set it, it is unclear to me what this value should be and I would most likely just use a 1,1,1 vector .

As I said in my previous comment. DART is giving a default direction and I would leave it as is.

I am using dart 6.9.4

I would advise you to switch to the latest master. Or wait for 6.10.

So I definitely did notice some difference.

Yes as I said I was mistaken that DART ignores the friction.

I'll finish the PR today and you can test it..