GEISTT Lab RTI
Background and purpose
The idea of a Lab RTI (run-time infrastructure) arose from the repeated experience of re-inventing the same wheel in several of GEISTT simulation-based concept development projects. The overall goal is to provide the lowest common denominator of infrastructure functionality for a lot of projects, as simply as possible, so that the projects can focus on their core functionality and research questions.
The RTI is intended for projects such as:
- Simulation-based design and concept development
- Simulated operative training
- Human-machine interface (HMI) research
- User testing
The RTI, or a similar predecessor of it, has been used successfully in a number of projects, including:
- Autonomous vehicle control HMI research
- Stress-adaptive training research
- Air traffic control decision support research
- Driving simulator co-simulation
Supported languages and platforms
What you get
The Lab RTI provides:
- Well defined, simple-to-use publish/subscribe-based communication between components, such as simulators and HMI prototypes
- Common messages for runtime control (start, stop, etc), client & channel discovery, metrics and measurements
- Common object model for high-level concepts such as simulated entities
- Web-based runtime control application
- Command-line runtime control and debugging/analysis application
What you don't get
Compared to something like HLA, DIS, DDS...
- A standard
- Entity ownership, authorization, transfer
- Sender-side filtering and other advanced bandwidth-saving techniques
- Gateways, boosters, firewalls and such networking tools for distributed simulation
- Advanced time synchronization and lag/latency compensation
- Audio/radio (pitch talk) or video streaming (pitch media streamer)
How to use it
- Get the RTI up and running (see README)
- Add the appropriate Lab RTI client library for your platform to your project. If using Unity or Unreal Engine see the wiki pages for setup instructions.
- Implement client behavior as necessary
- Define a data exchange model, i.e. messages specific to your project
- Implement project specific data exchange message handling - application logic for publishing and receiving your project specific messages
The RTI implementation is based on open-source technology.
- Protocol Buffers by Google
- Official client libraries for TypeScript and Python
- Not using official client library for C# / .NET because it doesn't work with .NET Core and Unity
- Not using official client library for C because it is subjectively a weird/broken/unfinished implementation
- Not using official client library for C++ because it has a large dependency chain (boost beast) and seems somewhat unfinished
- .NET Core for some tools
- Vue.js for web-based user interfaces
- Why socketcluster? Because it makes integrating web-based HMI prototypes a breeze!
- Exchangeable transport mechanism. Virtually any pubsub mechanism could be used with minimal effort. Clients implement most functionality. Minimal complexity in cluster/broker.
- Why not just use JSON? Loosely defined data contract (no schema). Bandwidth efficiency (field names > data). Parsing.
- Why not just use HLA? We can't afford it. Our clients don't want to pay for it. We don't want the complexity.