Godot Simulation Telemetry

Features

• CSV Data Collection
• UDP based Server
• FlyPT Mover Integration

At BATS Wireless, we have customers that place our systems in intense environments, such as on large boats in extreme weather conditions or on top of fast moving vehicles. This requies our engineers to design long lasting systems that can take many strong forces for years to come. As apart of this testing process, we needed a way to simulate forces on our systems as they would be experienced in real life.

Thankfully, the software team already had an in house simulator using the Godot Engine and a Go based computation server as a way to make sure the software in our embedded systems works without having to setup systems in real life and have a faster development velocity. This includes radio connections, reflection simulation, wind patterns, water physics, and different vehicles and structures to attatch a BATS Antenna Positioning system to. The Godot application and the Go server make sure that state is consistent between each other, and the Go server acts as a virtual radio and positioner to communicate with an emulated BATS system.

While this is very useful for software testing, what we need from this is the current state of a Node, namely a moving vehicle. Collecting the Yaw, Pitch and Roll is the minimum amount of information we need to get the motion rig moving with FlyPT Mover. Godot, like most 3D game engines, has that information available and we can send a simple packet to our Go server to record the Node we configure to be watched for telemetry purposes.

Traditional simulation games like racing sims or flight sims make use of outgoing UDP packets or a shared memory pool to allow motion rigs to simulate what is happening in game. We didn't go with this route directly, as the physical testing was happening on a machine that didn't require a full simulation to be running for the several hours or days that we plan on stress testing our domes for. There are edge cases with physics that we don't feel we need to account for during a regular software integration test due to their relatively short nature that might appear during a long session, physics bugs might pop up that we can't control, or we might just be running our 6 Degrees of Freedom rig on a low powered device. Instead, I collect the data in a CSV file during a simulation run and made a Python script that parses each row and sends it out over UDP. This means that:

1. We can verify the data is good and doesn't have any outliers from a bad tick
2. Different runs can be loaded and ran much faster than changing scenario configs in game
3. Almost any machine with a Python install should be able to act as a server for this telemetry