SparkFun Forums

[monstrum]

Almost every project with an IMU claims to use gyros and accelerometers to determine attitude and position. I perfectly understand the concept but what I don't get is how you really can use an accelerometer to determine attitude when it's not stationary.

If you put it on a helicopter all it will ever measure is acceleration generated by the rotors. If you are stationary in a hover (disregarding tail rotor) it will be pointed straight up and the accelerometer (3-axis) will measure 1 G straight up. Now the helicopter gets a gust of wind and tilts a few degrees. As the rotor still generates the same force, and still points in the same angle as the accelerometers "up"-axis, the accel will still measure exactly 1 G.

Unless the altitude is compensated for by increasing main rotor thrust (by adding another sensor such as a barrometer), there is no way for the accelerometer to know the craft has tilted.


Am I missing something.

[trialex]

When you are in flat level hover, your thrust vector is exactly opposite in direction and equal to the gravity vector.

When you are kocked over a bit by a gust, your thrust vector changes, but the gravity vector remains the same.

[monstrum]

Yes, that is true.

But can you really sense the gravity? What you sense when stationary on the ground is not the gravity itself, but rather the relative acceleration caused by the earth not accelerating in the same direction as the gravity.

Consider the following thought experiment:
You have a car with a two-axis accelerometer. One is pointed forward and one to the right. Now we can sense all acceleration affecting the car (disregard the up/down axis).
If you hit the throttle, we will read an acceleration in the car (forward), let's say it is 9.82 m/s^2. No matter what direction we drive, we will still read the same acceleration (forward, 9.82 m/s^2).

So, what if we have a large crazy solid brick wall coming after the car. This wall is accelerating at 9.82 m/s^2 and travels completely straight.

Now, if the car goes in the same direction as the wall, the distance between them will be the same. However, if you turn, the distance will decrease. However, the accelerometer in the car will have no clue.
The only way to know which way the wall is accelerating is to let go of the throttle until the car touches the wall and is, relatively to the wall, stationary. If we know the direction the wall is accelerating, we can calculate the angle at which the car is positioned.


If the car's front is a helicopter's top and the crazy brick wall is the earth's surface, what's the difference from how it works in reality?

[metaforest]

Calculating both orientation and acceleration from just an accelerometer works.... but it's very error prone. It only works reasonably well when either acceleration or orientation change very little over time and the other changes a lot over the same time interval. If they both are likely to change at similar rates the output will be useless.

A low pass filter is used get the one that changes slowly, and a band pass filter to get the one that changes quickly. Neither output will be very good, but might work well enough, for say.... an iPhone.


The gyro allows us to subtract the gravitational constant.

So when the heli is sitting on the launch pad.... we snap the gyro reading and the accelerometer reading and call that at_rest zero reference. We also set our virtual orientation vector, virtual position, and virtual speed vector to zero. The virtual gravity vector is facing straight up at -1G. This makes our net_acceleration vector zero, since it cancels out the 1G vector pointing towards the center of the earth.

Now you start climbing straight up towards 30 meters. Initially the accelerometer sees acceleration that will read as > 9.8m/s so based on our gyro we calculate a virtual gravity/orientation vector, and subtract that from the output of the accelerometer. We now have our net acceleration without regard to body orientation. This is the net acceleration vector.

Ok now to estimate speed:

We sample our net acceleration vector as often as possible. We now add some calibrated fraction of this acceleration vector to our virtual speed vector. As we accelerate the speed vector increases in some direction. When we decelerate speed drops towards zero. At any constant speed acceleration is zero.

Ok now to estimate position:

We sample our virtual speed vector as often as possible. We now add a small fraction of the virtual speed vector to our virtual position vector.

Now all this looks great if you have no noise or drift in your system.
It works like **** in a real system. Over even a few minutes the system will lose enough accuracy with just two input vectors to be useless for estimating position. Same with orientation.

This is why GPS is so useful. It gives you position and you can estimate a speed vector from the rate of change in position. Working backwards that can help you adjust for drift and noise in the accelerometer. Adding a magnetic compass lets you do the same thing for the gyro.



Cheers

[manton]

If you are falling at 9.8m/s your gravity vector is zero no matter what your orientation. IF your command your heli to accelerate forward the body tilts and the

I think what you meant to say here is that if you are in free fall with an acceleration of 9.8 m/s/s, then your gravity vector is zero. Falling at a constant velocity won't give you a zero gravity vector. If you reach terminal velocity (due to air friction), your gravity vector would also be non-zero.

[monstrum]

Thanks for your input.

That means that if you have constant thrust magnitude and tilts the heli forward, the helicopter will start moving but it will also drop towards the ground. This should make it impossible for the accelerometer to detect any change in the gravity vector and thus it will have no clue that the helicopter has changed orientation.

I perfectly understand that a 3-axis gyroscope can be used in conjunction with a 3-axis accelerometer to estimate position and angle for the system. What disturbs me is that many (not tested in real flight off course) autopilots claim to use the accelerometers and the gyros with a kalman filter to get the orientation without drift. This will probably work on a testbench were the craft is stationary or held by hand and moved around, but it should not be possible in real flight.

Unless, you have more information about the acceleration by using GPS, altitude sensor or whatever. Then you could probably use information from the accelerometers to aid the angle estimation by signal fusion.

[metaforest]

If you are falling at 9.8m/s your gravity vector is zero no matter what your orientation. IF your command your heli to accelerate forward the body tilts and the

I think what you meant to say here is that if you are in free fall with an acceleration of 9.8 m/s/s, then your gravity vector is zero. Falling at a constant velocity won't give you a zero gravity vector. If you reach terminal velocity (due to air friction), your gravity vector would also be non-zero.

Ok fine in a vacuum.

I changed my post quite a bit trying to refine my point.

Cheers

[tz]

Unless you have a very precise system, distance (position) calculations will be all but useless.

To get distance, you need to double integrate the acceleration, which means the error increases with the square of the amount of time. Not drift, just noise.

[emf]

What disturbs me is that many (not tested in real flight off course) autopilots claim to use the accelerometers and the gyros with a kalman filter to get the orientation without drift.

Generally, the filters work by assuming that most of the time you'll be in non-accelerated flight, so the accelerometer data will be correct. The attitude estimate is based off the gyros, but is slowly nudged towards the what the accelerometer reports. The correction is big enough to be able to overcome gyro drift, but small enough to be of little concern during short turns, climbs, etc.

A mechanical artificial horizon used in aircraft has a similar mechanism. They have pendulous vanes inside that sense which direction feels like "up" (in the same way as an accelerometer), and gradually correct the gyro towards that direction by altering the flow of air to the vacuum pump. If you do a 180 degree turn and roll level, your artificial horizon will probably be indicating a turn of one or two degrees.

[tz]

And what is the price of an autopilot for aviation use? If you got the same set of electronics and/or mechanics, it would work. But it does NOT use a $30 chip gyro.

Back before nav satellites, they had to fire missiles from submarines to very remote targets, and they used (litteral) gyros and accelerometers for "inertial navigation", but they probably cost more than the small airplanes.

[emf]

No doubt aviation autopilots cost thousands of dollars, but the needs of airliners are far different than those of an RC helicopter. From what I understand, most of the fancy AHRS systems used on aircraft use ring laser or fiber-optic gyros (some might augment this with GPS), but I'm pretty sure there is at least one out there that uses $30 chip gyros and has been through FAA certification. The gyro drift isn't *that* bad, and you don't need perfect accuracy to keep from falling out of the sky.

It's true that you couldn't navigate any meaningful distance relying solely on MEMS gyro + accelerometer outputs, but real aircraft don't either -- they use radios, GPS, compasses, airspeed, and altimeters

[monstrum]

About my original question. This guy has written down exactly what I've been thinking. Basically it states that unless you know that the craft is in steady-state such as standing on the ground, an airplane at constant velocity and angle, etc, an accelerometer can not possibly know which way is up or down.
http://www.lunar.org/docs/LUNARclips/v5 ... eters.html

So, I can see that a Kalman filter can cancel out the angular drift in an IMU using the accelerometer data, but only if it assumes that the craft is in steady state. That means it should only be usable for airplanes (or other already angle-stable crafts), not helicopters.

[metaforest]

I'd say that for a RC Heli, you would be able to use an IMU for stabilizing the vehicle, if you also track the command inputs. In this limited app the IMU can respond much faster to sudden environmental influences than the pilot.

I have also see some examples of using one and two axis gyros in RC planes to help with stabilization. Again these systems are also monitoring the command inputs to help.

In these two applications long term drift and high frequency noise are not going to cause problems if the controller manages them properly.

[lehmanna]

In case of an RC Heli stabiliziation is really no problem. A lot of devices have showed up on the market in recent year, such as the AC3X, V-Stabi and Robbe's Helicommand. Unfortunately all corresponding internet sites are german

@monstrum: Your assumption is correct. Accelerometer alone won't do the job. But I think somebody's already said that shortly after the beginning of the thread (being too lazy to look that up now ).

[metaforest]

I must say that the sited source @monstrum does a much better job at explaining it. "Deviation from freefall...." DUH!

@lehmanna: I disagree with RC heli stability. Especially the small ones. They are very sensitive to small gusts. Here knowing the command stream and IMU inputs can allow for very fast compensation for a sudden change in air flow around the vehicle.



Maybe with an extra input, say a panic button, the control system might be commanded to restore a stable hover ASAP when the pilot makes an error that they don't know how to recover from. During this recovery the system might ignore anything but large inputs from the pilot hinting at obstacles. *shrug*