AC3.5-rc9 compass calibration constants can still be wrongly assigned

Hey Randy,

I open a new issue as suggested in the AC3.5-rc9 release post.

The issue: When the compass configuration changes after calibration has been done, AC uses the incorrect calibration constants.

This issue I’ve reported a while ago, in a thread where EShamaev heard it, and responded that it will be corrected. So, since 3.5 is close to be finished, I just tested it and find it still to not be working.

It’s extremely easy to reproduce, yet some details:

I have a AUAV-X2 plus an external compass. So, normally I do see two compasses, #1 and #2, with IDs ID = 466441 and ID1 = 131594. #1 is chosen as primary, and marked as external. Calibration sets some constants. I then disconnect the external compass and reboot. I do get a “Prearm: Compass not calibrated” warning. The IDs are set to ID = 131594 and ID1 = 131594. The calibration constants are exactly as before, i.e. DIA and OFS values are those of the external compass, and DIA2 and OFS2 are those of the internal. Compass #1 is still selected by the system as primary.

I’m not sure I understand why a “compass not calibrated” warning is issues, since in fact it is calibrated. I mean, it’s better than not to get any warning, but it doesn’t seem to be very accurate.

What concerns me most is that #1 is selected a primary. It indeed appears that the wrong constants are used. When I use both compasses, MP tells me that my vehicle is oriented at 22°, while when I have the external compass disconnected my vehicle is said to be oriented at 299° (without having moved the vehicle of course).

IMHO this should be a show-stopper for a release; I would consider this a serious safety issue. It e.g. means that if the external compass fails at startup and is not recognized, the vehicle will fly with wrong compass calibration. EDIT: I’ve learned that this isn’t accurate, see below.

Cheers, Olli

You’re disconnecting a compass, and it is recognizing something is wrong, and it is requiring recalibration. I’m not seeing what the problem is?? Perhaps I’m not understanding something, but this seems like expected and correct behavior?

i) external compasses can fail from one day to another for other reasons than me disconnecting it

ii) the whole idea of having compass IDs is defeated by not having linked them to their respective calibration constants

I don’t understand the underlying logic, but I could imagine that the correct behavior could be achieved by having the primary set to #2, such that it uses the correct calibration constants, and having #1 flaged as not used.

And if one fails, it will give you the same error and require recalibration. I’m not seeing where this is some big safety hazard. It isn’t associating calibrations with IDs. And it isn’t looking at it as “this id should be #1” It’s just telling you what the ID currently is. Compass 1, 2, and 3 are assigned in the order in which they are seen on power up. I2C is scanned first, which is why external ones are always first.

It is not a complex system. It would probably be better if you could assign them more specifically. And you could then troubleshoot easier. But it has never been that way. If one fails or is removed, it will see the calibration makes no sense and prompt for it.

it is as simple as that: I think a compass should not use calibration constants which it knows are incorrect. As simple as that.

You can debate that of course, but to me the statement is such simple logic that I’m going to continue to think what I just said I’m thinking.

:slight_smile:

What are you contending that it “knows are incorrect” and uses anyway? It sees the calibrations are no longer valid and forces the operator to recalibrate. What is not working properly for you??

1 Like

@olliw42,

I’m afraid I agree with Matt. The code recognises that the offsets are incorrect and so we flag this up to the user that they must re-do the calibration and the vehicle is prevented from arming (the user has the option to override the arming check but then it becomes a conscious choice on their part).

If the user does a calibration then the correct offsets are used (or rather re-calculated by the calibration routine).

I think the current method is sufficient to be safe and I can’t think of a better solution immediately. If a compass fails the user is warned and prevented from arming. I’m not sure we would want to just silently search through the other offsets we have available and try and use them because then a compass failure could go unnoticed by the user.

We also don’t want to clear out the offsets because if it was a temporary failure (i.e. the user temporarily disconnected an external compass) we wouldn’t want to force them to re-do the calibration once they plug it back in again.

I generally agree with your statement, “I think a compass should not use calibration constants which it knows are incorrect.” but I would add, “in flight”. I think the code is doing a reasonable job of ensuring that incorrect offsets are not used in flight.

1 Like

thx for the replies

I do think that one can do better, let me give it a 2nd try

No one on earth ever would have two internal compasses with identical IDs attached to the copter, and I think this very clearly distinguishes the situation I describe from the situation you guys seem to have in mind.

Your way is kind of “Oh, there is a new compass on #1 which doesn’t match what it was before, so let’s issue a warning”.

my way is kind of “Oh, there is a new compass on #1, which doesn’t match what it was before, but, hey, I do know this compass already, I have it in my list as #2, so let’s issue a warning and use the calibration constants I know for that compass”.

In other terms, it doesn’t make sense to have two identical compasses in the system, with different calibration constants. And there is no need to override the earlier ones on #1, because they are already available on #2.

I do now agree however with you guys as regards the safety concern, I did overstate that, I have not fully comprehended the options offered by AP, they are, as you say, sufficient to be safe. Sorry for that (I have changed my first post accordingly).

But I continue to think that the behavior is not correct, or let’s say, far from optimal. A general logic probably could be that whenever a compass already known to the system appears on the wrong “port”, a more decisive action can be taken than what is done currently.

cheers, Olli

Ok, so say we have compass A’s offsets in slot 1 (aka “port1”) and compass B’s offset in slot 2. Then suddenly compass A is missing so B appears in slot 1. We could pull B’s offsets from slot2 into slot1… and then would we shift the offsets we’ve got for compass A into slot2 (i.e. swap them)? … and then would we allow arming and take-off as per normal, or would we still pop up a warning to the user saying, “something’s changed with your compass setup, was this intentional” and ask them to somehow confirm?

as said, I don’t know about the internal logic in the code, I just do see the results on the surface

I could imagine that it could be achieved by changing the primary to #2 (this parameter is probably there for a reason). Swapping the configs until those used are in sequence #1,#2, … with primary first (I also consider a #3 here) might be another approach. I don’t know.

Yes, sure, as said, a warning should be raised. And it could be more specific, something like “Compass Configuration has changed”, as you suggest too.

As regards what the user is then supposed to do I’m not sure. You guys have a broader vision here (as I just learned, see safety thing, LOL). I’m not sure if there is a concept of warnings with different criticality. It might also depend on the configuration. E.g. if I would have two external compasses and one internal, and one of the external fails I would not mind to fly. If I would have one internal and one external, and the internal fails, as a hobbiest I would also not mind but others might mind. If however in that 2-mag configuration the external fails, I would mind a lot. So, sorry, I don’t see an immediate, satisfying answer to that point.

Maybe I should add a bit of “history”, why I’m so after this. I in fact have 3 mags, the internal, a standard external on i2c selected as primary, and a third external on my DIY uavcan gps-mag node. With the current logic it seems that it chooses the internal mag when the external on i2c disappears, and this in addition with wrong calibration constants … even though I would have a perfect external one available. This just didn’t (and doesn’t) look right. What I want to emphasis is: We are not just talking about 2 mags (how many mags does PH2 have again?).

Cheers, Olli

I recalled that there had been the thread “Idea for reducing frustration with compass prearm failures” (Idea for reducing frustration with compass prearm failures), and the suggestion Idea for reducing frustration with compass prearm failures. I didn’t follow up and don’t know what finally was done, but having reread it now I actually find it relevant to the present thread, even though might not look so at first. I do see similarities in the lines of logic, which I could see fit together to a broader concept. Just wanted to point to that.
:slight_smile: