search

PX4 / PX4-Autopilot

PX4 Autopilot Software
https://px4.io
BSD 3-Clause "New" or "Revised" License
8.5k stars 13.51k forks source link

Automatic airspeed scale calibration for FW and VTOL #16440

Open moreba1 opened 3 years ago

moreba1 commented 3 years ago

Describe problem solved by the proposed feature Flying in different locations need new airspeed calibration because of air density change with AMSL altitude. so we need to calibrate the airspeed scale in new locations. but doing it manually is difficult and may be dangerous for users.

Describe your preferred solution After takeoff In a loiter with constant altitude and for a duration, airspeed calibration activated (ASPD_SCALE_EST = 1) then autopilot measure average of groundspeed in every round and use for airspeed calibration. after calibration, it should be disabled and fly to the next waypoint.

LorenzMeier commented 3 years ago

We are calculating the true airspeed already based on the current altitude. What use case do you have that would require additional calibration?

dagar commented 3 years ago

The airspeed scale factor is still often worthwhile for things like pitot position error. Currently it's not safe to keep airspeed scale calibration enabled at all times (ASPD_SCALE_EST), but it's something @sfuhrer and I have discussed recently. Either an explicit calibration flight (large loiter) or monitor a normal flight to consider committing the estimated TAS scale if it converged, everything checks out, and other properties were satisfied (eg enough turning).

moreba1 commented 3 years ago

We are calculating the true airspeed already based on the current altitude. What use case do you have that would require additional calibration?

I calibrated the airspeed scale at 1000 m AMSL altitude, but in the second flight at 2000 m AMSL altitude it was uncalibrated.

sfuhrer commented 3 years ago

I calibrated the airspeed scale at 1000 m AMSL altitude, but in the second flight at 2000 m AMSL altitude it was uncalibrated.

Could you share logs from these two flights?

And yes, I think we should work towards having the estimation enabled always, with checks in place to not create dangerous situations.

moreba1 commented 3 years ago

Either an explicit calibration flight (large loiter)

This is good. calibration of airspeed scale with a loiter in first of each flight.

moreba1 commented 3 years ago

@sfuhrer

  1. I noticed that the airspeed setpoint in FW_AIRSPD_TRIM is different from TECS airspeed setpoint. FW_AIRSPD_TRIM set EAS but when we define FW_AIRSPD_TRIM we will plane fly at this actual airspeed.
  2. Also in QGC, EAS displayed not TAS . https://github.com/PX4/PX4-Autopilot/pull/14858 . but in this log (v.1.11.1), the plane uses TAS for flight, not EAS.

image

image

moreba1 commented 3 years ago

src/lib/tecs/TECS.cpp image

sfuhrer commented 3 years ago

Hi @moreba1, the controller will always try to keep the IAS (resp. CAS) constant. CAS is passed into TECS, and there converted to a TAS setpoint, as that's what TECS internally needs. Also the tecs_status.airspeed_sp is in TAS. So it's normal that FW_AIRSPD_TRIM is not equal to tecs_status.airspeed_sp. This PR https://github.com/PX4/PX4-Autopilot/pull/16585 should make it more clear for the future. I think it makes sense though to display CAS/EAS in the HUD of the groundstation, as if you fly manually, that is the airspeed feedback you're most concerned for.

moreba1 commented 3 years ago

the controller will always try to keep the IAS

1- if FW_AIRSPD_TRIM and airspeed in HUD are not the same when operator will be confused.

  1. EAS2TAS is different in each flight, so TAS will different in each flight. Designers want to set TAS constant in all drone flights
  2. If CAS displayed in HUD when we will set scale calibration. we will be confused because the average of min and max of groundspeed in loiter equal to TAS, not CAS.

I think FW_AIRSPD_TRIM and HUD airspeed must set to TAS.

sfuhrer commented 3 years ago 
1- if FW_AIRSPD_TRIM and airspeed in HUD are not the same when operator will be confused.

FW_AIRSPD_TRIM is a very safety related system setting, that no operator should need to touch. Only developers. And they should know the difference between IAS/CAS and TAS. If you want to have user-facing airspeed setpoints, then I would recommend using change speeds commands in the groundstation (which are currently also in CAS --> maybe we could change that part, to have the user interface in TAS).

  1. EAS2TAS is different in each flight, so TAS will different in each flight. Designers want to set TAS constant in all drone flights

It will only be different if you fly at different altitudes. I don't see a problem in having a changing TAS depending on the current altitude, that's standard for any sort of planes.

  1. If CAS displayed in HUD when we will set scale calibration. we will be confused because the average of min and max of groundspeed in loiter equal to TAS, not CAS.

I don't really get your question. The scale (from IAS to CAS) can be estimated automatically, or then set manually by comparing groundspeed and TAS while loitering (note that the scale is also applied to TAS).

I think FW_AIRSPD_TRIM and HUD airspeed must set to TAS.

I disagree with the FW_AIRSPD_TRIM part, but would agree that having TAS displayed in the HUD would be beneficial (but only if we keep CAS).

Can you elaborate in which use cases setting a TAS would need to be required from an operator?

moreba1 commented 3 years ago

It will only be different if you fly at different altitudes. I don't see a problem in having a changing TAS depending on the current altitude, that's standard for any sort of planes.

Flight performance and power consumption (lift/drag ratio) depend on the angle of attack and AOA has a direct relationship with TAS, not IAS, so developers want to maintain TAS constant. Also, the range of ground speed related to TAS and wind speed, if TAS be more, maximum ground speed will be more and it is not desirable for aerial imaging. @dagar @Antiheavy