This is a problem that I’ve been wracking my brains over for a while and I just can’t seem to work it out. Even though it’s not strictly an support issue, I’m posting in the hope that some of the clever brains here can help me out. I want to be able to install the AltIMU-10 into my model aeroplane in any orientation and then calibrate it later so it works normally. I’d like to do this because it’s hard to perfectly align the tiny AltIMU axis with the aircraft. This is the AHRS code
I thought I had already solved the installation offset problem already but it seems I have only partly solved it. What I’m doing is storing the orientation of the AltIMU when the airframe is pointing north & level. This gives the installation offset/error.
Every iteration I’m then multipling the inverse of the installation error by the AltIMU orientation. What I’m seeing is that the gyros rotate around the wrong axis. For example, pitching the aircraft up and down will cause the heading to rotate. But after a few seconds the accelerometers & magnetometers pull the AHRS back so that it shows the correct orientation of the aircraft.
So this tells me that I need to somehow rotate the angular velocity vector from the gyros so the axis of rotation align with the aircraft not the sensor. I just don’t know how to do that.
Please if anyone can assist I’d greatly appreciate it. And if my question was too vague, I can post a video to youtube demonstrating the issue.
I don’t mean to be too critical, but alignment of the sensor and body frames is a really, really basic issue and not something to be tacked on after everything else is done.
My approach is to put a 3x3 rotation matrix right into the routine that returns the raw measurements from each of the three sensors, which aligns the sensor axes with the vehicle body axes.
In many cases that simple operation can be accomplished by permutation and reflection of the axes. However, a 3x3 matrix can also correct for gain errors, slight misalignment of the sensor and cross-correlations between sensor axes. An additional vector may be required to correct for offset errors. My favorite procedure for correcting magnetometer and accelerometers is described here: sailboatinstruments.blogspot.com … ation.html
I reviewed what your code is doing with the offset quaternion and it looks fine to me. Your code multiplies by the offset is the very last step before output, and that value is not feeding back in to other computations, so it should not cause this conflict between the gyros and the accelerometers that you are seeing.
One thing to note though is that quaternion multiplication is not commutative. On the line that multiples offset.conjugate() with rotation_buf you might need to switch the order of those two things, but still that should not cause the problem you are seeing.
As a basic test, does your system output get very close to the unit quaternion right after you run the “set_offset” command?
If you comment out the code that applies the offset, do you still see this behavior where the gyros give bad results and the accelerometer and magnetometer slowly correct it?
You are right, the code I linked to does not cause a conflict between gyros & accelerometers. I’ve been trying a lot of different things to get the AHRS working as I I’d like and I got mixed up.
Anyway, multiplying the inverse of the offset by the rotation_buf doesn’t work because, although it rotates the orientation, it doesn’t change axis of rotation. So it only works if the axis of rotation are parallel with the axis of the aircraft. What I mean is you can mount the IMU upside down, back to front, or whatever but this method only works if the IMU is square with the axis of the aircraft. If it isn’t square, then there is some fusion between the axis. So rotating around the z axis (changing heading only) might result in some rotation around the y axis for example.
If I rotate the acceleration / magnetometer vectors by the offset quaternion before they go through the complementary filter, then I get the situation where gyros cause funny rotations and the accerometers / magnetometers slowly correct it. In other words I can get the system to work as intended if I ignore the gyros.
I think if I can rotate the gyros in a similar way then the IMU will work in any orientation. But it seems that working out how angular velocity translates to a different set of axis is challenging.
Your code, since it was based off of mine, should be treating the X, Y, and Z axes equally. I don’t understand why you are seeing special behavior that makes the axis of the aircraft be more special than any other axis. Unfortunately, I don’t have any advice on what to do about it.
To belabor my point, if you get the sensor/body orientation correct and self consistent to begin with (including small misalignments), no kludge needs to be added on after the fact.
David - I’m struggling to explain it clearly. It does treat the axis equally but it doesn’t seem to apply rotations as I expected. I would make a video to demonstrate it but it’s probably not worth anyones time thinking about this problem at the moment.
Jim - I get it and that’s what I’ve ended up doing. I still think it would be better to ‘calibrate’ the sensor orientation rather than try to line up a tiny little AltIMU by hand while the glue dries and everything. But it’s looking like a complex problem and perhaps it’s not worth the effort.
This has moved to my personal ‘too hard for now’ basket. Thanks for the input though guys.
