DPRG List  

[DPRG] PID Loop Question

Subject: [DPRG] PID Loop Question
From: David M Wilson davidmw at tx.rr.com
Date: Tue Feb 23 14:58:30 CST 2010

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


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

More information about the DPRG mailing list