[Dprglist] PID

Wed Sep 30 01:02:31 PDT 2020

Hi David,

Thanks *very* much for going to the trouble of plotting that data, I'd
like to say it's informative, but informative in as you say, being
confusing.

I'll back up a little and explain again what (in theory) we're supposed
to be seeing. [Notably, I'm still expressing velocity from 0.0 to 100.0,
not as I eventually intend in cm/sec. The task is to move forward
exactly 2 meters.]

I have a PID class (the actual PID controller), a PIDController wrapper
class (that gets system configuration, contains the slew limiter and
the 20Hz loop running in its own thread). There is then the Gamepad
controller stuff calling a Behaviour class's one_meter() method which
is providing a script to "move exactly one meter forward" behaviour.
I've not changed the name but it actually now tries to move two meters.

We start on line 122 by accelerating from zero to a cruising velocity
of 50.0 (half of full speed, in theory). The loop that does this is a
20Hz loop so I'm relying on the slew limiter (operating from the
controller, not the PID loop) to not immediately go from zero to half
speed. You can see this as the setpoint of both port and starboard PID
controllers goes from 0.003 (line 124) to 50.0 (lines 1082 and 1095).
You can see the encoder's step outputs gradually spread apart as the
velocity increases, e.g., at 50.0 the messages are about 60 steps apart.

We then cruise at 50.0 velocity until we get to 9/10 of the target
distance (lines 7296 and 7301), then begin decelerating from 50.0 to
the targeting velocity of 10.0. You can then see the PID output as a
gradually decreasing value as it chips away at the robot's velocity,
until we hit a velocity around 10.0 and begin correcting back and
forth, small bits of positive and negative outputs around line 8428.

At lines 9740 and 9767 for the starboard and port PIDs resp. we then
change the setpoint to 0.0 and begin to actually stop. The robot
thinks it's stopped at lines 9834 and 9838 when the two callback
methods are called.

*Then* we can see these flurries of PID messages as the wheels rock
back and forth about 1/8-1/4 of a turn.

But up until that point the overall behaviour of the robot seems (at
least from the outside) to be working fine. The robot accelerates at
a reasonable rate up to a cruising speed, maintains that until the
9/10th point (1.8 meters) then slows to a crawl, stopping always
about 2cm past the 2m tape mark on the floor. Then that rocking
behaviour begins. When on the stand it continues indefinitely. It's
interesting to note that when the robot is on the floor it comes
to a stop about 2cm past the 2m mark, waits maybe a half second,
then reverses almost exactly onto the 2m mark. That may be a
coincidence though. Then it kinda oscillates back a forth a bit
randomly, what looks like repeated attempts at error correction.
During all this time the setpoint is 0.0 (as you can see in the log
during those PID message bursts from around 9844 til line 10801
when I hit the Kill (Home) button and the robot begins to shut down.

In looking at your gnuplots I don't understand them either. The
murray-01 shows the setpoint going from 0.0 to 10.0 but then
dropping back to zero very quickly, which isn't what's happening
even in the log. E.g., the setpoint reaches 50.0 on line 1082, which
is about 1/10th of the entire journey. It stays at 50.0 until line
7286 then changes to 10.0 then later on to 0.0.

Are you plotting by line number as a fixed time period? It should
be noted that the logging messages are coming from whatever is that
first field in the log after the line number, e.g., "pid:stbd" is
the starboard PID controller, "motor:port" is the port motor. So
the messages themselves aren't coming at a fixed rate at all, which
makes your point about writing timestamps clear as necessary in order
to plot time on the X axis.

At this point I'm going to (since it's the easiest thing) to re-hook
up the potentiometer so I can fiddle with the I and/or D values of
the PID controller to see if that makes any difference. I'm mostly
suspicious of the fact that when the robot comes to a velocity of
0.0 just after the 2 meter mark the P is still registering an error,
which is likely what's causing the rocking behaviour. I'll dig into
that in what's left of tonight and over the next few days as time
permits.

And thanks again for the plots. It reminds me that being able to
visualise the data can be a huge help.

Cheers,

Murray

--------
PS. I'm not sure if you've heard of it but there's a professional
software application called Splunk that runs as a web service and
receives logging data from a cluster of computers, providing
monitoring, alerting, and some nice data visualisation outputs so
you can see what your servers are doing. Almost everywhere I've
worked in the past 5-6 years is using Splunk.

Over the past few days I've considered writing a tiny version of
Splunk in Python, to examine and chart my log data. Turns out that
Splink and Skink and Splank and Slunk and Slink are all taken,
though I think some of those actually involve snakes. But given
that "splink" is pronounced by some Kiwis as "splunk" (in the same
way that "Nick Cave" sounds like "Nuck Cave" sometimes here in New
Zealand, I think I'll name it Splink. The other Splink is a
"Probabilistic record linkage and deduplication at scale" which
couldn't possibly get confused with my project.

So, spurred on by your graphs, if I manage to find the time to
rewrite my GnuPlot plotter for the PID controller I'll do it to
instead just analyse the log outputs from Splink, rather than
write the data generator inside of the PID controller as I did
in version 1.

On 30/09/20 6:45 pm, David Anderson via DPRGlist wrote:
> Hi Murray,
> 
> I've plotted some of your data.  Here's the error, P, setpoint and output for your port motor:
> 
> http://www.geology.smu.edu/dpa-www/robo/data/murray-01.png
> 
> I honestly can't make any sense of it at all.  It does not look like a plot from a PID controller.
> 
> The oscillations around the set point you describe are clearly obvious. Here's a zoom in on just that portion:
> 
> http://www.geology.smu.edu/dpa-www/robo/data/murray-02.png
> 
> It  looks like the set point, the blue trace, is moving around, not steady at 0.  So if the PID controller is being commanded to do that it's not its fault if it's oscillating.  Why is that value moving around?
> 
> The initial startup is also bit bizarre.  Here's a zoom in on that:
> 
> http://www.geology.smu.edu/dpa-www/robo/data/murray-03.png
> 
> It looks like the P,I,D terms are logged after they are already scaled by their gain constants.  What you need to see are the raw values calculated for the proportional error, the derivative error, and the integral, and the final output 
> power to the motors.
> 
> Here are similar plots for your right wheel:
> 
> http://www.geology.smu.edu/dpa-www/robo/data/murray-04.png
> 
> http://www.geology.smu.edu/dpa-www/robo/data/murray-05.png
> 
> http://www.geology.smu.edu/dpa-www/robo/data/murray-06.png
> 
> It would be very useful to also log the wheel velocities.
> 
> And a time stamp.
> 
> cheers,
> 
> David
> 
> 
> 
> 
> 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