Avoid PWM saturation on high speeds.

[cua-cua]

Control the maximum speed and accelerations automatically ignoring lineal speed errors
so if we are below the theorical speed but the PWM is saturated (100%), stop trying. The control is applied on this zone braking one motor.
Review code and change distance calculations based on ideal speed to encoders sum.

[Peque]

Yeah, I think applying double correction on the angular speed (by breaking with double force instead of breaking with one wheel and accelerating with another) may be enough.

We'll see! 😄

[Peque]

So, ideally, we should implement a system that takes into account the "available margin" (in volts) for acceleration. Which means, accelerating more slowly as we reach higher speeds. This requires knowledge of feedforward parameters.

Anyway, I think avoiding PWM saturation is a good idea. If that happens, we should better reduce linear speed (i.e.: apply double angular correction on one wheel or some other way).

Not following the linear speed profile may not be that bad, as long as we make sure to track the position based on the estimation (encoders) and not the profiler.

Again, this should be applicable only for the extreme/unlikely case where PWM is saturated. We should probably just avoid that situation. Stepping-up may be good enough to always have a good margin.

[Peque]

Note: we were hit by this bug at OSHWDem 2019, where during a diagonal at high speed, the PWM got saturated and the robot just crashed into the wall without trying to turn once the straight line was finished. So, even if we decide to "abort" in case of PWM saturation, we should review that abortion process to make sure the robot breaks instead of bumping into walls at the highest speed...