UAVCAN Compass: appearing as compass 2

[rmackay9]

We have a report in Copter-3.6 beta testing in which a user has 2 UAVCAN GPS/Compass module's attached. There are two slightly unusual things happening:

• this message appears twice in the logs "GPS 1: specified as UAVCAN". I would expect the 2nd time it appears to be "GPS 2:"
• the UAVCAN compass(s) are appearing as COMPASS3. They are external so I would expect them to appear as the first compasses in the list.

This is the discussion where the issue appeared. The user has since deleted the log but I have a copy.

[EShamaev]

As for GPS, I have a plane with 2 UAVCAN GPS and they are enumerated and used correctly with blending. Can you please send me logs and version of firmware that was used.

As for compasses appearing at the end of the list - that is true. UAVCAN compasses are enumerated after all other compasses, so they get added the last. This was discussed during implementation.

[rmackay9]

@EShamaev, thanks for looking into this. Here's a link to the log.

The firmware version was Copter-3.6.0-rc12 but I strongly suspect the same issues happen with master.

[EShamaev]

I could not recreate the problem.

According to log, there are severe problems with GPS

For messages, it's even more strange as this message is coded in GPS_Backend.cpp that is common to all GPS's and not UAVCAN specific. That number is taken from state.instance

For example GCS messages from my last log: MSG, 15980008, GPS 1: specified as UAVCAN MSG, 15980063, GPS 2: specified as UAVCAN

There might be a chance that both GPS's have same node ID on CAN bus, but that is shown only in terminal messages.

My recommendation is to check node ID on both GPS and find out what is going on with first GPS receiver and if the problem persists, evaluate further with logs from the terminal.

Update: with debug level 2 it might be also possible to understand what's going on. However as I understood from conversation on forum, the person resigned from discussion.

[EShamaev]

The situation on compasses needs to be discussed again, however. Now being external, the UAVCAN compasses are still enumerated in the very end.

I was already thinking what can can be done as:

• number of compasses limited to 3 is not enough already in many use cases
• compass identification is not ideal
• calibration of compasses for large frames is painful

I would be glad for any input about this

[rmackay9]

@EShamaev, I think we should talk about this perhaps with @Tridge on or before the next dev call.

For the last point we've got the new inflight compass calibration method, it just needs to be documented.

Thanks again

[highfreq]

Node id is 42 and 43, i know dynamic id is not assigned so i set them.

[highfreq]

Finally looks like compass handling is recognized to be painful and not ideal, 3 compasses is not enough.......looks like important things are getting into consideration, that is great!!!!

[highfreq]

Just on a side note, uavcan compasses being the last to be picked up, the second one will never work with FC that has 2 internal compasses (cube 2.1 for example). This important misbehaviour was reported and ignored months ago. Maybe when Here 2 GPS will put out their UAVCAN firmware and people will start to use UAVCAN gps on a much larger scale it'll be obvious that has to be solved. I hoped it could have been done before that but looks like it is not the way it works.

[rmackay9]

@highfreq,

Txs for the feedback. I don't have answers for all the issues but it is actually possible to completely disable the Cube's internal compasses using the COMPASS_TYPEMASK parameter which would probably allow the 2nd UAVCAN compass to appear. It is difficult for user to use this parameter though because we don't tell the user (in an easy way) what compasses they have. I'll try and get this added - I can do part of that and MichaelOborne can do the other part.

[rmackay9]

As a side note, here is a requested changed to MP to decode the COMPASS_DEVID parameters so that users have a better idea of what compasses are being used.

[highfreq]

Have to find what is the hardware of the second on board compass. I know one is the same hardware as the external so i can't disable the driver, otherwise also the external would not work. Probably disabling the second on board will make space for the second UAVCAN. Now i need to understand what is the hardware i want to disable. Obviously Compass_typemask as it is is useless for 99% of the users, QGC made a nice panel that everybody can understand and use.

[highfreq]

Oh, almost forgot, thanks for your support and Merry Christmas.

[Naterater]

For what it's worth, it appears that compass 3 z-values do not keep the same trends that the other compasses do. The X-Y values are fine (just offset a bit from one another).

[Naterater]

X and Y charts here:

[highfreq]

I have read the devcall on the forum and it looks like my log is really scary. I would like to understand what the problem has been and patch it. If somebody feels the UAVCAN gps are the root of the prob i'll take them off. Even if i am no longer on the Ardupilot Discuss forum, i can still test whatever patch would come out and feed any kind of info that may be needed. This is the part of the devcall that scaries me:

Horrible thing is that the EKF failsafe didn’t trigger

40 seconds for the EKF failsafe to kick in and land the vehicle

https://github.com/ArduPilot/ardupilot/issues/10095 2

Perhaps Lane-switching is delaying ekf failsafe triggering?

Compasses are a mess

But actually using mag3

Scariest bug we’ve seen in a long time

Corrado

[IamPete1]

No new reports, this area of the code has changed significantly, so unfortunately I don't think there is much more we can learn from this issue. I think we should close, @rmackay9?