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!
Comments
Hi Andrew & the entire gang,
Thanks for getting into more precise airspeed measurements and models!! Much appreciated.
Three questions / comments which may very well originate from my ignorance, but I'll ask anyway:
cheers
-mikko
Hi All,
I have problem with Airspeed sensors.I have 3 3DR, 2 RCTimer Airspeed sensors. I couldnt get it working.
I have tried with APM 2.5 and PX4. I have blowed air to pitot but AirSpeed indicator on HUD olny show 1 - 3 M Airspeed.
Wich part cause this problem ?
PS: I was followed intruction on APM Guides to setup sensors.
Thank You
I-Tech
Where do I put it in relation to my landing waypoint?
I still have unanswered questions above, and I hope others will chime in.
Thank you.
iskess, the distance is to the WP, time or altitude, which ever comes first. You can put a DO_CHANGE_SPEED command in your landing sequence. Plot a gradual decent and use the speed command. The key to a good landing is a good approach. You need to plan the landing.The cruise speed is not controlled by the landing command, you must put it in.
One more autolanding question, sorry if I am drifting off the thread topic:
LAND_FLARE_SEC is the time before landing point. Does this include the waypoint radius of the landing point, or exactly the LAND point.
I just started doing some autolandings. The APM does a very good job, but because it doesn't know exactly where the ground is it drives it on fairly hard without a flare which is rough on my airframe when I fly at high weights. I noticed that the APM makes no attempt to slow the airspeed down before touchdown. I would think that it should slow to Min speed when near the landing waypoint rather than maintaining cruise speed.
1) Is this what LAND_FLARE_ALT and LAND_FLARE_SEC are supposed to do? Or do these only work for flaring in conjunction with LAND_PITCH_CD for airplanes without airspeed senors?
2) If applicable to aircraft with airspeed, if I increase LAND_FLARE_ALT and LAND_FLARE_SEC much too high, what could be the result. Will it always honor the min speed so that it won't stall?
3) Would a sonar sensor assist in determining flare height like a poor man's radio altimeter?
4) Could the code be written to allow a minimum airspeed and desired sink rate so that the autopilot could apply throttle to maintain a sink rate. This would be a nice option for longer runways and more fragile planes.
I am just trying to better understand the autoland logic.
Thank you.
Thanks Tridge and Paul.
I didn't expect wind estimation to work in the flight direction. I spend most of my flying time going in circles so pitot free flight works quite well for me. Might be acceptable for other pilots also.
I have been flying 2.75b for two weeks now , with the auto cal enabled. It works great, set and forget. I should probable turn it off, or could we filter it and look for a min change and have it shut its self off? Great work, we are lucky to have Paul and Tridge.
Good shot of your LiPo burn in the mat there too Tridge !!
@Matthew,
The Kalman filter is actually a wind estimator (the first two states are the X and Y wind components). The 3rd state is the airspeed ratio (actually 1/sqrt(ratio)).
So it will cope fine with steady wind. It will also cope fine with random changes in the wind. It could be fooled by the wind changing in a way that correlates with the direction you are flying (so wind from the south when you are flying north, and from the north when flying south). If you have weird wind affects like that then don't turn on the auto-calibration!
I've flown it quite a lot now in all sorts of wind conditions and it has produced a good estimate, but the fact that it can be fooled is why it is not enabled by default. The idea is you turn it on, get a good ratio estimate for your sensor and airframe then disable it again. I've just left it turned on for my AcroWot, but that is because I'm deliberately trying to test the code.
Cheers, Tridge
-
1
-
2
-
3
-
4
-
5
of 5 Next