<div dir="ltr"><div dir="ltr">Thanks David,<div><br></div><div>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.</div><div><br></div><div><div><img src="cid:ii_kfrd4uls1" alt="image.png" width="542" height="378"><br></div></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> <br></div><div>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.</div><div><br></div><div>Here's a video of a night run for a neon light scribing effect. </div><div><br></div><div><div><a href=" https://youtu.be/dUj93wLMa0s"><img src="cid:ii_kfreh7l13" alt="image.png" width="542" height="247">https://youtu.be/dUj93wLMa0s</a><br></div></div><div><br></div><div><div>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.</div></div><div><br></div><div>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.</div><div><br></div><div>Karim</div><div><br></div><div><br></div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 30, 2020 at 11:31 PM David Anderson <<a href="mailto:davida@smu.edu">davida@smu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Karim,</p>
<p>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. <br>
</p>
<p>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.<br>
</p>
<p> 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.)</p>
<p>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.</p>
<p>You don't need full odometery to do the watchdog, just the zrate
calculation: <br>
</p>
<p> zrate = (left_encoder_counts - right_encoder_counts) /
WHEELBASE; <br>
</p>
<p>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. <br>
</p>
<p>Anyway, very cool project. The navigation and location sensing
are marvelous. I know how hard that is :)<br>
</p>
<p>cheers!</p>
<p>dpa</p>
<p><br>
</p>
<div>On 9/30/20 3:51 PM, Karim Virani wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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...<br>
<br>
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:<br>
<br>
<a href="https://youtu.be/DUaA3fbXoF8?t=25" target="_blank">https://youtu.be/DUaA3fbXoF8</a><br>
<br>
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.<br>
<br>
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. <br>
<br>
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:<br>
<div><br>
</div>
<div><br>
</div>
<div><img src="cid:174e5f223cacb971f161" alt="image.png" width="412" height="254"><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Sep 30, 2020 at 2:38
PM David Anderson via DPRGlist <<a href="mailto:dprglist@lists.dprg.org" target="_blank">dprglist@lists.dprg.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey
Murray,<br>
<br>
OK that explains it. I'd thought the line numbers represented
equal <br>
time intervals. My bad. So those graphs are basically
useless. Ignore.<br>
<br>
I've been looking around for a log plot from one of my robots,
but <br>
didn't really find anything PID specific. I know Karim
encourages his <br>
teams to log data, perhaps he might have something more
germane to your <br>
specific situation.<br>
<br>
Here is the closest I could find to a similar plot, the rcat
robot <br>
driving in a straight line between two waypoints 10 feet
apart, and <br>
rotating 180 degrees at the endpoints, using acceleration and
<br>
deceleration ramps for both the straight line and the
rotations. The <br>
log data rate is the same as the control loop rate, which for
this robot <br>
is 25 Hz. So 25 samples per second, 40 ms between data
points.<br>
<br>
<a href="http://www.geology.smu.edu/dpa-www/robo/data/rcat-pid-01.png" rel="noreferrer" target="_blank">http://www.geology.smu.edu/dpa-www/robo/data/rcat-pid-01.png</a><br>
<br>
The trace of green x'es is the requested velocity, and the
blue asterisk <br>
trace is the requested rotation. So these are the inputs to
the PID <br>
controllers. The pink open boxes and cyan solid boxes are the
left and <br>
right power being sent to the motor, so these are the outputs
of the PID <br>
controller.<br>
<br>
The brown open circles and tan solid circles are the actual
measured <br>
left and right wheel velocities from the encoders. What the
robot is <br>
actually doing. These are the values from which the PID
proportional <br>
error, derivative, and integral are derived.<br>
<br>
In the first segment the green requested velocity ramps up to
400 (top <br>
speed is 1000) and holds there for about 3 seconds, then ramps
back down <br>
to zero. The blue requested rotation stays at or near zero,
indicating <br>
the robot is going in a straight line. The small
perturbations around 0 <br>
reflect the navigation behavior keeping the robot pointed
toward the <br>
target waypoint as it drives. To an observer it just looks
like it's <br>
driving in a straight line.<br>
<br>
Notice the acceleration and deceleration ramps are not
symmetrical, as <br>
the up ramp aims for a velocity set point at 400 and is quite
linear, <br>
while the down ramp uses the distance_to_target to set the
velocity and <br>
has a softer denouement.<br>
<br>
When the robot has come to a stop at the end of the first
segment, the <br>
green requested velocity trace remains at zero but the blue
requested <br>
rotation ramps to -200, causing the robot to rotate in place <br>
counter-clockwise. You can see that the power (cyan) and
velocity (tan) <br>
of the right wheel again ramp up going forward. But the power
(pink) <br>
and velocity (brown) of the left wheel is in reverse, going
backward. <br>
Same thing happens for the return trip, except that the
rotation at the <br>
end of that segment is clockwise rather than
counter-clockwise.<br>
<br>
Here's a zoom in on the transition from the straight line
segment to the <br>
rotation, in which various values go through zero. Always
good to check <br>
out the transitions :)<br>
<br>
<a href="http://www.geology.smu.edu/dpa-www/robo/data/rcat-pid-02.png" rel="noreferrer" target="_blank">http://www.geology.smu.edu/dpa-www/robo/data/rcat-pid-02.png</a><br>
<br>
<br>
Hope this is useful<br>
dpa<br>
<br>
<br>
<br><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div></div>