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.