EK3_SRCn Explanation

ArduRover
1

In this documentation I am unable to fully understand how the EK3_SRC parameters are meant to be set.
https://ardupilot.org/plane/docs/common-ekf-sources.html

If I have 2 GPS do I set both EK3_SRC1_xx and EK3_SRC2_xx parameters?

Thanks

2

I had a different situation, where I wanted to use GPS as primary altitude source, with baro as fallback. I had a look into the code (I’m not an Ardupilot developer, so I could be wrong). Here are my conclusions regarding my scenario as well as your dual-GPS situation.

EK3 seems to only use the primary GPS. EK3_SRC2 is used in two scenarios.

  1. When EK3_SRC_OPTIONS:FuseAllVelocities is enabled, then it will try to use GPS when it is assigned to any of the EK3_SRCx parameters.
  2. When EK3_SRC_OPTIONS:FuseAllVelocities is disabled, it will only use the manually selected EK3_SRC, which is always 0 unless the user RC imput is configured to manually select another EK3_SRC.

There is a hardcoded baro fallback, in case the GPS accuracy is not deemed acceptable, it will always set the height source to baro.

So in your case, if you have good GPS (e.g. RTK), set SRC1_VELZ to GPS, SRC1_POSZ to Baro and set all other SRC to 0.
It will then try to use your primary GPS for velocity control, and fallback to baro. And baro will be used for absolute height. I think Baro is recommended as POSZ because it is set to 0 at takeoff, so it is a more intuitive height reading.

If I am wrong, somebody please correct me. It is quite complicated. The documentatioon explains that there is a baro fallback for the deprecated EK2_ALT_SOURCE: “Primary height sensor used by the EKF. If a sensor other than Baro is selected and becomes unavailable, then the Baro sensor will be used as a fallback.”.

So my conclusion is that the EK3_SRC1_VELZ and POSZ parameters could use some explanation. And the doc page at Using GPS for Altitude Sensing — Copter documentation implies that setting all EK3_SRC parameters to GPS will disable the baro callback, but based on the code for Ardupilot 4.3.6, it seems that the baro fallback is actually hardcoded, it will always set height source to baro if GPS accuracy was not deemed acceptable.

Maybe I can contribute to some revision of the docs, if all my statements are correct?

3

I am at 4.3. I use Ardupilot in Agriculture where I set alt sources using GPS as flying low with baro is a pain. Most of the time when GPS glitch, the craft just shoot to the sky with max out. there is no switching to use Baro at all because the altitude is just gone cause the craft to see potential thrust lost.

That is only experience.

4

During GNSS failure, the best option may be to switch to inertial navigation immediately, pause the mission and let the system attempt position hold using inertial sensors only. (Including baro, if it can be reliably used). If after, say, 2 seconds, GNSS is still not recovered and the system has no backup positioning method, I think the least-worst course of action the system has, is to automatically perform a slow landing. However, at this moment operator should take over manual control.

5

when it is lost GNSS. drone went to vibration because it maxed out flying up to the sky. it can help by switching to stabilize mode. but sometimes it is too fast to take control it falls from the sky in just seconds.

Most of our Agriculture drone users never been trained in stabilize mode. so we just take it as one of a thousand bad luck with GPS.