3D Robotics

Lorenz Meir of the Pixhawk team had a good email discussion with the APM dev team on airspeed math, and was kind enough to write it up in a very helpful primer.

Check out the whole thing here, which walks through the math and measurement techniques.

His tips at the end apply to sensor measurements of all sorts:

"Conclusion To get an optimal altitude or speed estimate, follow these rules of thumb:
  • Get as much ADC resolution as possible, in the best case 10-100 times or more than your needed accuracy
  • Sample at a much higher frequency and take the average/median (e.g. sample 10 times in a row, take the average/median, return this filtered value). This technique is called oversampling and if the sampling repetitions occur at a much higher frequency than the sampling interval, it should not delay the signal (no phase shift).
  • Do a plot over a sensor range to figure out if your sensor is linear, if not, fit a quadratic/cubic function and linearize
  • Do a static calibration if necessary
  • Compensate for temperature changes if the sensor is sensitive to it
  • Do not over-fit or over filter and just correct as much error as you need to make your application work. Too many projects and people get entangled in their own complexity and failures and crashes are the result of too high complexity and too few testing"

E-mail me when people leave their comments –

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

Join diydrones


  • I'm in the midst of designing a PCB for a quadcopter and wondering if I should include a pressure sensor on it, I don't really understand why airspeed is such a big deal. Why do you need it? Would there be any reason GPS course and speed over ground wouldn't be enough for a copter?
  • In my EZSTAR project, I take the GPS velocity into aircraft space, then project it on the pitot's axis (basically throw out the Y and Z components) and use that vector length for the comparison. That way you're measuring what the pitot would "see" and not velocities in other directions.

    I've gone through the calibration a few times and I can never get it better than 5 mph over temperature. I've tried a few sensors and they'll calibrate and work great one day, but 3 months later I'm off a few mph. Go figure.
  • I set up a pitot on my T-28 Trojan and logged GPS and raw pitot A/D values on my APM setup. Subtract off zero level, apply smoothing, take square root, multiply by 1.45. After accounting for light wind, quite good agreement with GPS speed above several meters/sec. Below that is probably too noisy to be useful. Would need more hardware effort to reduce noise per Andrew Burns post above.

    I note that APM_ADC already samples the 12 bit A/D inputs at 400Hz and averages when you call APM_ADC.Ch(), so oversampling is already being done.

  • I'm currently working with some pressure sensors for work. I've managed to extract a usable 1mm of water (about 0.01kPa) noise floor out of some Freescale absolute pressure sensors which read from -80 to +150kPa (gauge). That's about 0.005% of full scale, something those sensors were never designed to do so I'm pretty happy about it.

    My advice for working with pressure sensors, especially when dealing with very small variations in pressure is:
    - Calibrate the sensor yourself, in my case I'm dealing with water pressure so I calibrated them with a vernier height scale and a water column. You could easily set up a similar calibrated water column but have the sensor in contact with air.
    - The temperature calibration of those sensors is pretty rough, you can clearly see the readings drift and then suddenly 'snap' back into line every so often. Granted they only deviate by 10mm of water (0.1kPa) or so before snapping back which is only a tiny fraction of their full scale range.
    - Most of the sensors will be ratiometric which doesn't matter if you're supplying your A/D with the same voltage as your sensor. In my case my A/D is running off a separate 5V reference so I'm also reading sensor supply voltage and have calibrated the ratio of input to output voltage for each sensor.
    - Always think about noise. My sensors are about 2m from the A/D so everything to and from them goes along shielded twisted pair cable, shields pulled to earth, careful not to create ground loops etc. My sensors are running off a low noise linear power supply, when running them from the 5V USB power of a laptop the noise level in the signal was an order of magnitude higher.
    - I'm using a 16bit A/D, in my opinion you should turn to increasing A/D resolution as a very last resort, if you can get away with 12 bit resoultion all the better. If you start going to 18 or 24 bit resolution A/D's you'll have a hard time making use of the extra bits without having the eaten up by electrical noise (also high bit-count A/D's tend to take much longer per conversion, better to oversample a number of times with a lower count A/D).
  • I am presently working on an altitude hold unit for helicopters and here in Luanda, Angola the diurnal barometric pressure changes can cause a 10m change in altitude over an hour and that is with calm weather. Not such a big deal but worth knowing....
  • Developer
    Barometric pressure isn't constant or precise enough for "accuracy really matters". Sonar is probably better for "ground feeling" purposes.
  • I'd like to think about or consider adding some complexity :). I know it can be argued that over the course of some normal flights, the air mass passing by the launch point doesn't change so much. But let's say that it is, or that the flight was a little longer than usual for some reason. Assuming that we weren't using sonar for altitude information during the last few feet of automatic landing and that we wanted the altimeter to maintain its original accuracy at the end of the flight. Similarly to differential GPS, might a duplicate altimeter attached to the ground station reporting current ground level readings, and sending this value up to airframe via telemetry. The airframe could use this as the ground level reading and be assured that when accuracy really matters, its ready to do the job (landing that is). Any thoughts?
  • Thank you Chris,

    I'm designing a new airspeed limiter/controller and this discussion showing i'm on right way :)
    Another point: *forget the non-temperature compensated sensors,
    I'm using 24bit ADC and last 5 digits going crazy from temperature changes. This is my second design and production from this reason.
This reply was deleted.