Airspeed Sensors are Overrated
This is just a short opinionated post about airspeed sensors. I was recently trying to configure a small ZOHD Talon 250g with ArduPilot, and it seems to be impossible to disable airspeed-based gain scheduling. Even if there is no airspeed sensor, ArduPilot would rather estimate some airspeed than allow you to disable gain scheduling altogether.
What is airspeed-based gain scheduling
The idea behind airspeed-based gain scheduling is sensible. When you're flying slower, there is less airflow over the control surfaces and thereby they are less effective. So ideally, at lower airspeed, you would like the control surfaces to deflect more compared to higher airspeed.
The effectiveness scales quadratically with airspeed. With a nominal airspeed of
For example, when the nominal airspeed is 15 m/s, the effectiveness of a control surface is reduced to 36% when flying at 9 m/s. When flying 22 m/s, the effectiveness is increased to 215% of the nominal value. In order to get the same response from the airplane, the control surface deflections must be scaled accordingly.
But do we need it?
At first glance, it seems very important to compensate for such large differences. And an airspeed sensor is the go-to solution for it. However, I would argue that for many use-cases it is not important to compensate for this. If you only want an airplane to cruise at a certain speed, and maybe climb and descend occasionally, it is perfectly possible to fly with a fixed set of gains.
There is two things to be aware of. If the gains are too high, the airplane will start to oscillate at higher airspeed. And if the gains are too low, it will be difficult to control the airplane at lower airspeed, for example during landing. That being said, in my experience it is very easy to find an appropriate set of gains that doesn't have these problems. And it seems to be the default in INAV as well, so many people in the hobby would agree with me.
Simpler is better
The advantage of flying without airspeed sensor is simplicity. There is a whole range of problems you no longer have to care about. The pitot tube cannot be blocked, the fragile sensor cannot break in transport, the communication lines cannot be compromised, etc. And it saves weight too.
Alternatives
In some situations, it might still be desirable to have more control during landing for example. While an airspeed sensor is one solution, it is definitely not the only one.
The simplest solution would be to map a switch on the remote controller to a different set of gains for landing. This would be super easy to set up in INAV for example, but I'm not sure about other firmwares.
It is also possible to create an airspeed estimate based on throttle setting and climb/descend rate. However, this requires more work upfront, including some flight tests.
Another approach would be to do live system identification of the control effectiveness, and change gains based on that.
There is probably more possibilities, but this goes to show that you really don't need an airspeed sensor and that there are many good alternatives.
ArduPilot really want to use airspeed
When I configured ArduPilot to not use an airspeed sensor, it still tries to calculate the airspeed in the Kalman Filter. And this airspeed is then used for gain scheduling. And what's worse, the airspeed seems to be based only on GPS measurements. There are parameters in the Kalman Filter to configure drag, so that it could produce a more reliable estimate, but these parameters are zero by default.
Imagine a scenario with strong headwind. The estimated airspeed would be too low and that would increase control surface deflections. This could potentially make the airplane oscillate or even make it unstable.
When looking at the relevant source code in the function that calculates speed scalar, there seems to be no possible configuration to disable it completely.
It's off course possible to simply modify the code here, but I am be careful to just change that. Probably other parts of the code rely on these assumptions too, such as auto-tune. I will first give ArduPilot a try without any modifications.