Accelerometer Suggestions

Over the past week I’ve gotten the kit of parts accelerometer from last year working on the Vex for getting position and velocity (or it’s mostly working).

Does anyone have suggestions for an accelerometer to use for inertial navigation on an FRC bot? The current one works on Vex, but I’m afraid it won’t be able to handle the faster accelerations and speeds of an FRC bot. I like the MMA7260Q from Freescale, largely because I can choose the sensitivity that works best on it, but it’s a 3.3V part and I’m not sure our team wants to deal with making a power converter (we have no skilled electrical students; we have 2 mentors but I’m not sure they’ll have the time to do it).

Look at Analog Devices for ratiometric 5 V parts.

If you don’t want to wait to get something shipped SparkFun has some good accelerometers.

Also can you post some code? If you really have that working I want to see it.:slight_smile:

I have bought this from SparkFun awhile ago but havent had the time to write code for it. Once I have it ill post it for all teams to use.

I was looking at Sparkfun about Accelerometers, as they seem to be one of the best carriers for usable ones (boo BGA soldering, we bought a gyro directly from Analog accidently 2 years ago, and thankfully we knew someone who could solder it for us).

Chris, if you use that soon please tell me how it works, as the ADXL203 seems to be the best option available if we don’t want to build a power converter for voltage. The only worry about that is if a 1.7g range will be enough.

Attached are the .c, .h, and readme files for the code. It’s designed to work with Kevin’s ADC code and is based largely off of his gyro code (so if it looks familiar, that’s why).

So far it’s accurate to about 3 inches for 1-1.5 seconds, and like 6-8 inches for 2 or 3 seconds. It’s not as accurate in reverse as it is going forward. Based on those errors, I definitely need a more accurate sensor for a large bot.

accelerometer.c (12.2 KB)
accelerometer.h (5.45 KB)
accelerometer_readme.txt (10.5 KB)

accelerometer.c (12.2 KB)
accelerometer.h (5.45 KB)
accelerometer_readme.txt (10.5 KB)

I g is about 32 feet per second, so 1.7g would be able 54 feet per second. I dont think your bot will be going that fast :stuck_out_tongue: However i have never used an accelerometer so maybe that number means something else

It’s about 54 feet per second squared (acceleration, not velocity). I figured out already that a robot geared to 9 feet per second can get an acceleration somewhere around 1.7 or 1.8 gs. I want a little wiggle room though to help account for deadband and the sensor I get not being perfectly with the specs.

Of course I hope on having a fast robot, so it might not be an issue since that will have a slower acceleration. I’m just gathering suggestions.

AH! Thank you for pointing that out. I wasnt even thinking about that. You are correct i think.

Now I am not saying you are wrong, but how did you arrive at that 9ft/s robot achieving a 1.7g?

This would theoretically mean that, if it could go that fast, it could reach a speed of 54ft/s from 0ft/s in just one second. I thought that such G’s might only be “possible” during a full speed collision.

I figured that for a robot with 6" diameter wheels to go at 9 ft/sec, it would have to have wheels spinning at 344 RPM. The CIM motors have a free spinning speed of roughly 5200 RPM, and a torque at stall of 2.4 Nm. Since we have 4 CIMs in our drive system usually, that would give us a stall torque of 9.8 Nm.

Reducing our RPM from the motors to 344, increases our stall torque to 148 N*m (this is ignoring all gear train inefficiencies). Dividing this by the radius of the wheel (.0762 meters) gives us 1942 N of force at stall. F = ma, so we divide the force by the robot’s mass of 60.5 kg, and we get an acceleration of 32 m/s^2, which is actually 3.3 gs!

I had originally gotten 1.6 gs, but that’s because I used the wheel’s diameter in place of its radius.

Of course, this acceleration is actually impossible because the wheel traction would probably never allow for any force greater than 1000 N.

Collisions are much worse; I registered a 1 g acceleration on the accelerometer when it was only 5 degrees from vertical, which meant the impact generated was more like a 12 g acceleration. Driving around with it being used for position I’ve gotten .5 gs from the Vex robot, which is no where near the power of an FRC bot.

Thats close to that of a Space Shuttle! Even F-1 cars can pull that much during acceleration. There is no way that a FIRST robot can pull more Gs than a F-1 car(800Hp vs 2) during anything, let alone a Space Shuttle.

The reason I am going after this is because I want to use the accelerometer for same purpose(get position form it). And if this is true then everything I believed is completely false!

I think you might be forgetting the INERTIA of the robot… It can’t physically accelerate that fast!!!

As I said, this was in perfect conditions. In reality, this isn’t possible for a few reasons:

  1. The wheel traction won’t allow for it. Going through the math, an odd coincidence is that the coefficient of friction between your wheels and the ground is the same as the maximum amount of gs your robot can accelerate at before the wheels slip (assuming your robot has no dead weight and has the same friction on all wheels). This means FIRST robots using skyway wheels can’t get above .8gs of acceleration, and the roughtop/wedgetop tread are limited to 1.3 gs.

  2. This is an instantaneous acceleration where your robot has not moved yet and your motors are instantly outputing stall torque. Your motors can’t output that much torque without ramping up to it first, and applying torque through the wheels will start your robot to move, which means you won’t be stalling anymore.

Under very unique (and basically impossible) conditions, I believe these motors could create that much acceleration; however, as I said, I believe that is impossible.

Don’t be surprised if you get readings like these from collisions though; collisions are capable of creating accelerations of several 1000s of gs, meaning collisions will still render position sensing invalid much like they do for encoders.

I didn’t discover some of these numbers until trying to prove everything again; seeing the new data about what gs are possible with the wheel traction we have, I’m no longer worried about choosing an accelerometer.

Feel free to try the code I developed for position sensing. It took me over a week to develop it working on no other code, and that’s alot of valuable time come build season. It does work, better accelerometers are needed for better accuracy is all.

Thanks for the code. But first I need to “understand” accelerometer. Haven’t really had the time to do that. I will start with the kit of parts accel and LabView. I have no idea if I can finish this in 6 weeks, but I will try none the less. Is your’s based off of Kevin Watson code?

Yes, my code is based off of Kevin Watson’s gyro code. It requires his ADC code to run, and will look very familiar to his gyro stuff. I don’t know what LabView will do for it, I have only used the accelerometer with this code I developed and don’t have any past experience using accelerometers. Good luck!

He did have an accelerometer code made in 2005, I think. You might want to check it out(probably similar to yours); it’s somewhat similar to the gyro.

Our team was lucky enough to receive a LabView data acquisition module and software($2700) to play around with. It has a 14bit A/D converters to acquire data that can be shown graphs. I want to try and use this to speed up our development.

I’ve seen his '05 accelerometer code; it had the ADC built into it (rather than seperate like he did with the gyro in '06), so it wouldn’t work with other sensors using analog ports at the same time. It does acceleration similar to mine, I just went a step further and tried to calculate velocity and position as well.

14 bits is alot better resolution than you’ll get on the robot controller; keep that in mind, as there is a huge difference in what you can measure between these. A 14 bit A/D will make each number in the output practically 1 millig for the kit accelerometer, while the A/D on the FRC controller has about 16 milligs for each number on the output.

Well that s why I am working on trying to get an external PIC on board to do the extra crunching. I will certainly using the oversampling feature to attain the max res possible. External PIC might should be able to output 13bit easily and maybe 14bit with some optimizing.(It also has to do the gyro and the trig calculations)

You should be able to do 12 bit on the RC. In fact, that is the initial setup of the Kevin’s ADC code.