Wheel motions not completing

[gcl8a]

Some students are still having the issue where their wheels get close but not quite to the end of the motion and then stop. So, for example, a straight segment will never complete and a turn won't start.

Some have had luck raising the gains, e.g. (0.3, 0.06, 0). However, the default gains have K_I = 0.04, so I don't understand why the wheel doesn't complete.

Is it an integral clearing thing? I thought that that only happened upon reaching the target, so I don't see how that could be it, but maybe I'm misunderstanding how it works.

[gcl8a]

My guess is the decaying integral term is not building up enough?

Edit: That's likely the culprit. Say the wheel is "1 tick short". Then the integral will stabilize at 59, since I_TERM_SIZE is 60. But then it gets divided again by I_TERM_SIZE, so in this case, the contribution from the integral is,

59 / 60 * 0.04 = ~0.039

which is not going to be enough to energize the motor to go that last bit.

(Incidentally, this is why I don't recommend the rolling average -- it's computationally expensive and it results in a steady-state (offset) error.)

--

Also, why not let the integral build up while running? Does that cause an issue?

    float controlErr = Setpoint - nowEncoder;
    // shrink old values out of the sum
    runntingITerm = runntingITerm * ((I_TERM_SIZE - 1.0) / I_TERM_SIZE);
    // running sum of error
    runntingITerm += controlErr;
    if(getInterpolationUnitIncrement()<1){
        // no i term during interpolation
        runntingITerm=0;
    }

    currentEffort = controlErr * kP + ((runntingITerm / I_TERM_SIZE) * kI);

[madhephaestus]

~0.039 unit vector maps to a pwm value of 160 out of 4096, which is not nothing, but perhaps not enough on systems with high friction. we can go higher. I had kept it low because the interpolation and the i term were fighting and causing jittering. Now that i drop I during interpolation it should be stable to increase it a bit more.

[madhephaestus]

Is there any action to take in the default code, or is this something that the Motor::setGains() method resolvs on a case by case basis?

I also strongly suggest investigating friction. The most common, and least obvious, is if you push on the little encoder wheel during assembly, it can scrape on the underside of the encoder, and cause a huge amount of friction from the controllers perspective.

TO anyone finding this issue in the future:

I propose a test. Take your robot and tie a string with a bag on the end to the wheel. Then put weights, like batteries, in the bag until the friction in the gearbox cant hold it up at 90 degrees and the wheel backdrives. Compare number of batteries on a normal Romi, and one that is having issues converging. I suspect the amount of weight to move the ones that aren't arriving at setpoints will be much higher.

[gcl8a]

If there is that much difference, then we should add instructions on how to tune them. But an easier test is to have them use setEffort() and then report back the actual speed (this could even be a lab exercise). That would help us know how much difference there is and let us suggest they look closely at their motors.

But I suspect a lot of the problems are related to battery charge.

Regardless, with proper integral control, it should always reach the target. Alternatively, we just default to linear interpolation, which will likely carry them through to the target more reliably.

[madhephaestus]

Battery issues can be eliminated by just running off USB and taking one battery out. On my robot, on USB power, 0.1 effort got the wheels spinning. When testing with a student, with fresh batteries, and on battery power i saw efforts of 0.5 not moving, and 0.6 moving.

I like the idea of making that a lab to compare effort to measured speed.