Over the last couple of weeks I’ve been trying to track down an altitude issue I’m seeing in flight (I’m flying an DJI S1000 with a pixhawk with Copter 3.5.2. During some flights the altitude seems to be right on and others it’s off by ~10-15 meters (pretty significant given they’re between 30 - 50 m HAL). Some of the flights were on really cold days (around 2-3 deg C). Inputting the GND_TEMP param didn’t really seem to make a difference. I also noticed the EK2_ALT_M_NSE param had been set to 3 and from what I could tell in the EKF documentation the default value should’ve been 1. Changing it to 1 also doesn’t seem to have had an effect. It doesn’t seem to be hardware either as I’ve tried on two separate autopilots.
The only thing that seems to be correlated is how close the pixhawk home altitude is to truth. As a good example here are some altitude plots made from data captured by an onboard computer on two consecutive flights:
Flight 9
On flight 10, the home altitude reported by Copter was right on with elevation data I have via a DEM. The EKF reported altitude and gps raw altitudes seemed to agree very well.
On the previous flight (which ended about 45 minutes prior to this flight), the Copter reported home alt was about 13 m higher than what the DEM said it should be and there was a fairly substantial altitude offset.
I’ve combed through a lot of the code dealing with the baro and didn’t see anything obvious that would explain this. One theory I had was that have this incorrect GPS altitude on takeoff induced an apparent vertical velocity that made its way into the EKF, but the NKF3.IPD altitude innovations don’t seem to support this (they’re in general between -.5 and .5 m).
Is it possible that an incorrect home alt could cause the baro reference pressure to be interpreted incorrectly? I’m looking into this now and would appreciate any insights the dev team may have.
Did you take a look at the changelog of ArduCopter 3.5.3, 3.5.4, 3.5.5 and 3.5.6 ?
I think one of those had altitude fixes, but I am not sure right now.
As for this issue, your home alt will waver as much as 50ft when below 13 satellites. In my experience, it doesn’t get a good lock on alt until 14+ satellites, which for me doesn’t occur until I’m above the tree line.
If I understand how things are supposed to work, the altitude at your home position being incorrect shouldn’t affect the reported altitude when the altitude source for the EKF is set to BARO (because the altitude is essentially just the pressure difference between where you take off and where you currently are in flight). It apparently does though which is the crux of the issue.
The altitude-related changes he mentioned may indeed be affecting you now: the problem was that the EKF would trim its origin based on GPS altitude, which could cause it to drift significantly. The change essentially allows us to turn this off (and it’s off by default). I don’t remember if this change has been released in 3.5.5. It is implemented in Master, though. Given your observation that GPS altitude truth may be correlated, this seems like a likely culprit.
edit: The relevant PR is here. If you have the EK2_OGN_HGT_MASK parameter, then your version has this fix. If you don’t see it, then try updating firmware and make sure this parameter is = 0.
Another possibility, as you mention, is temperature. If you are using a Pixhawk 2.1 or any FC with an IMU/Baro heater, you can turn it on with the BRD_IMU_TARGTEMP parameter. After a warmup period, the baro should stay at a consistent temperature (Proficnc recommends 60C for Pix 2.1). All boards should output the BARO.Temp data in the logs, though, so you should be able to check if it is changing significantly in flight.
This is correct. Those updates and that param is not in Copter 3.5. I’ve been flying and testing it for months in the heli dev software built on 3.5, and it fixes the discussed issue here.
That seems like it describes what I’m seeing. It appears those fixes were committed after the 3.5.5 tag and so do not appear to be part of an official Copter release. Is there a reason I shouldn’t try to build master where it’s at now and try flying it (sitl first, of course)? Looks like there’s been a lot of work since then with no releases.
That is my helicopter development fork. I had all those commits separately in previous builds (38 commits). I just squashed them into one for the 3.5.6 build. I put them in the heli dev firmware because I had problems with altitude decay flying at 60 mph making a lot of tight turns on survey flights. On a hour long flight I lost 17 meters.
That firmware is for heli only, and is stable for long term testing of features that go into Copter.
I’ve flown 3.6-dev quite a bit recently, but only with helicopter. I don’t know the status of testing for other vehicles, or how stable it is. It will be in a constant state of flux until 3.6rc1 is released.
