Off-Center Installation

[Maine_Guy]

Perhaps someone can steer me in the right direction to research this a bit more?

Curious if anyone has attempted to apply correction values for an accelerometer that is not installed in the center of the airframe? I have an application that would put the sensing unit a fair distance from the center of the plane, which will cause the accelerometer to interpret the movements of the plane incorrectly. I've seen some flight controllers have an 'offset' to compensate (probably with some complicated vector math involved).

Is there any code out there already I might be able to 'borrow' from to accomplish this task?

-j

[happul3]

Perhaps someone can steer me in the right direction to research this a bit more?

Curious if anyone has attempted to apply correction values for an accelerometer that is not installed in the center of the airframe? I have an application that would put the sensing unit a fair distance from the center of the plane, which will cause the accelerometer to interpret the movements of the plane incorrectly. I've seen some flight controllers have an 'offset' to compensate (probably with some complicated vector math involved).

Is there any code out there already I might be able to 'borrow' from to accomplish this task?

-j

I don't think there is anything at all to compensate. Let's think what acc actually measures:

It is easy to see that acc will give exactly the same response to translational motion (acceleration) of the frame whether it is mounted at the center or away from it. It is also easy to see that acc will give exactly same response statically frame is at _any_ different angle. Acc will however give a different response (transient) _while_ the frame is rotating. In other words, rotational movement will produce zero acceleration when acc is at center of rotation and non-zero when acc is not at center of rotation. But once rotational movement stops, acc's response becomes independent of its position on frame. Keeping in mind that acc is used only to estimate translation motion and static angular position with respect to earth gravity vector, whereas it is gyro's responsibility to estimating rotational motion, one can conclude that all the positioning acc off-center is going to do is to introduce a bit of additional high frequency noise, which is probably insignificant because acc is noisy anyway and there is an LPF to take care of that.

[Maine_Guy]

The gyros won't care about position, but the accelerometers are fooled. Take the case below:

Accelerometer.jpg

(7.01 KiB) Not downloaded yet

If the sensor were mounted on the wing tip - when the plane rolls, the sensor thinks the plane is gaining or losing altitude. The farther from center, the worse this is amplified.

I believe this is the magic math I seek. You calculate the velocity from your position and trace it back using a formula like this. I need to review the code a bit more to tease out where all this happens.

[happul3]

I can't say I understand meaning of four arrows in your drawing, so I'll respond generally about roll.
For clarity, we need to make a distinction between roll itself and transitions to/from roll. Let's ignore transitions for a moment.

During roll itself one wingtip is higher, other is lower. This static tilt will be register by acc exactly the same way wherever it is mounted on airframe. Agreed? The other element to roll is circular motion (the actual purpose of roll . The circular motion will generate different acc response depending on how close acc is to the center of rotation. The center of rotation is obviously not the center of airframe but some point quite far outside of frame. Because it is far (relative to airframe dimensions) the difference in acc signal dependent of its position is going to be quite small, and probably negligible. Also, for this particular motion there is nothing special about airframe center. Positioning acc there will produce signal large than produced by positioning acc at inner wingtip and smaller than at outer wingtip.

Now about transition to/from roll. That motion is basically _change_ in tilt angle. Acc will produce very different responses for that motion depending on whether it is in the center of rotation (in this case that is also close to center of airframe) or away from it. Is that what you are concerned about? Consider plane starting to roll from perfectly level attitude, lowering left wingtip and raising right wingtip. What will acc see? In addition to changing G vector (which acc sees identically wherever it is mounted), acc will register acceleration in direction perpendicular to G with magnitude dependent on how far acc is mounted from center. You might say that acc will be fooled during transition because it sees combination of G and this additional vector and the software might infer incorrect tilt angle. But I remind you that this is only during transition that acc produces seemingly incorrect reading if mounted off-center. As soon as roll angle is established, acc reading becomes accurate. So it should not be a problem. But wait, there is more. Multwii code is actually far too smart to be fooled by this extraneous acceleration due to angular motion. It relies on gyro to determine rapid changes in attitude, while acc (through complimentary filter) is only allowed to affect estimated attitude slowly, hence it is a non-issue even during transition.

I hope I have not miss something here, but if I did please let me know.

Edit: I think I finally understood part of your drawing. It is vertical movement of the off-center acc resulting from tilting, isn't it? I think it is going to have even small effect on acceleration vector acc sees, so I neglected to discuss it. Nonetheless, the same arguments to why it would not matter apply: 1) It is only transitory effect, affecting transition to/from roll, and becoming exactly zero when roll is established and 2) it has negligible effect on estimated attitude calculation, at least the way it is implemented in Multiwii (it may have non-negligible effect on calculations associated with altitude hold, but that is not relevant for planes anyway, right?)

[Maine_Guy]

It is vertical movement of the off-center acc resulting from tilting, isn't it? I think it is going to have even small effect on acceleration vector acc sees, so I neglected to discuss it. Nonetheless, the same arguments to why it would not matter apply: 1) It is only transitory effect, affecting transition to/from roll, and becoming exactly zero when roll is established and 2) it has negligible effect on estimated attitude calculation, at least the way it is implemented in Multiwii (it may have non-negligible effect on calculations associated with altitude hold, but that is not relevant for planes anyway, right?)

Yes, the exaggerated vertical movement was my concern in that example sketch. If the FC was mounted in the center VS the wingtip, they are going to see different accelerations during a turn. Maybe I'm over-thinking this and the distance issue would be negligible. I reviewed the IMU code - although well commented with links, the math there is beyond me at the moment (rotation frames and 32 bit conversions!).

I'm debating putting a FC / accelerometer 30+ inches above the center of the airframe. Seems like there would be some issues with the control of the device with that distance.. but perhaps not.

A very solid altitude hold is what I'm trying to achieve. I've hacked into the alt hold routine and modified it to work on my plane. So far, it works fairly well, even holding altitude in turns.

[Maine_Guy]

never mind.....

[QuadBow]

You try to get rid of systematic and measurement errors. There is an algorithm available for this purpsoe since the first Apollo mission.
It is the famous Kalman Filter Algorithm http://en.wikipedia.org/wiki/Kalman_filter.

But, there are many calculation required. For a real-time system like a copter it is impossible to run this algorithm on a 8bit processor.
The algorithm prefers floating point multiplication. So, even the 32bit based ARM processor used for NAZE might be too weak...

[happul3]

Yes, the exaggerated vertical movement was my concern in that example sketch. If the FC was mounted in the center VS the wingtip, they are going to see different accelerations during a turn. Maybe I'm over-thinking this and the distance issue would be negligible. I reviewed the IMU code - although well commented with links, the math there is beyond me at the moment (rotation frames and 32 bit conversions!).

I'm debating putting a FC / accelerometer 30+ inches above the center of the airframe. Seems like there would be some issues with the control of the device with that distance.. but perhaps not.

A very solid altitude hold is what I'm trying to achieve. I've hacked into the alt hold routine and modified it to work on my plane. So far, it works fairly well, even holding altitude in turns.

Yes, you are greatly over-thinking the issue. Look, the IMU code is conceptually extremely simple. It just uses gyro input to keep track of fast changes (millisecond timescale) in tilt of airframe relative to G. It is simple addition of three components of measured G vector with three components gyro reports. Happens every ~3 ms. Changes are small, hence it is a reasonable approximation. But it will drift eventually away from true value. That's where accelerometer comes in. Important to understand that it is used NOT to estimate acceleration (first derivative of velocity), but angle of airframe relative to G. It may seem like an redundancy (essentially the same information IMU gets from gyro), but it is not. Acc is much more noisy for angle estimation and may be affected temporarily by acceleration, but it does NOT drift the way gyro does. So the IMU mathematically fuses these two sensors to generate angle information that is both capable of quickly reacting to rotation and yet does not drift away. This fusion is done by "complimentary filter", which is a fancy name for simple arithmetical addition of two values, each multiplied by a fraction, as in 0.99*sensor1 + 0.01*sensor2. In principle, there are better ways to fuse sensors (Kalman filter for example), but I am not sure the improvement would be noticeable in this particular case. Ardu software may use Kalman filter for sensor fusion in 32bit ARM version, but I do not recall substantive reports of improved handling.

Anyways, for what you were asking about all this is irrelevant. No filter including Kalman can solve your problem because there is nothing to solve. Once you understand what IMU does you should be able to see that off-center positioning should have negligible effect. Just go through all the elements of motion and see for yourself what effect it will have on sensor output. I tried to provide such analysis in previous post, but that did not seem to help. So you'd better do it yourself before offering money for nothing.

[Maine_Guy]

Thanks for the explanation happul3. Appreciate the detailed response and shedding light on this subject.

Trying to understand the code and basis of IMU operation is pretty intimidating. The vector math and translations are not exactly simple. Impressive actually.

I've read several places that stress the importance of putting the FC in the center of the airframe. I was worried the distance involved here (30" from center) would cause weird flight issues.