[Request] OSD icon local position configuration support

[lida2003]

As the MSP display protocol provides some flight controller information, prioritize using the local x-y position if we have a local icon position definition.

Add something like osdpos.ini

• if we don't have this ini file, use xy info in msp display protocl
• if we have this ini file, then prioritize using the local x-y position

I think hd-osd-tool is pretty good tool for visually see where these icon is. Then generate text values in ini file.

Well, it's much more convienent when msposd is deployed on GCS.

[lida2003]

Android apk FPVue can position the icon where you want.
The GUI feature requested is some thing like this, but the FPVue uses MAVLinkV2, which is different from MSP disport protocol.

[tipoman9]

Currently we are focused on providing support for the standard OSD configurator included in all major Flight Controllers Firmwares.
Yes, it is very old technology from the analogue Tx era, but has wide adoption in the FPV community.
Yes, additional GUI configurator would be nice to have.
Feel free to implement it.

[lida2003]

@tipoman9

I saw your video on x86??? https://www.youtube.com/watch?v=niyOnrXOFfU

Your comment below: "The latter is still Work in Progress and is currently supported on x86 ground station, but If there’s sufficient interest, I will port it to Radxa Zero"

interest++

[tipoman9]

@lida2003
It should be straightforward to port, since cairo is well supported on radxa, but I'm not interested, since I use _x86 as ground station. I hope someone will test it and will do a PR if changes are needed in msposd code.
The average users are just fine with air-unit rendered icons, since they to not need additional OSD widgets or AHI.
BTW, here is a preview of setting position of UI elements from the configurator ;)
https://youtu.be/8ztjzZoL8DY

[lida2003]

Well, I'm thinking about trying this on my Jetson Orin Nano board(#17) as a ground station.

I can:

• do the test
• minor coding on C/C++

But further infor I needed:

• Makefile changes for native Jetson build, with little changes from x86 target?
• How to do image stablization? did you use gyroflow?

[henkwiedig]

You are refering here to the displayport sub command MSP_DP_SYS ?
This will give fc configurator support for these osd elements:

// System elements rendered by VTX or Goggles
typedef enum {
    DISPLAYPORT_SYS_GOGGLE_VOLTAGE = 0,
    DISPLAYPORT_SYS_VTX_VOLTAGE = 1,
    DISPLAYPORT_SYS_BITRATE = 2,
    DISPLAYPORT_SYS_DELAY = 3,
    DISPLAYPORT_SYS_DISTANCE = 4,
    DISPLAYPORT_SYS_LQ = 5,
    DISPLAYPORT_SYS_GOGGLE_DVR = 6,
    DISPLAYPORT_SYS_VTX_DVR = 7,
    DISPLAYPORT_SYS_WARNINGS = 8,
    DISPLAYPORT_SYS_VTX_TEMP = 9,
    DISPLAYPORT_SYS_FAN_SPEED = 10,
    DISPLAYPORT_SYS_COUNT,
} displayPortSystemElement_e;

This is kinda what the /tmp/MSPOSD.msg file is doing now plus some additional elements wich would need to be rendered on gs.
Questioning myself how data would be transported to ground in case of gs only rendering.
DISPLAYPORT_SYS_VTX_TEMP is only known to VTX and currently not send to gs, should air always render this / inject this as normal MSP_DP_WRITE_STRING ?

[lida2003]

@henkwiedig local position icon should be similar to PixelPilot, well, it uses MAVLinkV2 to get message(value) from FC.

Apparently, there is no icon info, which is different from msposd. Maybe msposd can add this for mavlink v2 extension.