✅ SITL OSD Support + Ideas for HD Fonts

[Scavanger]

SITL requires an external program for the OSD, for X-Plane a plugin solution would certainly be a great thing and having only one Inav plugin for both would certainly also be great. To run SITL over MSP is unfortunately not possible, to integrate the OSD would be one thing and at the same time to switch to HD fonts, here are a few ideas:

• Fonts: The DJIWTFOS fonts are great for this, they are already in raw RGBA format and can be loaded relatively simple in OpenGL as textures.

• INAV side: The cleanest solution would be an own displayport, based on displayport_msp_osd, which transfers only the changed characters and the dependency on MAX7456 is also gone

[Scavanger]

What a pity, no reaction.
I had hoped for cooperation.

[RomanLut]

What a pity, no reaction. I had hoped for cooperation.

Sorry for a late answer!
Yes I would like to itegrate SITL into plugin, but not only OSD but also full "SITL" menu tree.
The goal is to make it easy to use for the end user, so it would be possible just to click "SITL -> Connect to SITL" and fly, like with HITL.
I just did not have a time to compile, run, and check how interprocess communication works in SITL yet.

Ok I will check SITL this week, I think that setting up analog OSD at least should be pretty fast because it is implemented aleady.

[Scavanger]

Analogue OSD for SITL via the HITL MSP command will not work because the analogue OSD is dependent on the MAX7456, you have to use the MSP display port.

I have almost finished the support for HD fonts for HITL, based on the fonts for WTFOS (DJI), on the INAV side I have solved this via a new display port, which is activated via a CLI option.

The challenges if you want to integrate SITL completely:

• SITL is controlled via the command line of the SITL executable, shipping the exe with the plugin is not a good idea, maybe download it online from Github.

• For the settings you almost need a GUI (e.g. for the SITL LOG, to enter the IP address, the channel mapping), the X-Plane widgets are really horrible (to program and also the optics), but there is an imgui binding.

• SITL communicates via TCP, making it portable for Windows, Linux and MAC can be a real headache, if you don't want to crack a nut with a sledgehammer and use something like Boost or QT.

[RomanLut]

Analogue OSD for SITL via the HITL MSP command will not work because the analogue OSD is dependent on the MAX7456, you have to use the MSP display port.

Compared to HITL, SITL has a big advantage that you can compile completely different code into PC executable. So it is possible to remove MAX7456 communication and just send whole video buffer throught the same channel which is used to communicate with X-Plane already. I still have to look how it works.

I have almost finished the support for HD fonts for HITL, based on the fonts for WTFOS (DJI), on the INAV side I have solved this via a new display port, which is activated via a CLI option.

How do you pass OSD MSP commands from FC to X-Plane?

I was thinking on supporting HD OSD in HITL, but:

Analog OSD has framebuffer. So I can just read framebuffer and transfer small parts to X-Plane with each MSP_SIMULATOR command response. Thus X-Plane has a copy of framebuffer which it can render.

Digital OSD does not have framebuffer. It sends MSP commands through separate UART. So in order to support HD OSD, I have to send OSD MSP stream through the VCP UART (somehow), or ask user to connect second uart using USB-UART convertor( this is really ugly solution).

[Scavanger]

How do you pass OSD MSP commands from FC to X-Plane?

As I said, an extra displayport is needed, which actually does the same thing as the MSP displayport (displayport_msp_osd): Only the changed characters are sent, instead of sending them directly, the buffer is saved and the HITL MSP command retrieves the buffer and then sends it.
The subcommands are the same as for the MSP displayport, so the X-Plane OSD doesn't care if it comes from SITL/TCP and an extra MSP command or from HITL/Serial and piggybacked on the HITL command.

I'll finish it in a few days, then you can have a look at it.

[Scavanger]

OK, here is my first implementation for HD Fonts:

X-Plane Plugin:
https://github.com/Scavanger/INAV-X-Plane-XITL/tree/HD-SITL

Font package:
https://1drv.ms/u/s!AgjVCBn-11JIyhiWYmjG_jGVEhY2?e=y3Q35u
(copy folder "fonts" into the assets folder)

INAV:
https://github.com/scavanger/inav/tree/HITL-Dislayport

The whole thing is "work in progress", nothing finished yet.
I also started to change the menu and played around with IMGUI for the SITL settings.

[RomanLut]

Ok, so I assume I should wait for pull request or green light from you, then I will merge and release new plugin.

Random notes:

1. I am able to compile plugin for Windows 👍
2. After fixing MSG_SIMULATOR command version and payload I am able to run it. Fonts render propertly, but OSD is flickering/not rendering properly. I will wait for final implementation from you.
3. Analog OSD support should not be removed from plugin obviously (I assume WIP)
4. I would like to keep compatibility beetwen older firmware and new plugin as far as it is possible, extending exising v2 format with flags. If we swich to v3, then I would like to implemend completely different payload. Plugin will have to support both v2 and v3.
5. I do not like an idea that user has to enable special display port in CLI. The idea behind HITL is to allow connecting existig builds to simulator. Instead, if user enabled MSP OSD, then firmware should signal it to simulator and pass HD OSD payload.
6. New display port requires ~3Kb RAM for framebuffer. It might be an option to discard special display port and allocate smaller buffer where MSP OSD traffic is stored and then transferred along with MSP_SIMULATOR command payload. It depends on MSP OSD/ framebuffer changes traffic, which I will check in final implementation.

[Scavanger]

2. Yeah, still a bug.
   3/4. Yes, good point
3. I don't like the idea either, the only problem is that the displayport has to be initilased at startup.
4. The ram usage is about the same as MSP OSD Displayport, so since that's not a problem either, I don't see a problem here.

[RomanLut]

With:

HITL: hd osd support #9327
iNavFlight/inav#9327

SITL: OSD CMS menu does not work #9344
iNavFlight/inav#9344

HITL/SITL: allow hitl/sitl to arm with uncalibrated accelerometer #9345
iNavFlight/inav#9345

SITL: implemented built-in serial receivers support in SITL, implemented FC proxy mode, updated SITL docs
iNavFlight/inav#9365

Configurator:
SITL: adjusted SITL tab (built-in serial receiver support) #1849
iNavFlight/inav-configurator#1849

and a plugin currently in development:
https://github.com/RomanLut/INAV-X-Plane-HITL/tree/main/release

It is now possible to connect to SITL similar to connecting to real FC:

1. Start SITL in configurator mode, with serial receiver
2. Connect with HITL plugin

Tested under Windows.
Tested with SITL running inside Docker and X-Plane on Windows.
Testing on Linux is required.

[Scavanger]

Awesome!
Only one small suggestion for improvement:
The IP address should be freely configurable.
I personally develop INAV in Windows but compiling and debugging runs under WSL, XPLANE runs on the host but WSL cannot be accessed under the local loopback.
I had SITL support almost ready, but due to other projects I don't have time to finish it. However, I can send you the code for the free entry of the IP if you are interested.

[RomanLut]

Yes, I am interested.
Alternativelly, I could add dev console command to set SITL ip address.

[Scavanger]

https://gist.github.com/Scavanger/c2272ca7c42e70f6f82341d84bfaa46b

It`s based on the XPlane widgets, not very fancy and pretty, but functional. ;)

[RomanLut]

Thanks, integrated into master.

[RomanLut]

Well, with these commints #14 (comment) SITL can now be used with HITL plugin, featuring HD OSD and plugin tools. While OSD support could be implemented for the original SITL <-> X-Plane communication (via array datarefs), I am not willing to do it, because it is a lot of work to repeat existing functionality. I would rather vote to deprecate datarefs communication method.

Will close when all commits are merged in.

[RomanLut]

SITL connection is supported in release 1.4.0