[Dprglist] PID

Kipton Moravec kip at kdream.com
Wed Sep 30 09:16:25 PDT 2020


I have not done motor PID in a long time. We used to get into big 
disagreements about windup of the I term.

IMHO, the best PID has a feed-forward term. This is where you have a 
"model" of what you need, and predict what the output should be for a 
given input. Then the PID only fixes the errors of that model. If done 
right, you do not have the windup.

My last PID (actually PI) was a resonate power supply where we did cycle 
by cycle PI at 50 kHz. I had to hand optimize the code because the cheap 
16-bit custom processor had a 16 clock multiply peripheral where we put 
the two multiplicands in to registers, and the answer would be available 
16 clocks later. So I would do other things during the 16 clocks to set 
up the next multiply. We had a mathematically equivalent version of the 
PID equation that was much simpler to compute.

I will have to see if I can find my write-up on the simpler PID. It may 
be lost because it was done for work at my old job.

Kip

On 9/30/20 1:11 AM, Patrick R. Michaud via DPRGlist wrote:
> This reminds me of what I've seen called "motion profiling" in FTC/FRC, where the motors (driving wheels) use PID to follow a velocity curve rather than a position setpoint.  The end result is a lot smoother stop/start of the motors, since a new position setpoint doesn't result in a drastic step change in the P-term going to the motors.
>
> The navigation library (Roadrunner) my team used in last season's competition used velocity motion profiling for its drivetrain, and it was really nice to not have sudden starts/stops impacting the autonomous navigation.  They also wanted to try to do some motion profiling on their lift mechanism, but didn't quite get that working (they were able to tune a simpler PID to be "good enough").
>
> Pm
>
> On Wed, Sep 30, 2020 at 02:00:29PM +1300, Murray Altheim via DPRGlist wrote:
>> Hi Rud,
>>
>> The setpoint for the PID controllers is a velocity value. The basic
>> task is to accelerate to cruising velocity at 25% of the distance,
>> then slow at 90% down to targeting velocity to stop at 2m.
>>
>>    0                              1m                             2m
>>    0          ->cruising                             ->targeting  0
>>    0              25              50             75         90  100
>>    |_______________|_______________|______________|__________|____|
>>
>> Does that make any more sense?
>>
>> Cheers,
>>
>> Murray
>>
>> On 30/09/20 1:50 pm, Rud Merriam via DPRGlist wrote:
>>> Hi,
>>>
>>> I'm not understanding the log outputs.
>>>
>>> At line 9740 the stbd motor has reached the 2m mark. The setpoint is set to 10.00 while earlier it was set to 50.00. I would think the setpoint should be the end position, i.e. 2m equivalent.
>>>
>>> At line 9754 setpoint is not 0 and the error is 10.019. If it is at the end position the error should be 0. After that error is non-zero so outputs are generated which move the motors.
>>>
>>> IMO the setpoint should be the number of steps (or equivalent) you want the motor to have moved. The error is the difference.
>>>
>>>
>>> -73 -
>>> *Rud Merriam K5RUD*
>>> /Mystic Lake Software/ <http://mysticlakesoftware.com/>
>>>
>>> On 9/29/20 7:24 PM, Murray Altheim via DPRGlist wrote:
>>>> Hi,
>>>>
>>>> Addressing the hunting behaviour on the KR01 robot that we've discussed
>>>> previously (i.e., rocking back and forth about 1/8 of a wheel turn after
>>>> stopping), here's a full color (!) log of the journey:
>>>>
>>>> https://service.robots.org.nz/wiki/attach/PIDController/pid_bounce_log.html
>>>>
>>>> I may mention this in tonight's video discussion, thought to provide a link
>>>> here. It basically shows the encoder and PID controller output as the robot
>>>> accelerates to cruising speed then decelerates to a slow, targeting velocity
>>>> before attempting to stop at the 2 meter mark.
>>>>
>>>> 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
>>> _______________________________________________
>>> DPRGlist mailing list
>>> DPRGlist at lists.dprg.org
>>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>>>
>> -- 
>>
>> ...........................................................................
>> 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
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org


More information about the DPRGlist mailing list