Is there ay news about UAVCAN GPS problem?

ArduCopter Copter 3.6
1

Is there by any chance some news about this problem?

Since i didn’t ear anything back i am kind of scared to keep flying the UAVCAN GPS.

The fact that UAVCAN GPS/COMPASS is picked up as number 3 doesn’t worry me too much but the anomaly about failsafe kicking in after 40 seconds of the failure really scares me and i was wondering if it has anything to do with the use of UAVCAN GPS.

2

I agree completely, we’ve been struggling with UAVCAN for years. It would be a great help to get dynamic node ID back in the code as well. The EPM gripper doesn’t facilitate static setting of node ID. The Zubax GNSS is a great piece of kit but there has always been a bit of a wrestling match to get it properly implemented with AP. Cheers RB

3

Hi Corrado,

Sorry for the slow investigation on that incident. I hope/expect that Tridge and I will do some more review in the near future.

I don’t think the EKF failsafe’s slow triggering (40sec) is directly related to the UAVCAN GPS/compass’s protocol. At the same time, I haven’t seen a performance comparison of these GPS/compass modules vs others.

4

Ok, thank you very much!!

Please keep me updated if you find something interesting on the slow triggering.

Corrado

5

@Corrado_Steri,

Tridge and I had a better look at the logs and concluded a few things:

  • Both GPSs are reporting very bad positions and velocities so the cause of the flyaway is just the GPSs. The compass is not to blame.
  • the EKF’s reported velocity innovations are extremely high so we think we can speed up the triggering of the EKF failsafe by enhancing the failsafe to look at how high above the threshold the velocity innovations are. I’ve created an issue here to capture this enhancement.
  • EKF switching is not slowing down the triggering of the EKF failsafe
  • A recently found bug in the EKF’s use of the compass is also not related
6

Ok great, thank you guys.

I think the GPS went crazy at a certain altitude (if you look at the logs the number of sats drametically decreases over a certain altitude) because of some kind of strong radio interferences due to the very particular place at wich we were flying.

Corrado

7

@Corrado_Steri,

Related to this issue, we’ve just merged a change that we hope will speed up triggering an EKF failsafe. The idea behind this change came after analysing the logs you provided from that horrible crash. It’s a sensitive part of the code and we need to be careful of false positives (i.e. the EKF failsafe could trigger too easily) so it likely won’t go out until Copter-3.7 because that will provide the best opportunity for extensive beta testing.

8

Glad it helped, quad didn’t crash it only gave us 10 very “interesting” minutes.
Wouldn’t be possible to give user the chance to choose what to do in an event like what happened to us?
For example i am now mounting a flow on the machine and as far as i know it should help in a situation like that, ignoring the gps and let me fly safely back. So in a situation like that i would like it to switch to flow hold for example.

9

It’s possible to set the EKF failsafe to switch the vehicle to AltHold by setting the FS_EKF_ACTION parameter. We could add other options as well. Theoretically with a flow sensor the EKF itself would use it in it’s position estimate and reduce reliance on the GPS but this needs more testing. I already know that there is at least one issue.

10

Ok i’ll set it to althold at the moment and see if issues with flow hold will be addressed in future

1 Like