AHR2 altitude vs. GPS altitude

[Thorsten]

Hi all,

I hope it is ok to post this here...

I was running a 40 min auto mission today using a pixhawk, AC3.2rc9 with Randy’s landing detector patch, EKF enabled, and a ublox M8 GPS. The flight was smooth. When geotagging the 770 images based on the log file I was wondering why the GPS altitude was constantly decreasing. Checking against the other altitude data was even more confusing:

• AHR2 altitude was constant at about 460m while GPS altitude was decreasing about 8m
  
• However, both Baro altitude and GPS relative altitude where both stable - same as AHR2 altitude
  
• When landing in RTL I normally stop at 7m a.g.l. before the final decent at a slower speed. But this time it stopped at about 1.5m a.g.l. before the final descent. You also see this discrepancy in the take off and landing altitudes at the exact same location in all data except the GPS altitude data.

This leads me to the assumption that the only correct altitude measure was the GPS altitude. But as it seems it was not used during flight but only the baro altitude. Then, the next question is where do these obviously wrong GPS relative altitude values come from?

Are there any EKF settings which can be tuned to rely more on the GPS altitude data. There is EKF_ALT_NOISE but it seems to be problematic to set this to too low values on copters and only related to the baro. Or is the GPS altitude generally not used in EKF/DCM?

For 3D mapping reliable altitude measures would be of great advantage. Apart from that the landing process should be as secure and reliable as possible. 

Below you find some corresponding screenshots. 

The log file was too big to attach so it can be downloaded here: http://www.thorstenbehrens.de/2014-09-23_12-19-53.bin

Any help is greatly appreciated! And as always I am happy to test any patch.

Thanks in advance and best regards,

Thorsten

AHR2 vs GPS altitude:

GPS RelAlt vs. Baro altitude:

[Jonathan Challinger]

GPS.RelAlt is our inertial navigation altitude (for some reason, confusingly).

Baro alt was probably drifting due to atmospheric or board temperature changes and GPS alt was probably correct. It'd be nice to very slowly adjust baro alt using GPS.

If you want the best baro alt you can get, you must let the board temperature stabilize for about 5-10 minutes before flying. This probably means putting a small battery on the copter for a bit and then swapping it for your flight battery.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jonathan Challinger]

You didn't have a temperature-related problem, but you had gradual baro drift over the flight, which is completely expected.

We could use the GPS to slowly correct for long-term drift, especially if we only do it when we have a good VDOP. I think that would mean waiting for a good VDOP before taking off.

[Charles Taylor]

Is this type of baro drift caused by ambient pressure changing? If so it wpuld be useful to be able to enter an altimeter setting at the beginning of the flight and manually update throughout the flight. Using something like a hand held Kestrel makes getting local updates quick and easy.

[Randy Mackay]

Another option could be to use an APM2 or Pixhawk based antenna tracker and have it intermittently send ground pressure updates.

-Randy

[Jesus Alvarez]

I am with Jonathan in this.

I think a slow baro drift correction with GPS data is a must. Specially in long flights with aircraft.

I think I have seen Paul write about EKF was already doing it?

[Paul Riseborough]

Yes,

I'm currently working on a patch to allow the use of GPS to perform slow height corrections to the baro alt.

[Paul Riseborough]

Thorsten,

I've finished ground testing an EKF patch that applies a drift correction to the baro alt using GPS.

https://github.com/priseborough/ardupilot/commit/232a72efd2345953fd3d0ce75c44f35786862ea3

It allows the maximum rate of baro correction to be adjusted in units of cm/minute. I hope to give it a flight test tomorrow if weather permits.

Paul

[Thorsten]

Hi all,

thanks for all the information and details!

Another problem with baro drift is when the real/GPS altitude is constantly increasing and you are flying above the allowed 100/120m limit. Geofence will not trigger and one is operating illegally. 

The M8 seems to be a great improvement. Together with a nadir gimbal direct georeferencing (when generating digital surface models and orthopotos) is perfect. However, it is very sensitive for example to bluetooth (I can provide a log with the 3DR module if of interest). Hence, any GPS based correction should be adjustable and maybe switched of by default. If there is no interference it seems one can rely on the M8.

Paul, sounds great! I am happy to test your patch on a long endurance flight. However, I would need a complied file for a pixhawk hexa.  

Thanks and best regards,

Thorsten

[Paul Riseborough]

Thorsten, I've now created a branch for this feature.

https://github.com/priseborough/ardupilot/tree/ekfGpsAlt-wip

Preliminary testing showed that the EKF patch  in and of itself was doing the right thing, however switching between INAV and EKF in flight causes problems due to the fact that INAV is using an uncorrected baro alt, resulting in a significant and unpredictable altitude jump on switchover. I may have to implement this in the baro object, so more work is required.

Regards,

Paul

[Jonathan Challinger]

Right, I think the correct thing to do is for the baro object to be in charge of correcting for atmospheric pressure.

--

[Ben Nizette]

I did some work a while ago to get AP_Baro to track atmospheric drift
over time, see [1]. The approach was very simple and kind of
brain-dead, it required that the craft sit at fixed altitude with GPS
lock for a while to get a good starting reference point. I needed
reliable absolute alt, not just a lack of drift, so I had to calibrate
the system over a few minutes; people who just don't want a loiter to
slowly climb could probably get it done in 10s of seconds. After cal
it tracked OK.

In the end through I abandoned that approach and hacked up a little
MAVProxy module that read ground pressure from a mostly-busted Pixhawk
I had lying around and tweaked the GND_ALT_OFFSET param every minute
or so.

Ben.

[1] https://github.com/benizl/ardupilot/blob/z_fusion/libraries/AP_Baro/AP_Baro.cpp

[Charles Taylor]

Next telemetry radio needs a barometer :)