[Dprglist] Power vs Velocity for PID controllers
secretary at dprg.org
secretary at dprg.org
Tue Apr 21 12:28:57 PDT 2020
Murray,
I looked over your pseudo-code and it appears that you are trying to
create a torque controller. The lines below suggest that you are using
"target_power" as your reference and "current_power" as your feedback
signal. What this would do is attempt to keep the current of the motors
constant, and consequently a constant torque (remember current is directly
proportional to torque) . This means that in a case of low load, the
voltage would go up to supply more current (i.e., more torque) and the
motor would run faster than intended. Under heavy load the voltage would
reduce to supply the target current (i.e., target torque) and the motor
would run slower than intended. I don't think this is what you are looking
for.
target_power = 0.5
while True:
current_power = motor.get_power()
error = target_power - current_power
Also, since you are ganging two motors per side, how the current is shared
between the 2 motors is not likely to be equal. They would almost assuredly
run at different speeds. Most motors are not matched (especially
inexpensive motors).
Regards,
Doug P.
On Tue, Apr 21, 2020 at 11:27 AM secretary at dprg.org <secretary at dprg.org>
wrote:
> 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/33c04c18/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/33c04c18/attachment-0001.png>
More information about the DPRGlist
mailing list