Centering the crosshair. Is it possible?

[imfatant]

I have the DJI FVP Goggles Mk1, and am using HD fonts.

Is it possible to centre the crosshairs (and artificial horizon) precisely? Seems a maddening process.

Seems to depend on Betaflight's osd_canvas_width and osd_canvas_height variables too.

Many thanks.

[benlumley]

It's not possible at the moment, and no plans for it.

[imfatant]

Is it possible, in theory, to write individual pixels to the frame buffer such that basic vector line graphics could be displayed based on various air data (like attitude and GPS position)? I have some free time coming and would quite like a project to hack about with.

[benlumley]

yes - that would be possible. you could fork a version of msp-osd that has a fixed crosshair or adds framing lines. msp displayport cannot do this; it draws characters, not vectors - so it would be fixed rather than under control of the FC; it would show over menus / over the stats screen etc.

more simply.... you could also offset the position the osd grid is drawn so that it's not centered in the goggles by half a row - then you could make it so the center of one row/column is. the center.

there has been some experimentation with a goggles side osd based on msp telemetry as well; so if you wanted a bigger challenge you could pick that up - hop on to discord and look in the osd development channel if you wanted to chat.

[j005u]

Yes, it's certainly possible. msp-osd works by copying existing font glyphs into the framebuffer, but nothing is stopping one from doing custom drawing code. There's no graphics acceleration to speak of, so you're somewhat limited in complexity, but reasonable results can be had.

You need two fundamental parts:

• Something to stream msp telemetry values over from the air side to goggles reliably
  • msp-osd's air side uart proxy is an okay starting point, but since we're streaming different kinds of data some of the logic and compression stuff need to get optimized
• Something to render on air ground side and inject into the DJI gui process
  • msp-osd has got you covered as a starting point once again

We've found that a) injecting into the existing GUI process takes quite a bit of reverse engineering skill and scares developers away and b) C scares most developers away. So Saidinesh and myself have been working on a proof of concept that uses a combination of lvgl for the framebuffer based drawing backend along with Javascript bindings for "widget authors".

We have an early poc based on the QuickJS engine forked from a lvgl community project here: https://github.com/saidinesh5/lv_binding_js Work has currently stalled a bit though as we figured out that the QuickJS bindings provided are of rather low quality and we'd need to rework most of them. Since that's quite the undertaking anyway we intend to create new bindings for nodejs instead to get that 20x+ JIT boost to JS execution.

The goal with this would be to replace the DJI GUI entirely so we don't have to struggle with basic modifications and enable community provided telemetry widgets / other extensions.

I also have an even earlier poc of the same thing with LUA here: https://github.com/j005u/luavgl-dji But we came to the conclusion that JS, especially with a little magic to enable React style development, would end up with the broadest set of possible devs.

So yeah, hop on our Discord. We could always use more hands on the replacement GUI effort and we're also happy to help out however we can if you choose to take some other path.

[imfatant]

@j005 @benlumley Wow thanks so much! I'll get started shortly and no doubt have further questions etc.