PX4
AirspeedSelector: remove @volatile from the ASPD_SCALE params
This flag prevents the params from being loaded from a param file. Originally it was thought that this scale was more airspeed sensor specific, but it has shown that it's mainly the position of the pitot on the vehicle that influences it, and thus it's similar for a model and should be passed to new vehicles.
Changelog Entry
For release notes:
Improvement: remove @volatile from the ASPD_SCALE params
Thanks @sfuhrer definitely it is location. We see similar scales regardless of sensor type (wind needs to be limited - will open an issue on that).
This could be fine if the parameter is actually not changing flight to flight.
Maybe bump the threshold here to something meaningful to avoid saving negligible changes (eg > 1%)?
https://github.com/PX4/PX4-Autopilot/blob/8dc3975456d3096b114f4e5adbd528859da9e6e1/src/modules/airspeed_selector/airspeed_selector_main.cpp#L400
What is the problem with this changing in flight and not being volatile?
My biggest issue with this is that in high wind (which is relative) this param changes to unrealistic values.
What is the problem with this changing in flight and not being volatile?
It screws up the param transfer hash. It's not a big deal I just wouldn't have it change the param literally every flight if there's no real change (eg 0.00001).
My biggest issue with this is that in high wind (which is relative) this param changes to unrealistic values.
That sounds like a real bug beyond this simple parameter issue. The updating of the parameter could be more much conservative.
What is the problem with this changing in flight and not being volatile?
It screws up the param transfer hash. It's not a big deal I just wouldn't have it change the param literally every flight if there's no real change (eg 0.00001).
Noted with thanks.
My biggest issue with this is that in high wind (which is relative) this param changes to unrealistic values.
That sounds like a real bug beyond this simple parameter issue. The updating of the parameter could be more much conservative.
I don't know if it's a bug per se but it certainly isn't right. For instance (and I have logs of this), the scale is never higher than 1.2-1.22ish but in high wind (>8 m/s) and longer flight times (>20min), aka not 2 min flights, the scale goes up to 1.27-1.28. That just becomes a concern because if it increases enough you run the issue of stalling... So what happens during 1h+ flights was the thought. We just turned it off... Same setup flying in no wind brings scale back to 1.20-1.22, etc.
What is the problem with this changing in flight and not being volatile?
It screws up the param transfer hash. It's not a big deal I just wouldn't have it change the param literally every flight if there's no real change (eg 0.00001).
Noted with thanks.
My biggest issue with this is that in high wind (which is relative) this param changes to unrealistic values.
That sounds like a real bug beyond this simple parameter issue. The updating of the parameter could be more much conservative.
I don't know if it's a bug per se but it certainly isn't right. For instance (and I have logs of this), the scale is never higher than 1.2-1.22ish but in high wind (>8 m/s) and longer flight times (>20min), aka not 2 min flights, the scale goes up to 1.27-1.28. That just becomes a concern because if it increases enough you run the issue of stalling... So what happens during 1h+ flights was the thought. We just turned it off... Same setup flying in no wind brings scale back to 1.20-1.22, etc.
I'm a bit surprised that you find 5% variation an issue, I doubt that airspeed can be measured more accurately with our cheap pitot s we generally use on drones.
5% variation in a high wind condition is also what we roughly experience, e.g. here in a 1.5h flight with winds up to 15m/s:
If the degradation of your airspeed sensors (e.g. due to dirt in the pitot) over time is less than 5-10% then you may be better off with only estimating the scale once in calm air.
The constantly adapting scale may also help to compensate for small physical measurement errors due to changing conditions like temperature, density and humidity (I haven't verified that but I wouldn't be surprised if those effects also contribute to more than 5% variation).
It screws up the param transfer hash. It's not a big deal I just wouldn't have it change the param literally every flight if there's no real change (eg 0.00001).
I was not aware of that. I originally had an update cliff of 1% but removed it in https://github.com/PX4/PX4-Autopilot/pull/20764/commits/98c8d801af9916e4db9983c585c5733d86e7a103 as I didn't see the purpose of it. And anyway, if the cliff is 1% than still 90% of the flights have a update larger than that. What is the parameter transfer hash exactly about? When is it used?
Dev call: Make a threshold for saving changes of 3-5% and then it shouldn't change every time -> not volatile.
