Barometer pressure glitches with PX4

Some important stuff first:

  • I’m using the PX4FMU+IO, not the Pixhawk
  • I’m currently running with git master to get logging to work, but the problem also occurs on 3.1.5, so I’m posting about it here.
  • The problem can be replicated in a benchtop setting without the motors running.
  • It happens with at least 2 different PX4FMU+IO stacks, so I don’t think it is a hardware issue.

Hi, I’m trying to get the Arducopter firmware working on the PX4FMU/IO board stack. I’m having some issues with invalid altitude measurements. Typically the altitude will go to 0.0 or NaN and stay there after flying for a while. Sometimes it will go to large (20,000m+) positive or negative values first.

First, I tried running release 3.1.5, installed with the firmware upgrader. On my first tests, the altitude measurements would drop to 0.0 after a while and the quadcopter would shoot up in the air if it was in altitude hold mode.

Unfortunately, logging to the PX4’s SD card did not seem to work with this version, so I built the latest git master version (773bc7bcbe06363535dd0326c264fb114362f553) of ArduCopter and have continued testing with that. Logs work with it, but it still has the altitude measurement issue.

In the logs this seems to concide with the pressure measurement from the barometer momentarily dropping to 0. Often, the barometer temperature measurement will also read some incorrect value (>400C) at the same time. Both pressure and temperature measurements recover after a short time (sometimes a single line in the log) but the altitude measurement stays at 0.0.

I’ve had this problem occur on two different PX4FMU+IO stacks, so I don’t think it is a hardware issue. Just to be sure, I captured I2C bus #2 traffic from power on until the altitude got stuck at 0.0 in a benchtop setup and decoded/plotted all the barometer measurements. The only strange thing I see is that the MS5611 sometimes seems to return a 4th byte when reading the ADC. I’m not too familiar with the sensor, so that may be a feature I just haven’t read about yet. Other than that, the measurements look good and I don’t see any sudden jumps or drops to 0.

My test procedure was as follows:

  • Power on RC transmitter
  • Power on the PX4 by connecting it to my computer via. USB
  • Connect over USB with APM Planner 2.0
  • Arm PX4IO board with safety switch
  • Arm using CSC
  • Throttle up to 50%
  • Switch to alt-hold mode
  • Relative altitude wanders around 0.0 on GCS
  • Eventually, altitude drops to 0.0 and stays there. Lifting or moving the PX4 does not change altitude measurement (attitude measurements still update correctly).

Since that was a stationary benchtop setup with only the PX4 powered, vibration is unlikely to be part of the problem.

I’ve also attached a log from an actual outdoor flight where this problem occurred. I was using Droidplanner 2 for telemetry. It glitched one time but recovered, and glitched a second time where I got a NaN altitude on Droidplanner. At that point putting it into alt-hold mode would of course cause it to ascend uncontrollably.

I modified the startup file to put nsh on /dev/ttyACM0.

I then did another benchtop test, waited for the altitude to get stuck at 0 and ran the ms5611 program in nsh:

nsh> ms5611 info
state @ 1000a370
ms5611_read: 35936 events, 116228818us elapsed, 3234 avg, min 215us max 45532us
ms5611_comms_errors: 8104 events
ms5611_buffer_overflows: 62 events
poll interval:  10 ticks
report queue	20/800 (2/2 @ 20012500)
TEMP:           3944
SENS:           1789660778
OFF:            3324585324
P:              994.890
T:              39.440
alt:            153.965
MSL pressure:    1013.2500
factory_setup             76
c1_pressure_sens          52371
c2_pressure_offset        48860
c3_temp_coeff_pres_sens   32145
c4_temp_coeff_pres_offset 26762
c5_reference_temp         31651
c6_temp_coeff_temp        27847
serial_and_crc            14798

Meanwhile, ArduCopter shows a 0 altitude.

So the ms5611 driver seems to be working correctly after the program occurs although the error counters are greater than zero. Usually I see some errors during normal operation and it doesn’t seem to always be a problem. I’m not sure what message is published by ms5611 when it has an error. Would a single bad reading on the barometer cause ArduCopter’s altitude measurement to get stuck at 0?