Hi
With altitude offset (GND_ALT_OFFSET), sure you can adjust the barometric altitude. But why in meter? This value can’t be set. It can be used, if I also have a ground altitude and see some differences…
A better solution is a preassure-offset.
How it can work:
Use 1013.25hPa (Standard preassure to calculate QNE) as default (e.g. GND_QNH)
Read absolute preasure
If GPS-Info is there, read Altitude from GPS and calcualte the QNH with the preassure
Make QNH adjustable in hPa (GND_QNH)
calculate altitude
Why QNH (read here: wiki.flightgear.org/Altitude)?
This value is available for nearly all airfields. A lot of stations sending METAR or similar real world weather info where QNH is allways available. This value can be grabbed with a lot of (free) apps. So when I’m in the filed, I will knwo this value all time. When I come in for a land, I can update the value and can land savely.
Is here the right place to discuss things like this?
@tridge Thanks, but I’m not happy with it. The ArduPlane Parameters list the following hing: “This sets the QNH pressure in millibars to be used for pressure altitude in the altitude limit.”
Well, I dont need this for an altitude limit and an advanced file safe. I need QNH to know the altitude. Sure, it calibrates on startup. But while in the air, this value can change. If the altitude should be right on landing, I have to check the QNH again and do some ajustements.
Should the request be changed to something like: If a value of Zero, then auto-calibrate the baro, if not use this value as QNH to calculate altitude.
Maybe you should describe a bit more what you are trying to achieve?
My guess is that you are trying to integrate with the QNH altitude handling used by full sized aircraft to ensure sufficient vertical separation between aircraft.
There are a few problems with doing that. Full sized aircraft can cope fine with altitude errors of tens of meters, as the pilot will either use visual sighting of the runway for landing, or will use sensors generally not available on RC models (eg. radar) to get accurate approaches.
In a small model flying at 40 meters the sorts of errors you get with QNH do matter.
Those errors stem from a few sources. First off, QNH is based on meters above sea level, which means you need a terrain model to turn it into an altitude above a flying field. Terrain models can have significant errors. So if you planned a mission at home based on AMSL using QNH then you may find your model flies into the ground. The ardupilot code copes with that by taking a barometric pressure reading at startup and assuming the local pressure doesn’t change much over the flight. That is generally a lot more accurate than using a QNH plus terrain model.
The second problem is the differences between barometers. The sort of barometers we use in ardupilot (ie. the MS5611) does have significant variation between sensors and with temperature. It is not a great sensor for absolute values, at least if you care about the last few meters of accuracy.
There are situations where a QNH based altitude would be useful in ardupilot. For example, if you want to fly long distances where the local pressure may change significantly, or if you want to fly at higher altitudes where QNH based aircraft separation with full sized aircraft becomes important then using QNH could indeed be useful. You’d just need to properly understand the limitations.
So if you can explain exactly what you are trying to achieve then we can try to work out how we can accomodate it.
Cheers, Tridge
I should also mention that changing the pressure reference while flying may impact the integrity of the EKF. We would need to discuss with Paul Riseborough how to cope with a sudden change in barometric reference.
Hi Tridge, thanks for that serious discussion. Are you from the Canberra UAV-Team? If so, congratulations! And you made a good review to technical details.
Yes, I will an integration into the real world. The kind of flying down under to find joe will never be allowed in Europe. Also the FAA discusses now, what Visual Line of Sight means. From our FOCA (Switzerland) I have an understanding what is needed. Flying BVLOS (Beyond VLOS) is one plart, flying within a CTR is the other. Flying there means respecting the separation as well as following the ATC-commands.
Separation is the part of law. There is also a part of business where the QNH is maybe not the best concept as you described above. I thought the sensors are better than they are… I assumed that they can be used for a precious landing too. Something I need. We plan to land on buildings. There is no room for faults! Best there will be waiting for LIDAR?
The last part where I expect some advantage of QNH is flying in our mountains. We will find Joe up there when the “normal” helis don’t fly anymore (bad weather). I then need to know the exact AMSL. We have access to official and detailed geo-info. Sometimes we cant see obstacles but we know where they are. So knowing where we are may help. If you don’t have to calculate to the relative high on launch may prevent some errors too. And in this weather-constellations, the QNH may vary often within our operation of 2h airtime.
Well, back to ArduPlane. I don’t need terrain following or tricks like that. Probably I also don’t need this in any automated mode. For first solution it would be enough to just have the AMSL-Value in the HUD (ladder?) or any other gauge. If we get an ATC-command or flying in bad weather, we plan to do it only in assisted mode. What do you think about the following:
At startup you can tell QNH as well as the AMSL-Value of the startup-point. Like this, AP can run with relative altitude and can display the AMSL according to QNH. With some experience of this, we can discuss what to do with QNH in a version 2.