Pixhawk Cube changing GPS altitude to barometer altitude without indication

Hi all,

I’m having challenges with Pixhawk altitude sensor. I have set GPS altitude as primary altitude sensor. reason to that is that I’m flying quite long flights, like 2 hours and barometric altitude is not reliable because air pressure can change during the flight time.

The problem is that sometimes Pixhawk changes itself primary altitude sensor from GPS to barometer and the reason might be that there is bad GPS signal for some reason. Anyway, I dont know this primary altitude sensor change at all and I cant see any indication about it from the Missionplanner screen or parameters or anywhere. So plane is flying smoothly and I am happy. Well… then sometimes plane suddenly crashes in the trees even the altitude seems to be high enough in the MP screen. And then I’m saying wtf … no, no not again ???

I have few MP logs where this situation is happening, so if anyone is interested to help with this issue.

Currently I’m using only barometric altitude and during the flight I’m monitoring the air pressure changes and update the altitude offset based on that. This altitude offset updating could be also autonomous but I’m doing it manually so far.

1 Like

Upload the logs…we can take a look at them.

The autopilot uses a barometer which measures air pressure as the primary means for determining altitude (“Pressure Altitude ”) and if the air pressure is changing in your flight area due to extreme weather, the copter will follow the air pressure change rather than actual altitude .

So I am not sure why you want to use the GPS for Alt. GPS altitude may be incorrect and unreliable.

Another thing to remember, " In ArduPilot , altitude can be gottten by following formula. alt = 153.8462f * temp * (1.0f - expf(0.190259f * logf(scaling))); temp = ground_temperature + C_TO_KELVIN(273.15);"

Ardupilot barometer drift is usually too large to be reliably used, especially for longer flights.

1 Like

One log can be found here.
Air pressure decreasing - crash

So I am not sure why you want to use the GPS for Alt. GPS altitude may be incorrect and unreliable.

Im flying B-VLOS operations and survey planes are flying about 2 hours in each flight. Flight altitude is about 40 meter from ground - plane is following terrain but not with terrain-follow mode. If air pressure changes during the flight so much that flight altitude is reduced 15m - 20 meters -> plane will hit the trees. Earlier years 2015-2018 I was flying only with baro, but then I started to test GPS altitude as a primary altitude sensor, which was working pretty well. I am aware that GPS signal can be incorrect and unreliable but in practice it has worked surprising well.

So how would you fly long flights safely - like several hours ?

@Implicit -> Yes, fully agree. I have seen that several time. Do you have any ideas or solutions for that ?

I was trying to avoid along answer but if you are keen on making Alt as accurate as possible, here are some food for thought.

In commercial airplanes, they typically use an Altimeter to maintain altitude. An Altimeter operates basically on the same principle as barometer, just different technology. Depending upon where on the planet you are located, you input QNH (barometric pressure adjusted to sea level) for the local area. QNH is provided by the tower when landing, and its different when you are 36,000 ft above the MSL (Sea level).

Inside Pixhawk, you have barometer. It is not a commercial grade barometer and not designed to give 100% accurate results. Also, it is susceptible to temperature variance.

Inside Ardupilot,

  • set TCAL_ENABLED to 2 (to learn and use calibration)

  • power down the board and let it cool for a few minutes

  • power on the board and leave it for about 10 minutes

  • learning will happen as the board heats up and while it is not moving

  • the TCAL_BARO_EXP should be updated with a non-zero value

  • optionally turn off learning by setting TCAL_ENABLED to 1 (to use but not learn new calibration values)

Source: https://ardupilot.org/copter/docs/common-baro-temp-comp.html

I will be playing around with this in few weeks so I can give you more lessons learned tips perhaps.

I don’t use $29 dollars GPS.

You can try something like this https://zubax.com/products/gnss_2 read the specs…

Adding few experts to help you out @dkemxr @smartdave @Marc_Dornan @rickyg32 @MartyMcFly

There are some people that do long mapping missions using RTK GPS exactly for the reason you state. This will produce a more consistent altitude over a long period. Regular Ublox M8 GPS is wildly inaccurate for altitude estimates.

Uploading a GCS ground level barometric correction has been discussed but it has not been implemented yet. It would be a great feature.

Yup, a $20 dollar GPS is useless for any commercial application.

It would be nice to see an external Altimeter for Ardupilot…maybe an overkill.

Is it possible to use lidar for your flight?

That would give you the most accurate altitude readings, providing you are not flying over trees and such

I wrote an article about LiDARs once


Long rage ones can cost upwards of $25,000 each

What is the average altitude being flown? You can get 150m ones for about $300

RTK GPS is a good option. I have bought Here+ and planning to test that. Only problem is that I guess it doesn’t help at all in this problem. I have set GPS sensor as primary alt sensor, so in this case it would be RTK GPS as primary alt sensor, that’s great. Now what happens is that during the flight (or in the beginning of the flight) autopilot changes barometer as a primary alt sensor (that’s my guess). Pilot is happy and also RTK GPS is happy, and MP screen shows that flight is going well. Only problem is that plane is flying based on barometer alt sensor, and the altitude is going down (in case that air pressure is changing). And then plane crashes sometimes.

That’s how it’s happening in my point of view. If you take a look the log file I linked in previous message, can you see and understand what is happening there? I’m not quite sure what’s happening. GPS says altitude is stable, baro and AHRS2 is showing that altitude is going down. GPS was a primary alt sensor. Plane was flying via planned waypoints correctly and for the pilot everything is ok. So something odd is happening.

1 Like

I have tested a lidar in the plane and it’s one backup option. Plane is mainly flying over the forest so the lidar values jumping quite a lot. One solution is desperately to predict from those jumping values when the plane is maybe going lower and lower. Quite difficult anyway. Our flight team is flying like 8-10 hours a day and this is maybe too difficult and painful task to follow so intensively lidar altitude values. In the field there also also so many other things to do.

If there is better solution, I’m interested to hear that.

1 Like

Can you post you parameter file…

I am checking your bin file. Also Tlogs.

I am eager to solve this problem as i will be doing what you are doing very soon…so lets figure this out.

There are now two folders available.

These two crashed has same situation. GPS alt is set as primary alt sensor. GPS altitude is showing that plane is flying stable and correct altitude and is not drifting at all. This is absurd ! Baro shows that plane is little by little going down.

I will transfer parameter files on Monday

  1. Kittilä crash - 2020.
  • only .bin is available
  1. Virtasalmi crash - 2019
  • .bin and .tlog files are there
  • Flight altitude is based on reference altitude and that’s why flight altitude looks quite low.
    You can roughly add 20 meters to the flight altitude to get real flight altitude.
    Waypoint altitudes are correct. Waypoints are about 15-20 meters above trees - following smoothly terrain.

One idea: could it be so that if for some reason autopilot decides that GPS is not reliable or available, then barometer is selected. And then game is lost. And why GPS altitude is showing totally wrong altitude in this case. Plane is going down and GPS is saying:“No, it’s not going down”. Or is there something what I don’t understand.

EK2_ALT_SOURCE: Primary altitude sensor source
Primary height sensor used by the EKF. If the selected option cannot be used, baro is used. 1 uses the range finder and only with optical flow navigation (EK2_GPS_TYPE = 3), Do not use “1” for terrain following. NOTE: the EK2_RNG_USE_HGT parameter can be used to switch to range-finder when close to the ground.

I am passing out its late here, I will check it thoroughly tomorrow.

I had a quick look at your bin file.

The barometer and ALT, wow…swigging like crazy.

Also, post a pic of your plane. I am curious what are you flying

Once we have all the data, i will invite a programmer that understands Arduplane code better than all of us.

We have been using GPS lately on a job that needs our quad to fly above a structure with an error of around 20-30cm. We are having good results.
We are using F9 GPS with correction coming from a cors service.
The only thing we have to watch is at the beginning of the mission before take off, when the gps goes to fixed, we need to give the system around 30 seconds to settle altitude. From that point altitude is very precise and consistent.
I advice on not to use anything less than an L1/L2 F9 gps receiver. With that on we fly for hours during a day and never loose RTK FIX.
You can inject RTK correction from MP or have GPS connecting directly to internet on the UAV, depending on your architecture.

For any specific pointers as to how to use GPS for primary altitude while mapping why do you not contact @Naterater. He is a mapping pro on these forums and is generally very helpful. I believe he does use such a setup with multiple onboard RTK units.

What brands have you tested so far. Any preference?