[Dprglist] PID
Chris N
netterchris at gmail.com
Wed Sep 30 07:51:28 PDT 2020
Murray,
In order for yourself and others to make sense of this information, it
really ought to be time stamped.
What I found most useful is to use a CSV format and to have the timestamp
AND ALL RELEVANT VALUES TOGETHER in each line.
So in your case then, each line might contain the following (only showing
values for one motor for brevity - you obviously want stbd and port on the
same line):
timestamp, stbd absolute encoder count, stbd measured velocity (in
whatever units you keep track of it), stbd target velocity (aka
setpoint), stbd commanded motor power (e.g. PWM duty cycle % or equivalent
unit) stbd error, stbd P contribution, stbd I contribution, stbd D
contribution, stbd Kp, stbd Ki, stbd Kd
Some of these values (e.g. error) are technically redundant, because they
can be calculated (target velocity - measured velocity) by Excel, but
explicitly recording what your code calculates is a good sanity check.
Also, the PID tuning parameters Kp, Ki and Kd (possibly a separate set for
each motor) usually don't change during a test run, but recording them
along with the measurements and calculated values helps a lot when you
later go back and look at the data.
I usually also include the readings from each sensor and even internal
state information from my control logic , such as the value of certain
critical global variables, or the state (literally) that certain finite
state machines were in at that point in time.
This may sound like a large volume of output, but if you keep the
formatting minimal (e.g. CSV - like) , it is actually not that much. I
found the following to be a compromise between making it readable to a
human and still easily readable by Excel: instead of strictly using
comma separated "values", I include a few labels in between.
Example:
instead of
..........,1456,1460,75,73,.......
I do
.........E,1456,1460,M,75,73,........
"E" is the prefix "reminding me" that the next 2 values represent the
absolute encoder count
"M" is the prefix "reminding me" that the next 2 values represent the
commanded motor power / pwm.
Excel will happily put the E and the M into separate columns and therefore
these prefixes don't get in the way of plotting, and my brain is happy
because it can easily parse each line of 20+ values
Of course you can still interleave the CSV formatted output with
informational messages that don't adhere to this, but then you need
to filter out those lines before importing into Excel or tell Excel to
ignore those lines.
Chris.
On Wed, Sep 30, 2020 at 4:02 AM Murray Altheim via DPRGlist <
dprglist at lists.dprg.org> wrote:
> 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
>
> _______________________________________________
> 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/20200930/f3de8856/attachment-0001.html>
More information about the DPRGlist
mailing list