Go to Post What really matters is what you got out of the FIRST season, and how you can use it to build on what you know. - Adam Richards [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 17-03-2005, 13:08
Chris Bright's Avatar
Chris Bright Chris Bright is offline
Registered User
#1023 (Bedford Express)
Team Role: Webmaster
 
Join Date: Feb 2003
Rookie Year: 2003
Location: Temperance, MI
Posts: 54
Chris Bright will become famous soon enough
Send a message via AIM to Chris Bright
PID Control

SO we all know by now that not many people used the CMU cam with any success. Who here has used the default PID code given by first? We didn't because there wasn't enough time or need. I'm just curious.
__________________
2003 - National Rookie All-stars
2003 - Great Lake Rookie All -stars
  #2   Spotlight this post!  
Unread 17-03-2005, 20:34
Donut Donut is offline
The Arizona Mentor
AKA: Andrew
FRC #2662 (RoboKrew)
Team Role: Engineer
 
Join Date: Mar 2005
Rookie Year: 2004
Location: Goodyear, AZ
Posts: 1,308
Donut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond repute
Re: PID Control

Tried it. Didn't have enough time to calibrate it, so it wasn't successful. We'll be experimenting with it (or writing our own version of it) for next year's robot during the off-season. We're planning on an omni-drive bot though, so we'll be spending more time working on the drive code for that.
  #3   Spotlight this post!  
Unread 17-03-2005, 22:28
eugenebrooks eugenebrooks is offline
Team Role: Engineer
AKA: Dr. Brooks
no team (WRRF)
 
Join Date: Jan 2004
Rookie Year: 2001
Location: Livermore, CA
Posts: 601
eugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond repute
Re: PID Control

Quote:
Originally Posted by Chris Bright
SO we all know by now that not many people used the CMU cam with any success. Who here has used the default PID code given by first? We didn't because there wasn't enough time or need. I'm just curious.
We wrote our own PID code, as we have been in prior years.
It is pretty straight forward once you understand the basic
concepts of a mass, spring and a velocity dependent damping
force. Students have no problems understanding and implementing
these things, with a little guidance.
  #4   Spotlight this post!  
Unread 17-03-2005, 23:39
Anthony Kesich's Avatar
Anthony Kesich Anthony Kesich is offline
Programmer Turned Engineer
AKA: SonKenshin
#1097 (Site 3 Engineernig)
Team Role: Leadership
 
Join Date: Jan 2003
Rookie Year: 2003
Location: Sacramento, CA
Posts: 186
Anthony Kesich has a spectacular aura aboutAnthony Kesich has a spectacular aura about
Send a message via AIM to Anthony Kesich
Re: PID Control

I am actually using the default PID algorithm given to us by FIRST. It has done its job well for me. I use the velocity controler for driver interface. I actually makes the driving much smoother and easy to control. I am also using the position controller for autonomous. I have had great succes with both.

One of our member's father is actually a professor of control algorithm at UC Davis so he went over all of the code with me. For calibration ease, he actually had me make the kD = 0. I've kept it that way and it catually seems to work just fine. So, in reality, I am using a PI algorithm.

-Tony K
__________________
C is screwing up my English--I'm ending all my sentences in semi-colons;

Horray for most things! -George Carlin

"Sure, I'll play rugby. Besides, I have a lot of experience running from really big guys who want to cream me." -Me, Freshman year
  #5   Spotlight this post!  
Unread 18-03-2005, 09:09
kaszeta's Avatar
kaszeta kaszeta is offline
Registered User
FRC #0095 (Grasshoppers)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2002
Location: Lebanon, NH
Posts: 334
kaszeta is a glorious beacon of lightkaszeta is a glorious beacon of lightkaszeta is a glorious beacon of lightkaszeta is a glorious beacon of lightkaszeta is a glorious beacon of light
Re: PID Control

Quote:
Originally Posted by Chris Bright
SO we all know by now that not many people used the CMU cam with any success. Who here has used the default PID code given by first? We didn't because there wasn't enough time or need. I'm just curious.
Team 95 was using it for a while on their test bot for autonomous, but wrote our own code for the final bot (and pulled it before competition problems with wheels slipping, which with position-based PID control can give some very erratic driving).
  #6   Spotlight this post!  
Unread 18-03-2005, 20:25
jdong jdong is offline
Linux Nerd
AKA: John D
#0245 (Adam-Bots)
Team Role: Programmer
 
Join Date: Apr 2004
Location: Rochester, MI
Posts: 98
jdong will become famous soon enoughjdong will become famous soon enough
Re: PID Control

We are using PI control at low speeds, implemented using the hall-effects in the Kit.

It works quite smoothly, but somehow ours stops tracking at about 60% PWM output. However, at that point, PI has relatively few advantages. The tricky part was a smooth transition from closed loop to open loop drive at the 60% mark.
__________________
John Dong
Co-Captain, Webmaster / Programmer
Team 245 -- Rochester Adams Robotics
  #7   Spotlight this post!  
Unread 21-03-2005, 23:31
Tom Saxton's Avatar
Tom Saxton Tom Saxton is offline
Registered User
no team (Issaquah Robotics Society)
Team Role: Mentor
 
Join Date: Dec 2003
Rookie Year: 2003
Location: Sammamish, WA
Posts: 98
Tom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud of
Re: PID Control

We started with the PID code from FIRST, but had to fix many significant problems.

1. There is only one set of gains for all the motors. This is a problem if you're using the algorithm to control motors which are different (drive and arm) or have different loads (more friction or just motor differences between left and right sides). We generalized the code to include the gain constants in the per-motor structure.

2. The way they do the integral term is ludicrous. It computes a running sum of the error over all time, then divides that by pid_time (the count of loops). The sum never gets reset, so it grows without bound even when you are changing the target value. Even worse, when you change the target value (set_pos or set_vel), it resets pid_time to 1. This is horrible for two reasons. First, it doesn't reset the sum, so the integral term that was mollified by dividing by pid_time (sum = 2000, time = 1000, integral term is 2) is now blown sky high (2000/1 = 2000). Second, there's only one pid_time global, so changing the target value for ANY motor causes the integral term for ALL of the motors to go ballistic.

3. The PWM values are set up like they are for a different motor controller. PWM_ZERO is 132, but the Victor's zero point is 127. There's even code in there to take into account the motor controller's deadband, so that small signals actually do something, but since the zero point is wrong, it completely misses the mark. The MAX_PWM and MIN_PWM values were also centered on 132, so you also had to find that hidden error.

4. There was a hard-coded limit of two motors (or more correctly, two PID controllers) with no hint at what was required to control more motors.

5. The per-motor structure wastes a lot of space with duplicate values for both position and velocity modes, although only one set will be in play at any time. On a controller with only 1800 bytes of RAM, wasting 32 bytes per PID controller is not good coding.

6. While there were great comments about how to tune the PID (once you fixed the bugs), there was not much in the way of how to use the code. It wasn't too difficult to figure things out if you already had a good understanding of both PID and C, but I would think the idea behind this code was to make PID more accessible to teams without strong software experience.

We did get it cleaned up and used it to control a total of six motors in four groups: left and right drive (2 CIMs each), arm elbow (van door) and arm wrist (globe). (Each pair of CIMs was controlled by one PID "motor," we just copied the same value to both PWMs.)

I hope to clean up our version of the PID code and publish it on our web site. PM me if you want to see it before I have a chance to clean out our debugging junk.
__________________
Tom Saxton
http://www.idleloop.com/
  #8   Spotlight this post!  
Unread 23-03-2005, 23:23
gnormhurst's Avatar
gnormhurst gnormhurst is offline
Norm Hurst
AKA: gnorm
#0381 (The Tornadoes)
Team Role: Programmer
 
Join Date: Jan 2004
Location: Trenton, NJ
Posts: 138
gnormhurst will become famous soon enoughgnormhurst will become famous soon enough
Re: PID Control

I spent a lot of time tweaking that code. I wanted to use it in manual drive mode, but it wasn't responsive enough (when you let go of the stick it kept going, for example). Our manual drive is back to open loop.

For auton, there is a fundamental problem with the code as is, and I have written about it elsewhere. The S_DRIVE thing sets the position target at the final goal and lets the PID system chase it. This leads to the motor drive values being pegged at their max, so small hanges can't get to the motors, so the loop is not closed -- it's open.

This means that both motors will push as hard as they can, but if one goes faster than the other, there is nothing the PID system can do about it until it gets closer to the goal, so it tends to turn in a circle.

I modified this so that I increment the PID target position a little bit each cycle, and not so much that the system ever pegs (clips). This keeps the loop closed and the robot driving straight. Well, sort of. To get it to really drive straight you need to have an integration term on the error, but that always made it unstable.

I ended up calculating the heading error (difference between wheel counts) and running an outer loop to maintain a zero heading error. I used an integrator on this outer loop, and I got it to be fairly stable.


Related subject: We have an arm that is driven by the van door motor, and a pot to measure its absolute position. I had hoped to just run the motor until the arm got to the desired position, but even though it is geared down twice from the output of the motor, when the arm is loaded it can still back drive the motor, even with the Victor set to "brake" mode.

My solution was to make an always-on arm servo. It sagged when we loaded the arm up so I tried to add integration to that loop to compensate, but it always oscillated. I decided that I was measuring position and controlling the motor's speed, which are an integration apart (position is the speed integrated). Integration carries with it a 90 degree phase shift at all frequencies (integ(cos) = sin, for example). My additional integration added another 90 degrees for a total of 180 degrees which reverses the feedback at all frequencies: guaranteed oscillation.

I got rid of the integrator and just increased the loop gain until the arm didn't sag as much. Works good!

There was also an issue of stiction in the arm drive train: applying increasing amounts of voltage to the motor did not move the motor until the static friction (stiction) in the drive train was overcome, but then the voltage was too high for what we wanted. I thought about popping the motor with big, short pulses to break the stiction, but I never tried it.

-norm
__________________
Trenton Tornadoes 381
2004 Philadelphia Regional Winners
2006 Xerox Creativity Award
---
My corner of the USPTO.
My favorite error message from gcc: main is usually a function
My favorite error message from Windows: There is not enough disk space available to delete this file.
  #9   Spotlight this post!  
Unread 24-03-2005, 01:01
Tom Saxton's Avatar
Tom Saxton Tom Saxton is offline
Registered User
no team (Issaquah Robotics Society)
Team Role: Mentor
 
Join Date: Dec 2003
Rookie Year: 2003
Location: Sammamish, WA
Posts: 98
Tom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud of
Re: PID Control

Quote:
Originally Posted by gnormhurst
For auton, there is a fundamental problem with the code as is, and I have written about it elsewhere. The S_DRIVE thing sets the position target at the final goal and lets the PID system chase it. This leads to the motor drive values being pegged at their max, so small hanges can't get to the motors, so the loop is not closed -- it's open.

This means that both motors will push as hard as they can, but if one goes faster than the other, there is nothing the PID system can do about it until it gets closer to the goal, so it tends to turn in a circle.
For autonomous, what you want to do is run it in velocity mode to drive both sides at the same speed, then manually monitor encoder ticks until one or both sides reach the target.

We had really good results using the PID code in position mode to control arm segments. We can command a position and have it hold pretty well even when adding or removing a tetra. It would sag a little, but not enough to drop the tetra if it started with some backwards tilt. The only problem we had was integration wind-up when we requested a large movement. I've since read about that issue - there are easy solutions like zeroing the integration term until the arm gets close to the target position.
__________________
Tom Saxton
http://www.idleloop.com/
  #10   Spotlight this post!  
Unread 26-03-2005, 19:44
dm0ney's Avatar
dm0ney dm0ney is offline
Will Code For Food (Food Optional)
AKA: Deepak Mishra
None #0217 (The ThunderChickens)
Team Role: Alumni
 
Join Date: Jan 2005
Rookie Year: 2004
Location: Shelby Twp., MI
Posts: 48
dm0ney will become famous soon enough
Send a message via AIM to dm0ney
Re: PID Control

We used the 'kit' pid code for the first regional. Since then, we have migrated back to pid code written last year by our team. The switch is very easy as we have macroed 'KIT_PID.'

We only used the position loop during autonomous and we also split gains and max/min for rotate and drive.

The pid code was quite easy to tune for linear distances but until we split gains, we had a heck of a time getting spins with the same gains.

The reason we abandoned the kit pid code was eventually a robot will not drive straight (assuming it drove straight to begin with). Last year we had implemented 'go straight' code that would compensate for mechanical imperfections by engaging encoder counts and running it through pid. We tried implementing this into the new code but decided that since we already had code that works, it wasnt worth rewriting it and inserted the macros instead.
__________________

Alumni
Team #217, The ThunderChickens



Student, Class of 2009
California Institute of Technology


Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
PID cmd_drive can't drive straight? gnormhurst Programming 4 18-02-2005 01:54
(Experimental) PID Control System jdong Programming 14 18-06-2004 15:55
PID control loops - closed loop feedback KenWittlief Technical Discussion 56 26-04-2004 21:27
PID control loop/Encoder question Zee Programming 18 30-01-2004 23:14
more control options smokescreen Technical Discussion 17 05-03-2002 15:41


All times are GMT -5. The time now is 14:08.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi