With the release of the 2.74 version of APM:Plane and the introduction of TECS, the ability of APM to take full advantage of an airspeed sensor for fixed wing aircraft was greatly enhanced. A lot more people are now buying and installing airspeed sensors. APM has had support for airspeed sensors for a long time, but tuning for good airspeed control was somewhat difficult and error prone. Now it is much easier.

The next APM:Plane release will be 2.75, and will come out soon. In that release airspeed sensing will be improved even more, with three key changes.

New Digital Airspeed Sensor

The first change is to add support for a new digital airspeed sensor from Measurement Specialities, the MS4525DO. The PX4 dev team announced this sensor recently, and I've been test flying it to ensure it works well with APM. It does! This new sensor is a huge advance over the analog sensors we've been using up to now.

The key difference is how low the thermal drift is in the reported differential pressure. A long standing problem with airspeed sensors has been the drift in the reading as the sensor warms up. This doesn't matter very much if you only need accurate airspeed readings at high speed as the contribution of thermal drift to airspeed drops rapidly with speed (as airspeed is proportional to the square root of the measured differential pressure). At lower speeds, such as when landing, it can matter, and having a sensor with low thermal drift is very nice. The I2C based MS4525D0 has internal temperature calibration to cope with thermal drift, which really helps.

The difference can be seen in the following graph

the green line in the graph shows the airspeed from an analog sensor, and the red line shows the airspeed from a MS4525D0 digital sensor. The readings were taken on two Pixhawk boards side by side, started at the same time. You can see that the analog sensor drifted quite quickly to above 2 m/s average, whereas the digital sensor settled at around 0.5 m/s.

Right now we only have a driver for the MS4525D0 on the PX4 and Pixhawk. It would be possible to write a driver for the APM2, and we'd welcome a contributed driver.

Before we settled on the MS4525D0 we also tried the EagleTree I2C airspeed sensor but we found it suffered from thermal drift just as badly (and in some cases more badly) than the analog sensor. We still have the EagleTree driver in the tree, so if you have an ETS airspeed sensor it will work, but we don't recommend it if you can get the MS4525D0.

Automatic Airspeed Calibration

The 2nd big airspeed change in the 2.75 release will be the introduction of automatic airspeed ratio calibration. The airspeed ratio is the ratio between the calibrated airspeed and the square root of the differential pressure measured by the sensor. This ratio is normally around 2, and is controlled with the ARSPD_RATIO parameter in APM:Plane.As is described in the documentation, it is common that this ratio needs to be calibrated for different airframes. There are several reasons why the ratio may be different from 2.0:

  • positional error, caused by how the sensor is installed in the aircraft
  • sensor error, caused by small leaks or differences in sensor construction
  • pressure altitude differences, caused by changes in airspeed measurement with altitude

For previous releases of APM:Plane users wanting the best possible airspeed measurement needed to calibrate the sensor themselves, by flying the aircraft and looking at the logged airspeed compared to groundspeed. That worked, but it was not convenient.

For the 2.75 release Paul Riseborough has contributed a small 3 state Kalman filter which can automatically calibrate the airspeed ratio while flying. To enable it you need to set ARSPD_AUTOCAL to 1 and then just fly normally. The ARSPD_RATIO is automatically updated while you are flying. The following graph shows it working on my AcroWot:

I had deliberately set ARSPD_RATIO to 1.2 on takeoff to give the autocalibration code something to do. As you can see, the groundspeed and airspeed don't match at all well while the ratio stays low. After a few minutes of flying the autocalibration has raised the ratio to the right value of 2.0, and the airspeed nicely matches the average groundspeed.

Compensation for pressure altitude

The final major change in airspeed handling for the 2.75 release is the introduction of the EAS2TAS ratio throughout the code. The EAS2TAS is the estimated to true airspeed ratio, and reflects the fact that airspeed measured by an airspeed sensor drops relative to the true airspeed as altitude increases. This change is due to the lower air pressure, which means less air molecules hitting the sensor.

We already had compensation for EAS2TAS in the core navigation code in the 2.74 release, but for 2.75 we have propagated this ratio throughout the code. In particular the ratio is now used to adjust tuning parameters in the servo control loops, adjust the navigation code and even adjust the loiter radius with altitude. The idea is to make APM tuning parameters for an airframe be the same at sea level as it is at the top of a mountain, which will make it easier for users to share parameters, and also be a big advantage for anyone who flies at a wide variety of altitudes.

We have tested this code using the excellent JSBSim flight dynamics simulator, which allowed us to take a simulated aircraft up to altitudes far beyond what we could go to with a real R/C model. The EAS2TAS compensation worked well up to altitudes of around 30km.

Overall the upcoming 2.75 release should be a big improvement for anyone using an airspeed sensor. We hope you enjoy flying it!

Views: 12511


3D Robotics
Comment by Chris Anderson on September 17, 2013 at 9:21pm

This is awesome. Good airspeed data is essential for fixed wings and you're right that it's been too hard to tune the sensors to date. Now this. All hail our new digital airspeed sensor overlords!


Developer
Comment by Arthur Benemann on September 17, 2013 at 9:48pm

It's really nice to see things that I learned at graduation, like gain scheduling,  being used in a real example.

Well done Tridge and Paul !

Comment by Simon Wunderlin on September 17, 2013 at 11:49pm

Thanks for the update tridge. Since I am mostly on fixed wing I am looking forward to the 2.75 release.

@Chris: is 3DR going to sell the MS4525D0, if so do you have a rough idea when it'll be available?

Cheers

-S

Comment by Gary McCray on September 17, 2013 at 11:54pm

Very professional result, excellent job.

In all aspects it seems, flight control operation is becoming much more solid and predictable lately.

Our hobby is starting to get pretty serious.


Moderator
Comment by Gary Mortimer on September 18, 2013 at 1:43am

As ever, nice!

Comment by mP1 on September 18, 2013 at 1:48am

Awesome doco, awesome must try.

Comment by kwijatkowski on September 18, 2013 at 6:03am

One question: how this code deals with wind? In windy conditions it is common that airspeed does not match groundspeed. I do not want this algorithm to change parameters in this situation...

Comment by Matthew Coleman on September 18, 2013 at 7:43am

Very nice.

for those that don't have a pitot fitted, is the setup completely reliant on directly measured windspeed or can it work with calculated windspeed and IMU groundspeed?

Comment by Gisela & Joe Noci on September 18, 2013 at 8:22am

The biggest problem in Airdata sensing for airspeed is the placement of the static and dynamic ports leading to the sensor itself. A dynamic source from a Pitot tube located many tube diameters forward of the aircraft sttucture ( nose, if rear prop driven, or wing leading edge, etc) is really the best, and is normally the easiest one to place. The more difficult one is the static port source. Any change on the static port not seen by the dynamic port will register as an airspeed change, or course. Leaving the static port source vented to the fuselage interior is never satisfactory- prop wash pressurizes the interior via inlet vents, etc. The mere forward motion of the aircraft forces air into air inlets, passing through the fuselage to any available outlet. The pressure within the fuselage is never neutral. A Pitot-Static tube works well, but needs to be well designed to avoid airspeed reading changes due to aircraft pitch changes. Such static pressure variations cannot be filtered out as it is not possible to how they arose. Static port hole placement on the Pitot-Static tube need to be the correct diameter to tube diameter relationship, and need to be correctly positioned rearwards of the dynamic entrance. The shape of the Dynamic tip must also not induce vortices rearwards that affect the static inlets. All an art of its own. A practical alternative to the combined tube is placing the static ports, 2 off, one either side of the fuselage, under but well below the the wing, along a flat smooth section of the fuselage. This section should be flat for at least a 60 to 90mm radius around the inlet hole. However, a neat trick is to have the two hole directly opposite each other, and to use a 5mm inner diameter brass tube through these holes, completely flush and smooth with the fuse exterior. A 3mm brass tube is then T'd ( soldered) at the 5mm tube center - it must NOT penetrate the 5mm tube, merely junction with the wall. This T is then tubed ( silicon, etc) to the static port of the sensor. Any protrusion of the 5mm tube outside the fuse causes turbulence at that tube mouth, and incorrect pressure. Glue the tube in and sand it flush with the fuse side. If the tube mouth is near any undulation in the fuse, landing gear strut, etc, the same problem. Using two tubes in the side, and then leading two silicone hoses from them, and T joining ( or rather Y joining) them some 100mm away from the tube mouths does not work - any side wind entering the one hole will partially exit the other hole, but still pressurize the T inlet, falsifying static pressure. Having a clean, straight unimpeded path for the side wind air flow to exit the other hole minimizes these effects considerably.

This is the method we employ on our SurVoyeur mk-I and mk-II aicraft ( see the various blogs..) and it work perfectly. We use the Freescale analog pressure sensor, and do a temperature compensation run, with a 3rd order polynomial fit for the correction. This takes about 1.5 hours to do. We achieve 3% accuracy at 2m/s airspeed, 1.2% from 4m/s up to 9m/s and 0.6% from 9m/s up to 24m/s. Then it diverges again, reaching 1.1% at 34m/s. Our flight speed range is from 9m/s to 24m/s, so all is well.

Finding the correct source of static air data, if not via a combined Pitot-Static tube of correct design, is the most challenging task of achieving correct airspeed data...

We do the same for the static pressure sensor ( for baro-alt) and achieve less than 2meter height variation over 10deg C to 55deg C, assuming ambient pressure does remain constant. Not even the good old Siemens BMPxx sensor can achieve that..Remember 1mbar variantion is approx 8meters..

Joe

The Nampilot


Admin
Comment by Morli on September 18, 2013 at 11:59am

Hi Nampilot,

Thanks for the detailed pitot tube setup. I am still lost in it. Can you pls show any photo + any hand drawn picture of what you detailed will be highly appreciated.  Thanks again.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service