Baro vs. GPS altitude in longer auto missions

[Holger Steinhaus]

Hi,

in AUTO mode, ArduCopter is currently controlling it's altitude using barometric pressure. On longer flights, the changes of barometric pressure can add up to quite some difference, e.g. due to thermal activity or weather changes. The plot attached shows a rather short copter mission (20 minutes). The alt difference is more than -8 meters. 

The problems caused by this behavior are obvious:

• auto-land or RTL/Land are stopping the fast decent at 10m (hard coded) - only 2m left for stopping in the attached example :-O
  
• most airspace regulations relevant for us are expressed in height over ground (AGL), not over a certain baro value at time of takeoff
  
• counter-intuitive: you do your flight planning, working with absolute GPS coordinates. At least you do for x and y cordinates, but not so for z.

I guess we need some GPS compensation for CTUN.Alt in the long term? Any plans for that in ArduCopter 3.3? I think I remember an existing Github issue - but can't find it right now. 

How is ArduPlane handling this issue?

Regards,

  Holger

[Thorsten]

Hi Holger,

I reported the same issue a while back: https://groups.google.com/forum/#!topic/drones-discuss/xzUL7P9gNU0

Another problem is image processing/georeferencing.

Paul was working on something (https://groups.google.com/d/msg/drones-discuss/xzUL7P9gNU0/UQfZogS9OYoJ) but the link he provided is dead.

Would be really good if the baro alt would be adjusted according to the GPS alt.

Cheers,

Thorsten

[Tom Pittenger]

The way plane handles it is to never use GPS for alt. Ever. It has much worse error than GPS. The GPS system is optimized for Lat Lon and the advertised accuracies of 3m or whatnot only apply to lat lon. Height is much worse, 10-20m and tridge has even heard of 80 meter errors.

The solution in place is to use an absolute agl accuracy system such as sonar or LIDAR.

--
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.

[Craig Elder]

I think Tom has a typo in his message.

It should read:

The way plane handles it is to never use GPS for alt. Ever. It has much worse error than the barometer.

[Tom Pittenger]

yes, sorry. I wrote that reply on my phone. <facepalm>

[Jin Chengde]

In the plane, we use QNE if the plane above 3600 meters（in china）， if we below that altitude , then we will change to QNH .

APM also have the parameter to adjust you baro drift.

then you have one apm in ground to read the QNH and send it to the other apm in the air.

does MP have some function to send the QNH to apm in real time?

[Thorsten]

In all tests I made the GPS altitude is much more consistent, i.e. no or at least much less drift compared to the baro. There had been other reposts recently about bark-altitude drift as as well (e.g. http://diydrones.com/group/arducopterusergroup/forum/topics/building-copters-with-round-tubes-stronger-lighter-easier-to?commentId=705844%3AComment%3A1938681&groupId=705844%3AGroup%3A394475).

For sure it might not the best idea to relies on the GPS only - at least as a general setting. I am hoping that some adapted EKF will help to merge the data reasonably. Maybe a failsafe can be triggered if the baro and the GPS alt diverge over some threshold. Maybe 10-15m. 

Since flight times are increasing constantly this problem will become more important.

For flights in open fields the PDOP with an M8N is often around 1. So for normal long endurance flights 10-20m or even 80m sound strange. (btw., out of curiosity: why is the PDOP reported as HDOP in ardupilot?). Ah, ok, I guess we must differentiate between absolute and relative accuracy. So a DOP can be low even if there is a big offset. But for navigation in ardupilot the relative measure is all that counts - or? And if there would be a sudden change in the offset the failsafe could be triggered.

[Holger Steinhaus]

I remembered that this issue was already discussed somewhere. Because this issue seems to be important for anybody flying longer than a couple of minutes, I have opened https://github.com/diydrones/ardupilot/issues/2022

 

In all tests I made the GPS altitude is much more consistent, i.e. no or at least much less drift compared to the baro. There had been other reposts recently about bark-altitude drift as as well (e.g. http://diydrones.com/group/arducopterusergroup/forum/topics/building-copters-with-round-tubes-stronger-lighter-easier-to?commentId=705844%3AComment%3A1938681&groupId=705844%3AGroup%3A394475).

For sure it might not the best idea to relies on the GPS only - at least as a general setting. I am hoping that some adapted EKF will help to merge the data reasonably. Maybe a failsafe can be triggered if the baro and the GPS alt diverge over some threshold. Maybe 10-15m. 

Since flight times are increasing constantly this problem will become more important.

For flights in open fields the PDOP with an M8N is often around 1. So for normal long endurance flights 10-20m or even 80m sound strange. (btw., out of curiosity: why is the PDOP reported as HDOP in ardupilot?).

After browsing through about 10 logs with auto flights between 30 minutes and 1:10 hours I can absolutely support that statement. I did not find any suspicious glitches/deviations in the GPS.Alt. I think together with averaging over a minute or so, the compensation should not cause any side effects.

 

The solution in place is to use an absolute agl accuracy system such as sonar or LIDAR.

I would not expect that these units perform well in a height of 100m and over changing vegetation. 

Holger

 

[Tom Pittenger]

The new pulsed light LIDAR lite is advertised to work up to 40m but in reality I get about 37-38 but cut the limit off to 30m to ensure reliability.

--

[Jon Farhat]

In civil aviation, the Altimeter is constantly changed over a cross country flight to update to the nearest reporting station.   In fact, I find that my altimeter is dead nuts perfect to the Garmin on board.

Sure would be good to operate the same way.  Use both to determine your position.   Sure would be good to work in absolute altitude, set your pressure, compare to GPS, call that home and launch.

I know, I know, I'll get a flood of "this is a hobby system...." comments.    But seriously, can't we learn from this?  APM is becoming a serious tool for professionals and everyone I know is asking absolute altitude control and Baro AND GPS integration into that.  NOT Baro vs. GPS.

[Jon Farhat]

In regards to :

• most airspace regulations relevant for us are expressed in height over ground (AGL), not over a certain baro value at time of takeoff

Like civil aviation doesn't consider AGL?  This doesn't make sense.    Waypoint Mission Flight plans should be written in MSL.   Period. 

On Friday, March 27, 2015 at 1:25:27 AM UTC-7, Holger Steinhaus wrote:

[Jon Farhat]

I'm not proposing to eliminate the current, HOME=zero alt concept for the bulk of users.  My humble opinion is that APM should support (as soon as possible) how aviation currently addresses the issue. 

My question regards advanced use, not hobby folks.  So please don't reprimand me for 'imposing' complicated procedures on a hobby market. 

Pressure Altitude:  Indicated Alt when altimeter is set to 29.92 

Density Altitude, (Pressure alt, corrected for non-standard temp)

Is it really that hard to input a launch point's altimeter setting to the APM?

If you know your cross-country flight path, you also know the variation along the way. (again, pro use here).

We've done tests with repeating the same waypoint missions, at identical and divergent atmospheric conditions.   The identical conditions proved out to altitude accuracy of 1 meter.   Seriously. 

Then when we launched on a hot day, or with an inversion... yes then we saw 5 meters resolution.

The point is, the only obtaining good weather info, produces good alt results,  why can't the serious users have that option?  

That's all we're asking.  Not to uproot your entire attempt to keep the FAA out of your pants.  Believe me, these are questions our FAA friends are asking.  

On Friday, March 27, 2015 at 1:25:27 AM UTC-7, Holger Steinhaus wrote:

[Tom Pittenger]

In a way we do update our AGL by using the terrain follow mechanism. So, when enabled, the home !=zero for the whole mission.

As far as updating baro in flight, what you are refereeing to is differential baro readings. In a self contained system there is no way to fix that. If there is a telemetry link to the ground then in theory we could have another APM device connected on the giving updated baro readings of zero agl, just like an air port does. However, that only works of you are within range of telemetry.

The next level, which is the ultimate solution, is to have a 3/4g link checking the weather every few minutes and getting the baro info for the exact area you're currently at. This would be a relatively easy thing to do for a companion computer running Linux.

--

[Jon Farhat]

Tom, those are fantastic suggestions, especially the latter.   Would be brilliant to implement that.  We’d do anything to help!

You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/idiv0aHJA-0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

[Jon Farhat]

As a first step towards this:

The next level, which is the ultimate solution, is to have a 3/4g link checking the weather every few minutes and getting the baro info for the exact area you're currently at. This would be a relatively easy thing to do for a companion computer running Linux

Consider on a typical cross-country flight, you know your Altimeter setting at takeoff, and only when you are nearing the airspace of the destination airport, do you call ATIS and get the new ALT for that field.

Meaning, even if the ‘update’ system you define for now ONLY uses those two points, it would revolutionize waypoint missions, planned in MSL.    Update in flight, next to that.

On Mar 29, 2015, at 9:31 AM, Tom Pittenger <t...@airphrame.com> wrote:

You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/idiv0aHJA-0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

[Holger Steinhaus]

Hi Jon,

 

• most airspace regulations relevant for us are expressed in height over ground (AGL), not over a certain baro value at time of takeoff

Like civil aviation doesn't consider AGL?  This doesn't make sense.    Waypoint Mission Flight plans should be written in MSL.   Period. 

Why would writing waypoints in MSL help here? As long as the barometer still is the only source of altitude information, short-time changes in air pressure still wash me up into the forbidden airspace (if it is rising). And changes in the opposite direction make me crash into ground at my takeoff site during auto-land, if the air pressure change is large then the 10m that are hardcoded into ArduCopter for "flaring". These changes happen all day, when there is the slightest thermal activity.

Holger

[Holger Steinhaus]

I don't think that a differential baro is needed - just (very) slowly adjust the ground pressure so that the baro height stays close to the GPS altitude minus the GPS home altitude. Off course heavy filtering an averaging (lets say over a minute or so) is needed to suppress noise and glitches. 

Holger

[Jon Farhat]

Holger

Exactly.   Writing missions in MSL allows for the variation in launch positions.   Trying to exchange and edit missions, always as an offset from the exact takeoff point is really a pain in ass.

Download ForeFlight or any civil or commercial aviation planner, and all start their plans in MSL.

If you upload a flight plan to a service, or monitoring or ultimately "Field Services” they are not going to want to see some offset from a launch point called zero. 

If this community is serious about being accepted by governing powers beyond the knee-jerk limitations they’ve imposed, we have to start thinking about flying drones like you would fly full manned aircraft. 

It’s just sloppy to work in AGL all the time.  I get it for the hobby world… but just trying to look ahead. 

--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/idiv0aHJA-0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

[Jon Farhat]

One last point to consider.   In discussions with the FAA recently, there is a scenario floating around that would involve authorizing repeatable flight path routes as a first step.   Sort of micro-airspaces.   Considering issuing wavers for that before full FAR/AIM is issued.

All they need to worry about is when it launches and if it lands at it’s destination, abeit now a round-trip. 

Being able to offer flight plans in MSL units is essential in our opinion. 

You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/idiv0aHJA-0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

[David Pawlak]

It's pretty much accepted that altitude tolerances are pretty "rough", even with instrument flight rules. It's been a long time now so I don't really remember exactly what the tolerances are, but even if it was 100ft ( I think it's more like 300 or so) on drone scales, that's still a lot.

In general aviation they correct every once in a while to local pressures. We could receive a ground reference from the GCS, which may not represent aircraft "local", and hope of course that we don't loose GCS connection. If we return to home, we sohuld be OK (as long as we've made it that far) by using local pressure for landing.

General aviation uses pilots to control altitude, (FPV?) and or generous IFR ground clearance minimums.

[Tom Pittenger]

For the record, msl altitude is obviously available from GPS, it's just somewhat useless for navigation so that's why agl is used. The value is available for downlink proposes or whatever comms and differential stuff we need it for.

--

[Tom Pittenger]

Also, I was perhaps under the false impression that everyone was aware of the Plane param "ALT_MIX" which does exactly what you guys are asking for with regard to slowly blending GPS alt and baro alt (in either direction). I believe this feature has been depreciated due to GPS being measured as much much worse than baro, although I'm not sure if those tests were done in the USA which included WAAS.

-TomP

[Holger Steinhaus]

Hi Tom, 

very interesting that Plane seems to have a feature similar to the one that I am missing. However, it seems that this is a dead end now (there is no code that seems to use this param anymore since ArduPlane 3.0.0). Before abandoning it, AP was using the GPS info directly for altitude control (I have looked into AP 2.69). I can absolutely understand that this approach leads into big trouble, as the spatial and temporal resolution of GPS altitude info is too low for this purpose and the noise/glitching is high!

But this is not, what I am talking about. My intention is to slowly turn the little knob on the altimeter, until the long-term difference between GPS height (=GPS altitude - GPS altitude of home) and the baro height vanishes. This should happen in small steps, lets say a few m per minute, while altitude target is constant. This approach is also fully compatible with future extension towards terrain following.

I have started to implement this approach - it seems to work ok in the simulator. As soon as the weather permits I will do a test flight, still without compensation but logging the offset that would be used for. 

BTW, the wording for height, altitude and elevation seems to be a bit strange in the baro code. Is this intentional?  It is completely against the usual standards used in aviation, what IMHO promotes bugs and makes it hard to understand. For comparision: http://en.wikipedia.org/wiki/Altitude#/media/File:Vertical_distances.svg

@tridge: added you into CC, as you seem to have removed the alt_mix functionality in ArduPlane 3.0.0

Holger

[Holger Steinhaus]

As mentioned in the last post, I am working on a patch that implements some kind of automatic QNH (ground pressure) adjustment of our barometric altimeter, based on a filtered GPS altitude signal. Today I made a longer copter flight (72 minutes in Auto - what a boring thing ;-) ). As the plot shows, I would have suffered an altitude drift of 13 meters again during this flight, which is about 14% of the chosen working altitude of 95 meters. Due to the ground pressure correction, I stayed in a band of about 3 meters for more than one hour. The improvement came at the cost of some +-1.5m additional height jitter. For my intended mission type, this is not really a bad deal, but I think there is room for improvement by better tuning of the low pass filter.

If anybody is interested in this patch, it could be found in my repo: https://github.com/hsteinhaus/ardupilot/tree/gps_qnh . Currently, the patch is based on a two day old master, but I am working on adapting it to Randy's latest changes to the home altitude logic. A pull request will follow then.

The attached plot was recorded with the GPS altitude low pass set to a time constant of 1 minute (correction delay for filter warm-up: 90s), with a correction step size of 1cm/second. While the step size seems to be fine, I will try some more rigid filtering during one of the next flights (tc = 3 minutes, warm-up delay: 4 minutes). 

Holger

[Thorsten]

Hi Holger,

(since I cannot find my reply it seems I accidentally replied to you privately but not sure - too tired...)

Great! I just wanted to ask if you had a chance to test your patch! :-)

I hope to find some time next week to test test it. I'll contact you.

Cheers,

Thorsten

[Tom Pittenger]

This is where lidar comes in handy. Have you tried it? Would it work for your application?

--

[Holger Steinhaus]

Hi Tom,

I don't see how Lidar could help when flying in 90m AGL, particularly over forests with 20m trees or other irregular vegetation. The Lidar signal would probably be more than noisy here (way more noisy than the GPS reference IMHO).

The current implementation of the Barometer class might be good enough for flights in the region of 10 minutes, but is obviously not sufficient to maintain altitude during longer auto and loiter flights in the >1h region (cf. my plot in the initial post - altitude deviation 10% in 25 minutes of flight, that means a potential drift >20% per hour, on a quite normal day with rather quiet weather). For longer flights, we either need a way to continuously re-adjust the baro via ground station interaction, or some smarter way.

@Thorsten: yes, did a couple of flights so far. But no expressed or implied warranties...

Holger

[Hugues D]

Hi Holger,

I just posted a blog on diydrones (http://diydrones.com/profiles/blogs/1h-15min-flight-time-airbotservices-x4-with-brushless-gimbal) showing an altitude management issue during a 1h15 flight in loiter mode. Worse and more worying, I'm noticing this baro drift issue on the bench after a few minutes only.

Does you patch work for Arducopter too or only arduplane ? If ok for Arducopter, do you have some instructions to install/use the patch ? I would gladly test it. I intend indeed to do autonomous surveys above forests for at least 20 min flights...

Thx,

Hugues

[Alex Dinovitser]

I can't believe that nobody has considered using the Flow-Camera for height over ground (AGL) measurement!...

As the camera moves with the vehicle, the image of the ground moves across the sensor chip providing a parallax speed measurement. The GPS RTK provides accurate real ground speed measurement. The ratio of the two measurements is the ground clearance.!. 

I know it's not this simple since you have sway and vibration of the camera to compensate, however, that can all be averaged out in software using eg: EKF or whatever. 

Also, when the drone is holding its horizontal position and is moving vertically, (eg: to land), another algorithm can be used to measure its distance from the ground using the Flow-Camera. This algorithm measures the relative parallax speed of points across the image (eg: at the corners and in the center) of the flow camera, such that the the vertical speed approaches zero as the drone approaches the ground, for a fully automatic landing!

If someone is interested in working on this, please let me know.

AD

[Holger Steinhaus]

Hi Hugues,

very interesting report on diydrones, impressive flight time! 

I did not try my patch with ArduPlane yet. I think the changes to get it working should be rather trivial, but I have no deeper knowledge of Plane yet. So I would prefer to get it working with ArduCopter first.

The instructions for trying the patched version are rather simple: 

1. checkout the patched version from https://github.com/hsteinhaus/ardupilot/tree/gps_qnh3

2. build and flash it

3. tune the new GND_* parameters. I recommend to start with the following values: ADJ_RATE=1.0, ADJ_TC=180, ADJ_DELAY=180. Using these values, the GPS altitude filter will wait for three minutes before stating to compensate, rejecting any signal component with a higher frequency than 1/180 Hz. The adjustment will happen with a rate of 1 cm/second. 

I think the patch should be capable to handle the thermal drift issue as well.

However, please consider that the patched version is based on master (just before the latest, possibly breaking, series of changes went in). So it is well possible that there is some code, even if not related to my patch, might crash your copter. Of course my patch could break your copter as well ;-). So you have been warned...

@Alex

Interesting idea. There are two reasons why I did not try OF yet: the first the reported interference of the OF module with GPS signal quality (which is extremely vital for my application), second the complexity and added weight of another sensor. I still believe that we already have enough sensor redundancy to remove the effect of changing air pressure. However, if there is a demand for true terrain following, the OF approach could be probably way more powerful.

Holger

[Alex Dinovitser]

I think the community needs to address the issue of EM interference, which may be a root cause of much drone misbehavior and instability. Most of these problems have simple solutions, however, I have seen much poor design and little consideration of these matters in the community.

For example, if the flow camera interferes with the GPS receiver around 1.5 GHz, an appropriate remedy may be an Aluminium foil clad plastic enclosure for the camera, Simple!

We might need a separate forum for this discussion.  What do you think?

--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/idiv0aHJA-0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

=====================================================

Dr Alex Dinovitser

Ph: 0428 268 157

https://www.adelaide.edu.au/directory/alex.dinovitser

=====================================================