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.
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!
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.
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
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?
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.
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
