My bet is this will be something really simple that I’ve overlooked, or a mountain…
We are working on a project that may lead to us operating drones in the same airspace as traditional aircraft. Altitude separation is going to be a critical component of this. The traditional aircraft of course read altitude referenced to sea level, with an adjustment for barometric pressure (altimeter setting).
I know how to get my height ASL, however that information is from the GPS. Is there a way to get mission planner (or QGC) to display the barometric altitude with an adjustment for the altimeter setting? The goal is not to have the most accurate altimeter, the goal is to have altimetry data that is the same as everyone else in the area.
Yes, it’s already there: It’s called “QNH”. You will find it in the status tab of Mission Planner. It’s a kind of “normalized air pressure” for the actual weather conditions calculated back to mean sea level.
It’s a common to use for synchronizing barometric altimeters in airplanes.
Thanks! I figured I couldn’t be the first person to look for this. But QNH? That never occurred to me.
I just tried it out.
It seemed to work with Plane (4.0.9, it was the first thing I had on hand with a battery).
It didn’t work with Copter. (4.1.3) I kept getting an error that said it couldn’t write to BARO1_GND_PRESS. I tried to change the value manually, and also use the “adjust aircraft baro height” in the CTRL-F menu. All came back with the same error. Does this function only work with Plane or is there some kind of error here?
I’ve been wondering about this for a while, and it was encouraging to see the QNH feature in Mission Planner. However, I tried setting it on an actual Rover running 4.2 and the parameter is read only. Since it’s silly to set QNH on a Rover in most cases, I tried Copter and Plane in SITL (both 4.2), and got the same read-only error you experienced.
Also, the units are not standard for aviation. They should at least be hPa, and there should probably be an option for using inHg for operating in US airspace.
Altimeter setting errors are all too often the cause of accidents and incidents. We shouldn’t let ArduPilot’s interface be a possible reason that one of our vehicles causes an airspace violation or worse.
I agree, it would be nice if the units lined up with the local ATIS or METAR, but that’s not a deal breaker for me. Canada also uses inHg for altimeter settings, but being between Europe and the US means converting between French and Freedom units is pretty common. I’ve seen many altimeters that have both windows for the settings.
My main concern is functionality of the feature. I’ll need it on Plane, and it would be a nice to have on Copter.
I’m sure it’s a non-trivial task to get various baro sensors on widely varied autopilots to fall in line close enough to certified equipment. I don’t envy that one bit…
If it makes it simpler, ADS-B isn’t an issue for me. This will all be radio. But I need to know that my reference for altitude is the same as the traffic around me to maintain vertical separation.
I’ve been tracing this problem down for a few weeks now. The most important fix is the proper calculation of barometric pressure to indicated altitude being in accordance with general aviation standard (i.e. non-temperature compensated). The following commit will be submitted as a PR soon to fix the incorrect calculation of altitude from barometric pressure (from the perspective of general aviation).
This is the first step in solving the larger problem as described. It doesn’t allow for changing the barometric offset from say a METAR etc for landing later in the day when the pressure has changed or at a different landing spot physically further away with a different MSL field elevation.
I’ll focus on the barometric pressure change problem later… Technically this approach would cover the situation, but I’ve currently put in safe guards such that you can’t change it in flight because things can go very poorly if you get it wrong.
Speaking as a non-programer: Could some of the safeguards be relaxed if the plane has a long-range lidar rangefinder for AGL and landing? Hopefully this could prevent a finger issue entering in the wrong altimeter setting and going for a dirt dive. High to low, look out below…
Depending on the company/country rules and regs, instrument certified radar/sensor based altimeters are often used to supplement pressure altimeters at the extreme terminal portion of an approach, with critical decisions made based on their readings. You can read just how critical they are in the news lately re:5G interference.
In the ArduPilot ecosystem, rangefinding altitude sources could be leveraged similarly to build a “composite crosscheck.”
I think you’re right. The landing page for ranger finders in the wiki does say “precision landings and altitude control” but the terrain following page doesn’t mention range finders at all. (For plane)
So the ranger finder is still valid for the landing portion of the flight, but won’t save a fat finger issue during cruise.
My interest is for VFR traffic separation. At this point we are far from being allowed to have a drone fly an IFR approach in controlled airspace. When we get to that (and I hope we will), then we’ll be needing certified altimetry reporting devices, both for pressure altimetry and any supplementary sources such as radar altimetry.
Agreed. The process is there for copter and I think that’s why I got confused with plane.
A Lua script could be used to prevent (or warn against) a severe fat finger, but the rangefinder should not, as a matter of practice, adjust the pressure setting automatically.
