Is GLOBAL_POSITION_INT independent from GPS in case of unsufficient GPS reception ?
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
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 
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 
1 Like
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
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 insteadIs 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
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
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
I have an alternate long term solution, which I know requires more dev time.
Part of the problem is that MinimOSD is rather dated now, way back when Oilpan was all the rage.
There have been some newer very capable graphical osd’s, AlceOSD and PlayUAV, but these have started as closed source. The developer realizes it isn’t going to make him rich and abandons it.
It would be great to have an “official ArduPilot” OSD that is graphical, can support at least 2 cameras, and is open source.
It could become part of the ArduPilot ecosystem and would be constantly in step with the code as it develops. I know i am only one voice, but I would buy the “official” version just as I have done with APM1.4, 2, pixhawk1, 2.1 and now pixhack v3.
Just my 2 cents (but, please, please, please)
1 Like
I have an alternate long term solution, which I know requires more dev time.
Part of the problem is that MinimOSD is rather dated now, way back when Oilpan was all the rage.
There have been some newer very capable graphical osd’s, AlceOSD and PlayUAV, but these have started as closed source. The developer realizes it isn’t
going to make him rich and abandons it.
This came up on the dev call today, in fact.
I’ll swipe my notes:
UTC2334 - changed the VFR_HUD message
Should we switch back?
Should we add a parameter so people can change it?
Minimosd
Only a couple of versions we care about
HOTT and graupner
JP: we need to get it right at our end
Use devop bit to get back old behaviour
For people that can’t update their minimosd firmware
Would like to use minimosd as a screen update protocol rather than mavlink
Use existing ArduPilot OSD code
Would also future-proof things
Mavlink screen-painting message?
Peter will add a devop bit to get back old behaviour
Add comment on discuss post
Need to work on getting testers before we issue stable
Working with consumers of our telemetry stream
Users don’t update?
It would be great to have an “official ArduPilot” OSD that is graphical, can support at least 2 cameras, and is open source.
It could become part of the ArduPilot ecosystem and would be constantly in step with the code as it develops. I know i am only one voice, but I would buy
the “official” version just as I have done with APM1.4, 2, pixhawk1, 2.1 and now pixhack v3.
tridge thinks we should make the minimosd software a lot dumber. strip
out the mavlink functionality and plumb it through ArduPilot’s new-ish OSD
code.
He’s not going to jump right into that - but he’d love to see someone
attack it!
Peter
1 Like
An ardupilot osd would be brilliant.I for one would purchase it,and sure 100’s of others would as well,just makes sense to stay with the family,thanks for every ones input
I made some changes for the Jeti Telemetry “Mav2Duplex”
In Mavlink I added the lines:
case MAVLINK_MSG_ID_GLOBAL_POSITION_INT:
{
//relative_alt = mavlink_msg_global_position_int_get_relative_alt(msg);
osd_alt = mavlink_msg_global_position_int_get_relative_alt(msg)*0.001;
}
break;
Then I uncommented //osd_alt = mavlink_msg_vfr_hud_get_alt(msg);
This works just fine. Now the displayed altitude on the Jeti is the relative altitude.
Here ist the fix for the Mavlink2Hott
case MAVLINK_MSG_ID_GLOBAL_POSITION_INT:
apm_bar_altitude =mavlink_msg_global_position_int_get_relative_alt(&msg)*0.001;
break;
If someone is intrested in HEX files instead I could upload them somewhere.
I have the same problem when using a teensy3.1 Mavlink to taranis setup.
does “relative_alt” actually give the barometer alt? or just a home adjusted GPS alt? if not how do I get the barometer alt? I thought i was getting barometer alt previously with the old setting, right?
You can use relative by setting this option to 1:
DEV_OPTIONS: Development options
Note: This parameter is for advanced users
Bitmask of developer options. The meanings of the bit fields in this parameter may vary at any time. Developers should check the source code for current meaning
Bitmask
Bit Meaning
0 ADSBMavlinkProcessing
1 DevOptionVFR_HUDRelativeAlt
1 Like
I have a Radiolink PRM02 which delivers telemetry to a Radiolink AT9S
I upgraded from 3.55 to 3.67 (Chibios) and noticed the altitude was referencing height asl rather than relative, I changed the bitmap in DEV_OPTIONS by checking the pop-up and saw the value was 2.
The alt is now reading relative so I think that’s correct?
I note a previous comment that “The meanings of the bit fields in this parameter may vary at any time” is it safe to use this option?
Thanks.
Yes, the dev options have been stable in my experience. It’s just a notice that things could change and it’s not one of the regular parameters.
Hi, thanks for the reply.
Mission planner gave me a ‘pop up’ prompt and auto populated the correct value so I’m happy that all is ok. Also guessing that Radiolink won’t be modifying the code for their serial to i2c adapter any time soon!
Thanks again.
I don’t even get that dev option choice.
I do get
ADSBMavlinkProcessing
But not the other one.
And i get the pop up so I can’t write the figure in manually…
I guess I could manually add it to the Params file and upload the setting but I don’t want to mess up.
Mission planner is updated, although I went back to nuttx AC3.6.7
Hi,
Here’s a couple of screenshots from my set up:
Pixracer runing 3.6.7 Chibios
Mission Planner 1.3.65 (got the update this evening)
Made the change and now getting relative height in radio telemetry
Alt read ok in mission planner though…
2 Likes
hi,
thanks friend, my problem is solved