rapier
rapier copied to clipboard
dimforge
Mechanical Kinematics solving
Hi there - this library is very impressive and I'd love to start experimenting with using it within the context of robotics simulation.
Step one for us is looking at getting a stable kinematics solution - without any force resolution. This isn't my area of expertise so I thought I'd drop a question here.
Recently you guys have added Multibody joints as well as Impulse joints with a comment that these can be more suitable for robotics applications. However Multibody joints don't support kinematic loops if I am correct (four bar linkages and such).
The Impulse joints in this engine do seem to work with kinematic loops quite well with our limited experimentation - however they are very bouncy (even with a high number of iterations). Perhaps the issue here is simply tuning / or the fact we were within the example framework and left gravity on etc
My real questions are:
Are impulse joints fundamentally not suitable for numerically solving complex joint loops - or will we get to somewhere stable and repeatable with zero-gravity and enough iterations?
If they are not suitable, is there a third joint type that could be sponsored/contributed in the future for solving non-colliding kinematic-loop based systems in a stable way (still numerical of course)?
If so, is that out of scope for rapier - as we're really entering what might be considered CAD territory as opposed to real-time physics engines here. For our use case these seem like similar applications though, so it'd be very interesting to hear what you clever folks have to say.
Hi!
Are impulse joints fundamentally not suitable for numerically solving complex joint loops - or will we get to somewhere stable and repeatable with zero-gravity and enough iterations?
If you are using joint motors, they are not very stable in the currently released version of Rapier because they are integrated explicitly. We are currently working on improving this situation in the api-improvements branch which switches to a linearly implicit integration of joint motors.
Impulse joints can be suitable for joint loops, though the more complex the system is, the more iterations will be needed. The constraints solver is based on Projected Gauss Seidel, which is fast, but has a hard time converging to 0 error even with a high number of iterations. So, at some level of joint system complexity, switching to another kind of constraints solver like NNCG or direct methods (none of which are implemented in Rapier yet) will give much better results. But these alternative solvers are also significantly more computationally expensive compared to a low-iterations PGS, so they may not yield real-time results for scenes with many bodies/joints/colliders (but again, that depends on the complexity of your scene).
If they are not suitable, is there a third joint type that could be sponsored/contributed in the future for solving non-colliding kinematic-loop based systems in a stable way (still numerical of course)?
AFAIK there is no third joint type. You could use multibody joints for all the joints except the one(s) that "closes the loop" (which you model as an impulse joint). Take a necklace for example: you can use multibody joints for everything except one of the links. The multibody will form an open chain, and the loop will be managed by a single impulse joint.
Once the api-improvements branch is merged/released, the main ways to improve stability (except finding good parameters) are:
- Adding some post-projection to the constraints, where the violated constraints are teleported back to a valid state (not an approach I like, but that may work well for a system without dynamics or contacts).
- Using another constraints more complex solver like NNCG with better convergence at high iteration counts.
These could be contributed/sponsored features, though they are quite significant pieces of work. I don’t consider them out of the scope of Rapier as long as we can figure out a design that doesn’t hurt the performances of the default PGS solver (which I believe we can).
All that said, for purely kinematic systems without contacts, perhaps an inverse kinematic solver could be enough for your use-case. I haven’t reviewed the literature to see if there are inverse-kinematic solvers that work with joint loops. But if there is one, chances are that you will get much better results with it than relying on the impulse-based constraints solver.
This is also something we are looking forward to add to Rapier in the future (the FABRIK algorithm being the one we will try first I think).
Thank you for the detailed reply - I'll parse through this information gradually - probably starting with experimenting with Multibody + single impulse for loops. We'll probably work with SolveSpace first, as it seems to work well and has at least some WebAssembly support - haven't yet investigated the quality of the JS API.
The idea of Rapier expanding to more and more use cases is definitely exciting - IK included. I suppose I'll leave this issue open as a place to collate literature, starting with: https://www.researchgate.net/publication/273392189_Closed-Loop_Inverse_Kinematics_for_Redundant_Robots_Comparative_Assessment_and_Two_Enhancements
More recently: http://disneyresearch.s3.amazonaws.com/wp-content/uploads/20210208220011/root-2.pdf
Which I found on an issue here: https://github.com/TriPed-Robot/trip_kinematics/issues/17 - MIT licensed python kinematics solver
Hello,
Do you have updates concerning IK solver integration in Rapier ?
