[Dprglist] Power vs Velocity for PID controllers

secretary at dprg.org secretary at dprg.org
Tue Apr 21 09:27:27 PDT 2020


Murray,
    I was reading over my response and noted an error:
*What I said:*
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.

*What I should have said:*
However, the electrical power in the motor's winding is Power = current *
voltage. In this case (3.6 A) * Voltage, where for VEX system is 7.2 V. or
~26 watts. This is why stalled motors often fail within seconds.

Sorry for the confusion.

Regards,
Doug P.

On Tue, Apr 21, 2020 at 10:58 AM secretary at dprg.org <secretary at dprg.org>
wrote:

> 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/70d01629/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/70d01629/attachment-0001.png>


More information about the DPRGlist mailing list