New SITL "TARGET": Webassembly (Experimental)

[Scavanger]

Yes, INAV in the Browser!

Intended to use with INAV-Configurator Web (PWA) iNavFlight/inav-configurator#2448

It works, inkl. TCP "UARTS" and Simulators, but due to limitations of the browser envoronment/emscripten some workarounds are mandatory:

• Only a WebSocket client can run in the browser (no TCP/UDP), so a ‘serial_ex’ interface has been implemented for UART1. Emulates a serial connection via simple function calls.

• Other UARTS and simulator interfaces require a locally running proxy that converts the WebSocket into a ‘real’ TCP/UDP socket.
  I will integrate a proxy server into the X-Plane XITL plugin so that at least for X-Plane, the whole thing should be easy to use.

-A few more tricks and pull-ups are necessary (e.g. Config) because the emscripten API does not provide all the functions we need.

I'm marking the whole thing as experimental, as the communication Webassembly -> Proxy -> Application is a bit ‘backwards’ and runs a bit shakily.
The alternative would be to rewrite the entire network code (UART and Sims) and switch completely to Websockets, but it's probably not worth it.

[sensei-hacker]

For my wasm build that runs in a browser / PWA, I used two different options to avoid a proxy.

Option 1:
MSP can be handled by just exporting Module.mspProcessCommand()
That's about 50X faster than messing with sockets on both ends.

Option 2:
The other technique I did was I added a small web socket function to SITL. No need to make Configurator speak raw TCP. SITL can easily strip off the web socket header, then pass the data as per a raw socket.

[Scavanger]

@sensei-hacker

Option 1: MSP can be handled by just exporting Module.mspProcessCommand() That's about 50X faster than messing with sockets on both ends.

Good idea, but it's not that simple, because the INAV main loop runs in a separate thread (web worker) and has to be synchronised, hence the queue and encapsulation in ‘serial_ex’ and only the configurator would have access to it.

Option 2: The other technique I did was I added a small web socket function to SITL. No need to make Configurator speak raw TCP. SITL can easily strip off the web socket header, then pass the data as per a raw socket.

The problem: You need a Websocket server and a client. Both the configurator and the SITL run in the browser, but a Websocket server in the browser is not possible.
And you had to rewrite the entire code for the simulators (X-Plane, Realflight), and the X-Plane plugin needs to be adapted.

[sensei-hacker]

I might be misreading your comment.
It almost sounds like you're saying why it's impossible for me to write and use the code that I already wrote and already use?

[Scavanger]

Just show me :).
The approaches you described didn't work for me.

[sensei-hacker]

The simulators are native code, they can't run in the browser. No matter what anyone does with SITL, native code is absolutely required to run the sim. I don't see any big benefit of running SITL slowly in the browser while running a sim. So IMHO they aren't really relevant here.

Configurator can run in the browser, so for me, that's the use case for SITL in the browser. To run with Configurator. Which has been working for well for about six weeks.

Running SITL in the browser with a native code proxy for web sockets, with a native code sim, gets you 50X slower communication and what else?

On other words:
Option 1
sim.exe
SITL_proxy.exe
browser

Option 2
sim.exe
SITL.exe

What's the benefit to adding a browser on top of the native code? If you're going to run SITL_proxy.exe, why not run SITL.exe instead and skip the whole browser and web sockets and all of that entirely?

[Scavanger]

Yes, you're right, the simulator interface is a nice gimmick, but more of an academic one.
I've built the corresponding proxy server into a test version of the INAV X-Plane plugin: it works really well, so there's no need for an extra programm here.

[sensei-hacker]

Fyi I'm working on organizing my work into something I can actually show to someone else.