airspeed architecture discussion

[dagar]

Rough notes for updating the architecture around airspeed, differential pressure sensors, the new wind estimator, automatic scale factor calibration, fault detection, etc.

Notes

• run a wind_estimator instance per airspeed (ModuleBase allow multiple instances of a module #9143)
  • how do we specify which airspeed it should be using? Parameter with device id?
• add estimate TAS scale to airspeed
• single system wide vehicle_airspeed?
• all differential pressure sensors need device ids and index calibration parameters
  • CAL_DPRESN_ID
  • CAL_DPRESN_OFF
• need to be able to start multiple instances of the same sensor (ModuleBase allow multiple instances of a module #9143)
• update calibration procedure for multiple sensors (add quickcal option while we're at it airspeed "quick cal" advanced option #8463)
• where do we calculate airspeed from differential_pressure?
• sdp3x specific differential pressure adjustments (currently in sensors) should be pushed into the driver
• worth keeping support for analog differential pressure sensors?

[acfloria]

sdp3x specific differential pressure adjustments (currently in sensors) should be pushed into the driver

The sensor specific one can be moved to the driver as it only works for that one configuration. The pressure drop compensation should be kept within sensors as it could be extended for any flow based sensor. The problem there also would be that the absolute pressure is required for the computation and I think that one is not available on the driver.

[dagar]

Ok, I'll go over it with you before anything changes. I thought this entire thing was specific to the SDP3x.
https://github.com/PX4/Firmware/blob/master/src/modules/systemlib/airspeed.c#L83-L143

[Antiheavy]

add estimate TAS scale to airspeed

maybe not exactly on topic, but if finding accurate TAS is thing here, shouldn't there be a better measure or way to calibrate outside air temp than currently exists? How does this work now?

[dagar]

Most of the differential pressure sensors we currently have drivers for report temperature as well.

[priseborough]

That will work if sensor is wing mounted. I have also seen them mounted in the fuselage with batteries and avionics. To support that type of installation, we could provide the user with the ability to set a field level temperature and use the standard lapse rate to estimate the OAT (Outside Air Temperature)

[CarlOlsson]

Regarding the airspeed architecture I think it is important to differentiate between the current best estimate of the airspeed and the measurement from the pitot(s). So somewhere (e.g. for now in ekf2_main) we should publish this to a topic such that it can be consumed by all other modules.
Like in Paul's proposal here

[CarlOlsson]

Then the user could decide based on a parameter which kind of airspeed estimate he/she wants to use for TECS, controllers, mapping etc.
Different airspeeds could be e.g. filtered pitot or body velocity minus wind

[tstastny]

Then the user could decide based on a parameter which kind of airspeed estimate he/she wants to use for TECS, controllers, mapping etc.
Different airspeeds could be e.g. filtered pitot or body velocity minus wind

@CarlOlsson I like this idea. As e.g. guidance level wind consideration probably only wants the super low-passed ground vel - wind vel (ignoring small gusts / side slips etc), but something like TECS airspeed control (operating on a bit more low level) may want something closer to the actual filtered pitot to be safe.

[Antiheavy]

(add quickcal option while we're at it #8463)

It would also be useful for a "quick test" function added along with a "quick cal" function. One, both, or neither could be called from a built-in pre-flight checklist (e.g. in QGC).

[Antiheavy]

Fault detection and failsafe would be nice to add to the discussion here - see related issue post:
#9869

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Antiheavy]

I'd like to keep this issue open as we (slowly) work on various airspeed architecture improvements brought up in this thread.

[CarlOlsson]

Some comments

• Currently the variable names in TECS does not match the fieldnames in the tecs_status topic. This is very annoying when debugging, we should go through the names in TECS and then rename the fields in the topics
• Everywhere in the codebase where airspeed is used it should be clear what airspeed (EAS/TAS/IAS). This also applies for airspeed setpoints.
• We should add a status bitfield to tecs_status similar to how it is done in the ekf. E.g. to indicate pitch angle setpoint saturated in pos. direction, pitch angle setpoint saturated in neg. direction, underspeed, airspeed sensor enabled, bad descent etc
• It seems cleaner to do all calculations in TECS on true airspeed and do all conversions from IAS outside of the library. (Since we anyway scale throttle_cruise and throttle_max outside of the library based on eas2tas)

[sfuhrer]

Thanks @priseborough and @dagar for the merging of #11846, we will probably give it a try next week or so.

Meanwhile, @RomanBapst and I think a separate airspeed module would still be helpful. The basic idea we had is to convert the current wind_estimator module into an airspeed module, which then takes care of wind estimation, airspeed sensor scale estimation and airspeed sensor fault detection, and optimally do this all for multiple airspeed sensors running simultaneously. One possible output of such a module could then be a single airspeed estimate, like 'current_best_estimate_airspeed', coming from either

• a fusion/selection of the multiple airspeed sensors
• just from one airspeed sensor as the other one is detected as faulty
• from the groundspeed / windspeed difference if no airspeed sensor is available/healthy

Additionally, a flag could be set, such that the modules using airspeed have an idea how much they can rely on this 'current_best_estimate_airspeed'.

I've seen that most of these ideas have been proposed at some time already, so I wanted to know where you stand atm, and if you at all see advantages of such an airspeed architecture compared to what we have now.

[CarlOlsson]

I think it absolutely makes sense. Just remember that you still have to push the TAS into EKF2 when the GPS is lost to improve the dead reckoning performance.

[Antiheavy]

merging of #11846, we will probably give it a try next week or so.

@sfuhrer as far as I know we are the only ones who have been testing the airspeed failsafe. It works pretty good, but we had to be sure the params were set up correctly for our aircraft. Feel free to ping me if you like: "Todd Colten" on PX4 Slack.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sfuhrer]

Closing this as the new airspeed validation and selection module is merged now. Follow up issue is #12237 (multiple airspeed sensors support). As soon as the new airspeed module has proven to be stable, we should start using the airspeed_validated topic in the control modules.