100KM

The problem with airspeed sensors

pitot-tube.jpeg?profile=RESIZE_710x

Airspeed sensors have been a major concern for both manned, and unmanned aviation alike. Yet almost every fixed wing or VTOL vehicle is dependent on it. So what is wrong with these sensors and why are they used?

How an airspeed sensor should work

A standard airspeed sensors consists of a pitot tube, a temperature sensor and 2 pressure sensors. The pitot tube has 2 ports (holes), one at the tip (like an injection needle) which is called the dynamic port, and one at the side which is called the static port. Each of these ports are connected to a pressure sensor. When the tube is pointing forward on a moving vehicle, it can measure the difference between the pressure from dynamic and static port. When factoring in the temperature it can estimate the current speed through air.

So whats the problem?

Over the years many problems have been identified with the use of airspeed sensors in both manned and unmanned vehicles. There is not one major problem so here is a list in random order;

For both manned and unmanned aviation

  • Icing: The same ice you see forming on the wings of an airplane can accumulate inside the tubes. When this happens the reading get unreliable or inconsistent at best.
  • Water: It might sound scary, but a few drops of rain inside the tube can cause the sensor to fail. The pitot tube holes are therefor made as small as possible.
  • Sand & dirt: Due to the small size of the holes sand or dirt can get lodged inside the tube rendering it useless.
  • Calibration: An airspeed sensors requires calibration before every flight. This is needed to account for the difference in readings the 2 pressure sensors will give. No 2 sensors will read exactly the same. The calibration is a snapshot that can be different from one moment to the next.
  • Drift: As the sensors are in operation they tend to drift due to temperature changes, how they drift is not always the same so it is hard to compensate for this.
  • Angle of attack: As you might imagine the system only works correctly if the sensor is pointing directly into the wind, but the pitch angle of any aircraft, especially unmanned, can change based on speed, air pressure, temperature or drag.

Specifically for unmanned vehicles

  • It’s fragile: The sensor needs to measure undisturbed air to work, and therefor needs to stick out in front of the UAV. The pitot tube is hollow and fragile and can easily break during transport or landing.
  • It needs special calibration: Not everyone is a UAV specialist, and properly calibrating an airspeed sensor takes a specialist. The board computer cannot tell if the calibration was done correctly, it just needs to assume it was.
  • Temperature drift: A UAV heats up as it flies. This means there is a drift in temperature that does not correlate to the air temperature. The board computer will try to compensate for a temperature that is not the actual air temperature.
  • Cross wind: Where manned aircraft usually have multiple airspeed sensors, UAVs normally have only one. If it flies in a cross wind there will be extra pressure measured on the static port (on the side).

The effect of incorrect airspeed readings

If the airspeed data is missing most vehicles UAVs will not takeoff or enter some failsafe mode. But usually the data is not missing, it is simply incorrect. With incorrect readings it will either fly too fast and therefor very inefficient, or it will fly too slow and in many cases crash.

Another serious side effect of bad airspeed readings is landing. Fixed wing UAVs are generally loaded to their maximum capacity. That means they need to fly their absolute minimum speed to land without damage. If they land too fast they start tumbling and usually break their wings or worse. VTOL fixed wing UAVs do not have this problem, but still suffer from inefficient or dangerous flight behavior when the readings are incorrect.

Eliminating the danger

During the research & development of the DeltaQuad VTOL UAV it quickly became clear that the airspeed sensor was a major concern. We therefor embarked on achieving the impossible: completely eliminate the danger.

Having members on the PX4 core development team can be a big advantage when pioneering in unmanned aviation. Using this advantage we managed to completely eliminate the need for an airspeed sensor by using a variety of other sensors to estimate our airspeed accurately and consistently.

Achieving accurate and reliable estimation was not easy, and required very specific tuning and testing, but the end result turned out better then we hoped. Using our estimated readings we not only eliminated all the issues in relation to airspeed sensors, we had also increased the efficiency of our vehicle by 20%

So if you are considering the purchase of a fixed wing or VTOL UAV, and you see a probe sticking out in front that look suspiciously like an airspeed sensor, make sure you think twice.

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • 100KM

    Hi Alex,

    Sorry it took a while to respond, but lets go:

    not sure about the "new"-ness of this feature
    I never claimed it was new.

    > I don't think your unit is IP64 rated either, even without an AS sensor, so let us not go there
    Any vehicle with exposed electronics cannot be rated IP6 anything. That aside we fly in heavy rain storms and have no issues whatsoever.

    > it would automatically dissable the use of Airspeed in the flight.
    Thats only if it detects it. if the AS simply starts reading 2m/s lower you cannot detect that unless you fly with 3 sensors. 

    Anyway the general point is that it works. (ratio) Calibration is done but system integrator, so your point about everyone not being an expert is not valid. You are not selling kits either. You are selling ready build planes.

    You are right about the integrators, and indeed flying without an airspeed sensor requires the software to be tuned to the airframe. And indeed we sell full systems, not kits. they have all had this tuning.

    > All the (end) user needs to do is preflight calibration. Yes it is a "step", but just one step (cover tube and press a button). It is not hard work or complicated. And well worth it for what we get in return.

    Now you are oversimplifying it a little. "simply cover the tube" requires some sense of what you are doing, and you need to verify if the calibration succeeded. We put our vehicles in the hands of rangers in kruger national park and all they need to remember is to put the clips down. People can operate our systems without any training. The AS would impede that.

    > About the temperature, I am supersized you are not aware of this but there is built in offset for both temperature and altitude to minimize drift.

    You do not have to be supersized that im not aware of this :) i am. But you also know the temperature sensor is not in the pitot tube, its often on top of (or even worse, inside) the vehicle. 

    There is 1 limitation which you did not touch. Probably PX4 does not have such a safety feature and that is why did not consider it. In Adruplane it is possible to set a maximum transition time, after which if the transition is not "successful", then the VTOL would abort and land itself safely.

    Although the topic here is not why ardupilot is better then px4, i will touch on this briefly as i wrote this feature in to px4 3 years ago. https://github.com/PX4/Firmware/commit/2fa73802464ed7e3ff6ef9a2efdd... and i had a vivid back channel with Tridge who made sure he kept ardupilot up to date with all the features i added for vtol in px4. Not only the transition timeout feature but also stuff like pusher assist and quadchute were all conceived and implemented by me on PX4 and later ported to APM by Tridge.

    > Let me give you a trivial example. Your pusher motor or it ESC fails just before transition or the prop is lose for whatever reason. Please tell me exactly what you unit would do. How/when it would detect that something is wrong and how it would react.

    It would hit failsafe due to any of the following events happening:
    - No forward motion
    - Loss of altitude
    - Maximum angles exceeded

    And it would abort the transition, and land as quadcopter.

    In most cases with GPS (ground) speed it would also work, albeit not as accurately.

    We do not rely on ground speed for this.

    > However in strong winds it will not work.

    I think you are making several assumptions and reacting to those. But you are most likely unaware of how this is implemented in PX4 and think these features are unique to ardupilot and require an airspeed sensor. The truth is that many of these features were built into PX4 before APM even supported VTOLs, and i dont think there are any significant features related to VTOL that are in APM and not in PX4. You could consider talking to tridge or others involved in that period of vtol development on the collaboration that was going on.

    In a very strong wind at transition altitude (say 40-50kph) GPS speed would be reporting only 25kph when the UAV is infact already at over 60-70kph. How would you detect that without an airspeed sensor. No matter what algorithm you have. You just started from a stationary position, so you have no possible estimate of wind speed.

    Again you seem to believe we are basing things on GPS. we are not. Wind is easily estimated in quadcopter mode, even when "standing still". and motion is required to achieve a proper transition unless you want to fly in conditions where you would have 0 ground speed at 100% throttle. In that case aborting the flight seems more sensible.

    > Finally there is no way that you can get the same accuracy with synthetic AS as with real one, especially in turns (in and out of) and gusty conditions

    An airspeed sensor does not solve that for you because you dont read cross wind on an AS. both PX4 and APM compensate banking with throttle and the slew rates on the throttle output make that acting on a gust is no faster with synthetic or real airspeed.

    > My point is that it cannot be better. You will always need a bit of "over compensation" on a UAV to stay safe on a sensor-less plane. You cannot edge it out and fly close to stall speed or rather most efficient airspeed when requiring the ultimate airtime endurance

    I'm not sure what kinds of frames you fly but i have never encountered an airframe were close to stall speed is the most efficient flight. you might get long flight times but overall (distance) you will be very inefficient. Flying close to stall speed is dangerous with any set of sensors and would require very wild tuning making it less efficient. Having said that, the "overcompensation" you need to do in an AS-less setup is less then what you need to compensate for inaccurate AS readings. So i would argue that an AS-less setup can fly closer to stall speed than one with an AS.

    Just saying so will not convince anyone. You are welcome to post scientific facts like a flight log in real life circumstances, in typical temperature and conditions. So not lab test.

    I'm not sure what you are getting at. We have posted ample logs and our vehicles have collectively logged thousands of flight hours in every imaginable condition (from the desert to the arctic). They have done so consistently and we have never logged a failure that would have been prevented by an airspeed sensor. 

    "Does not using Airspeed sensor have its advantages?" YES.
    No argument here

    "Is it possible to do on Arduplane and PX4" YES
    These are both awesome systems

    "does it work well and reliably" YES
    I will see your YES and raise you that it works more reliable

    "Is it better or safer than using and airspeed sensor" NO!!
    Down to the meat of your discussion; you raised only a few points and examples that gave me the impression you have a wrong understanding of how these systems work. All of these points are addressed equally well in an AS-less setup. but the issue you are not really getting in to is the fact that the amount of failures on these sensors is exponentially higher than others, and that it requires a level of accuracy and knowledge that not everybody possesses.

    I could point you to the issue trackers on both PX4 and APM but a simple google search on "rc airspeed sensor failure" tells you all you need to know. You might have been lucky with your setups, but you already indicated the failure that happened due to rain was in spite of instructions not to fly in rain. It seems you have made a good point towards my article there.

    I'm sure you will have a lot of things to respond and feel free to do so, Or come and visit us sometime when you are in the Netherlands so you can see for your self.

    Cheers.

    Front transition timeout · PX4/Firmware@2fa7380
    PX4 Autopilot Software. Contribute to PX4/Firmware development by creating an account on GitHub.
  • 100KM

    Hi Tom,

    I never suggested this was anything new on PX4. It's been available for almost 2 years now.

  • Developer

    Nice to hear PX4 finally has an airspeed estimate!

  • Hi Sander,

    Long time no speak.

    Here is my take on you article. As you will see I do not agree with all of it.

    First of all. Ardupilot (Arduplane) code has a working synthetic airspeed sensor feature for many many years. It works well. We tested it out of curiosity, on same Skywalker X8 unit as you are using. We did this test almost 1 year ago on the quad plane and it worked flawlessly (apart from the fact that I did not and still do not like that frame, terrible at holding a straight line in side wind, low wind resistance and flimsy wind tips). So not sure about the "new"-ness of this feature. Both Fixed-wings and Quadplane can function with it on Ardupilot quite well.

    Please note, this was made last year in May, only was not published till September, hence the date on youtube. Secondly it was a complete scrap build (we put it together in 1-2 days), just to quickly test the maturity of Arduplane Quadplane code for us. It is handing on the ceiling of our workshop. As you can see not Airspeed sensor. All default PID and so on. That is how mature Arduplane quad code was already at that time. I was ready to tune, but did not really have to touch and part of the quad plane side.

    https://youtu.be/KYJ38_QTOls

    You are correct on the limitations of an AS sensor. Suffice to say current iteration of Arduplane is quite capable of eliminating some of the major ones (water/ice or other blocking). In past for 4 years we have only had a single UAV mishap from airspeed sensor. When the client saw tropical rain was coming, but was on a deadline and decided to risk it (I don't think your unit is IP64 rated either, even without an AS sensor, so let us not go there).  Any way even in that case the problem was the feature for disabling the use of AS sensor by the system if a fault is detected had a bug, which has since been corrected. Otherwise (as is in current code now) it would automatically dissable the use of Airspeed in the flight.

    Anyway the general point is that it works. (ratio) Calibration is done but system integrator, so your point about everyone not being an expert is not valid. You are not selling kits either. You are selling ready build planes.

    All the (end) user needs to do is preflight calibration. Yes it is a "step", but just one step (cover tube and press a button). It is not hard work or complicated. And well worth it for what we get in return.

    About the temperature, I am supersized you are not aware of this but there is built in offset for both temperature and altitude to minimize drift. We make some of the longest flying (electric) sUAVs on the market (even 5+ hours) and never had major issue with AS precision on long flight.

    The thing that does drift significantly on long flights is barometer.

    There is 1 limitation which you did not touch. Probably PX4 does not have such a safety feature and that is why did not consider it. In Adruplane it is possible to set a maximum transition time, after which if the transition is not "successful", then the VTOL would abort and land itself safely. Let me give you a trivial example. Your pusher motor or it ESC fails just before transition or the prop is lose for whatever reason. Please tell me exactly what you unit would do. How/when it would detect that something is wrong and how it would react.

    In Arduplane this (transition successful detection) is done by the unit getting to a (user) preset minimum airspeed and staying above that for a a (users) set number of seconds. This is all fine and dandy. With airspeed sensor, this would work very well all the time and would be able to prevent a bigger problem in an even of such a failure.

    In most cases with GPS (ground) speed it would also work, albeit not as accurately.

    However in strong winds it will not work.

    In a very strong wind at transition altitude (say 40-50kph) GPS speed would be reporting only 25kph when the UAV is infact already at over 60-70kph. How would you detect that without an airspeed sensor. No matter what algorithm you have. You just started from a stationary position, so you have no possible estimate of wind speed.

    Finally there is no way that you can get the same accuracy with synthetic AS as with real one, especially in turns (in and out of) and gusty conditions. So you will have to use very simple min % throttle, which will never be as safe or especially as efficient as using real airspeed. As I said, I know first hand that it work. I also understand that you did some special coding for this in PX4 to work very well for you (as you have just reported). My point is that it cannot be better. You will always need a bit of "over compensation" on a UAV to stay safe on a sensor-less plane. You cannot edge it out and fly close to stall speed or rather most efficient airspeed when requiring the ultimate airtime endurance. Just saying so will not convince anyone. You are welcome to post scientific facts like a flight log in real life circumstances, in typical temperature and conditions. So not lab test.

    To sum it all up, yes, a lot of your points are correct. However to set the record straight as a lot of users are learning here.

    "Does not using Airspeed sensor have its advantages?" YES.

    "Is it possible to do on Arduplane and PX4" YES

    "does it work well and reliably" YES

    "Is it better or safer than using and airspeed sensor" NO!!

    Cheers

    Alex

  • 100KM

    No, that would require an impossible level of fine tuning on your actuators

  • Aha, so you scale actuators according to airspeed. In that case, would it not be possible to work the other way round and calculate airspeed based on response to actuator changes? This only requires INS and servo output.

  • 100KM

    @andreas 

    You need to distinguish between 2 processes:

    1. Keeping the vehicle flying stable
    2. Estimating airspeed

    Process 1 only uses estimated airspeed to scale actuator outputs (elevons). The transient phase is not a real concern there. It uses a myriad of sensors to control the output to the pusher motor to maintain stable flight. This results in a constant airspeed if external factors remain constant.

    Process 2 is indeed slightly delayed, but as this is not factored into the thrust calculation that does not really matter.
     

  • So, for given vehicle in stable flight (given air density, temp which you mention through baro, temp sensors), thrust + pitch should give you airspeed is that what's at the heart of your approach? My question is, what happens at transient phases? Let's say you push the nose down without touching the throttle. You will end up with a higher airspeed but it will take a while to be reached. Same for pulling up.

    How does your approach account for the transient period, does it directly calculate or does it guesstimate? Does the different airflow on the prop lead to different load on the motor which is then picked up by looking at the voltage for example (I don't really know if what you term as motor voltage is a function of throttle setting only or is also dependent on motor load)?

  • 100KM

    If you know the voltage, motor IR, motor KV, prop size, type and pitch angle you can calculate thrust. a bit like how eCalc does it.


    But from a control perspective the absolute thrust value is not as relevant, its about knowing the scale factors, quite similar to how you tune a quadcopter. proportional thrust to error. 

    Voltage comes in to scale the scale factors because obviously the scale factors assume an amount of thrust is produced proportional to the amount of throttle increase. voltage is one of the variables that effect that.

    This is why tuning a vehicle for flying without an airspeed sensor is somewhat difficult and there is no generic way of doing it. The parameters only work for a specific setup.

  • @sander,

    I do not understand how measuring a voltage allows you to calculate motor thrust.

    Can you elaborate on where you take the measurement and how you solve for thrust (given the required model parameters, of course).

    Thank you

This reply was deleted.