[Dprglist] PID
Murray Altheim
murray18 at altheim.com
Thu Oct 1 01:23:39 PDT 2020
On 1/10/20 8:38 am, David Anderson via DPRGlist 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.
Hi David,
Ah, sorry (!), actually my bad for not making that clear. Last night
I went ahead and added a timestamp to the Logger class (relatively easy
change) and tonight I'm going to incorporate some of Karim's ideas on
improving the log output. Rather than log from both the PORT and STBD
PID classes I'll log from the PIDController class where the control loop
can see both, so I can put the data from both sides onto the same line.
Probably should have done that to begin with. I'll post an updated log
online as soon as that's done.
> 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.
I'd hardly say it's coincidence that I'm tackling a very similar first
challenge to try to tune my PID and develop some robot chops.
> http://www.geology.smu.edu/dpa-www/robo/data/rcat-pid-01.png
>
> [...]
> 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.
Yeah, my approach to that was to get within a certain distance to the target and
slow down to a "targeting velocity" so I could stop as close as possible to the
intended distance. That of course is just a test behaviour -- in practice I might
want to use the output from a sensor to drive within a certain distance from a
wall, forinstance. But I'm guessing that once I get to a point where I can more
reliably control the robot's position, velocity, etc. and finally convert my
velocity to cm/sec, I'll be telling the robot what to do and getting its data
all in SI units. That's kinda the goal anyway.
[...]
> Hope this is useful
Yes, certainly! I also find this kind of analysis quite interesting. It
reminds me a little bit of the kind of data sent back by NASA rovers
during their traversals. It occurs to me that part of being a robot
builder is being able to generate (and potentially visualise) data we
get back from them. This includes plots and graphs, photos, videos, and
certainly what Karim's doing with drones et al. Very cool.
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
More information about the DPRGlist
mailing list