RelAlt Disparity

Hi Devs and All,

There are lots of different altitude meaures in the log files.
I was flying a mission 39m agl. (should have been 40…)
The only measure around this value is CAM.RelAlt. All others are about 4m higher. Hence, my questions are:
Why are they higher and is there a measure giving something like the CAM.RelAlt for the whole flight?

I am also wondering why CTUM.BAlt/AHR2.Alt is drifting the exact same way as GPS.Alt.Normally, they diverge. And how can it be they are 10m off just from the start?

Thanks a lot and best regards,

I guess it does not really matter but this data is from a Pixracer with APM:Copter V3.4-dev (0eac5a5c) From July, 4th and an M8N GPS.

Can you post the log? Thanks.

Hi Francisco,
thanks for looking into it!
You find the log at:

The 10m offset is there from the beginning.
The first Mode change (to Loiter) was during booting. But that was most probably me.

Somewhat unrelated I think:
What also looks a little strange (to me…) is that there are two WP files generated in Mission Planner. It seems that MP reads the mission stored in the log file and then constructs a second mission based on the cmds found during the flight.
The mission was generated with Tower. The first file, i.e. the mission stored after the PARAMS section, contains a WP “0” with an agl of 148m. But it is ignored during the mission - which is ok… But why is it ignored and where does this behaviour come from?

I had a look at two other logs (subsequent flights in the same area and day).
CAM.RelAlt is 2-4m below BARO.Alt and POS.RelAlt in all logs.

WP 0 is home.

I’m still looking at the logs to come up with a reason. If you could produce a log with this difference but with LOG_DISARMED turned on it might help.

Thanks a lot! I’ll make test test flight tomorrow with LOG_DISARMED turned on and the latest firmware installed and then post a new log.

Re WP0: Makes sense, but then there must be a “bug” in Mission Planner because it shows WP0 as part of the mission. Maybe @Michael_Oborne can have a look.

Thanks and best regards,


Hi Francisco,

at you find a log with LOG_DISARMED turned on from today flying the latest master with Paul’s EKF enhancements (8793c75). This time as well as in four other flights from today the offset was 2m.
Tower reports a failed “Above ground estimate”. Everything else is fine.

Let me know if I should run some further tests/settings?
Thanks a lot as usual!


Thanks. I think I understood why it happened in the previous log but I’ll look at this one too. Yesterday and today has been spent celebrating Portugal’s win in the European Cup but I hope to return to my “duties” tomorrow :slight_smile:

1 Like

:soccer: Congrats!!!

1 Like

Hi @Thorsten,

Sorry it took me so long to answer. As you have noticed we have multiple altitude logging (maybe too much?). And we also have multiple reference points:

  • EKF origin
  • home
  • terrain

This means that usually we can get relative altitudes to any of these points. Even baro altitude is a relative altitude (to the ground pressure).

EKF origin and home don’t always have the same altitude, it depends on how much drift happens between setting one and the other. In this last log it is clear that they have that 2 meter altitude diference, you can check the ORGN logging: EKF origin is set at 140.08m and home at 142.00m.

The relative altitude in the CAM logging is relative to home: this means that when it logs, it gets the current altitude and subtracts the home altitude. Since the home altitude is about 2 meters higher than the origin, you get a relative altitude 2 meters lower than if it would be compared to the origin.

Does that clear your doubts? If you have any other question, go ahead and I’ll try to explain it.


Hi Francisco,

thanks! I am happy that it is a feature and not a bug!

However, I am having a problem with it. It seems there is not enough altitude logging :wink:

For all mission planning and analysis the RelAlt-AH (above Home), which is now part of the CAM log, is important. It is the altitude you want the survey (or auto mission in general) to take place. The problem is that this information is only available in the CAM messages in AC3.4. But depending on mission planning the CAM message and thus the auto mission altitude is not available during the entire flight.

CAM message recording is triggered by CAM_TRIGG_DIST > 0. And, for example when planning a mission in Tower CAM_TRIGG_DIST is set to a reasonable value (> 0) when the first WP is reached and reset to 0 after the last WP is reached. But the RelAlt-AH value might be important for mission analysis for the entire flight for several reasons - mission analysis in general, interval based camera triggers, video based photogrammetry, object detection, etc…

In AC 3.3 RelAlt-AH was part of the GPS log. It was removed by @tridge two month ago for technical reasons:

I suggest that RelAlt-AH and RelAlt-EKF are both logged in the POS log - or any other place which might be more appropriate.

Should I open an issue at It would be really great if this could be solved before AC3.4 is officially released.

Cheers and thanks again for taking time looking into it!

I don’t want to say that for sure we aren’t logging relative altitude to home, but, if we are, I couldn’t find it. So, yes, I think you can open an issue for it - but I can give no promises that it will be addressed, I would say the chances are low.


Hi Francisco,

thanks again for your support!
I opened an Issue at:

I think it is important to have the correct altitude above ground logged - especially from the user’s perspective - since this is the RelAlt value which is expected and because it can be correlated to any other mission planning data.