Baro drift compensation using Tracker

AntennaTracker
1

I’m trying to get Plane to land reliably in automatic mode and I’ve noticed that it is getting a consisent altitude estimation error and thus sometimes tries to flare way too early. After checking the logs I’m noticing that the altitude estimate (with Baro as an absolute source) is off by several meters. I do have a rangefinder, but in this specific scenario the error is so big that the flare starts before the operational limit of the rangefinder.

My hypothesis is that due to long-ish missions I fly the ground pressure changes quite a lot resulting in such an error. My ground tracker has no GPS and thus no VELZ source and this is how the mostly immobile flight controller on the ground sees the changes in barometric altitude:

BARO.Alt
BARO.Alt1920×973 88.9 KB

I was under impression that somewhere in the Tracker documentation I saw it being used as a ground pressure source, but I can’t seem to find that functionality. The closest I did find are:

  1. Ground calibration in Tracker which is very odd to me as it seems to assume that the baro is mounted externally on a non-insignificant height and thus assumes the antenna itself is always at the ground level which is probably not where it is going to be for long range.
  2. Altitude offset in AP_Baro which seems to be doing precisely what I want, but is ArduPilot specific.

I would like to make a PR which adds automatic ground pressure corrections from the Tracker and thus I’m out for advice and want to know if I haven’t missed anything.

The way I see it:

  1. The tracker’s offset should rather mean the altitude of the antenna assembly above the ground and thus should not be used for angular calculations. It would be still captured by the same logic of comparing against the landed aircraft during the calibration step.
  2. We still calculate the difference of pressures in baro mode but we do not add the offset.
  3. If the barometer is mounted not where the antenna is located this can be made into a parameter instead. Since it is unlikely to change during operation.
  4. AP_Baro gets a MavLink handler that filters packets coming from an Antenna Tracker frame type and updates the altitude offset parameter based on the pressure and navigation status packets coming from the ground station. This way the operation should be transparent to non ArduPilot flight stacks because the parameter manipulation happens inside the AP code and we don’t rely on the parameter name in the Tracker-UAV communication.
  5. The Tracker already does send its global position packets therefore by passing the altitude offset from step 1 (in case of a stationary tracker of course) the UAV would be able to extrapolate what the current ground level pressure is and adjust accordingly.

I would be glad if someone gave me feedback on whether this all makes sense. Thanks!

2

Both barometers are subject to temperature drift.
If you have tracker and have RTK capable GPS receivers you can use GPS as altitude source. RTK pins the error so it is constans therefore RTK-GPS altitude can be used for landing on takeoff site.

3

@landswellsong Updating the barometer offset during flight isn’t a new concept. I’ve seen someone successfully do it through Mission Planner, and it worked quite well. Inspired by this, I’ve started working on a similar approach—adjusting the baro offset via ArduTracker.

@LupusTheCanine Exactly, since both barometers are prone to drift over time. We assume the tracker remains on the ground, so we can use its reported altitude (which drifts over time) as a barometer offset for the plane.

4

Make sure first that the ground baro is not influenced by wind direction and speed changes.

5

Temperature drift will be different for both barometers unless you use heated flight controllers like CubePilot or CUAV Cubes and both can maintain the same temperature which isn’t given in summer.