Hello everyone,
I haven’t fully understood the AHRS_WIND_MAX and ARSPD_WIND_MAX parameters. Could you explain them in detail? How should I set these parameters for my vehicle flying at speeds of 25-30 m/s? What happens if I set these parameters to 0?
Hello!
In Plane, if you set ARSPD_WIND_MAX to a non-zero value, then you enable it.
If the difference between measured airspeed and GPS speed is greater than this, then this airspeed sensor can be marked as unhealthy and disabled, by also enabling the corresponding ARSPD_OPTIONS bit.
It is meant to protect you against a blocked airspeed sensor, showing a very low value.
So a reasonable value to set this to is greater than your maximum expected wind.
AHRS_WIND_MAX is similar, but instead of completely shutting down the airspeed sensor, it will instead clip/constrain its sensed value so as not to exceed this difference.
So if GPS speed is 10m/s, airspeed is measured at 20m/s and AHRS_WIND_MAX=5, then the airspeed value used by the system would be 15m/s.
Depending on your setup, you might want to use one, the other, or both.
or neither 
.
I have many years of experience flying fixed-wing aircraft and VTOLs, almost all of which were equipped with airspeed sensors. I don’t understand the logic behind trying to detect an airspeed sensor failure based on the difference between ground speed and airspeed. To me, this approach seems rather illogical:
Sorry George, but the relationship between GPS (ground) speed e.g. 10 m/s and an airspeed reading of 20 m/s isn’t a reliable indicator; the difference depends on windspeed and flying in tailwind, headwind or crosswind.
To illustrate: a wind speed of 10 m/s and an airspeed of 20 m/s result in a ground speed of 30 m/s withtailwind, 20 m/s with crosswind, and 10 m/s with a headwind. The absolute difference between ground speed and airspeed is then 10 m/s or 0 m/s, depending on the direction of flight. In my view, the usefulness of the difference measurement as an indicator of the sensor’s functionality depends largely on the ratio of airspeed to wind speed.
I enjoy flying in stronger winds (relative to airspeed), so I haven’t enabled those features at all, because they would indicate too many false-positive airspeed sensor failures.
Perhaps I’ve missed something — I’d be happy to be corrected.
Rolf
@Rolf, the typical mechanism to detect air data anomalies in more complex aircraft is to use redundant sensors and flag an error on an outlier. I’ve never seen anything do a ground speed comparison for this purpose. I suppose it’s an ok way to try and gain some failsafe behavior on a non-redundant system in a very benign environment, but I’m with you - I’d just leave these disabled.
I am in full agreement @Yuri_Rage. Here are a few ideas: Since version 3.7.0 beta 1, it has been possible to have more than two airspeed sensors. With three sensors, one is marked as faulty if its reading significantly deviates from those of the other two. I’m considering equipping a plane with three airspeed sensors to gather real-world data. Another option would be to compare two real sensors with empirical values derived from a combination of engine power, variometer readings, attitude and, if applicable, landing flap settings, using these as a third ‘pseudo’ sensor. However, this would require a few calibration flights in key situations such as cruise speed, descent or climb at a specific rate. For expensive aircraft, using three real sensors and comparing them via a LUA script seems more practical.
Rolf
@Rolf the triple redundant scenario you describe is exactly how it’s done on more complex aircraft (if not quad redundant). A single sensor failure is easy to handle. Dual or complete failures are harder to sense, and most of these systems come with warnings regarding those scenarios. Pending results of your Lua exploration, it’s probably worth pushing some actual firmware updates to align our strategy with industry.
I’m not saying that the current fault detection behaviour is state of the art. It’s… simple.
Here’s a scenario: You have a big bird, with cruising speed of 40m/s. You expect to get winds of up to 20m/s, thus set ARSPD_WIND_MAX=20. A blocked Pitot reporting close to zero airspeed at cruise, could thus be determined to be faulty, as the minimum airspeed vs groundspeed difference you could ever get would be 20m/s, not 40.
Does that make sense?
40m/s is a lot faster than most Ardupilot controlled fixed wing drones typically fly.
15-25m/s is a realistic value and this isn’t far away from stronger windspeeds at low altitude. The current strategy fails in this aspect.
If a very basic error check is needed, I think it would make a lot more sense to compare measured airspeed with synthetic airspeed.
And for more advanced planes the multi sensor approach is of course best (as suggested by @Rolf )
Mathematically, it’s correct, but in practice it’s of no use if the faulty sensor in your example reads just 1 m/s instead of 40 m/s. In that case, the failure won’t be noticed in a headwind—for example, during takeoff or on approach. The situation looks even worse for the other wind directions the weaker the blockage is.
In my experience, partial blockages of the dynamic line are the most common causes of failure. In my case, this was often caused by particles that only partially block the pressure line during the previous landing and ist unnoticed during the preflight check because the blockage is only partial.
In addition, in practice, the forecast of actual wind speed is likely to be very inaccurate for most people, which, in addition to the dependence on flight direction, increases the error rate (both false positives and false negatives).
The basic idea of a robust method would have been better if calculations had been performed using vectors instead of scalars.
I haven’t enabled the method either, but as a safety measure, I’ve added a switch on the remote control to disable the sensor use RCx_Option 107 “Disable Airspeed Use”.
As soon as it gets a little warmer here, I want to start recording data from actual flights.
Rolf
Thank you very much to everyone for your interest and for your answers.