OK, I’ve been looking at Kevin’s gyro code, and have been trying to work out an algorithm to maintain a certain heading using the gyro supplied in the kit.
My thoughts are leaning towards something like this:
Reset_Gyro_Angle();
if(Get_Gyro_Angle > 10){//1 degree
turn left
}
else if(Get_Gyro_Angle < -10){//-1 degree
turn right
}
else
stop
Am I correct about the gyro values, where a positive value would be a turn to the right and a negative value would be a turn to the left?
And would this code (without optimizations) allow self adjustment to a certain heading (despite oscillations)?
Well, it may or may not work entirely depending on how much play there is inyour drive train, how hard you turn left and right, and a bunch of other issues. The general idea is right though - you just may need some P, PI or PID control instead of using some set turn speed.
PS: I didn’t use Kevin’s gyro code this year so I don’t know about the snippet there; however, the idea is in general correct.
Yes. I was just wondering about the general idea. I was planning on adding some type of control system depending on how much time I have to tune, and how insane I am :p.
Which combination of P, I, and D control is generally recommended for position control?
Also, AFAIK its better to call Get_Gyro_Angle() once. Each time you call it, you shut off interrupts while the code inside it executes… You want to keep them on as much as possible.
While this probably isn’t your idea, don’t Reset_Gyro_Angle() before you get the angle… it will result in getting 0 as an angle
I’d probably go with I. The I term will compensate better if you have long term error, it’ll ensure that if you’re heading slightly off course, over time you’ll correct.
Not to rewrite a book on PID control, but basically let’s say that you want to turn 30 degrees. The P term will get you most of the way there, but you’ll always have error. You’ll be turning really quickly when you’re pointing at 0 degrees, but as you get closer to 30, the power you’ll be putting to the wheels will get proportionally smaller. You may or may not over shoot that 30 degrees, but you’ll end up settling to some non 30 degree value.
Part of my job is that I do a lot of travel. Right now I’m in a hotel with not a lot to do, so you lucked out (or maybe are being punished?) and you’ll get a PID story.
A PID Story, by Matt Adams
I’m going to make up an analogy to PID which I haven’t heard before, so it may not be the greatest, but bare with me. I like the idea of a blind, voice recognition robot driving a car down the road with noisy robotic passengers that are saying “steer right” or “steer left” based on how far off course the driver is from driving straight.
The P term is a passenger in the car with a megaphone, but his megaphone’s volume is proportional to how far off the robot is from the road. When the proportional difference is small, so the robot can’t hear the quiet plead of the proportional megaphone passenger telling him to “Steer Right!”.
The I term is the passenger in the back of the car with a battery powered megaphone. It starts off as a dead battery but gets charged along the way. It gets louder over time, and more persistent if the robot doesn’t respond. The amount of current going into his megaphone battery is proportional to how far off course the driver is. A big benefit to I is that even with a little error, the megaphone battery of the I passenger is charging up, so over the “Steer Right!” will loud enough to tell the robot driver to turn right. Naturally, with both the proportional and integral passengers in the car telling the robot to “Steer Right!” you can get a pretty responsive machine. An important thing to note with the I robot is that you better put a cap on how loud the megaphone can get, because, if for example the car isn’t running but it’s off course, his megaphone battery will charge up. When the engine starts the all powerful megaphone 88 gigawatt megaphone will completely dominate the voices of the P & D robots with potentially dangerous results!
The D passenger robot isn’t just any robot. Its a wacky creation by a hippie controls engineer (who probably went to some west coast school). It doesn’t say turn right or turn left, it only says, “Chill out, dude” in a really laid back tone while tie-dying t-shirts in the back of the car. Its also talking into a megaphone, but his volume is proportional to how effective the corrections have been in steering the car. If the P & I robots were loud, the driver has probably turned the car quite a bit, turning up the volume on the D megaphone.
So when your blind driving robot hears the P & I robots saying “Steer Right!” the D robot is helpful in leveling the crowd with it’s all powerful yet completely calming “Chill out, dude” command. This keeps the other two robots in check and keeps the driver from over-steering too far, especially when the car is getting close to being straight but the I robot has a lot of juice stored up in its megaphone.
Of course, the real question is how many passengers do you want in the car, and how loud do you want the regular voice of the megaphone-less robots to be? This process, called tuning, is the key to good controls. There are whole books on tuning which you could read, though I must warn you I don’t think they are nearly as exciting as a story about a car being driven by a blind robot and its 3 robot friends. (Well, 2 robot friends and a hippie, ride-mooching robot).
How to Tune PID in 2 Paragraphs, also by Matt Adams
A quick method for tuning basically a PID is to set I & D to zero, and see how far along the P can get you, and then you add some I until you start getting some overshoot that’s still acceptable, and then drop in some D, if you so desire, to calm things down.
If you want an under damped system, you can just run a PD setup. However, this will be relatively sluggish, and you’ll always have a steady-state error. In the above example, you won’t get to 30 degrees, you’ll be stuck at 29.
Without I, you’ll need to accept this error.
Here’s the thing: Either you need to detect when your driver is trying to go straight, and use the gyro then, or modify the drive code so it changes the angle that the gyro want’s to be… Unless you just want some sort of position holding code.
Either way, download the package of files for the gyro, take a look at how its used in user_routines.c, there’s a bit more you need to do then just Reset_Gyro_Angle()
the simple way to let the gyro steer your robot is to use the single-joystick algorithm for steering
zero the gyro reading as you have already discussed
then use the gyro heading signal as if it were the single-joystick command
if the robot starts going off course the gyro heading will become non-zero, and that error signal is then used to steer the drive train back to the zero heading.
This is built into the 2005 scripting code. Dave Lavery demonstrated exactly what you’ve described during the 2005 kickoff. Have a look at the 2005 kickoff and if this behavior is what you want, go to http://kevin.org/frc/2005/ and grab a copy of the code.
If you do a quick search of my posts, about a month ago I actually posted the P-only version of Team 95’s gyro rotation code (the actual code is PID, but that’s left as an exercise to the programmer to implement).
