Closed aamorel closed 2 years ago
would it be possible to have a video highlighting the instabilties you are mentionning?
Yes for sure !
Here, the contact is between surface from first body and ground: stable contact. https://user-images.githubusercontent.com/43774341/177783393-5a274935-f625-4ed1-af1d-f9a4abcb41b0.mp4
Here, the contact is between surface from last body (surface on top) and ground: unstable contact. https://user-images.githubusercontent.com/43774341/177783402-ccf71133-e3e7-43cc-ba1d-e86bf3f90e8d.mp4
Hi @aamorel
Can you try to flip the normal on the top surface (so that it's towards the same direction as the bottom surface) and try again?
Hi @gergondet, thank you for your time
Flipping the top surface's normal does not change the instability.
Actually, I don't think the bug is due to the direction of the normal, because when I set the contact between the two other surfaces from the first body (white one on the bottom) with the ground, the contact is stable (even if the surfaces are facing the sides).
Hi @aamorel
I gave it a try locally and I'm able to reproduce the issue.
I will look more into it in the coming days but in the meantime, switching the contact constraint formulation to position instead of velocity improves the situation significantly.
If you are using a basic controller then you simply overwrite the contactConstraint
object before adding it to the solver:
using ContactType = mc_solver::ContactConstraint::ContactType;
contactConstraint = mc_solver::ContactConstraint(solver().dt(), ContactType::Position);
solver().addConstraintSet(contactConstraint);
If you are using an FSM controller you simply specify the contact's constraint contact type:
constraints:
- type: contact
contactType: position
Thank you for your help.
Even with the contactType: position
, the contact is still drifting for the surfaces not linked to the root body, as you can see below (for example at t=5s
):
https://user-images.githubusercontent.com/43774341/177964640-9065f1f8-7b70-4214-ade2-0731a757e1a5.mp4
We are also trying to dig into this on our side.
Hi @aamorel Can you please redo the simulation with one module only. This problem is certainly reproducible with one module. In one of the roombot you will attach the base to the ground and normally the terminal point will rotate nicely keeping the constraint to the ground fixed, then you link the terminal point of that one roombot to the ground and let its base unconstrained. Normally at this stage we will see the terminal point constrained not really fullfilled. @gergondet just checked that the numerical constraint (i.e. as formulated in the QP) hold well in both cases! This might means that the solution found for the base motion when the terminal point is constrained is wrong and the rendering since it starts from the base will give the impression that the terminal point constraint doesn't hold. We believe it's a problem that we can identify the root from a very simple one dof case. If you can do this fast, it will help us.
Hi @aamorel
This is an integration issue which makes the floating base result wrong and results in an apparent motion of the contact when in fact the constraint is properly enforced regardless of the surface you choose for the contact.
It doesn't appear when you choose ACM0
because in that case the contact constraint simply locks the floating base motion. When you choose ACM1
then the floating base motion has to compensate the joints' motion to fix your selected contact surface. Integration issues on the floating base then moves it to the wrong position and the contact surface appears to move.
It is fixed by https://github.com/jrl-umi3218/RBDyn/pull/66 which has unfortunately been stale for a while. When applied, the drift dissapears. I will merge this PR within the afternoon.
Hi @gergondet
Thank you for investigating this issue. Indeed, the RBDyn library version with corrected integration results in no motion of the surfaces. I tested it on our sample controller with various surfaces, no apparent motion of constrained contact surface anymore.
Looking forward to the merge of this PR.
Thanks a lot for your prompt help resolving this issue.
Hi @gergondet , @kheddar
Sorry I was away last week. Thank you for your help, it was super efficient ! I'm closing the issue.
I have a robot composed of 4 bodies linked by 3 continuous actuated joints.
I am attaching to each of the bodies some surfaces (using .rsdf files). I would like to programatically add or remove contact (fixed no DOF) between these surfaces and other surfaces (ground for example).
I am testing the behavior by creating a contact between one surface and the ground, and then move the joints to verify that the contact is well set (that the surface in contact does not move). In this setting, I only have kinematic constraints.
Contacts between surfaces attached to the first body and the ground are normal. However, for the other surfaces, the contact is not stable. By this, I mean that when moving the actuated joints, the contacted surface is slightly moving. This perturbation increases when I move the joints faster. But the contact is partially working because the surface does not move freely: it is still constrained, but only loosely.
Do you have any idea where this behavior could come from? I checked the definition of the frames to which the surfaces are attached and everything seems correct.
Here are the surfaces visualized:
Here is the .urdf and .rsdf:
Please tell me if you need further information.