Page 1 of 1

Problems with many-jointed robot

Posted: 06 Sep 2013, 23:53
by bessemermine
Hello again,

I'm having a bit of a problem with joints again, that probably still has its origin in scaling and engine parameters. I've twiddled the settings quite a bit here, but whenever I suppress one problems, I'll come up with another.

I recently posted about a two-joint rotational spring & damper leg structure for a robot; I'm not trying to fit that onto a robot body to replace solid rigid-body models of the legs imported from CAD.
Here's the scene: ... nglegs.ttt

Up until now, I was having problems with the joints falling apart. By changing some of the masses (design consideration #8) and simulation parameters, the joints seem to hold better.
Now I observe an instability, where the small jitter in the joints is giving rise to a large body motion with no other drive present; it's "skating" due to the jitter. The expected behavior is for the robot to just stand in place, with the legs damping out the initial drop.

Also, take a look at the top view, Page 6. There are graphs there that should be showing the torque at the joints, but it just appears to be noise with not much variation; I'm surprised to see this, consider that graphically, the legs can be seen deviating in position and returning to their controlled position.

I'm not sure what the best choices for ERP, CFM, and fudge factor for the joints and globally are in a situation like this; I would favor "hard" constraints and a slower solution over a faster method that allows accuracy in the joints to decline too far.

Note that there is a fairly complicated script attached to it that is intended to drive some of the body-connected joints through a specific motion profile, with adjustable phase and frequency. That should be largely disabled for this case, where frequencies are set to zero, and thus target velocities are zero to zero and target positions are set to constant.
The part that IS active is where all the joint Kp, Kd, and Ki gains are set in for loops, so it's all localized to one location.

So, if the Coppelia folks or anyone else with eyes on this might have some insight into how to get this simulation to behave properly, or at least more properly than the state I have it in now, any insight would help greatly. This is all going to be open source, too, so it could be available as an example, once it works a bit better.

Re: Problems with many-jointed robot

Posted: 09 Sep 2013, 00:50
by coppelia

We unfortunately don't have much time to go in depth into every project, especially since there is control involved. But we had a quick look:
  • First, you have a complicated control script that drives your legs. If you disable that script, the whole situation gets much more stable. It is important to have a very stable initial, passive situation, then build up from there
  • You should still adjust the masses and inertias up, and more similar. The rule of thumb is usually to make things stable even when it means cheating a lot. Then, in a second phase, make things more realistic from the values (masses/inertias, etc.)
  • All your joints are acting as spring/dampers. I am not sure if this is intended for the 2-3 base joints for each leg. Aren't they supposed to be controlled in position?
  • Try sometimes switching back and forth to the Bullet engine. That might give you a few clues.
  • You have an extremely high internal scaling factor (1000). Keep in mind that Bullet and ODE do not offer this internal scaling functionality: V-REP scales up/down all values appropriately (i.e. dimensions are scaled by F, masses by F^3, forces by F^4, etc.) so as to keep similar situations. This mechanism is mainly meant to get rid of floating point limitations when going very small or very large. But: the scaling could also introduce other problems, so be carefult with it
  • Legged mechanism are especially difficult to model and simulate. It can take a large amount of time until a good set of values have been found.
  • Another rule of thumb: do not play too much with obscure parameters (ERP, CFM, etc.). Instead play with masses and inertias. And with torques/forces
Next release we will have a 3rd physics engine ready, that offers high fidelity physics (Vortex Dynamics). That might handle your situation better than ODE or Bullet.