Everything solved, all great now

No point in discussing what is already perfect, sorry.

Corrado,

ArduPilot includes an EKF failsafe which is enabled by default and should trigger a Land in the case of a bad GPS glitch (some small GPS glitches can go undetected). The vehicle definitely shouldn’t fly 300 or 400 meters.

If you have a dataflash log (aka .bin log) we can have a look. I see the wiki page is a little out of date so I will update it later but in short the parameters are:

  • FS_EKF_ACTION = 1 to Land, 2 to switch to AltHold, 3 to trigger the failsafe and Land even if the vehicle is a mode like stabilize, acro or AltHold that doesn’t require a good position estimate
  • FS_EKF_THRESH = 0.8 <-- this can be adjusted to control the sensitivity

No point in discussing what is already perfect, sorry.

No point in discussing what is already perfect, sorry.

I agree with that on a general basis.

Why havent you switched to Alt-Hold manually?

No point in discussing what is already perfect, sorry.

Hi Corrado,

Thanks for the log. As you say the vehicle does fly a long way before the EKF failsafe switches the vehicle to Land mode so I’ve asked @priseborough (EKF expert) if he can give me a hand figuring out what happened.

I updated the EKF failsafe wiki page yesterday including the section about controlling the sensitivity of the check. It may be that setting the FS_EKF_THRESH to a lower value (like 0.6) will lead to the check triggering more quickly but still, I’m surprised it took so long to trigger.

A few things that worry me:

  • the vehicle is using UAVCAN GPSs. We see two two identical messages, “GPS 1: specified as UAVCAN” in the logs. I would have expected the 2nd one to say “GPS 2:”. I’m not sure we’ve done much testing of blending with UAVCAN GPSs although of course it should work.
  • we see a number of EKF core switches happening in the logs before the EKF failsafe kicks in. I worry that when we switch EKF cores, the “innovations” fall temporarily and this delays the triggering of the EKF failsafe. It may actually be safer to disable one core although I don’t think this is a good long term solution.

Just a few additional things I found while reviewing the logs:

  • The vehicle is using Copter-3.6.0-rc12 which is a beta version of the firmware which is very similar to the official released version but as a general rule, it is best to stick with the official releases unless you’re actively doing beta testing.
  • COMPASS_PRIMARY = 2 but COMPASS_USE2 = 0. I think AP will fallback to the next compass in the line (Compass3?) but it makes more sense to set the COMPASS_PRIMARY to the best compass on the system.
  • It looks like the flight modes on the transmitter are setup to Loiter and RTL only. It’s always best to have a more manual mode that doesn’t require GPS readily available for the pilot. Ideally that is Stabilize or AltHold.
  • vibration levels are a little high at 20m/s/s but it’s within the green zone (below 30m/s) so it should be OK.

No point in discussing what is already perfect, sorry.

No point in discussing what is already perfect, sorry.

you know, instead of saying, “it’s a big mess”, how about “I don’t understand this, can you please explain?”

1 Like

No point in discussing what is already perfect, sorry.

Done with help and testing :slight_smile:

As you wish… just FYI I’ve created this issue where we’re discussing the log.

1 Like

No prob, i am sure you guys will find another crazy person like me that will risk his machine to test UAVCAN stuff, probably much more polite than i am. When you guys will have solved all the compass and gps uavcan probs i’ll use it. No more risk taken from me :slight_smile:

It is about time to have some respect for people that help out risking stuff every day and reporting back issues, even if something is defined as a Mess (and it is) you should probably be a bit less touchy and consider what others have to say. This being said i am done testing stuff.

In the end, we are all very grateful to the work the devs do on the software to have it as great as it is today but without thousands of free beta testers it wouldn’t be what it is today, so some mutual respect would be much appreciated.

p.s. no wonder i went crazy trying to have my system recognize the second external UAVCAN compass…it will never happen, as i understand from a dev on github lately, UAVCAN compasses are picked up last by the system so if you have already 2 internal compasses in the FC, the second UAVCAN compass, being the fourth to be seen (or not seen i should say) by FC it’ll never work…what an undocumented mess it is :slight_smile:

This post was made 1 month ago, i was reporting how it was impossible to see the second UAVCAN compass. At time it looked like it was my fault being not able to configure it and obviously no problem was aknoledged at the time. Now it is clear that it couldn’t have worked because the undocumented support of UAVCAN gps/compass picks up the units as last in line…but hey we now have pixracer leds working :slight_smile:

1 Like