Servers by jDrones

Pixhawk Cube changing GPS altitude to barometer altitude without indication

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)


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

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.

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?

Using Drotek.

Had way too many problems with Emlid Reach M2


Ok thats good to know. I was contemplating to buy an Emlid. Thanks

The claim made by the author of this thread is bit confusing that the firmware switching between Barometer and GPS for Alt hold.

I am trying to figure out who is writing the Arduplane code these days. Is it Iampete or someone else?

I have a strong feeling that something has to be wrong in Arduplane code. At least sometimes our planes crash due to this situation. So it would be perfect, if Arduplane coder could join to solve this issue.

@UAVSkies, you were asking about our planes. See web page . There are some description about our planes and the company. We are conducting geophysical surveys, mainly magnetic surveys.

One thing for sure as some of us has mentioned, That upgrade to a better GPS. Here 2 also has issues. I don’t think Here 2 is any good. Just my opinion.

Servers by jDrones