[Dprglist] Unbad the PID

[Karim Virani]

Thanks David,

Prior to my first kick the robot didn't actually run off course - the
course simply ran off the dirt and onto the grass. Let's call that a path
placement error, I mean feature - yes that's a feature meant to show the
robot can handle terrain changes. Right. Here's the path in google earth.
Unfortunately there's no way to select the whole path to drag it to a new
location and recalc the coordinates.

[image: image.png]

But yes, the neat thing is that the robot knows where it is at all times to
a pretty good and accurate degree. Though those are ideal conditions. Open
field, clear sky. At home under tree cover our results might wander a good
6 to 12 inches.

That the robot gets stuck so easily seems more to do with using a rake
instead of a caster wheel. Pros and cons. We have ideas on how to fix that
and I'll be sure to share your stall detection suggestions.

There's also a major bug in the code somewhere undiscovered (unfilmed so
far) - where it might miss a waypoint and end up wandering as much as 100
feet before turning around and starting back to find the right waypoint.
And this is happening while it "knows" that its distance to the waypoint is
steadily increasing. Maybe it's a 180 error in heading. At one stage in
development I was accidentally feeding just latitude into both lat and lon
targets and that had the robot happily marching off toward the north pole
with a distance to target of tens of thousands of kilometers.

Here's a video of a night run for a neon light scribing effect.

[image: image.png]https://youtu.be/dUj93wLMa0s
<https://youtu.be/dUj93wLMa0s>

The 6X speed video is frame stacking so you can see a progressive build up
of travel. I shared a partial still of this previously and mentioned that
what looks like a warped path is actually a result of the drone wandering
in the wind. I'm still looking for an easy way to auto-align the frames to
take out that visual drift since it leads to an inaccurate sense of what
the robot can do.  I shared the daylight shot of the full path in the prior
post and it has the same repeatability as the DPRG path.

But looking closer at this video, particularly on the lower sections of the
6 and the 8, you can see the bad PID pretty clearly. It's accentuated
because the light bar is tail-mounted and the side to side motion of
oversteer is exaggerated leading to jaggies in the path. This then leads to
an interesting tuning approach. I'm going to have my team overlay the graph
of the PID responses on the video. We'll sync the timestamps by changing
the color of the lights briefly at the start point. This should help
develop their intuition of how PID tuning really works and not have it be a
specialty of just a couple of kids. They should all be able to help unbad
the PID. Probably need to do that on a not-so-wide shot.

Karim



On Wed, Sep 30, 2020 at 11:31 PM David Anderson <davida at smu.edu> wrote:

> 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: image.png]
>
> On Wed, Sep 30, 2020 at 2:38 PM David Anderson via DPRGlist <
> 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
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20201001/d6ba4639/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/20201001/d6ba4639/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 1239492 bytes
Desc: not available
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20201001/d6ba4639/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 331089 bytes
Desc: not available
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20201001/d6ba4639/attachment-0005.png>