[Dprglist] Power vs Velocity for PID controllers

[secretary at dprg.org]

Murray,
    I am a bit confused by your message. I think that you are confusing
power and torque. You might find this link useful:
http://www.epi-eng.com/piston_engine_technology/power_and_torque.htm .

   Take this scenario, your robot without encoder feedback is moving on a
level floor at a given speed, then it comes to a ramp and as it goes up the
ramp it slows down. In this case the robot's motors are being supplied a
set voltage. In a DC motor, the speed will drop as more load is placed on
it for a given voltage. This is because at a given voltage only a specific
current will be supplied to the motor.  Torque is directly proportional to
motor current. Typically what you want is when the robot reaches the ramp
you want the speed not to drop. This means that you need to increase motor
torque. You want the robot motors to provide more current going up the
ramp. This means that you have to increase the voltage to the motors.

Below is the performance curves for a VEX robotics 393 motor (used to be
their main motor). To get the different data points on this curve they are
changing the load and the voltage. At stall, the motor is pulling 3.6 A,
has a speed of 0 RPM. The motor's mechanical power is 0, because motor
mechanical Power = (torque * speed) / constant_based_on_units. However, the
electrical power in the motor's winding is Power = current^2 * voltage. In
this case (3.6 A) ^2 * Voltage, where for VEX system is 7.2 V. or ~93
watts. This is why stalled motors often fail within seconds.

[image: image.png]

Now take this scenario, your robot with encoder feedback is moving on a
level floor at a given speed set by your PID (or P, or PI, or PD)
controller, then it comes to the ramp. If you have a P controller the speed
will change to a certain level as the controller increases the voltage (and
thus the current and torque) to some value that is lower than your level
speed but higher than it would be without any feedback. The reason that it
doesn't maintain perfect speed control is because as the feedback value
comes close to the desired (reference) value, a P controller loses its
ability to change the output, in a sense it runs out of steam the closer it
gets. So for a P controller there will always have an offset from the
desired speed set by your reference signal. Often this is all you need. If
you have a PI controller, the I portion of the controller will allow your
output to match your reference setting at the expense of adding more
instability (however, it maintains response even as speed approaches
reference). For most robots this is usually all you need. Adding a D
component (i.e., PID vs PI) can add response with reduced oscillations in
output if done right, but is adds a level of trickiness to the tuning.  I
often use only a P, or PI controller, in my robot depending on what I am
doing. I often wrap a velocity PI inside of a heading P controller. In the
case of a line following robot, a PD controller is often used. What the D
does is add response to rapid changes. The robot will not run at the
reference setting with PD, for that can only be done with an I component in
the controller. Note that both I and D have a dt component, you must keep
loop time constant or adjust for varying it.  Also, please note that the
above is somewhat general, people with more knowledge may have a better
understanding than me.  I hope others will jump in and correct me where I
have gone off base.

Regards,
Doug P.

On Mon, Apr 20, 2020 at 11:27 PM Murray Altheim via DPRGlist <
dprglist at lists.dprg.org> wrote:

> Hi all,
>
> Over the past week I've spent many an hour working on my Python-
> based PID controller, which is using a ThunderBorg motor controller
> under the hood to drive a quartet (left-right pairs) of OSEPP motors.
>
> I've kinda got something working, at least the PD part of it seems
> functional, but there's a big gaping hole where a certain part of
> the implementation is concerned: prior to PID I was "successfully"
> driving the robot based on an encoder-based velocity measurement,
> but there was no PID, and my recent attempts to create a PID
> controller using velocity have failed.
>
> I believe this is due to the fact that I was attempting to use the
> velocity measurement as the PID input to set the motor power. As I
> think David noted in his YouTube video, there isn't a direct relationship
> between motor power and velocity so this was bound to fail. I like
> fail as much as the next person, but success is nice too.
>
> So with that in mind I've gone back to a power-based PID controller,
> knowing I still have a certain mountain to climb.
>
> The question I now have is: how to add a velocity-based control to
> my robot? Do I come up with some mathematical relationship between
> velocity and motor power, or do I create a velocity-based PID
> controller **over top** of the power-based PID controller, i.e.,
> two layers of PID control?
>
> Much-simplified pseudo-code:
>
>    KP = some_constant
>    KI = some_constant
>    KD = some_constant
>
>    target_power = 0.5
>
>    while True:
>        current_power = motor.get_power()
>        error = target_power - current_power
>
>        k_diff = KP * error
>        i_diff = KI * sum_errors
>        d_diff = KD * last_error
>
>        output = k_diff + i_diff + d_diff
>        slewed_output = slew(output)
>        new_power = current_power + slewed_output
>        set_motor_power(new_power)
>
>        last_error = error
>        sum_errors += error
>
> So would I incorporate velocity into the above somehow, or build
> Yet Another PID controller for velocity (using roughly the same
> structure as above, but solely dealing with velocity) that calls
> the above power-based PID controller?
>
> I thought perhaps we could discuss this in tomorrow's Robot Builders
> Night Virtual get together... but an email discuss is also welcome,
> thanks!
>
> Cheers,
>
> Murray
>
> ...........................................................................
> Murray Altheim <murray18 at altheim dot com>                       = =  ===
> http://www.altheim.com/murray/                                     ===
> ===
>                                                                     = =
> ===
>      In the evening
>      The rice leaves in the garden
>      Rustle in the autumn wind
>      That blows through my reed hut.
>             -- Minamoto no Tsunenobu
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20200421/27412770/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 313943 bytes
Desc: not available
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20200421/27412770/attachment-0001.png>