xplane_plugin: X-Plane's data extraction pluginrelay: External GUI program that takes the data extracted byxplane_pluginand sends it to iMotions over TCPbaton: C++ library for communicating withrelay. Provides an object that handles inter-process communication (IPC) and abstracts over it for ease-of-use. Currently located inxplane_plugin/subprojects
The data flow is as follows:
xplane_pluginextracts the dataxplane_pluginuses thebatonlibrary to send the data to therelayprogramrelaysends the data to iMotions
relay and baton are developed by this team and are not external programs/libraries.
xplane_plugin and relay are top level subprojects in the repo. It is currently undecided whether baton will be top level or not, and so for now will be found under xplane_plugin/subprojects/. In the event that we begin work on Prepar3D during this iteration, we can decide if baton is generic enough to use for both simulators and move it to the top level, or have a baton version for each simulator plugin as an internal dependency.
At the time of writing, the current version of iceoryx2 does not support cross-language communication. Only C++-to-C++ and Rust-to-Rust communication is possible, not C++-to-Rust. xplane_plugin is written in C++ and relay is written in Rust. Thus, iceoryx2 cannot be used to facilitate communication between xplane_plugin and relay.
However, this limitation only extends to what language the communication is compiled from. Rust-to-Rust communication where one end is compiled to a C library is valid. This is where baton comes in. baton abstracts over the finer details of iceoryx2 communication to relay and is compiled to C++ despite being a Rust library. This enables the plugin (again, written in C++) to communicate with relay (again, written in Rust) when this otherwise would not be possible.
A secondary benefit to using Rust over C++ for baton is that we can leverage Rust's superior concurrency and safety guarantees. By managing the threading and communication in the Rust library and providing the plugin only a very limited interface by which it can pass in values to be sent to relay, we make a worthwhile exchange. We trade up-front complexity for vastly reduced need for debugging further down the line, as our code is more likely to be sound. This is an important consideration, as the project will be passed on to new students for next iteration. It is a much better use of developer time to work on developing features instead of being mired in deeply complex concurrency concerns similar to the ones that appeared during the first iteration of this project when we began.
Here is a link to the same metric graphs, the reason for this is so that youre able to see how the data is supposed to look, just in case you want to add to this project but you dont have access to Imotions. https://docs.google.com/document/d/1KRa0qkovk8kHhXT9Z3p66wXcQFLISTJb8F0M-sINLZ8/edit?usp=sharing
For total understanding of how the data is actually being sent and where it works here is a flow diagram that shows how the data is being sent. https://docs.google.com/document/d/1KRa0qkovk8kHhXT9Z3p66wXcQFLISTJb8F0M-sINLZ8/edit?usp=sharing
Work in progress.
- Rust: stable (toolchain is pinned by
.rust-toolchain.toml; CI uses the Rust stable channel) - Python: 3.x (latest 3 series)
- Meson: >= 1.x
- Ninja: latest
- mingw-w64: required for cross-compilation to Windows (target
x86_64-pc-windows-gnu) - GoogleTest: for C++ tests
- Install rustup and ensure stable is active:
rustup updaterustup default stable
- Install the Windows target:
rustup target add x86_64-pc-windows-gnu
- Install meson & ninja:
python -m pip install --user meson ninja
- Setup and build:
meson setup --cross-file xplane_plugin/lin-to-win.ini buildmeson compile -C build
- Run tests:
meson test -C buildcd relay && cargo testcd xplane_plugin/subprojects/baton && cargo testNote:.rust-toolchain.tomlwill causerustup(and CI) to prefer the stable toolchain and auto-install the components/targets listed, keeping local and CI toolchains aligned