Altitude in MinimOSD relative to Sea level ?!

ArduCopter Copter 3.6
1

In 3.5 i was used to see the altitude shown in the OSD as being relative to Home Alt. Means: Immediately after booting it was zero and was also reset to zero by arming.
In 3.6.0 that behavior changed: At first, Alt is zero as usual, but after a 3D gps fix is aquired, the OSD shows GPS altitude, means absolute altitude above sea level. That is not reset after arming.

Does anyone know, how to get the “old” behavior again ?

By the way, the grazy thing is: MinimOSD firmware uses “mavlink_msg_vfr_hud_get_alt” function, but in Mission planners HUD altitude is displayed relative to Home Alt and not to Seal level ?!?

1 Like
2

Yes! I see this too - very confusing - and if you get a GPS glitch it switches back and forth!

1 Like
3

This has also broken our telemetry boards running MAV2Duplex (JETI) and MAV2Hott (Graupner)
Same thing, did show Arming altitude now shows ASL.

Looks like I will have to change the call in the firmware of the telemetry boards.

1 Like
4

Imho it would be better to restore the “mavlink_msg_vfr_hud_get_alt” behavior in AC 3.6.0 to the same as it was in 3.5

Probably easier than reflashing 1,000+ OSD & telemetry boards

1 Like
5

Mike Boland,
what telemetry board are you using ?
I’m using mavlink2hott firmware by M. Kosloff and this firmware still works.

1 Like
6

Thanks for the report and sorry for not mentioning this in the release blog post (although there were so many things to list)… the issue we faced is that the previous copter behaviour was inconsistent with the mavlink spec and also inconsistent across the ArduPilot vehicles (i.e. Plane and Rover do the right thing).

I know it is a lot to ask but it would be best if we could get the OSDs to use the GLOBAL_POSITION_INT message instead. this message contains both the relative and above-sea-level altitudes.

In any case, I’ll bring this up with the other devs to discuss what we can do. all input welcome.

2 Likes
7

I’m surprised to hear that a GPS glitch causes the alt to switch back to zero. I can test this but in the sending of the VFR_HUD message it uses a cached location if the AHRS can’t provide a current position.

1 Like
8

Haven’t checked the HOTT with 3.6 which I can do today but the code uses the same mavlink_msg_vfr_hud_get_alt which is apparently returning gps altitude now and not height above home.

So with 3.5 it gave relative altitude and now it should show alt ASL.

I am going in to fix this in the telemetry board code but my C++ skills is like a 2 year old with a Meccano set.

1 Like
9

My remarks to this topic:

  1. Height is one of the most important OSD/telemetry data exsp. for FPV

  2. “mavlink_msg_vfr_hud_get_alt" showed relative height for years in copter although this was inconsistent with mavlink specs. So OSD / Telemetry board firmware developers got used to this and used it as reliable, GPS independent, source for height info above home.

  3. I don’t think that resolving an inconsistency justifies to throw away thousands of these boards. One has to keep in mind, that a lot of guys probably will not be able rewrite the firmware and /or reflash these boards (and maybe sellers won’t provide updated firmware).

  4. If resolving this incosistency is so important, i would suggest to implement a “compatibility” parameter that allows the user to set the behavior of “mavlink_msg_vfr_hud_get_alt"

2 Likes
10

I strongly agree. This seems to be sacrificing usability for the sake of conformity. My experience is that it also doesn’t work very well at the moment :frowning:

1 Like
11

Yes I would just like a mean alt or maybe a choice mean or sea alt,please O please my developer friends

12

+1 on the “compatibility parameter”
Thanks!

13

andypiper,
you say, if gps glitches, relative height is shown again. I can’t confirm this, because i don’t experience gps glitches, but @rmackay9 says, the absolute height is cached.

Honestly, a “cached” height isn’t very useful while flying FPV , right ?

1 Like
14

Is GLOBAL_POSITION_INT independent from GPS in case of unsufficient GPS reception ?

15

This also changed something for Crossfire telemetry…
When in mode 2 it displays above home. When it switches to mode 1, it displays over sea level. Copter 3.5 and previous were all above home.
I spent a while complaining to TBS about it last month, and they’re working on fixing it…

But maybe I shouldn’t have bothered them about it until things are resolved here…

1 Like
16

There are a couple of messages that can give the AGL but as I see it the coders used get_alt where they should have used get_relative_alt.
So alt is altitude ASL and relative_alt is altitude above ground.

I am going with the sorting out of the MAVLink messages and getting the other stuff to fall in line.
AND I have a heap of telemetry boards and OSD’s that will all have to be changed :frowning:
Not something I am looking forward to but if it gets Ardupilot and MAVLink more consistent for the future I am prepared to byte the bullet :slight_smile:

1 Like
17

Thank you Mike,maybe they could make a parameter were we could aelect get alt or relative alt,im no coder so can not do it myself,hopefully it will get sorted soon

18

November 3
[57_1.png] rmackay9:

  I know it is a lot to ask but it would be best if we could get the OSDs to use the [GLOBAL_POSITION_INT ]message instead

Is GLOBAL_POSITION_INT independent from GPS in case of unsufficient GPS reception ?

Should be. It’s the path’s canonical concept of its position.

I made this breaking change - sorry.

We created a google group to try to coordinate GCS-affecting changes
(where “GCS” means something that consumes our mavlink output in this
case).

https://groups.google.com/forum/#!forum/ardupilot-gcs

We did do a survey to see who was using what. That survey turns out not
to have covered anything near the things it should have.

I have a feeling I might be adding a parameter in to get the old behaviour
back. That makes me sad - that’s code which we have to (apparently) carry
indefinitely, taking up flash, developer time to maintain, a (small)
amount of CPU, introduces yet another parameter for our users to wade
through and reintroduces differences between our vehicles that simply
should not be there.

Peter

Visit Topic or reply to this email to respond.

In Reply To

[57_1.png]
rmackay9
November 2 Thanks for the report and sorry for not mentioning this in the release blog post (although there were so many things to list)… the issue we
faced is that the previous copter behaviour was inconsistent with the mavlink spec and also inconsistent across the ArduPilot vehicles (i.e. Plane and
Rover do …

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

Peter Barker | Programmer,Sysadmin,Geek.
pbarker@barker.dropbear.id.au | You need a bigger hammer.
:: It’s a hack! Expect underscores! - Nigel Williams

1 Like
19

OK, we’re going to discuss this on the dev call tomorrow and decide what to do. Enough people have complained that I’m pretty sure we will do something.

I think we will push out Copter-3.6.1 for beta testing tomorrow so perhaps that will include the resolution (whatever that is)…

3 Likes
20

Thank you Peter and Randy,sorry for the extra work imposed on both of you,but what ever the out come you are both stars for listening and discussing this,cheers