DPRG List  

[DPRG] PID Loop Question

Subject: [DPRG] PID Loop Question
From: DaKenengineer-meister. kmaxon at qwest.net
Date: Tue Feb 23 21:29:35 CST 2010

To add another 0.02$ to the buck-O-eight already in the proverbial pot....

It is highly possible that I missed this in someones post along the way and if I did, I appologise for the restatement...

One very important part that has been taken forgranted but is worth stating to a beginner is that the (dt) portion of these functions has been dropped through-out.  This has been done because we are all assuming either interupt driven code in which (dt) is constant and drops out (taken account of by the tuning) or highly stable mainline code where the system timing does not change much.

It is worth mentioning here because a person new to amateur robotics may write a nice small tightly tuned code base from main that works very well when tuning a single motor or pair of motors and then wonder why things fall apart when they start using more printf diagnostics on the serial port (assumed blocking) or some such that significantly changes the (dt) of the system.

Without dropping into the simple calculus behind this effect, suffice it to say it is IMPORTANT that the execution of the sampling of the sensors and the updates to the system take place at REGULAR PERIODIC INTERVALS.  A background interupt based on a simple timer can be just the trick.  

If the interval is very low (rate is high) then then one needs to worry about the jitter from interupts of other priorities, etc...

Hope this helps as newbee's to the hobby tend to like to try things out calling them from main and end up struggling with the problems of why things that used to work break when simple layers of complexity are added...


  ----- Original Message ----- 
  From: John Dolecek 
  To: David M Wilson 
  Cc: Rick Bickle ; dprglist 
  Sent: Tuesday, February 23, 2010 3:54 PM
  Subject: Re: [DPRG] PID Loop Question

  David touched on this but It's also critical to have a constant voltage to the motors.  Any fluctuation will change the system response.  

  Any control system has to be tuned under the exact condition it will be used under.  It's possible to simulate the response mathematically, but not really feasible for what we're doing and probably also not very accurate. 

  On Tue, Feb 23, 2010 at 2:58 PM, David M Wilson <davidmw at tx.rr.com> wrote:

    >In my paper on the website, I used a “brute force” approach in which I had the robot loop through ranges of P and D terms, while it output speed >data to a serial port. This data was being captured by another PC. The robot made hundreds of tries with different values, and in the end, I graphed >the responses of those terms that were in the ballpark, and chose the ones with the best response.
    >If anyone has a better suggestion for this that has worked, please let me know.

    I offer not a better solution but a few words that might save others valuable time.

    After the recent LEGO first event I decided to refine my bot's wheel speeds in turns and then look for improvements in the  PID loop constants.

    Using this method probably gleaned from Rick's paper several years ago, I simply enabled existing code that outputs actual wheel RPM to the serial port.   Multiple motor runs are made using three nested loops incrementing P, D, and I.  The test run sets an RPM of 150 for 5 seconds, then 80 for 5 seconds, then zero for 5, then reverse at 120 for five.   Data was charted in Excel 2003, which isn't a great solution as it can only plot 250 data sets at one time.  Several executions using refined ranges and increment values resulted in several dozen hours of motor run time.

    With the chart open in Excel, it is easy and quick to click on the bad RPM curves (those with excessive overshoot or oscillation) and simply delete the plot line itself.  Do this until you are left with about 1 to 5 of the nicest looking curves.  Obtain the P, D, and I values from those curves and decide if you want to make another tuning run to refine those values.

    In other words, lots of run time, lots of data, lots of charting, and lots of battery charging.

    After this multiple day exercise, I plugged in the shiny new optimized PID loop constants and took the bot for a spin.  In a word, the results sucked.  Top speed was quite low, acceleration much too slow, differential turns became impossibly lazy, and the zero RPM hold speed had a case of the jitters.

    So to refine Rick's comments about using a brute force method, I add some  'common sense' that might not be immediately obvious.   I learned this once a few years ago but clearly forgot it and repeated the same mistakes.

    Due to the shorter battery life with a bluetooth serial connection, I decided to use a hardwired serial port for the data transfer while the tuning app was running.  The concept of having the bot running free on the floor for hours of tuning seemed unmanageable so I put the bot in a test stand on my desk.  I decided to tune using only one of the four wheel motors and figured on sanity checking the constants on the other motors when done.  I made a very crude attempt to add some friction losses to the one motor to better simulate real world use.

    The load simulation was way off and behaves nothing like the real thing when the bot is in motion.   Each wheel motor on this bot carries about .8 pounds of the body weight.  The impact of the bot's inertia on changing RPM settings is significantly different than the simple friction brake I was using.

    All this tuning was wasted effort since the device was not operating under normal conditions.  Don't make my mistake of letting a cable tether prompt you to move the bot off the floor - PID constants that are impressive with the wheels in the air aren't worth much on the ground.


    DPRGlist mailing list
    DPRGlist at dprg.org


  DPRGlist mailing list
  DPRGlist at dprg.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.dprg.org/pipermail/dprglist/attachments/20100223/f8ba9314/attachment.html

More information about the DPRG mailing list