[Dprglist] PID

[David Anderson]

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
>>> 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
>