This sounds like an advanced question to me and Im not sure where to go. But I have an IMU, http://www.chrobotics.com/index.php?main_page=product_info&prod... , and I will be getting pitch roll and yaw as well as accerometer data from the unit. How can I take the Z accelerometer data and turn it into a rough distance. Everywhere I read hints that there are ways but no difinitive answers as to if it has been accomplished or how to go about doing it. Ive read its possible through integration but my math is lacking since I havent seen an inegral in 10+ years LOL

 

Any help would be great!

 

Thanks

Views: 516

Reply to This

Replies to This Discussion

You can, but you need to turn the thing into an Inertial Navigation System (INS). Even then, the vertical channel (altitude) is unstable, so you need something like barometric pressure to stablize it.

 

Short answer: yes, but it is tough.

Even if I just want z changes of only 1 - 10 meters max?

In the end it won't work because the altitude you calculate from the accelerometers will drift surprisingly quickly.  no matter how accurate the accelerometer readings, they will vary a little bit even when the imu isn't moving.  all these little errors will add up and they won't perfectly offset each other so you will show a slow rise up or down.  that's why Tom says you need a barometer.  You need somethign without drift to counteract that.  I think you don't have that in your set-up at the moment.

 

The other complication you will have is that presumably your IMU is not always level.  So when it comes to measuring the verticle acceleration you can' just look at the z axis accelerometer.  For example, put the IMU on it's side and move it up and down - the Z axis accelerometer will show no change while the x (or maybe y) accelerometer will move all over the place.  so you will actually need to take the x, y and z axis accelerometer values and multiply them by the sin or cos of the roll and pitch angle and then add them up to get a kind of virtual Z accelerometer value.

 

Sorry, not all the math is spelled out above...but if it were me, i would just get a barometer and/or a sonar.  It will be much easier and a better result!

 

good luck!

The meters isn't as important as the seconds. The errors accumulate fast over time.

 

The other posters have stated (and not overstated) the difficulties but not provided the easy part. The equations of motion themselves aren't hard -- high school physics.

 

Acceleration is change in velocity divided by time. So if you multiply acceleration by time, you get change in velocity. If you do the calculation loop 10x per second, delta V = a * 0.1 because time is 1/10 seconds.

 

If you not consider that at the beginning of the time interval we were moving at V1 and at the end we are moving V2, average V during that interval is V = (V1 + V2) / 2

 

Velocity is change in position divided by time. So if you multiply average velocity by time you get change in position. 

 

Bottom line, Z2 = 1/2 * Az * t^2 + V1 * t + Z1    This works for X, Y, and Z.

 

As Randy points out, you need to know the Ax, Ay, and Az. This requires some math because the accelerometers may not be (probably are not) pointed exactly in the X, Y, and Z directions.

 

As Tom points out, even tiny, tiny errors add up. To do this right requires very accurate (read very expensive) accelerometers, very accurate timing. If you just want to have a computed position between GPS fixes coming in every second or so, that is OK. Each time you have a fix, update your X, Y, Z, Vx, Vy, and Vz 

Ryan Beall, Jose Julio and I did some extensive work on an altitude estimator based on APM and integration of the acceleration vector.  Randy and Ken are correct.  With our hardware it is hopeless.  You would need much much better sensors.   Even using the barometric pressure sensor and gps for drift correction it is hopeless - we found we got better results from the baro sensor alone versus coupling it with an acceleration based estimator.

Thanks for the replies a lot of information being taken in over the last 8 hrs.

 

Wow I didnt realize there was so much to this but it makes sense. I will apologize if my questions seem out there but i think my brain is mush from reading so many articles about accelerometers and pitch roll data and elevation and altitude, and now barometers to altitude.

 

But the explainations here today are the best so far and are more in my language LOL.

 

I do have GPS being logged and fixed at 1hz. I will probably bump this up to 2hz. The reason I have such a low frequency is because right now Im just logging the data and not really applying it to anything concrete.

 

I will be putting the GPS/CHR_6DM on board a boat to measure the position and motions of the boat and one of the things my school wants to see is the z motion of the boat. Just some raw averaged data is fine because they just want a cheapo version to show that it can be done with small sensors if we want to see results and not necissarily the most accurate results.

 

I have ordered a barometer sensor to incorporate in the system and I hope it will be here some time this week or next and then I can incorporate that as well.

 

Or should I abandon the accelerometer z movements for barometer readings? Everything I will be doing will be at sea level +/- 5 - 10 meters. or 15-30 ft.

 

Thanks again for all your input and help, I am learning a lot and your help is very appreciated.

Thanks for the heads up. At least I havent gone TOO far into investing time into trying to get this idea to work. I will try the baro sensor method to hopefully yeild some results for the school project.

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service