Open pjdewitte opened 3 years ago
Thanks for the report.
Connect an airspeed sensor after boot, e.g. by plugging it in on the UAVCAN network
Not sure how much of a general use case it is to plug in a sensor after boot. Is there a reason why you need to do it? If not, then I would assume that increasing the timeout before starting the selector to e.g. 5s would fix it for you, no?
Connect an airspeed sensor after boot, e.g. by plugging it in on the UAVCAN network
I included this as an easy way to reproduce; I agree that it is not a common use case. (I can imagine situations though, e.g. when you plug in devices one after another to distinguish between 2 identical sensors, so you can give them a fixed UAVCAN node id.)
Because the airspeed validator is structured such that airspeed sensors can become available and unavailable, I think it should handle this without edge cases. Increasing the timeout to 5s would make it work for our current setup, but I don't consider that to be the best and most robust solution.
In the end, in addition to the MAX_NUM_AIRSPEED_SENSORS
solution, we choose to replace the 2s timeout by a check that only runs the airspeed validator when we are pre-armed. I guess that is not generally applicable though.
Describe the bug When an airspeed sensor becomes available more than 2 seconds after system boot, the corresponding airspeed validator does not get the correct parameters until a parameter update occurs.
As a result, ASPD_SCALE_EST is not honored, and the aircraft starts to estimate the airspeed scale while it shouldn't. In our case, the estimate was sometimes wrong, so that we had to abort flights to avoid stalling or worse.
We believe this is especially relevant for UAVCAN-based sensors. We also get 2 warnings shortly after each other directly after boot, showing the airspeed selector started before the sensor was available:
To Reproduce Steps to reproduce the behavior:
Note: this behaviour was observed with v1.11.3, but I have no reason to think this behaviour has changed since then.
Expected behavior wind_estimate.tas_scale should be equal to ASPD_SCALE when ASPD_SCALE_EST is 0.
Log Files and Screenshots
The screenshot below shows the TAS scale from the relevant wind estimator. In-flight, we switched back to hover and adjusted a parameter before continuing. After that, the scale was correct.
Drone: Atmos Marlyn: tailsitter VTOL
Possible fix We're happy to make a pull request with the fix that works for us: In
AirspeedModule::update_params()
, loop over all validator instances (MAX_NUM_AIRSPEED_SENSORS
), instead of only the ones for which there currently is an airspeed sensor (_number_of_airspeed_sensors
).Alternatively,
AirspeedModule::update_params()
could be called when an airspeed sensor is added. Personally I think it is better to initialize all the airspeed validators as soon as they exist, as that is more robust.We also increased the initial timeout before the airspeed validator starts working, to avoid the warning messages right after boot. For our airspeed sensor it takes 4.5s to become available. If anyone can think of a more generic solution, we're happy to contribute to that as well.