I was playing around with the accelerometer the other day, trying to use its sum to determine velocity. However, I fiddled with my algorithm for a couple of hours and couldn’t get it to give me anything close to an accurate reading. Has anyone actually gotten this to work? I think they’re just way too sensitive to use for tracking. I’ll probably end up just using the gear tooth sensor to measure distance, which makes more sense anyway.
Maybe I need to upgrade to kevin watson’s oversampling uart?
I’ve played with an accelerometer, but from what I’ve heard they can be very tricky. I would go with the encoder/gear tooth sensors to calculate position. How is yours connected? Could you show us the code?
I just took in the data from it and summed it into a static variable. I tried bitshifting it, putting on a deadband, everything i could think of, but it looks like the data is just not accurate enough, or maybe it can’t read from it quickly enough. I’ll post the code later tonight, since it’s currently saved on a computer half an hour from here.
Are you accounting for ALL acceleration? Fun fact: That chip will provide you with a deluge of information all lumped in to one signal. You need to filter out gravity, acceleration from getting hit, deceleration and probably more I’m not thinking of.
Also, it measure acceleration, not velocity, so if you’re cruising at a constant speed, it’ll read back 0 acceleration…plus the above mentioned factors. Gravity is tough, it varies based on orientation, on the upside that makes it great for sensing absolute angle when you’re not moving, maybe use it for that and use encoders for velocity?
Hope that helped…
Using an accelerometer to determine your position is very, very hard. I’d start out by integrating once to determine your velocity and once you’re happy with your results, try to integrate if again for position. I haven’t tried it, but perhaps someone could try it out with the gyro code and report back. If you do, make sure that it is still and lying flat on a table while the bias is being calculated.
-Kevin
Yeah, I was trying to simply integrate the acceleration to get velocity. I couldn’t even pull that off. I came to the conclusion that gear tooth sensors make way more sense and it was slightly retarded to even consider using the acceleros in my navigation code.
I’d have to chip my two cents in and agree that using the accelerometer to measure speed is exorbitantly difficult. Our omniwheels provide a bit of slippage and encoders are therefore somewhat inaccurate, but in terms of being able to determine our location in autonomous, they are still our number one choice (versus the unreliability of the accelerometer).
using the accelerometer to measure speed is exorbitantly difficult?!
velocity is the integration of acceleration. If you have the sensor horizontal pointing fore and aft, then all you need to do is add the output of the sensor to a variable (16 bits is best) each time you pass through the main loop of your code, and subtract out the zero reading (offset)
the register will then contain your velocity, all the time.
Yea, but the velocity reported is, simply put, crappy. Velocity calculation from accelerometers is very hard in the sense that the results are noisy, and the noise readily amplifies with each integration. I’m sure you understand this.
The accelerometer isn’t useless though. It can be fused with the gyro, to eliminate most of the bias. Saying this can be done is one thing, but actually doing it is an altogether different thing.
The accelerometer shares the same weakness with the encoders–they are both sensitive to BUMPs, and other “high frequency” changes–and also the same strengths: they are both pretty consistent over the long term. Therefore, fusing the accelerometer with the encoders might not be as fruitful.
you need to step back a bit and look at the big picture. If there is noise and bumps they will be random and will average themselves out over time.
You could also filter the analog signal in HW or in the code. At any given instant the velocity integration may be a little off, but if you are reading it on every loop through your code, and using it for some purpose (like a PID closed loop speed control) the inertia of the motors and the robot will also help smooth out any random noise on the signals.
Have you tried using accelerometers for this purpose? Do you have any specific experiences to share? I’m eager to hear of your results.
Yes Ken, we all understand that it works perfectly in theory. I, however, have actually tried to implement this and failed miserably. The accelerometers simply are not reliable enough, coupled with the fact that a lot of the acceleration can occur in short spurts, which might not even be picked up by a given program loop.
Also: If you have a little bit of offset in your velocity calculation, then when you calculate position from that, it will be offset twice as bad.
If you have successfuly overcome these obstacles, please enlighten us.
In the past the teams I have mentored used the ADXRSxxx family of yaw rate sensors for two functions: to close the loop on steering with a PID feedback control system, and we integrated the turn rate to get a relative compass heading.
For both applications the yaw rate sensor works very well. We could spin the robot 360 degrees left, then 360 right and it came back to 0 degrees so well that we could not measure any error.
The two axis accelerometer in the KOP this year is also made by Analog Devices, its the same family of products. I looked into the part used, the ADXL311. This is an excellent device. Analog Devices literally sells them by the millions.
Maybe my last post gave the impression that all you have to do is hook up the wires and add some numbers together. OK, I admit that was over simplifying the entire design - that was only the starting point.
Ive read the data sheet for the ADXL311. Looks like this would be a good topic for a white paper. The device has a user selectable bandwidth, controlled by parts that are soldered on the board. I dont know the default bandwidth as the board is shipped in the KOP, but it would not be hard to set this device up to get a 10 or 20Hz bandwidth.
Bandwidth is the indication of what the device will let through to its outputs, and its also related to the noise-floor of the output signal. The lower the bandwidth you use, the less noise the sensor will have.
Im afraid I cannot give all the details of everything you would need to do to use these devices on your robot in the character limit of this post. Even if I could, that is part of what this program is all about - students and mentors on a team looking at the data sheet for the part, and the application notes that Analog Devices has on their website, and refining the response of the sensor, and the code that integrates it to get the results you want. I cant do that for you over the CD forum.
One key to success with these devices is getting the bandwidth set so that it integrates the acceleration for you between the times the uC reads the output signal. Keep in mind that your robot has a lot of mass, its not possible for your robot to be jerking around on the floor jumping from +2g to -2g to +2 gs at 5mS intervals. The force required to do that would be off the scale. (BTW: Jerk is accelerated acceleration). If you have the sensor solidly attached to a heavy part of your robot frame, the signal you get from it will be fairly smooth and noise (vibration) free.
These devices are excellent for measuring tilt and acceleration. They are also very good for calculating velocity. As Watson pointed out, going one integration further to get distance is pushing it somewhat, but all things considered, having more sensors on your robot is better than having no sensors.
Hi,
We are using the accelerometer to indicate that we are on the ramp sitting still and not rotating from side to side.
Consider mounting the accelerometer at a less than perfect horizontal orientation. We noticed that resolution (sensitivity) is much better if the acc. is tilted between 30 to 60 degrees. This has proved somewhat consistent for us.
Another use for the acc. is in autonomous mode. You are for example driving from point a to b. You are cruising at a nice speed when suddenly there is an unexpected spike (up or down) in accel. We are using this (in conjunction with wheel gear teeth data) to indicate a possible collision so we can execute a reversing action, and then put the bot back on the right path.
Regards,
ChuckB
[quote=
]
I have heard poeple do floating point trig calculations, then why can’t you do floating point integration calculations?
Wouldn’t it be accurate enough?[/quote]
the sensor connects to your analog to digital converters, and the output is an integer. What are the ADCs on the RC this year, 10 bits (I think)? that would give you a reading from 0 to 1024, with the ‘zero point’ around 512.
there is no need to convert that to a real number. If you are calculating tilt with the accelerometers that might be a different story.
This is my frist Chief Delphi post! Hope this information helps someone.
I agree it can be difficult to get reasonable data from the accelerometer. We designed a little test where we mounted the 2006 Gyro and X,Y accelerometer (plan attached) to a roll around cart and recorded the outputs using the NI data logger we got. Our plan for navigation is basically to use the gyro to set a heading and then use shaft encoders or gear tooth counters to drive straight to the next point in the waypoint list, stop, turn and then go straight again so I didn’t really think we would actually use the accelerometers for navigation. I did think that they may come in handy to tell us if we have started up a corner goal ramp and I was curious what I could get out of them. Well, after the data was put in an excel spread sheet, it looks like using only the accelerometer that is in the direction of the robot heading and the gyro and a little trig you can navigate through a few waypoints, travel over 50feet with an X,Y error when you are done of about a foot. See attached spread sheet if you are curious. We will still count wheel rotations but at least for now our controls group will use the gyro and accelerometers for navigation.
The excel files list the raw readings for 5v, Gyro, Temperature, Acc X, Acc Y. The sample rate was slow, 100 s/s but that seems to be fast enough. The actual path and the estimated path using the gyro and accelerometer are shown for two test cases.
The spread sheets basically take the raw gyro and Y accelerometer outputs, remove bias, let you set different dead band widths and gains. The final output is the X,Y position of the robot for each time tick. The heading from the gyro is used to update the robot position every sample. That is probably too much processing for the real application but if you assume the robot drives straight from waypoint to waypoint then you can save processing cycles and only calculate the distance traveled in the heading direction from the last waypoint in order to know when to stop and turn. If you look at the data carefully, you will see that the Y accelerometer output is zeroed while the robot is turning (for question mark that is from 6.93 to 9.23 and 15.33 to 18.74 seconds) this can be done because while turning the robot only uses the feedback from the gyro for our application.
http://members.cox.net/gnsmith/Just%20Gyro%20and%20Y%20acc_triangle1_results.xls
http://members.cox.net/gnsmith/Just%20Gyro%20and%20Y%20acc_question_mark.xls
http://members.cox.net/gnsmith/Team%20116%20Gyro_accelerometer_test_plan.pdf
i used this code to find acceleration. Tipping the accelerometer 90 degrees to one side should read 9.8
place this code in
void Process_Data_From_Master_uP(void)
float get_x_value;
float get_y_value;
int a = 205;
float dec_x;
float dec_y;
float x;
float y;
//get analog values for ana04 and ana05
x = Get_Analog_Value(rc_ana_in04);
y = Get_Analog_Value(rc_ana_in05);
/****************************************************/
/*******divide by a(205) to get voltage**************/
/****minus 2.5 to get a range from 2.5 to -2.5*******/
/******multiply by 1000 to get millivolts************/
/*divide by 290 to get G's (290 = millivolts in 1G)**/
/***multiply by 9.803(accelertaion due to gravity)***/
/****************************************************/
get_x_value = (((((x/a) - 2.5) * 1000) / 290) * 9.803);
get_y_value = (((((y/a) - 2.5) * 1000) / 290) * 9.803);
//find and print floating point number
dec_y = ((get_y_value - (int)get_y_value) * 10);
dec_x = ((get_x_value - (int)get_x_value) * 10);
if (dec_x < 0)
dec_x = dec_x * -1;
if (dec_y < 0)
dec_y = dec_y * -1;
printf("acc_x: %3d.%3d acc_y: %3d.%3dr", (int)get_x_value, (int)dec_x, (int)get_y_value, (int)dec_y);
i believe multiplying the (acceleration * change in time) should give you velocity.