This takes Betaflight MSP DisplayPort (so-called "canvas" although this is a misnomer as there is another Betaflight "canvas" mode for Pixel OSDs) messages through UDP and, using a font provided at /blackbox/font.bin, renders them to a framebuffer.
A custom font.bin may be placed on the root of the goggles SD card, at which point it will override the font in /blackbox/font.bin.
SFML and DJI viewports are available, as well as a mux which creates a pty and provides filtered MSP access, and reroutes DisplayPort messages to UDP.
To build for DJI, install the Android NDK and add the NDK toolchain to your PATH, then use make -f Makefile.dji to build the targets. Set DJI_LIB_PATH to point to the content of /system/lib pulled from your DJI hardware or a firmware dump, so that the linker can find libduml_hal.so.
On Windows, note that
makeand the actualarmv7a-linux-*compiler binaries may be installed in different directories.
To build for UNIXes, install CSFML and run:
make -f Makefile.unix
Provided targets and tools are:
msp_displayport_mux- takes MSP DisplayPort messages, bundles each frame (all DisplayPort messages between Draw commands) into a single UDP Datagram, and then blasts it over UDP. Also creates a PTY which passes through all other MSP messages, fordji_hdvt_uavto connect to.osd_dji- Listens for these MSP DisplayPort messages over UDP and blits them to a DJI framebuffer screen using the DJI framebuffer HALlibduml_halaccess library, and a converted Betaflight font font stored infont.bin.osd_sfml- The same thing asosd_dji, but for a desktop PC using SFML andbold.png.
Build the needed targets:
make -f Makefile.dji msp_displayport_mux
make -f Makefile.dji osd_dji
- Ensure that the correct UART is set to use MSP
- Enable MSP DisplayPort
On Betaflight, this is done using the following commands:
set osd_displayport_device = MSP
set displayport_msp_serial = <ConfiguratorUART - 1>
Eg.: If the Configurator says UART2, the value for <ConfiguratorUART - 1> is 1.
adb push msp_displayport_mux /blackbox
setprop dji.hdvt_uav_service 0
mv /dev/ttyS1 /dev/ttyS1_moved
nohup /blackbox/msp_displayport_mux 192.168.41.2 /dev/ttyS1_moved /dev/ttyS1 &
setprop dji.hdvt_uav_service 1
This tells the displayport mux to send data from /dev/ttyS1_moved to 192.168.41.2 (goggles) and to create a fake serial port at /dev/ttyS1 with the displayport messages filtered out.
Optionally, you can add -f, like nohup /blackbox/msp_displayport_mux -f 192.168.41.2 /dev/ttyS1_moved /dev/ttyS1 to put the serial port in a faster 230400 baud mode, and set the MSP serial port in your flight controller to 230400 to try to improve the framerate.
You can also omit setprop dji.hdvt_uav_service 1 , which will improve your OSD framerate at the expense of disabling all Air Unit / Vista side coordination functionality (AU recording, channel changes, some RC features, etc.).
adb push osd_dji /blackbox
adb push font.bin /blackbox
cd /blackbox
nohup ./osd_dji &
Hold the BACK button for 5 seconds. You should see the DJI UI disappear and be replaced by the MSP OSD (or at least a WAITING message at the bottom of your screen).
To restart the DJI goggles, hold the BACK button for 5 seconds again.
Rebooting will kill the process and return the goggles to "normal."
Enjoy.
Access to the DJI video driver is exclusive. We would have to build some kind of userspace frame-buffer sharing system to get this to work. The dji_glasses system uses DirectFB which provides this functionality on paper, but the DJI backend driver as well as the overall stack are not configured to use it properly.
See above - dji_glasses has three primary purposes:
- turning user input into commands for the radio/CP layer
- displaying the UI
- for whatever reason, recording video
Without dji_glasses running we will have to replicate these functionalities.
Use mcm2img.
python3 mcm2img.py mcmfile.mcm font.bin RGBA
https://github.com/fpv-wtf/margerine/wiki
- http://github.com/fpv-wtf team, for making this all possible and very helpful random bits of advice