News Proposal for Telemetry Standardisation (Work in progress, seeking input)

Some time ago I identified a gaping hole in tools to help game developers add motion simulator support to their games, primarily the lack of a standard for doing so. So I have set out to remedy the situation by doing the following:

• Step 1: Define a draft standard schema for motion data that is agnostic of the game vehicle type or simulator (what I've been working on leading up to this post)https://github.com/Open-Motion-Alliance/Standard
• Step 2: Seek input from developers of games and motion software (current step)
• Step 3: Refine and ratify standard
• Step 4: Source developers to work on game engine plugins to output data in this schema
• Step 5: Develop plugins for game engines and motion software
• Step 6: Spread the tools to game developers and game consumers

## Why the Need?
Integrating motion data into games is often a daunting task due to incompatible formats and complex integration processes. The Open Telemetry Alliance Standard aims to eliminate these obstacles by providing a unified framework for motion data exchange.

## Enabling Seamless Integration
The aim is to provide free plugins for common Game engines facilitating effortless integration and unlocking new levels of realism.With these plugins, game developers will be able to seamlessly incorporate motion data output into their projects, focusing on creating immersive experiences without worrying about compatibility issues.

## Empowering Motion Software
With a standardized format for telemetry the work to create plugins in Motion software plugins will be greatly reduced, it would most even be possible to create a meta-plugin that would work for any game supporting the standard

## Join the Movement
Join us in shaping the future of motion integration in gaming with the Open Telemetry Alliance Standard. Together, we can redefine the possibilities of immersive gameplay experiences.
https://discord.gg/2CEdbKYKsn
PS: Particularly looking for game developers with motion telemetry experience, be that developing games or plugins for motion tools.

I had a multi hour discussion with the developer of Sim Hub last night and he said what I've done is quite good for motion (which is what I was targeting) but rightly pointed out that there is often much more telemetry that can be relevant to different users in different use cases.. so I will endeavor to keep this in mind and try to include a method for that.

For now I'm really wanting to talk with developers that have experience in this realm or in building motion software plugins.

This is very much a start point for discussion before publishing as a concrete thing.

@Wagnard can you bring to the attention of others you know that would be knowledgeable in the area please?

hmmm,

Telemetry for motion
Telemetry for transducers
Telemetry for lighthing (yes, sun position and cloudness)
Telemetry for dashes
Telemetry for driving analysis
Units used for each value
....
....

To do a norm, let's do it for everything
But it's not just the values, it's also the way they come.
UDP packets, Shared memory.
Multiple types of packets or all in one
Different frequencies depending on packet type
There's so many things to consider.

I totally agree.. and worth doing..

I have defined units for each value if you check out the spec document in the repo https://github.com/Open-Motion-Alliance/Standard/blob/main/open-motion-alliance-schema-v1.0.json
Also have already created issues about protocol for transport and larger range of telemetry data https://github.com/Open-Motion-Alliance/Standard/issues

Just saw what you posted.
Not sure I would use JSON. There's to many junk bytes there to send over UDP.
A float is 4 bytes, if you send it in a JSON string it can be double with less precision.
I'm more on the struct side.
Remember that many people play online and want the network to be at it's maximum.
For local, shared memory is the best (both UDP and MMF optional would be better).
For pure motion, the minimum is the rotation matrix and a precision timer between calculations would be enough. It's just 17 floats and we can calculate everything else from there.
Would be great to have the driver/pilot head position relative to 3D point from wich we get the data.
Extra motion could be rpm, suspension travel, slip angles, slip ratio, open/closed cockpit, flaps, air brakes, gears....
Also for data frequency, I would say maximum possible. I'm testing the new Mover release at 0.1 ms right now.

It's just some small talk, need to go sleep...

I felt I had to put something out there to start the discussion.. I'm not a developer in this area, just pulled together what I could think of that is required.. this is why I'm trying to get developer feedback and iterate it

I’m kind of starting to lean toward toml as the format https://toml.io/en/

The reason I initially landed on UDP is so that console games could also easily drive motion rigs with motion software on a PC.

I'd really appreciate if you could add issues for some of the points you are raising after you've slept?

Correct me if I'm wrong but woudn't a binary fomats structure be specific to every game, I'm currently leaning heavily towards TOML as it is lightweight like a struct, but can be validated against a schema. https://toml.io/en/


TOML aims to be a minimal configuration file format that:

• is easy to read due to obvious semantics
• maps unambiguously to a hash table
• is easy to parse into data structures in a wide variety of languages
  

here is a TOML example:


# This is a TOML document

schema = "https://example.com/open-telemetry-alliance_schema_v1.0.json"
timestamp = 1649125392
game = "game name"
max_sample_rate = 1200

[motion_object]
object_location = "track name"
object_name = "name of vehicle"
object_type = "car"
acc_xyz = [ 2.0, 0.0, 0.0 ]
pos_xyz = [ 2.0, 0.0, 0.0 ]
rot_xyz = [ 2.0, 0.0, 0.0 ]
vel_xyz = [ 2.0, 0.0, 0.0 ]
cog-pov_offset_xyz = [ 0.0, 0.0, 0.0 ]

[[drive_points]]
name = "front_left"
type = "wheel"
current_terrain = "asphalt"
cog_offset_xyz = [ 123.45, 67.89, 100.0 ]
travel_xyz = [ [ 0.25, -0.25, 0.0 ], [0.25, -0.25, 0.0], [0.25, -0.25, 0.0] ]

[[drive_points]]
name = "front_right"
type = "wheel"
current_terrain = "asphalt"
cog_offset_xyz = [ 123.45, 67.89, 100.0 ]
travel_xyz = [ [ 0.25, -0.25, 0.0 ], [0.25, -0.25, 0.0], [0.25, -0.25, 0.0] ]

I think we should use structs (binary format) and they should be used both in MMF and UDP. Would be something like this (just an example):

Code:

struct Base // This is the base of the info, it will be at the start of all packets
{
    float time; // Time stamp of the data
    uint packetCounter; // Increasing value to control packet order in UDP, odd for when the MMF is being writen and pair for while not being writen
    int packetType; // For example: 1=MotionData 2=DashData 3=EventDataData 4=TimesData....
    ..... After this we have the corresponding structs with the data
}

struct MotionData // Would be sent for example at 100Hz, defined by the game creator
{
    float time; // Would be the absolute time in the game (should change only when in the game, not in menus or when paused)
    float[3] headPositionRelativeToCOG; // 0,0,0 if data received is already relative to the head
    float[4] rotation // World rotatin given by a quaternion (xyzw, 4 floats, no gimbal lock or rotation order problems)
    float[3] worldPosition; // Position in the world
    float[3] localLinearSpeed; // meters per second
    float[3] localLinearAcceleration; // meters per second^2
    float[3] localRotationSpeed; // radians per second
    float[3] localRotationAcceleration; // radians per second^2
    int wheelsAmount; // Number of wheels
    WheelsData []; // Info about the wheels
}

struct WheelsData
{
    float[3] PositionRelativeToCOG; // Position of the wheel
    float suspensionPosition;
    float suspensionSpeed;
    float suspensionAcceleration;
    float pressure; // If zero you have a flat tire
    flaot slipAngle; // radians
    float slipRation; // 0 to 1
    float surfaceType; // 0 for a perfect flat surface, bigger for bad surface
    ....
}

struct DashData
{
    float rpm;
    float rpmMax;
    float gear; // -1=reverse 0=neutral
    float gearMax;
    ....
}

struct TimesData
{
    int lap;
    float trackPosition; // meters
    float lapTime; // Seconds
    float sectorTime; // Seconds
    int sector;
    ....
}

struct EventData // Would be sent for example at 0.5Hz, defined by the game creator
{
    int lapMax;
    float trackLenght; // meters
    string location;
    string vehicle;
    string vehicleClass;
    ....
}

Now carefull this is mostly for cars or ground vehicles, planes need more info.
For example latitude, longitude, height... A good aircraft sim doesn't use position (x,y,z).
Maybe add a packet specific to planes, besides one for ground vehicles...

Text formats are complicated.
You need a parser, so it takes more time to read.
It also uses more bytes, a float is 4 bytes and has more precision than a float in text with 8 chars.
I'm all for compactness and speed.
Example, the quaternion for rotations doesn't give you problems with rotations order or gimball lock problems and it's just 4 floats (16 bytes).
The idea of diferent packets is to allow sending high frequency data faster and reduce the frequency for data less used. It can even work like an event. If something happens, we receive a specific packet.

Just some ideas...

Could you please post this to the github issue? It's not really going to work if I keep reposting other peoples comments. https://github.com/Open-Motion-Alliance/Standard/issues/3

This seems like good effort. Watching with interest.

Hopefully the first of many discussions.

Livestream with David Tucker from iRacing who will walk us through the iRacing API
Time: 1:00 am (UTC) April 11
https://youtube.com/live/Nq0YSA0Q6O4?feature=share