As mentioned in topic below, there is altitude error problem happens between GCS-alt and Baro-alt in arducopter when EKF2 is running.
Here we had a test in arducopter v3.8 rc5 too, alt error(10meters) problem happens too with EKF3 opened (pic below).
As rmackay said there are various altitudes based on various origins, but the question is which one should we trust? Is this normal?
You are looking at the same value (baro relative altitude above home) in three different points in time in the HUD, graph, and list. Of course they’re different.
I have updated the pic. You can obviously saw that the baro alt never goes down to zero until the plane landed from the baro alt curve, but the GCS alt is zero.
I guess this is a plane question?
Baro.Alt: altitude above EKF origin
CTUN.alt: altitude above home
@rmackay9 Thank you very much for your answer. This is a copter question. This problem happened both in plane and copter. What I want to know is why the value difference between Baro.Alt and CTUN.Alt is so big? Is this normal?
So I think this is normal and is caused by Barometer drift which can be worse especially as the board heats up. It really depends upon the weather but a barometer drifting by 10m in 10 minutes is within the norms.
I think your question now becomes, “why is the home altitude so different from the EKF-origin’s altitude?”.
The EKF Origin is set once soon after we get a good GPS lock (the EKF decides what is “good” based on various factors like number of satellites and reported accuracy).
The Home location is set once when the EKF origin is set (at this point the two will be in almost identical locations) and then again when the vehicle is armed. Home can also be set or moved from the ground station by right-mouse-button clicking on the map and then selecting “Set Home Here”. If you do this, I think you’ll see the CTUN.Alt and Baro.Alt move quite far from each other.
Each time the EKF origin or Home is moved, you’ll see ORGN messages appear in the log. One of the first fields, “Type” of the message specifies whether it’s the EKF Origin (0) that’s been set or Home (1).
As a side note, in AC3.5, there is a small potential issue with the EKF moving it’s origin altitude around to compensate for barometer drift. We have a patch coming from @priseborough that will turn this off and this will very likely be included in -rc6. I don’t think this is related to your question but adding it just in case.
@rmackay9 Thank you so much. I understand baro always dirifts, especially when temperature changed. And about the ORGN message we have not seen it before, also we have checked that the origin or Home is not moved. But in our flying test, we confirmed from rangefinder(sf11c) that the the flight alt(e.g.100m) is right, also in our experience we know its right, and from log we saw that Baro.alt is right(100m), but in the tlog the CTUN. alt is not right(big error). Then are you saying that the alt above home(CTUN) got big error just because baro drifting?
I don’t see a log that describes what you’re seeing unfortunately.
I’ve opened the log linked above and BARO.Alt, CTUN.Alt and CTUN.BAlt are all nearly identical. There is no range finder attached in this log.
@rmackay9 Yes, there is no rangefinder in the log above. But in the pic above couldn’t you see that the same moment Baro.alt = 10 and GCS.alt = 0? Also from the baro alt curve you can obviously see that baro alt never goes down to zero until copter landed, but the GCS alt have a zero moment before landing.
It’s fine for the two to be different though as explained above re the difference between alt-above-ekf-origin and alt-above-home. I think I might duck out of this discussion now and leave you to struggle a bit more with it at least until you find an issue that affects flight control.
Thanks for using ArduPilot and best of luck.
Furthermore the HUD shows you’re starting a climb. And the HUD is night updated by the microsecond. Whereas the dataflash log is updated very very rapidly. And you still have different points selected on the graph vs the table vs the HUD. So I still don’t see anything wrong here.
Could you please explain my case when both BARO and SONAR altitudes agree, while estimated altitude at some point suddenly (probably, after EKF switch) drifts for several meters:
@arifg Im so confused about the CTUN.BAlt, CTUN.Alt, CTUN.DAlt, CTUN.DSAlt, CTUN.SAlt, CTUN.TAlt? Where can I find the detail explaination?
I’m not a developer, though I have some experience in control automation and programming, so this is as far as I understand:
CTUN.BAlt - Barometric altitude;
CTUN.SAlt - Sonar (Rangefinder) altitude;
CTUN.Alt - Calculated (estimated) altitude, the altitude which controller assumes as current after processing data from the sensors;
CTUN.DAlt - Desired altitude - the altitude which controller “wants” to be, usually, when everything is right,follows CTUN.Alt with a small time lag.
Again, this is my understanding, not a formal description, somebody from developers would probably correct me…
any conclusion? I got the same problem. It causes the copter the crash
Can you elaborate on “it causes the copter to crash”? I don’t think this is something that causes crashes.
It does. In Auto mode it causes to copter to mistake in altitude evaluation and it crashes into a tree or even into the ground when altitude became negative. I experienced this several times but saved my copter by switching to manual at last moment. Can’t rely on auto mode outside of reception range for this reason.
My problem happens in loiter mode. There are two scenarios: fly up uncontrollably or fly down uncontrollably which would result in a crash. Please see the log file: 1 5-24-2017 3-24-02 PM.bin (160.4 KB)
I suspect this is a different problem than the one in this thread. I may repost it in another thread.
@nealjing yes, it would be wise to start a new thread.
And a log of an actual flight plus a description of exactly the process you went through and the result you saw would help.