$50 bounty: report pitch and roll minus any acceleration effects

I know, that's what I'm looking for. :slight_smile:

To be fair: an accelerometer is all you need to measure rotation if your sensor itself isn't also moving. Likewise if your sensor is ONLY rotating around its own axis then all you need is a gyroscope.

This is great as long as the device itself isn't moving

Your impression here is not correct. This is great as long as the device isn't accelerating.

If your device is moving with a constant speed ( in any direction ), then the inclination result you will derive from an accelerometer reading will be correct.

This is great as long as the device itself isn't moving

Your impression here is not correct. This is great as long as the device isn't accelerating.

If your device is moving with a constant speed ( in any direction ), then the inclination result you will derive from an accelerometer reading will be correct.
[/quote]

Yep you're right, I mispoke there. I've started using "moving" and "accelerating" interchangeably when I talk about my issues here but to be accurate I'm really only worried about acceleration forces.

An accelerometer solution cannot distinguish between actual acceleration, and the apparent acceleration implied by the effect of the gravitational force on the sensor element.

You can calculate the orientation of your device using a gyro sensor and an accelerometer, and you are STILL going to be confused in the short term by actual acceleration occuring. The solutions which work for a rocket or a helicopter won't work for an SUV because it keeps hitting rocks and boulders and big potholes, which exert large forces on the vehicle, and the rockets and helicopters generally don't.

If you also detect the geomagnetic field, a so-called "9 axis fusion", then whatever filtering scheme you use can reduce the orientation error caused by actual acceleration much more rapidly, probably rapidly enough for your purpose.

michinyon:
You can calculate the orientation of your device using a gyro sensor and an accelerometer, and you are STILL going to be confused in the short term by actual acceleration occuring. The solutions which work for a rocket or a helicopter won't work for an SUV because it keeps hitting rocks and boulders and big potholes, which exert large forces on the vehicle, and the rockets and helicopters generally don't.

Well, I'm not too worried about it being off when you're doing something hardcore like that. It's more noticeable when you're driving on a flat, smooth road and the device thinks you're pitched back at 10°, or -15° when you come to a stop light. If it could handle the cases like this (which should be similar to the helicopter application) then I would be happy.

michinyon:
If you also detect the geomagnetic field, a so-called "9 axis fusion", then whatever filtering scheme you use can reduce the orientation error caused by actual acceleration much more rapidly, probably rapidly enough for your purpose.

That sensor board actually has a magnetometer on it, but due to the way I'm mounting the sensor to my display I think there's too much interference for it to read correctly...I only accurately pick up W to N to E or so, anything in the other 180° is all over the place.

You are correct, sensing the magnetic field reliably is going to be a problem in an auto.

If you are mostly concerned about the perception of pitching backwards and forwards when you accelerate and decelerate the vehicle, then a 2-D solution using the accelerometer and gyro data is very simple. If you decelerate rapidly, this will create the illusion that the vehicle is pitching forwards. But if it isn't really pitching forwards, then the gyro data will reveal this. It's very elementary rocket science.

michinyon:
You are correct, sensing the magnetic field reliably is going to be a problem in an auto.

If you are mostly concerned about the perception of pitching backwards and forwards when you accelerate and decelerate the vehicle, then a 2-D solution using the accelerometer and gyro data is very simple. If you decelerate rapidly, this will create the illusion that the vehicle is pitching forwards. But if it isn't really pitching forwards, then the gyro data will reveal this. It's very elementary rocket science.

People say this but have yet to put up the code to prove it. :wink:

I did posit that a very crude way would simply be to query the gyro and if it's less than, say, 2°/sec of rotation then consider it to be 0° and ignore any changes in the accelerometer. But if you're on a gentle slope then you'll end up ignoring the accelerometer the whole time and you'll be reading 0° pitch while you're actually on a 9° hill. Not to mention that gyros tend to drift over time and that would need to be compensated for as well.

I assume that there's gotta be some open source arduino-based drone software out there that has something like this figured out, just gotta find it.

Evolution has worked out that rate gyros as well as accelerometers are needed
and equiped all the mammals birds and reptiles? with a pair of compact IMUs:

The way you get accurate orientation data is 3 axis gyro that drives a DCM or
quarternion orientation algorithm and use other signals (3-axis accelerometer
plus optional compass) to correct for drift and error. In zero gravity the accelerometer
is useless and you have to use laser-gyros to get ultra-low drift.

BTW if you allow yourself more than one accelerometer mounted in different parts of
your vehicle, then you can start to do more interesting stuff.

MarkT:
The way you get accurate orientation data is 3 axis gyro that drives a DCM or
quarternion orientation algorithm and use other signals (3-axis accelerometer
plus optional compass) to correct for drift and error. In zero gravity the accelerometer
is useless and you have to use laser-gyros to get ultra-low drift.

If you're only using the accelerometer to correct for drift and error, how do you measure orientation when you're sitting still at an angle and not in the process of rotating? The gyro will always return 0° of rotation.

It seems like a lot of these solutions assume you're trying to fly something completely level and always want to hone in on 0°. I don't want to be biased to any particular orientation, just report the current orientation correctly.

The simplest solution would be to smooth the accelerometer reading out over a period longer than the biggest jolts you expect to get, calculate the direction of the average acceleration and infer roll and pitch attitudes from that. This means that it would show 'roll' when you're driving round a roundabout but not when you are rocked by a pothole; arguably, that's the ideal behaviour since the tipping angle is dependent on acceleration as well as the attitude. If you need something better than that, perhaps you could explain why, and how much better it needs to be. Much better solutions are possible, but they're also much more complicated to develop and get working correctly. At the moment it's not obvious that you need any of that complexity.

PeterH:
If you need something better than that, perhaps you could explain why, and how much better it needs to be. Much better solutions are possible, but they're also much more complicated to develop and get working correctly. At the moment it's not obvious that you need any of that complexity.

If I put myself in the end-user's shoes, they know nothing about accelerometers or gyroscopes or the effects of acceleration on them. All they know is that when they're driving along a flat road it should read 0° pitch always. When they turn a corner it should read 0° roll (unless that corner is banked). Likewise if I come to a sign that says "8° Hill for Next 4 Miles" my device should read pretty close to 8° the entire time.

Once we're off road I would say all bets are off. Although if you're headed up a slope somewhere and you stop moving you should be getting an accurate reading (which is how I'm telling people to use it right now).

It's very disconcerting to just be rolling out of your driveway and seeing the pitch/roll changing. If I didn't know how it was working internally I would think something was wrong with it.

You need to understand how a DCM or quarternion is updated from a gyro - the DCM
or quarternion represent the orientation state, the gyro readings update it on a regular
clock tick. In effect the gyro output is integrated (its output is rotation rate - but in a 3D
sense)

Low-pass filtered output of an accelerometer gives you an estimate of the gravity vector
(9.8m/s/s upwards), which is used to correct for the drift of the gyro. Gyros drift (mainly
because you have to integrate the output), MEMS gyros drift loads. So combining them
you still get yaw drift, but that's all. Add a compass to correct yaw (works best with no
iron around!)

It seems like a lot of these solutions assume you're trying to fly something completely level and always want to hone in on 0°. I don't want to be biased to any particular orientation, just report the current orientation correctly.

No, all these algorithms report the orientation of one frame of reference with respect
to another in 3D (either local in terms of global, or global in terms of local). A 3D
rotation has 3 DoF,

Then don't try and just use an accelerometer to establish orientation because it doesn't work.

MarkT:
Then don't try and just use an accelerometer to establish orientation because it doesn't work.

I know, I want to integrate the gyro to make it more accurate, that's what they bounty is for! I want someone to write that code to make it awesome. :slight_smile:

No takers? C'mon guys! Why is this so hardddddd

Two words: kalman filter

JimEli:

[quote author=Rob Cameron link=topic=212655.msg1566487#msg1566487 date=1390940190]
No takers? C'mon guys! Why is this so hardddddd

Two words: kalman filter
[/quote]

Hey Jim,

I looked into the Kalman filter and what I found (or at least, the way it was being used in this instance) was to take a large percentage of the read from the gyroscope and add that to a small reading from the accelerometer (plus a certain percentage of the final result from the last read) and use that to determine an object's position. But it required that the object be constantly moving/rotating, like in a self-righting robot. It's always about to tip over so the gyro constantly has changing input. This solution won't do me any good if a vehicle is on a slope, but isn't rotating in any way. 95% of the 0° reading from the gyro plus 5% of the 5° reading from the accelerometer is going to read as almost 0°. (I posted a link of an example of someone using the Kalman filter for his self-righting robot in my first post on the thread.)

To be fair, I don't 100% understand the calculations going on in the Kalman filter, but this is how the Complementary filter works and several sources listed it as a "good enough" replacement for a Kalman filter. So while Kalman may be more accurate, the basic function at the end of the day should be the same as the Complementary.

(I'm actually using a Complementary filter when I display altitude from the barometer to get a smooth reading instead of the raw jumps of +/- 3 feet when sitting at rest.)

Unless my interpretation is completely wrong, in which case please point that out and tell me the secret of how I can get this to work for my project. :slight_smile:

There are several open source AHRS (Attitude and Heading Reference System) projects around for you to use as a guide. They are intended for navigation, but the "Attitude" part does what you want.

Here is David Grayson's, intended for the Pololu Mini-IMU and the Raspberry Pi: GitHub - DavidEGrayson/minimu9-ahrs: Program for reading data from the Pololu MinIMU-9 over I²C. Works on the Raspberry Pi and other embedded ARM Linux boards.

There is this link on Sebastian Madgwick's page: Open source IMU and AHRS algorithms – x-io Technologies

One on Google Code: http://code.google.com/p/openahrs/wiki/openAHRS

Finally you can buy self contained modules with code very cheaply these days: http://www.chrobotics.com/

jremington:
There are several open source AHRS (Attitude and Heading Reference System) projects around for you to use as a guide. They are intended for navigation, but the "Attitude" part does what you want.

Here is David Grayson's, intended for the Pololu Mini-IMU and the Raspberry Pi: GitHub - DavidEGrayson/minimu9-ahrs: Program for reading data from the Pololu MinIMU-9 over I²C. Works on the Raspberry Pi and other embedded ARM Linux boards.

There is this link on Sebastian Madgwick's page: Open source IMU and AHRS algorithms – x-io Technologies

One on Google Code: http://code.google.com/p/openahrs/wiki/openAHRS

Finally you can buy self contained modules with code very cheaply these days: http://www.chrobotics.com/

Thanks for the links! I'll look into them in the next day or so...if they contain the answer you shall be the winrar!