[Dprglist] PID
David Anderson
davida at smu.edu
Wed Sep 30 21:31:28 PDT 2020
Karim,
That is amazingly cool. The location accuracy and repeatability is
excellent. The first kick you had to give it was actually instructive,
as it showed the robot still knew where it was despite running off
course and getting stuck. And being kicked. Great video angle too,
really able to see what the robot is doing.
I have a modest suggestion for the stuck problem watchdog, which I've
done on a couple of robots. I'd noticed with my outdoor robot that when
it is stuck, it's almost always trying to turn. By calculating a Z rate
from the wheel encoders and comparing it to the IMU Z rate, or even a Z
rate gyro, the difference should be small most of the time. But when
it's large, your stuck. Basically the wheels say you're turning while
the IMU says you're not.
Even though the integrated wheel Z rate would not match the IMU heading,
the instantaneous wheel Z rate is a pretty good match for the IMU Z
rate. (Some IMU's don't have a Z rate, so just subtract the last
heading from the current one to make your own.)
Then each time about the control loop, the watchdog tests that the wheel
Z rate and the IMU Z rate are more or less the same, within some limit.
Larger than that triggers an escape behavior.
You don't need full odometery to do the watchdog, just the zrate
calculation:
zrate = (left_encoder_counts - right_encoder_counts) / WHEELBASE;
And WHEELBASE really doesn't need to be carefully tuned, as it's not
being used to accumulate an accurate location. Just close enough to
work, which you can maybe just measure with a ruler.
Anyway, very cool project. The navigation and location sensing are
marvelous. I know how hard that is :)
cheers!
dpa
On 9/30/20 3:51 PM, Karim Virani wrote:
> David, I see what you did there. Totally threw me under the bus. As
> much as I advocate for logging, my teams don't always listen to me. I
> know we have some logs lying around. I just don't have much time to
> look for them. Got a hot lead from a Nigerian prince and I really need
> to jump on that opportunity before it slips away...
>
> All kidding aside, I am pretty busy with work and personal stuff right
> now and the team's data is a mess, so I'm not likely to go spelunking.
> There are plenty of folks here to advise about PID. Plus I'm also
> shamefully tolerant of bad (almost good enough?) PID as terribly
> evident in the latest update for my geo-scribing robot:
>
> https://youtu.be/DUaA3fbXoF8 <https://youtu.be/DUaA3fbXoF8?t=25>
>
> This is the second run through the DPRG pattern. You might want to
> play this at double speed. The robot is only steered by precision GPS
> - there is no vision tracking on the previous ground marks. This helps
> show that we have pretty good results, even when the PID is not tuned
> correctly. We know there are encoder and power imbalance issues with
> the motors on this robot and the PID settings were taken from another
> robot of similar size and weight, but never tuned. I'd have gotten
> away with it too - if it wasn't for that pesky i-term and their crazy
> dog. There are some other issues with drop-out of GPS updates that are
> still being worked on.
>
> The robot also gets stuck every so often and needs a bit of a nudge.
> The team is working on a progress failure watchdog to maybe kick it
> into driving both wheels when it stalls, overriding the next waypoint.
>
> The ground marks are not very distinct in the video. This dirt is very
> dry right now. The sand on the beach is more likely to have moisture
> underneath. Sometimes after a rain the previous day or with morning
> dew, this softball field leaves better tracks:
>
>
> image.png
>
> On Wed, Sep 30, 2020 at 2:38 PM David Anderson via DPRGlist
> <dprglist at lists.dprg.org <mailto:dprglist at lists.dprg.org>> wrote:
>
> Hey Murray,
>
> OK that explains it. I'd thought the line numbers represented equal
> time intervals. My bad. So those graphs are basically useless.
> Ignore.
>
> I've been looking around for a log plot from one of my robots, but
> didn't really find anything PID specific. I know Karim encourages
> his
> teams to log data, perhaps he might have something more germane to
> your
> specific situation.
>
> Here is the closest I could find to a similar plot, the rcat robot
> driving in a straight line between two waypoints 10 feet apart, and
> rotating 180 degrees at the endpoints, using acceleration and
> deceleration ramps for both the straight line and the rotations. The
> log data rate is the same as the control loop rate, which for this
> robot
> is 25 Hz. So 25 samples per second, 40 ms between data points.
>
> http://www.geology.smu.edu/dpa-www/robo/data/rcat-pid-01.png
>
> The trace of green x'es is the requested velocity, and the blue
> asterisk
> trace is the requested rotation. So these are the inputs to the PID
> controllers. The pink open boxes and cyan solid boxes are the
> left and
> right power being sent to the motor, so these are the outputs of
> the PID
> controller.
>
> The brown open circles and tan solid circles are the actual measured
> left and right wheel velocities from the encoders. What the robot is
> actually doing. These are the values from which the PID proportional
> error, derivative, and integral are derived.
>
> In the first segment the green requested velocity ramps up to 400
> (top
> speed is 1000) and holds there for about 3 seconds, then ramps
> back down
> to zero. The blue requested rotation stays at or near zero,
> indicating
> the robot is going in a straight line. The small perturbations
> around 0
> reflect the navigation behavior keeping the robot pointed toward the
> target waypoint as it drives. To an observer it just looks like it's
> driving in a straight line.
>
> Notice the acceleration and deceleration ramps are not
> symmetrical, as
> the up ramp aims for a velocity set point at 400 and is quite linear,
> while the down ramp uses the distance_to_target to set the
> velocity and
> has a softer denouement.
>
> When the robot has come to a stop at the end of the first segment,
> the
> green requested velocity trace remains at zero but the blue requested
> rotation ramps to -200, causing the robot to rotate in place
> counter-clockwise. You can see that the power (cyan) and velocity
> (tan)
> of the right wheel again ramp up going forward. But the power (pink)
> and velocity (brown) of the left wheel is in reverse, going backward.
> Same thing happens for the return trip, except that the rotation
> at the
> end of that segment is clockwise rather than counter-clockwise.
>
> Here's a zoom in on the transition from the straight line segment
> to the
> rotation, in which various values go through zero. Always good to
> check
> out the transitions :)
>
> http://www.geology.smu.edu/dpa-www/robo/data/rcat-pid-02.png
>
>
> Hope this is useful
> dpa
>
>
>
> On 9/30/20 3:02 AM, Murray Altheim via DPRGlist 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 <mailto:DPRGlist at lists.dprg.org>
> >>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
> >> _______________________________________________
> >> DPRGlist mailing list
> >> DPRGlist at lists.dprg.org <mailto:DPRGlist at lists.dprg.org>
> >> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
> >
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org <mailto: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/2dd8645c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2500215 bytes
Desc: not available
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20200930/2dd8645c/attachment-0001.png>
More information about the DPRGlist
mailing list