Accelerometers & Gyros for N00bs

[ManicMechanic]

This summer, Vex is releasing accelerometer & gyroscope sensors, and I've been trying to figure out how they work and what they'd be used for. I tried reading posts from multiple sources and kinda sorta have an impression of how they work, but then I'll read something that seems to contradict the what I had mentally constructed from what I read previously.

Can anyone explain to a not-very-techie-type person (think "stay-at-home mom drafted as technical mentor/coach") how these 2 sensors work, and give some instances of when you would find them useful?

[dtengineering]

Think of the accelerometer as a big flat plate with a plumb bob (string with a weight on the end) hanging down from it. As you accelerate the plate in a horizontal direction, the angle of the string relative to the plate will change. As you tip the plate the angle of the string relative to the plate will change. The value returned by the accellerometer is, essentially, the angle of the string. Thus if you hold the plate level, you are measuring accelleration. If you hold the plate at constant velocity, you are measuring a change in the angle (tipping) of the plate. (Which, since gravity counts as acceleration, is the same thing, even though the plate isn't actually speeding up or slowing down, but I digress...)

In reality, it kind of works upside down, as my understanding of the MEMS (micro electro mechanical systems) devices we use acutally create a bubble inside the chip that floats, and it is the position of the bubble that gets returned. Same thing, but upside down.

A gyro uses... well... something similar, I think, to measure twist. I'll have to look up what actually goes on inside a MEMS gyro, or let someone else describe that here, however what the gyro is sensing and returning is how fast it is being turned.

Note that both sensors detect the rate of change in a parameter. This is a great opportunity to talk about derivatives and integrals with students. If you want to know what direction your robot is pointing, you use a gyro. By repeatedly measuring the rate of change in direction (turning one direction is positive, the other negative), you can create a graph. The cumulative area under the curve of the graph is... approximately... how far you have turned.

Likewise to determine your speed, hold the accelerometer flat, and rapidly measure your acceleration. Integrate that value and you have your velocity. Integrate that and you have your position.

There are several factors that make this a little more challenging to do than it sounds, and it is possible that you can use pre-defined software libraries that make this easier to do than it sounds (someone else takes care of the measuring and integrating for you), but that is a simple description of what the two sensors do.

We used a gyro on our robot this year to make sure it would track in a straight line. If the robot turned (without instruction from the driver) the gyro would send a message saying "I'm turning in this direction at this speed". The robot would then automatically speed up the wheels on one side and slow down (or reverse) the wheels on the other side to compensate and put the robot back on track. It worked great! Had we got the code working right, we could have used those measurements, integrated with respect to time, to determine which direction we were facing and help with navigating the corners of the course in hybrid mode.

Jason

[EricVanWyk]

I think the best way to understand a MEMs accelerometer is to look at one - http://archives.sensorsmag.com/articles/1203/20/fig1.jpg is a 3axis
http://www.sensorsmag.com/sensors/data/articlestandard/sensors/242006/334974/fig6.jpg is an early prototype that is easier to understand.

Essentially, you have a mass (the middle bit) attached by springs (the bits that wind back and forth) to the frame (the outer bit). When you accelerate the frame, the mass lags behind it. The distance it lags is proportional to the acceleration.

This gives us an acceleration-to-relative-position transducer. By measuring the relative position of the mass compared to the frame, we know acceleration. This is usually done capacitively. Capacitance is proportional to the distance between the plates, so now we have an acceleration-to-capacitance transducer.

Often you will see fingers like this ( http://www.sensorsmag.com/sensors/data/articlestandard/sensors/242006/334974/fig2.jpg ). These form the capacitors. Note that the actual capacitance is somewhere in the range of rediculosmallfarads.

To make the final leap, a circuit must convert capacitance to voltage. This is done in many ways. The easiest to conceptualize is putting an RC oscillator that varies its frequency with C. Measuring frequency is easily accomplished with digital logic.

In reality, companies will use more interesting / complicated methods to make the final capacitance to voltage leap. However, the basic mass spring -> capacitance is reasonably standard. The innovation there is how many axis one can fit on the same silicon.

And that creates a MEMs accelerometer. By changing the geometry of the springs and fingers you can create a gyro, but I have a harder time clearly showing this geometry.

[Richard McClellan]

Every FIRST robot that I have worked on has used quadrature encoders to measure both distance traveled and velocity. So I'm curious, how does using an accelerometer for velocity and distance traveled compare to an encoder? Is it more or less accurate?

Now that I think about it, I've never used an accelerometer on any robots that I've built, and I've been building quite a few robots over the last 5 years. What other things do FIRST teams use accelerometers for?

[R.C.]

Since this is for noobs, can anyone give details on which encoder, gyro, accelerameter to buy. How to set one up and tips on making them all work perfectly. Also calibrating them. Thanks, this will help a one of the new teams by us. We have only used a gyro so far.

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

[Nikhil Bajaj]

Hi Manic,
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!

[dtengineering]

I think the best way to understand a MEMs accelerometer is to look at one - http://archives.sensorsmag.com/articles/1203/20/fig1.jpg is a 3axis
http://www.sensorsmag.com/sensors/data/articlestandard/sensors/242006/334974/fig6.jpg is an early prototype that is easier to understand.

Essentially, you have a mass (the middle bit) attached by springs (the bits that wind back and forth) to the frame (the outer bit). When you accelerate the frame, the mass lags behind it. The distance it lags is proportional to the acceleration.



Cool link. Here's another image, but of a bubble-based MEMS acellerometer http://www.pcmag.com/encyclopedia_term/0,2542,t=accelerometer&i=37372,00.asp

There is also more than one way to make a MEMS gyro. This link http://www.sensorsmag.com/articles/0203/14/ is pretty good at explaining gyros in the second half of the article, and although it might not be introductory-level reading throughout, it's a pretty good little write up on accelerometers and gyros.

Jason

[Akash Rastogi]

This is a great topic. although I really don't have anything to add, could the OP or someone move it into the FTC thread? Thanks.:)

[Dan Petrovic]

Using a gyro and an accelerometer, you can tell where your robot is on the field at all times, this is especially useful during autonomous.

You can measure the acceleration to a point, continue at a constant speed then measure how long it takes to slow to a stop, timing the whole process. With this information, you can determine how far the robot has gone. Then you can turn 90 degrees counter-clockwise, the gyro will make sure that it is 90 degrees.

A gyro can be useful during teleop, as well. Let's say there's an objective that requires precise and accurate driving, like 2007. Now, you have your robot all lined up ready to score, a team comes by, hits your robot and rotates it enough to keep you from scoring. With a gyro, you can sense rotation that wasn't caused by your own robot and have it correct itself based on the readings from the gyro. This will quickly and precisely line up your robot again and will avoid any human error that would arise in this situation without a gyro.

Some teams have used a gyro to create a field based control with their crab drives. I don't know much about this, so I wont go into it.

[Trevor_Decker]

How accurate our accelerometer's ?

[EricVanWyk]

How accurate our accelerometer's ?

Completely dependent on the specific part in question. Digital accelerometers are in the range of 8 to 12 bits ( a couple thousandths of a g per count), but you can buy better or worse. Really what kills you is part to part variability - you can easily get 20% sensitivity variability and/or offset variability, so be sure to calibrate if you need to. Also, some of them are really temperature dependent.

[Trevor_Decker]

Thanks for the information,

sorry if these seem like stupid questions but; does g stand for grams or is it the acceleration of earth's gravity. also I am I correct to assume the lower the magnitude of g the better?

[EricVanWyk]

Thanks for the information,

sorry if these seem like stupid questions but; does g stand for grams or is it the acceleration of earth's gravity. also I am I correct to assume the lower the magnitude of g the better?

I meant g in terms of the acceleration due to earth's gravity. Sorry for the confusion!

I'm not really sure what you meant by your second question. Could you please rephrase it?

[Trevor_Decker]

is 100 g better then 1 g or is it the other way around?

[Vikesrock]

is 100 g better then 1 g or is it the other way around?

I think the confusion revolves around what you mean by better. Do you mean easier to measure? Or which is greater?

100 g is a much greater acceleration than 1 g. If you are talking about an option between a sensor with a range of 1 g and a sensor with a range of 100g then it matters what you are measuring and what kind of accuracy you need.

For a given resolution (in bits) a sensor with a larger range will have larger steps (less accurate for small changes in acceleration). A sensor with a smaller range may be saturated if the acceleration is larger than the range (5g of acceleration applied to a 1g sensor).

[Chris Hibner]

is 100 g better then 1 g or is it the other way around?


It depends on the application (i.e. what are you using it for?).

If you're using the accelerometer for an anti-lock brake system, you would want to use a low-g range, like a 1.5g accelerometer, since the largest acceleration you should see under braking is about 1g, (the extra 0.5g is because you'll want a little room for vibrations and noise so you don't get distortion in your filters, but that's a more advanced topic).

If you're using the accelerometer for a side-impact airbag crash sensor, you'll want to use an accelerometer in the 250g range since you mount it right next to the impact and you can see accelerations well above 100 g's.

The idea is that you pick your sensor by determining (from physics or tests) what is the largest acceleration you will see. You should then select a sensor that can measure with just a little more range than this maximum.

[Trevor_Decker]

It depends on the application (i.e. what are you using it for?).

If you're using the accelerometer for an anti-lock brake system, you would want to use a low-g range, like a 1.5g accelerometer, since the largest acceleration you should see under braking is about 1g, (the extra 0.5g is because you'll want a little room for vibrations and noise so you don't get distortion in your filters, but that's a more advanced topic).

If you're using the accelerometer for a side-impact airbag crash sensor, you'll want to use an accelerometer in the 250g range since you mount it right next to the impact and you can see accelerations well above 100 g's.

The idea is that you pick your sensor by determining (from physics or tests) what is the largest acceleration you will see. You should then select a sensor that can measure with just a little more range than this maximum.

So if I wanted to use an accelerometer to tell how fast a robot is moving (constantly adding/ subtracting the acceleration from the speed) , I would want a 2g accelerometer since the field is 54 feet in length, which divided by 32.174(earths gravity) = 1.678 which rounds up to 2.

would that be correct?
How accurate is a 2g accelerometer?

Thanks again for the help!

[Tristan Lall]

So if I wanted to use an accelerometer to tell how fast a robot is moving (constantly adding/ subtracting the acceleration from the speed) , I would want a 2g accelerometer since the field is 54 feet in length, which divided by 32.174(earths gravity) = 1.678 which rounds up to 2.Time for some dimensional analysis: 54 ft ÷ 32.174 ft/s2 = 1.678 s2. Since g is not given in s2 (seconds squared), you probably shouldn't rely on that calculation.

Constant acceleration of 2g means that for every second the robot moves, its velocity increases by 2 × 9.81 m/s = 19.62 m/s = 64.35 ft/s. I can't think of any FIRST robot that can sustain that sort of acceleration for any meaningful length of time. (So it turns out that that might be sufficient for measuring your robot's acceleration due to its own drivetrain, but for different reasons than you suggested.)

How fast is your robot, and approximately how long does it take before it reaches its top speed? That will help you find your average acceleration. You'll want a sensor that can handle that range for sure, but like Chris said, if you're depending on this sensor to measure anything but the idealized performance of your drivetrain—for instance, stopping due to hitting things on the field—you'll need to expand the range by some unknown amount.

How accurate is a 2g accelerometer?The accuracy of the device itself will be published on its datasheet, provided by the manufacturer (or sometimes the distributor of the part). It's usually a function of the device's temperature, so many incorporate a temperature sensor.

[Chris Hibner]

So if I wanted to use an accelerometer to tell how fast a robot is moving (constantly adding/ subtracting the acceleration from the speed) , I would want a 2g accelerometer since the field is 54 feet in length, which divided by 32.174(earths gravity) = 1.678 which rounds up to 2.

would that be correct?
How accurate is a 2g accelerometer?

Thanks again for the help!

As a side note, if you want to know how far your robot has travelled, you're much better off using encoders. With that being said, I have 10 years of engineering experience in control systems using intertial sensors (inertial sensors = accelerometers and gyros), so I enjoy talking about this stuff. So, here goes the answer to your question...

Is your robot slip limited? In other words, if you put your robot on the carpet facing against a wall and you apply full power, do the wheel slip or do the motors stall?

If the robot is slip limited, the highest acceleration that the robot can experience under its own power is the coefficient of friction between the wheels and the carpet (if you don't believe that, go through the math/physics, if you wish). Therefore, if your coefficient of friction is 1.5, you can accelerate up to 1.5g. Once again, you'd want to pad this to account for vibration and noise, so you might want to select a 3g accelerometer. Why pad for vibration and noise? See the "VERY IMPORTANT" section below.

If the robot is torque limited (wheels don't ever slip), then you need to calculate the force applied to the carpet by all of the wheels. You can do this by either going through all of the gear-train calculations, or just put a scale against the wall as you drive into it. Then use Newton's handy-dandy 2nd law (Force = mass*acceleration) to solve for the maximum acceleration.

VERY IMPORTANT: If you EVER saturate the accelerometer, your velocity and distance caculations will be forever wrong after that point. For example, let's say you are using a 3 g accelerometer and your robot bumps into something and experiences 4 g's for 0.1 seconds. Your accelerometer can only measure 3 g's, so for 0.1 sec you think you're accelerating 3 g's when in fact you're actually accelerating 4 g's. Your velocity calculation will then be off by 3.2 ft/s and your position calculation error will grow to infinity (at a rate of 3.2 feet per second - see the connection?). Not a good situation. There is a lot of engineering work that goes into solving these types of problems on antilock brake systems and traction control systems - a lot more time than you have in the 6 week period, which is why I would suggest encoders.

[Trevor_Decker]

As a side note, if you want to know how far your robot has travelled, you're much better off using encoders.

My problem with encoders is that if the wheels slip then the robot will think that it has moved more than it has.

I am not to concerned about the acceleration being greater then the accelerometer max, since I plain to get one that is between .5 g and 1 g greater then the hiegst acceleration the robot should be moving at, also the date from the accelerometer will probably only be used during the autonomies period, so it only really matters for the first 30 seconds. that being said it would be nice for it to work the whole time, Hopefully giving the drive an on screen birds eye view of the robots position.

[Bomberofdoom]

Accelerometers and Gyros have other applications than for the drivetrains:

In the 2007 game, where at the end-term of the match (20 seconed before end), you would have to lift up two of your other alliance robots, our team has developed a jack system to lift the two robots.
The robot had two "wings" (flat plates from each side that would open up). In the inner corners of the robot were 4 poles that were attached to a motor (The robot (http://www.chiefdelphi.com/forums/showthread.php?t=56063&highlight=team+2230). I'm afarid the good pictuers are gone, but it shows most of the robot). These poles were designed to be pushed downwards (more exactly, rotated downwards) when the motors where activated. At some point all 4 poles would reach the ground, and start pushing the ground, which, thanks to Newtown's third law (If object A exerts a force F on object B, then object B exerts an equal and opposite force –F on object A - http://www-istp.gsfc.nasa.gov/stargaze/Snewton3.htm), would result in the lifting of the robot itself, with the two other robots on each of the plates (overall lifting 2 robots "plus one more").

The major problem we had in our design is that we had only a total of 2 of the main motors we planned to use to rotate the poles, so we were forced to use 2 lesser powerful motors, which would result in that two poles would push the robot earlier than the two others, resulting in the tilting o the two other robots on our plates and thier fall or our poles braking from the pressure of 180 KG.

We resolved on using a 2-axis accelerometer to measure the the tilting to each direction - forwards/backwards and sideways. By integrating the change in each axis, we were able to come up with a mathematical algorithm for sending the correct speed to each motor, in order to compinsate for any tilts that would might have been caused from the varying dimension and weight of the alliance robots.

I've seen a team use a Gyro for thier robot's arm, to measure the rate of change in the arms movements to know what its current position is (by integeration, as described before me).

Note that usually a potentiometer is more effective and easier to use than a Gyro for this kind of arm positioning application. The potentiometer revolves with the arm, and as it revolves, it chances the resistance inside of it, and therefore the voltage that is recieved from it changes also. If the potentionmeter is constant, you get a constant voltage of that position. If your position would change, so would the voltage - even if you would stop in a new position, it would send the voltage for that position, instead of giving you the "rate of change" like the Gyro - no need for integration here in order to know what is your position.

Hope I gave a good lesson. :rolleyes: :p

[Chris Hibner]

My problem with encoders is that if the wheels slip then the robot will think that it has moved more than it has.

That's an easy problem to solve - use dummy wheels. In other words, put a wheel on the end of a trailing arm that is lightly spring loaded toward the floor. Hook up the encoder to this wheel. Then if the drivetrain slips, you don't have to worry because this wheel is just an unpowered dummy wheel along for the ride. We've been doing it that way since 2003 and it works perfectly every time. Last year we used two dummy wheels - one on each side of the drivetrain (the dummy wheels were in the same line as the drive wheels). By doing this you can also eliminate the gyro. I'll let you do the math to figure that out.

[ptan]

Can anyone explain to a not-very-techie-type person (think "stay-at-home mom drafted as technical mentor/coach") how these 2 sensors work, and give some instances of when you would find them useful?

I'm surprised no one mentioned this yet:

An accelerometer is a Wii controller.