Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proper handling of BODY_TO_IMU in all AHRS algos #93
Currently you can't really use IMU_TO_BODY to set a totally different
e.g. for ahrs_float_dcm:
Luke Ionno wrote on the mailing list:
Was very briefly discussed already a while ago:
This only solves part of the problem, e.g. in ahrs_update_accel the
This can all be fixed of course, but I guess the question still is
some more constraints to the problem:
e.g.1: on Lisa-M, the long side of the board happens to be the roll axis,
(sample of a case where you really want to run the ahrs in body)
In essence: any filter with more than pure kinematic model only (e.g. the
e.g.2: on the quadrotor the imu is mounted at 45 degrees ... rotating the
e.g.3: we update the imu-2-body during a tuning flight: I do not think
what about introducing an AHRS frame;
imu2ahrs (hardcoded) is done on RAW(*footnote1) IMU data
In most cases imu2ahrs will be as simple as channel allocation and sign
Moreover I think in the future this approach offers most advantages for
footnote1: I would prefer to rotate imu2ahrs on raw data in order to have
On Mon, Nov 28, 2011 at 7:56 PM, Felix Ruess <
As @dewagter said:
I get what you are trying to say, but if the roll axis = long side of
While this is basically also what I do in my trainer, we want to avoid to tell
I disagree here, you can also just transform into the imu frame...
I'm not really fond of doing integration and bias estimation in body frame.
E.g. if you integrate at a high rate in body frame, you
For bias estimation it's hard to specify a proper bias model
As you normally only make small adjustments in the air, I guess that in most
Hm... maybe not such a bad idea, but I'm not totally convinced...
Raw values are only ever used for debugging and calibration... ahrs
I still don't really see the advantage of running the ahrs in body
As stated above I think that if you run the whole ahrs in imu frame there will
To me that is actually the only advantage of running the ahrs in body frame,
So IMHO the proper way to do things is to run the filter in IMU frame
Raw and scaled values would have the same coordinate frame, the actual
On Tue, Nov 29, 2011 at 1:01 PM, Felix Ruess <
sorry badly phrased. in any case with aspirin 1.5 things are not good in
Now in all our quadrotors RAW and CALIBRATED data are NOT in the same
That was the motivation to call the intermediate coordinate system:
6 additions only for 90/45 deg
only in 45 deg mode
Well, let me put it this way: if you have simple 90 degree rotations, then
And I think it's better to define a IMU2AHRS of -90 deg than to define
Well I almost 100% agree, except for the 1 detail: I would like to make it
Idea: when possible run the ahrs in body. (I can not think of a reason NOT
interesting issue: how to prevent people from first calibrating and then
Huh? If you look in the ImuScaleX macros (subsystems/imu.h) , you can clearly see that currently there is no rotation/transformation, just the scaling/neutral. The only exception I know about is for mag when you have IMU_MAG_45_HACK defined.
I don't see the fundamental problem here... the filter should just not assume that ahrs-x direction is the same as body-x direction, and since you know the body2imu rotation. Of course you have to change the ahrs code and it's not so easy/clear anymore...
Well, but 90/45 degrees are special cases, and why should we limit ourselves to these special cases again?
Sure, totally agree on the premise, but if we do that for IMU2AHRS why can't we do the same for the BODY_TO_IMU?
I totally agree that we need a simple way to deal with the common 90 deg mounting problem, without having to redefine channels manually. But I'm just not totally convinced that another coordinate frame (limited to 90 deg rotations if I understood correctly) for this and then adjust something "on top of that" is the way to go...
I did a very brief review of some of the AHRS algos:
at the end of imu code:
if LISA_M // 24 mounting options per board
hm.... I really don't know how to best do this.. this will screw up your calibration again.
Looking at this from the other side:
So while I certainly agree that it can be annoying to have the imu values not rotated, is it really such a big issue?
Of course a nice solution to set the imu orientation for these common cases of 90,180 deg rotations would be good, but IMHO there are more drawbacks to this than benefits:
All that being said, if anyone really wants/needs this we can still add a hack, and people can use that hack if they want or not. Personally I'm just not convinced it is worth it... but you are free to disagree and add that of course!
oh: I totally forgot about "int_cmpl_euler": since that wasn't fixed since the brief review I posted earlier, it still applies:
The int_cmpl_quat has significantly different filter gains and thereby
On Mon, Feb 20, 2012 at 2:02 PM, Felix Ruess <
True, I get the problem... as I said, feel free to add a hack for the time
AHRS_GRAVITY_UPDATE_NORM_HEURISTIC like in float_cmpl would probably help
Also maybe we should make the gains configurable anyway? At least for the
Also regarding input filters, it would probably be nice to not re-implement
On Mon, Feb 20, 2012 at 2:37 PM, Christophe De Wagter <
The biggest "issue" we have is with faster planes and fast-period motions
On Mon, Feb 20, 2012 at 3:28 PM, Felix Ruess <
So if I understand you correctly these issues arise due the assumption we make:
If your velocity vector is correct, there should be no such problems.
It is not so much the speed that is wrong, it is the turn rate. The "model"
With no dutch roll or pitch oscillations the gyro measures just that. E.g.
But if you now add a fast period motion eigenmotion of only 150 deg/sec
The same happens in an aiframe with 20m/s2 vibrations from the
When vibrations are higher than gravity the filter even could temporarily
Filtering the accelero + GPS*gyro to get rid of eigenmotions and airframe
Hm.. I still don't understand why the turn rate would be the problem. Isn't it the speed vector that is wrong? I mean if you had the correct speed vector (NOT assuming speed was only in x-direction), then it should be correct.
Apart from noise or vibrations the gyro should measures the turn rate just fine. 150 deg/sec should be no problem at all, no matter if they are eigenmotions and oscillating or not. The dutch roll or pitch oscillations are slow enough to measure properly with the gyros...
I get what you are saying about the resulting error you get... But as long as you don't run into the gyro limits (or have serious vibration issues), it is not really the the turn rate that is wrong, but it is actually the model using to compute the centrifugal acceleration.
I agree it could help if you low-pass gyro measurements a lot for our filters (complementary and the like).
If you write a proper INS Kalman filter you don't (directly) have that problem. You keep an estimate of the velocity and you don't need to explicitly compensate for centrifugal acceleration. So there is no need for the simplified model from above.
Vibrations are a different issue...
On Sat, Apr 7, 2012 at 2:49 PM, Felix Ruess <
The vector not pointing the correct way is one source of error but not the
OK, I agree: I should have phrased it differently: it is the turn-rate part
Not to confuse: I would NOT filter the gyro's before integration, since
This is another problem. That problem is not handled here and will remain.
The [vx vy vz]' x [p q r]' as estimate for the kinematic acceleration
-GPS estimates the inertial speed very well. (only terms in the order of
In conventional fixedwings these errors are minimized when you estimate
You only get unwanted huge lateral accelerations if either the linear or
What we want to do in the accel update (in the filers we currently use) is
Sure, got that and definitely agree with you.
As I wrote above, I don't think this is a different problem. Imho the
No, you don't need a model at all! A strapdown INS is a purely kinematic
On Tue, Jun 18, 2013 at 6:26 PM, Felix Ruess email@example.com: