Hinge motor multiplication effects

Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Hinge motor multiplication effects

Post by Basroil »

I've been trying to use hinge motors for a 18 servo chain (think CMU robot snake), and come across some rather odd situations.

Unless the number of iterations is quite high, maxImpulse increases to the angular motor don't seem to work at all, regardless of max_impulse (tried a million times higher than needed). Thinking my code was off a bit, I double checked using the dynamic control in 2.80 (and motor demo in 2.81, looks like identical code with a name change).

The modifications done were:
  • Change the 0 mass spawn to 20 mass
  • Add values for m_numIterations and simulation rate
  • Lower number of legs to 4 (keeps stability)
For motor strength of 0.8 (default is 0.5) and all other settings at default , the 20 mass has a hard time getting up. According to the comments in the file, the increase in m_numIterations should decrease motor strength, but it has absolutely no effect. Even m_numIterations at 100 does not weaken the motors, and results look almost identical.

Changing the simulation to 1/120 from 1/60, the 20mass one no longer had issues. Lowering the max impulse to 0.4 resulted in nearly the same result as for the m_numIterations trials.

For the dynamic control, anything between 10 iterations and 100 iterations were for the most part identical, and completely irrelevant to the motor strength, but the simulation rate directly affected the overall motor strength.

Aside from that issue, it also seems that high gravity (ten times normal) requires either high simulation rate or high iterations to match the same results as lower gravity (with increased servo strength normalized to simulation rate). Is one of those two better than the other (1/500 dt or 100 iterations)? Or is it best to use a balance (say 1/250 dt and 50 iterations)?

I am currently not hitting any CPU limits at either extreme (under 2ms) even running in debug mode, so it's mostly from a perspective of stability rather than performance.
Marcell
Posts: 14
Joined: Fri Oct 19, 2012 8:58 am

Re: Hinge motor multiplication effects

Post by Marcell »

Sounds like the same problem I had with the hinge constraint the first time I tried them. I ended up increasing the stop ERP parameter to 0.8 like so:

setParam(BT_CONSTRAINT_STOP_ERP, ERP, 0);
Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Hinge motor multiplication effects

Post by Basroil »

Marcell wrote:Sounds like the same problem I had with the hinge constraint the first time I tried them. I ended up increasing the stop ERP parameter to 0.8 like so:

setParam(BT_CONSTRAINT_STOP_ERP, ERP, 0);
STOP_ERP actually does nothing to improve motor strength in the "chain" model. setParam(BT_CONSTRAINT_STOP_ERP, ERP, 0); actually just gives me errors, and setParam(BT_CONSTRAINT_STOP_ERP, ERP); has little visible effect. The only thing that seems to work is a combination of iterations and faster simulation speeds.

For the dynamic control demo, ERP actually needs to be lowered corresponding to the simulation rate or else instabilities form. Running the demo at 1000Hz, the spiders start flying, until ERP is brought down to 0.02 or so.
Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Hinge motor multiplication effects

Post by Basroil »

Well, six months and a revisit to old code gave me new insight!

It turns out the culprit is a bunch of

Code: Select all

btScalar k = info->fps * info->erp;
strung throughout the joint calculations. Since the joints are calculated each frame, and energy proportional to fps is added each time the joint is calculated, you end up with an exponential increase in energy added to the system as fps values increase!

While I understand the need for ERP, is there a reason why it needs to be a function of FPS rather than a fixed correction rate over time? And of course, if people could chime in with ways to resolve this other than simply multiplying ERP by timestep (so energy goes back to being linear), that would be great, since I can't really think of any surefire way to do it without possibly causing joints to simply fail.