Idea for reducing frustration with compass prearm failures

We’ve been getting an increasing number of reports of frustration with the inconsistent compass prearm errors. A good example is a recent log from Luis:


he is on a pixracer which has 3 compasses, one external and two internals. The two internals are a hmc5983 and the mpu9250.
The 2nd compass (the internal hmc5983) is way off compared to the other two. Compass one and compass three are nicely consistent. All Luis gets is a “PreArm: inconsistent compasses” message, which leads him into a never ending cycle of re-calibration as he tries to get the 2nd compass to produce a good result. It is highly frustrating, and also completely unnecessary as he has two good compasses.
I think what we should do is:

  • if we have consistency between the primary compass (as indicated by COMPASS_PRIMARY) and at least one other compass then don’t give a prearm error
  • at the time the prearm check is done, if we pass the “primary consistent with one other” test then we should automatically set COMPASS_USEn to 0 for any other compasses that are inconsistent
    that will allow a lot more people to fly without frustration, while still ensuring that people who have multiple compasses will have a backup.
3 Likes

Sure, sounds good to me.

I think it’s a good idea in general, but I think we should attempt to inform the user, or require them to disable the misbehaving compass.

Imagine the scenario, exactly like this, where the 3rd compass use is set to zero. Then, imagine something goes wrong with one of the other two compasses. And through an unfortunate series of events, leads to a crash. We’ll get criticized for having turned off a sensor without notifying the user.

Would suggest the compass is temporarily ignored until the user sets Compass_useN to zero. Possibly with a message. “Armed. Warning: Ignoring Compass N”

I like the idea and to complement what Rob said, setting the COMPASS_USEn should be only for the current running, not permanently saved.

The other issue is the bulk of our users only have 2 compasses and they still get the issue. I’m wondering if there is a way we could get them to choose which compass they want to use. Can we ask them to point their vehicle North taking special care to get it as accurate as possible and then show them the offset of both compasses and have them choose which one is closest to North - or we could do that choice automatically of course.

This doesn’t give them any fallback should the compass they are using have an issue HOWEVER if they simply can’t calibrate them it does give them an option to get the vehicle operational. The questions is how many users would simply choose this anyway and forget trying to magcal and get 2 compasses to agree.

Just thinking out loud.

Thanks, Grant.

Are we able to set parameters temporarily already? I believe that was an issue.

I’m not aware of any problem with that, but I don’t really know.

Hm. Yep. I think I’m just confusing stuff. Sorry for the noise. :slight_smile:

I don’t think that’s fully satisfying yet. I generally actually think that the concept of consistency, when it comes to the compasses, isn’t any good.

The point is that compasses are about the most nasty sensors around, for all their sensitivity to everything (IMHO. I consider that a true statement, if you don’t agree it might not be worthwhile to continue reading my thoughts).

So, e.g., I would never assume that an internal compass is better than an external. In the above suggestion it however could happen that the two internal ones nicely agree but disagree with the external, even though the external in fact might be the much “better” one. The edge case of just two compasses has been mentioned. Generally, asking for consistency between an internal and external compass is IMHO equal to asking for troubles.
So, I would change the philosophy to ranking the compasses by some goodness, and base judgments based on how it ranks, consistency would be irrelevant.

This rank should be determined by the outcomes of the calibrations, and external vs internal (you might also invent some in-flight learning feature, e.g. by measuring the general consistency with the EKF heading, and so on, but I only mention that here without discussion to indicate that the concept has some future potential).

I’ll just consider the case of one external now, extension to more is obvious.

I would place the external on top, BY DEFINITION!, since there is only one external it must be the primary, and the internals depending on their calibration quality. The copter would always only rely on the best compass, which here would be the external compass, but of course switch over to the next best ranked & healthy compass in case it becomes unhealthy, and so on. So, consistency is substituted by rank and health. Prearm-check means checking the health, especially of the primary.

The role of the calibration also changes, but I think in a way which is much more transparent, and thus amenable to users. The outcome of a calibration is also a goodness. So, the user does not have to bother with which compass is external, internal, primary, or which one is actually used (from what I see reported this seems to be one constant source of confusion and frustration with the current procedures). He/she gets a set of goodness, along with some information if that’s good or bad, if it’s acceptable for an external compass, and so on, and is taught that at least the primary must be all good. Importantly, a calibration basically would never fail (which seems to be another constant source of confusion and frustration), it’s just good or bad, with whatever refinements you deem relevant. Cases where it’s not healthy or really out of question of course should be handled also. These comments also affect the on-board calibration, those strictness - which I personally find a bit over-engineered - seems also a source of frustration.

I’m not saying that this is all fletched out and ready to go, please fill the gaps with common sense. I do think however that the issues with the compasses, and there are IMHO more than one currently, have a deeper reason lying in the structure of the approach.

Cheers, Olli

2 Likes

Without reading all this, problems like this can be solved maybe by calculating the baseline by a second low-pass filter with low cut-off frequency (e.g. 0.05-0.1 Hz). If you then remove the baseline from the signal, the signal will be aligned to zero. However I am not sure whether it will interfere with the heading estimate. Maybe one can do this baseline correction once when the compass’ are calibrated.
edit: I think one can also use a low pass filter to constantly calculate a scaling factor among all compass’. This might be the smarter solution.

I agree with Olliw42. Fact is the on board compass will always be affected by the currents flowing on the board. The on board compass should be seen only as a convenience but will never be anything like as accurate as a well sited external compass. Since Pixracer has a lot going on on a very small board, the problem is exacarbated, so specify that an external compass is recommended and if detected, it is assumed to be sited as far away from sources of magnetic interference. If an eternal compass is detected, that will be used as the primary compass, and on board compasses will be ignored., since the whole idea of an external compass is that it can be located away from sources of interference.
So connecting an external compass is the user saying I have a better compass which I wish to be used in preference to the onboard compass(es)

I can’t agree more with Olli.
We fly copter still with 3.2.1 and they fly great. But the moment we install 3.3 we got compass variance and so on.

For sure that compasses are not agreeing but it is interesting to see it flying well with a more “simple” ahrs than with the more complex EKF.

So maybe trying to make compasses readings agree is a no-no and it may be better to implement something as @olliw42 explained.

Compass issues are coming from EKF introduction and while not blaming EKF (cause it is clear it is the way to go), some attention and rethinking should be made on this topic.

By the way, 3.4 rc4 has improve the chances to get the compass variance message. But it still appears sometimes.