And the unfortunate pity is no (pro/developer) even has a suggestion. So many views and not a single replay/idea
The answer isn’t simple.
How do you got the real altitude of the plane ? Good question.
Currently, the ardupilot use mainly barometer but it is not a 100% reliable. The barometer gives an estimation of the altitude based on the pressure difference between the start point and the current position. The pressure reading is done with the sensors accuracy and many things can disturb it : UV, wind, temperature etc. So the estimation altitude from barometer isn’t 100% reliable.
Maybe I am wrong but I think that ardupilot fuse the altitude from all the sensor it has available to have a better estimation.
That means that the barometer reading is fused with the rangefinder reading and GPS alt, and perhaps estimation from IMU (?).
About the rangefinder : what the accuracy at 100m ? And does it got the altitude from ground or from a car or a tree ?
For the GPS reading it is the same thing : you only have an altitude estimation ( There are some black magics involved here so I won’t try to explain why)
So the question is how to have a reliable altitude estimation when you don’t have a good reference ? It isn’t simple as you got no way to know which sensors is giving you the better reading.
So about your question, you are looking two different parameters : the reading from the barometer and the altitude estimation send to the GCS. So the fact that the values aren’t the same isn’t an error for me as they are different things.
PS: about pity that developper doesn’t respond. This is a community work. So people answer when they got time or if they know … And generally it is always the main developper that are answering. So you can’t expect a direct answer on a question post since 1 day. It is free-time unpaid help. So be patient. And try to participate yourself on other subject if you can !
Unfortunately what you wrote does not explain the situation. Especially mine. I am fairly sure that both I and Firefly knows about the various altitudes. Baro, GPS, AMLS, etc. We all know about baro drift and have seen if happen multiple times. I build multiple UAV, most of them are using in Africa, there are some crazy pressure changes there. We know how to combat that. This is different. This is not just premature landing, but messes up the pictures as they are taken a wrong altitude and the overlaps are not what they should be and so on.
The thing here is (if you look at my topic, not rangefinder involved) is that the plane is reporting that it is lower than the required altitude, but it is not making any effort to correct it. That is will report alt error (current altitude vs target altitude), however does not climb to it. All this why having not trouble climbing and most weird of all, doing this on every second mission (same UAV 100% same hardware, same day same weather).
PS: I know how the support work. I am not ungrateful. What I meant is that it is so frustrating to have a bug so weird that even the knowledgeable people don’t know what to say about it or have any recommendations on what to look at.
I have posted this problem in other topic a month ago. Few plane player here, so I dont expect of a immediately answer. But I think this is a big problem here. And I actually know the different alt there, and the flght is not right. Using a rangefinder(SF11) is just to prove my opinion.
A issue I posted before, plane got stuck in loiter to alt mode, and this is caused by the alt error too. When alt error is big, plane gets stuck.
Looks like we all have the same problem.
I have been reporting a similar issue: Sonar on a Quadplane
My problem is that the altitude difference makes the landing un-reliable.
My proposal was to use a rangefinder (LIDAR or Ultrasonic) in the final stage of the descent to generate a flare and ensure a soft landing.
I have noticed a similar behavior, from 4 flights 2 or 3 are OK, sometimes I have very big altitude differences.
Waiting for the developer guys to handle this problem.
To support Pomper and Firefly’s points of views, being only a user I have flown quite a few missions with Pixhawk based planes and I have not seen this issue before. Yeah, occasionally you would overshoot a couple of meters but not by huge amount of meters. This issue however is related to something definitely going wrong. Its consistency and repeatable proves so. The system we are currently facing this issue with, has been flown at an area which is relatively flat and only about 200m above mean sea level, leaving wind out I would expect atmospheric pressure is pretty constant due to lack of mountains. Hence the plane should not experience major varying atmospheric pressure. It was then flown at an area that is about 1500m above mean sea level also pretty gentle area. At both locations in total we are talking about many flights most of which exhibiting similar behavior.
Are you flying with firmware 3.7.1? Here if the flight is long enough, usually > 10minutes, the alt in GCS must drift >10m, and the landing accuracy must be so bad
On condition that the EKF2 is turned on, and EKF1 is turned off.
Yeah we are on 3.7.1
Arduplane v3.7.1 AHRS_EKF_TYPE cant be set to 1, is this an issue? If set to 1, after reboot it returns to 2 again.
Now I am using EKF1 not EKF2
And the EKF status on Misson planner is off too.
Currently, they are very, very silent. I hardly see any replies from any of the developers anymore.
There have been many changes to plane altitude recently, please give plane 3.8beta a try. V3.7 is a little old, and that’s our fault. We keep delaying it because more and more major things kept getting added.
@MagicRuB Thanks for your advice! We have tried 3.8beta, there is a problem that my plane didnt use rangefinder during landing process, and we have not resolved now.
we have not resolved now
… so it’s unresolved? What’s the problem?
Here I have posted the log.
I have checked all parameters related to rangefinder, but have not resolved it.
@FireFly we’re concerned about the rangefinder issue you’ve brought up. Would you mind creating a new discuss issue so we can track it there instead of cluttering this issue? Meanwhile, we’re pretty confident this altitude problem is fixed in v3.8
@MagicRuB Thank you so much for your answer. I will create a new discuss right now.