Hi Manic,
Quote:
Originally Posted by ManicMechanic
So just to make sure I have this straight, it sounds like an accelerometer would tell me when a robot has speeded up, slowed down or tilted. During autonomous, it would be useful for telling if I had unexpectedly hit an obstacle, causing the bot to slow down or tilt.
I might use a gyro in autonomous when trying to see if the bot had unexpectedly swerved, for example, from unbalanced motors, or from being hit from the side. I could use it to correct course if the robot is tending to veer off a straight line or desired course. Is that right?
Can you think of practical examples of using these sensors during operator control? The only sensors we have ever used during OC are limit sensors -- to stop an arm from rising when it reached the perfect height, and to stop a joystick-happy driver from grinding the gears.
|
Right. An accelerometer gives you a signal proportional to acceleration (or a negative value for deceleration.) It is giving you a number that says, "I am speeding up/slowing down at this rate." Or to use a car speed analogy, it reports a value like "I am increasing my speed at 5 mph per second." If you were still, it would report zero mph per second, or also if you had a really really good cruise control and were constantly at the same speed, it would report zero mph per second. That's good, right?
But personally, I don't know how useful acceleration data actually is. The cop isn't going to pull me over for accelerating too fast (except reckless driving maybe?), he's going to pull me over for having a speed that's too high. But all the information I have from my sensor is acceleration. Well, if I know what speed I start at (lets say 10 mph) and that I then increased my speed at 5 mph per second for three seconds, I can find my new speed to be 25 mph. So even though I am only directly measuring my acceleration, I can calculate my velocity from that, as long as I know my initial velocity.
Similarly, one can go from velocity to position. If my car went at 25 meters per second for 4 seconds, and 10 meters per second for 3 seconds, then I've traveled 130 meters.
This type of trick, essentially performing an integral of acceleration to get velocity, and then an integral of that to get position, is commonly used in order to extract needed information from sensors that don't necessarily provide the quantities you need.
This can also be done with a gyro, where the original signal coming from the gyro is related to the angular velocity, or how fast it is turning. So it will essentially say "I am turning at 45 degrees per second." Now if we refer to the above, we can infer that we can say well, if I've done that for 3 seconds, that means I've turned 135 degrees! So you can use a gyro to keep track of your heading angle. You could then compare it to what the heading angle SHOULD be, and then adjust based on that. So you're absolutely right about that potential use of the gyro.
A lot of teams turn off their navigation-related sensors during tele-operated mode, or don't use them anyways. But there has been at least one team that uses their gyro to help them drive perfectly straight during tele-operated mode, and to do very precise turns (1024, at least that what I got from talking to them in the pit.) So there is certainly scope and application for using navigation in tele-operated mode.
Now you do have to be careful--what I've explained above is kinda the gist of how to use the sensors, conceptually. But there are a whole host of other issues to deal with--when/if you start using the sensors, you'll see them really quick:
1.) Sensors that you use are real devices, not ideal. This means that they'll have measurement noise and drift and all sorts of funny characteristics like temperature dependence. It's not scary, just a couple more lines of code and a little more thought you may need to add to compensate. Or, you may get enough accuracy for what you want to do without having to compensate. Actually, I'd try that first.
2.) Doing the integration process above takes a little understanding of how to do it algorithmically, and should be done on a fixed interval to make the math easier to handle (and more stable, mathematically, but that's a different story.) The integration process also introduces errors but doing it once it isn't so bad (say for a gyro to get your heading angle.) But doing it twice to go from accelerometer to position may be too inaccurate. I suspect this is a large reason why most people in FIRST use encoders combined with gyros to figure out their position.
3.) Note that there are scaling factors and stuff to apply to translate the sensor's method of communicating to the math you're using. It's not so bad though, just a little multiplication.
Most often, it seems, people use encoders and potentiometers for on-robot information (arm position and stuff) for both teleop and autonomous, and encoders on the wheels combined with a gyro for position estimation.
Hope this helps! This is kindof a "the gist of it" explanation, so for more details just ask!