Does Arduplane switch to secondary sensor if primary fails?
I believe it doesn’t (i can not find any info). Anyway it could be useful to have a second one for reference.
It does if the fault is detected, you can use EKF lane affinity so different lanes use different sensor instances.
1 Like
Reading this i can not fully understand.
I have a can arspd sensor and an I2C one.
Will the switch between them be automatic if a fault gets detected in the primary one? Or should i set something?
Does this works the same with gps and barometers?
I see i can switch manually using an RC switch, but i would like it to happen automatically also, if needed.
The issue is that the system only switches when a probe is flagged unhealthy, and quite often a bad reading (for example caused by rain partially blocking the pitot tube) isn’t enough to trigger that switch. If the airspeed ends up being overestimated, that creates a real stall risk.
Personally, I wrote a Lua script to force the switch from one probe to the other whenever the difference between the two becomes too large (> 3 m/s). The idea is to force—if it isn’t already the case—the use of the probe reporting the lower airspeed. That way, worst case I underestimate the speed, which is safer, rather than overestimating it.
But it’s a bit tricky, because there’s no direct airspeed binding available in Lua scripts, so I had to add the required bindings in my custom-compiled firmware. Unfortunately, I haven’t found a better way to get a truly satisfactory level of redundancy for airspeed probes.
1 Like
Without affinity all lanes use primary sensors for everything but IMU as long as the sensor is reporting healthy. With affinity each lane uses it’s assigned sensor. If sensors used by the lane aren’t consistent lane confidence in its estimate will drop, triggering EKF lane switch. It won’t always be reliable as sensor malfunction may look like valid input ex. clogged Pitot probe appearing as change in wind.
1 Like