Angular Velocity/Acceleration

[saxxon66]

Thank You

First of all I would like to say thank you, excellent job.
Very nice approach to give us all of these sample impl.

For our motion simulator (https://github.com/SimFeedback/SimFeedback-AC-Servo) we use telemetry data in different ways.

We use

• roll, pitch and yaw to represent the position of the kart in the world (like going uphill, ...).
• acceleration vector data by using the rate of change over time, we call it jerk, to get the acceleration feeling. This data will be lowpass filtered.
• rate of change from angular data, highpass filtered to support the acceleration feeling.

Can you implement angular velocity or acceleration?

Again, thank you for your support.

Some thoughts about ...

FlatBuffer

Problem is, the framework is a black box for the client.
It will send only binary data and you can not debug the network stream due to the serialization.
This is why most of the services use JSON in a not serialized binary form.

I do like the FlatBuffer framework but not for a public interface.
The performance gain will not be much, most cpu time will go into the network stream handling anyway. It is all good for the happy path, but if something goes wrong, ... .

So if you like the performance, latency aspect what about shared memory?

Or if you like to support a variety of different clients why not use JSON?
It has a ECMA data interchange standard and is supported by almost all programming languages (http://www.json.org/).

[KeirMeikle]

Hi, yes we will add acceleration vector and angular velocity, no problem. An update should occur next week.

We seek to minimise errors, programming time and maintenance cost by using flatbuffers. As the game evolves it will also let us add and remove new data outputs without performance loss. It's certainly an experiment, but so far it is working very well for us.

As for debugging difficulty, do you have a specific example in mind? For all intents and purposes you should be able to treat the deserialization process as a black box and trust the output. The worst that can happen is usually a dropped packet. If you really need to interrogate the flatbuffer format before writing or using the resulting data for some reason you can inspect the implementations of each generated function in your debugger fairly easily too. Flatbuffers can also be deserialized as json for debugging purposes so if that is useful we can add some example code to explain.

[saxxon66]

Thanks for the response and for adding the angular velocity.
You provide already acceleration in each direction, this is perfectly fine.

I do understand the motivation using FlatBuffer and it was more of some thoughts I would like to share. And yes you can debug it on the code level, but not many will be able to deep dive into something like byte order (Big-Endian) or other low level byte interpretation (using a IDE debugger).
Most are used to look at a string coming in as a response.

From my experiences it was a real pain to have something like RMI with a client jar that comes with a direct strong binding to the client and every iteration/version needs a full update (Server + client jar).
In contrast extending a JSON schema is easy and non intrusive. You can parse it even if you do not need all fields/properties. Extending is very easy w/o any client modification.

I do not have any personal experiences using flatbuffer.
Maybe I am wrong, so let's find out.
I look forward to "feeling" your game.

Cheers

[tocaedit]

May I suggest adding the World Velocity Vector aswell? We use this data mainly for hilly tracks.

[KeirMeikle]

May I suggest adding the World Velocity Vector aswell? We use this data mainly for hilly tracks.

@tocaedit Do you use all three components or would vertical be enough?

[tocaedit]

May I suggest adding the World Velocity Vector aswell? We use this data mainly for hilly tracks.

@tocaedit Do you use all three components or would vertical be enough?

All three because Lat and Long is sometimes used against yaw to calculate drift angle aswell