Posted 19 November 2016

Well, as usual, things aren’t quite as simple as they seem, and the ’10 minutes, tops’ rule still applies (whenever someone says ’10 minutes, tops’, they are lying by  at least one order of magnitude!).  But, on the bright side, I really do understand PID control systems a lot better now (a low bar, as just the other day couldn’t remember what the ‘P’ in ‘PID’ stood for!), and I now think that WallE (and/or WallE2) has  a pretty reasonable chance of homing in on an IR beacon with sufficient accuracy to be captured by a charging station setup.

In my last post on PID tuning, I had assumed that the PID compute engine normalized the tuning constants before doing the computation, and I decided I needed to check that assumption before continuing.  When I looked into the actual code in the Arduino PID library, I found that this was  not true – the PID compute engine does not normalize.  It simply computes the PID expression:

output = kp * error + ITerm- kd * dInput;

where ITerm is  ITerm+= (ki * error)

However, what this means is that my previous attempts to simplify the tuning problem by eliminating the I and D terms and just tuning the P term was doomed to failure – there was no way ‘do just P’ because the physical dynamics are too complex.  The response curves of the IR detectors (shown below),

4-detector heading test results

combined with the physical dynamics of the robot itself, require more than just a proportional response to the error (the difference between the sums of the two left and two right detector readings)   term.  Ken suggested I could do this by using a pulse train (similar to PWM) for the motor drive signal, but I think that is equivalent to adding some ‘D’ to the PID tuning parameters.

In addition to the physical dynamics issues, there is also the problem of the detector response versus distance.  At maximum detection range, all detector readings are near 1000, so the error term is very small, on the order of 10-50.  However, as the robot gets closer to the emitter, that error term rapidly gets much larger, on the order of 500-900.  This means that the PID tuning parameters appropriate for the ‘far’ case will be wildly inappropriate for the near case (another consequence of not normalizing the PID values internally).

In any case, after a  loonnnggggg series of floor field tests, I think I have arrived at a reasonably effective homing algorithm.  Instead of trying to modify the PID tuning parameters as the robot approaches the emitter, I found it more effective to keep the PID tuning parameters constant, and instead scale the  PID input (error) signal in three steps; 1 (no scaling) for error term values below 200, 0.2 (divide by 5) for values between 200 & 500, and 0.1 (divide by 10) for values above 500.  A representative set of data and some videos are shown below.  The last video shows a ‘side capture’ scenario, where the robot approaches at right angles to the IR beam and successfully captures the beam and homes in on the emitter.

Typical run with 1/5/10x scaling as emitter is approached.  Scaling term is shown here at 100x for clarity

Side capture scenario. Scaling term is shown 100x for clarity

So, at this point I’m convinced that the PID/input scaling arrangement will work, and that I can get WallE2 to home in on an IR beacon.  The next challenge will be to integrate the IR homing function with the normal wall-following function, and to design/fabricate the charging station itself.  Stay tuned! ;-).

Frank

Posted 16 November 2016

In my last post on this subject, I described by attempt to add PID control functionality to WallE’s IR light-following algorithm, and this is now looking pretty promising.  As an added bonus, I managed to suck my stepson Ken Frank, who graduated from Cornell with a MS in control theory, into helping me tune the PID controller. His first comment (well, the first comment after the obligatory “what have you gotten me into now, Ollie!”) was something like “you are over-controlling – you should simplify the problem and start with just ‘P’ – no ‘I’ or ‘D’. Then add P/I as necessary after getting the P value right.  Wish I had thought of that! ;-).

Anyway, I revised the code to do just that – with PID tuning parameters of 4,0,0 for both the far away and near cases, and re-ran my ‘floor range’ field test, as shown in the following video clip and plots.

Left/Right Differential (input to PID engine) and Output

All data from the run

More to follow…

After taking the above video and data, it occurred to me that it was possible (although not very probable, IMHO), that the PID engine might not normalize the tuning parameters before computing the new output.  So, I ran two more tests – one with a PID of 1,0,0, and another with a PID of 10,0,0.  These tests, along with the ones for 4,0,0, should provide some insight into that question.  As can be seen from the plots, the tracking behavior for all three PID = X,0,0 conditions are pretty similar.  I also included a video clip of the PID = 1,0,0 condition.

More to follow

Frank

Posted 13 November 2016

After reviewing the benchtop field test results, I decided to try implementing a PID (Proportional/Integral/Derivative) controller for WallE.  There is a quite nice PID library in the Arduino eco-system, thanks to Brett Beauregard (br3ttb@gmail.com), and  I already had it installed on my system from a previous project.  Getting it implemented for my project  wasn’t too much trouble, but of course  the issue with PID controllers is getting it ‘tuned’ (i.e. finding the values for P, I, & D) for the particular physical setup.

For my 4-detector system, I used the difference between the sum of the two left detector values  and the sum of the two right detector values as the input to the PID controller, and chose a setpoint of zero – i.e. the idea was to drive the difference in the detector sums to zero, which  should mean that the robot is pointed directly at the IR source.  The output from the controller was used in a differential fashion to drive the motors; the output was fed directly to the right motor driver as a 0-255 PWM value, and the left motor drive value was 255-Output.

The first  step was to set the PID values appropriately, and I had absolutely no idea how to do that –  so I just started with  the default values of 2, 5, and 1 for the P, I, and D values respectively, and DIRECT for the sense indicator.  Then I ran some tests on my 24″ benchtop range to see what happened.  Of course the first thing that happened is that WallE immediately departed from the plan and dove off the benchtop (I caught it before it hit the ground).  This was fixed by changing the PID output sense from ‘DIRECT’ to ‘REVERSE’, and I started getting some successful runs.

The next step was to make some more realistic homing tests, and for this I moved the IR emitter from my benchtop down to the floor at one end of my bench, and started WallE from the other end – about 1.5 m away.  I made a number of runs, changing the PID tuning parameters to try and find a reasonable arrangement.  After some playing around and some more Googling, I arrived at a tentative arrangement with a dual parameter set – one for small left/right differential excursions, and another for large excursions.  As  the following video shows, WallE successfully homed in on the IR emitter.

I also captured telemetry from the run, and plotted the left/right differential in Excel, as shown below:

Left/Right differential from 13 November floor field test

In the above plot, a marked difference can be seen between the differential behavior up to about point 33, and the differential between 33 and the end of the run at about 55 (the data after 55 was captured after I stopped the robot and picked it up, and before I got it shut down). I believe this change is due to my use of two different values for I & D, triggered when the differential became greater than 200 (due to increased received signal strength at the detectors, and possibly due to higher angle deviation as the robot neared the emitter).  More testing will be required to determine the best set of parameters for the 3-wheel WallE robot.

Once I get comfortable with IR homing using WallE, I plan to transition the capability  to WallE2, the 4WD robot.  This will probably require significant re-tuning, as WallE2’s steering dynamics are quite different.

Stay tuned!

Frank