FlyPT Mover

WARNING:
From 20 September 2024, a new release is available
Look for it on the new thread:
https://www.xsimulator.net/community/threads/flypt-mover-3-7.19016/

ALERT!
This is WIP. So expect problems!
Info on the next posts is not updated. It's still valid, but some new features are missing.

ABOUT
This can be considered version 2.0 of the FlyPT Hexapod Interface.
But due to limitations on how the code was developed, new ideas forced to a profound change.
So picked what I could from the old program to build this one.

Edit: Ok, many more changes on the internals originated the version 3.0.
The reason we are now on 3.xx.
So that 2.0 is past, but more on the internals and not on the UI.

THIS IS FOR WHAT?
It's a solution to get info from the games, SimTools or other applications and generate outputs to the hardware.
In between, you can play with the values and generate motion using motion cuing algorithms or pass values directly to the hardware.
Hopefully, I managed to make it simple and understandable. Might have an hard initial learning curve, but after understanding the basics, it's fairly easy to test infinite solutions and search for your rig ideal and personal preference.

VERSION HISTORY

3.7.0 BETA (20 09 2024) Will be released in a new thread:
https://www.xsimulator.net/community/threads/flypt-mover-3-7.19016/​

3.5.3 (12 09 2021) More info in this post

3.5.2 (27 08 2021) More info in this post​

3.5.1 (16 08 2021) More info in this post​

3.5.0 (09 08 2021) More info in this post (Online sharing setups)

3.4.2 (04 03 2021) More info in this post

3.4.1 (26 02 2021) More info in this post

3.4.0 ALPHA (06 02 2021) More info in this post​

For FS2020 Support, please go here: (not needed for the above builds, only for 3.3.5) https://www.xsimulator.net/community/threads/flypt-mover.13464/page-74#post-204212​

3.3.5 ALPHA (11 11 2020) More info in this post

3.3.4 ALPHA (03 11 2020) More info in this post

3.3.3 ALPHA (03 11 2020) More info in this post

3.3.2 ALPHA (29 10 2020) More info in this post​

3.3.1 ALPHA (27 10 2020) More info in this post

3.3.0 ALPHA (26 10 2020) More info in this post​

2.9.9 (08 05 2020) More info in this post

2.9.8 (19 04 2020) More info in this post

2.9.7 (16 04 2020) More info in this post

2.9.5 (24 03 2020) More info in this post

2.9.4 (22 03 2020) More info in this post​

2.9.3 (19 03 2020) More info in this post (WARNING, setup compatibility is lost. Sorry)

2.8.0 (06 12 2019) More info in this post

2.7.4 (14 11 2019) More info in this post​

2.7.3 (13 11 2019) More info in this, and this post (WARNING, change in file setup extension!)​

2.6 (17 10 2019) More info in this post

2.5 (08 10 2019) More info in this post

2.4 (04 10 2019) More info in this post

2.3 (25 09 2019) More info in this post

2.2 (24 09 2019) More info in this post

2.1 (20 09 2019) More info in this post

2.0 (20 09 2019) More info in this post
​

KNOWN PROBLEMS (latest version)

- Some sources with directions inverted in some values. If you detect it, just use a negative gain.
- Joystick is not detecting all keys and axes.
- Some missing rigs images.
- Some bugs, please report.​

DOWNLOAD
Please, go to flyptmover.com

MAIN WINDOW

You start the program with the main window:



The window has nothing.
To access the menu, just right click on the window.

From there, you can add modules. Those modules are displayed in the main window.
Here you can see the main window populated with modules:


So each time you add a module, a new window shows, where you can setup that module.
Each component receives and outputs data.
If you close the module window in the X, you are removing the module.
You can hide the module by pressing the arrow in the window, or by clicking in the square of the module in the main window.
So light squares are visible modules/windows, while darker ones are just hidden.

You can see the modules are ordered by type, each column is a type.
Calculations are made in the order of the columns and can't be changed.


Modules can be:

Sources
That receive data from games or generate data to be sent to poses or directs

Poses
That receive data from sources or generate data to be sent to rigs

Rigs
That receive data from poses and send data to outputs

Directs
That receive data from sources and generate data to send to outputs

Outputs
That receive data from rigs and/or directs and send data by serial or UDP (future version).

3D
For 3D views of rigs.

Graphics
For graphics visualisation from selected values.
​

Just think like this:

- All modules receive information
- All modules treat that info
- All modules send out the treated info to another module (see diagram)
- Not all modules receive or send info to all other modules. Usually a kind of module sends data to another kind of module.
​

Load and save setups

Setups are saved with the default "FlyPTMover" extension.
Every time you exit the application, the last setup is saved.
When you open the application, the last setup file is loaded.
That "LastSetup.FlyPTMover" file is saved on the installation folder.

You can save in a different location by accessing the main window menu (right click) and select save.
That way you can store multiple configs for different games.

You can load a file by dropping the setup file over the main window, or by selecting Load from the menu.

If you want to, you can associate the extension file to the FlyPT Mover and by double clicking on the files, the FlyPT Mover opens with that file.

All current info is saved. Fields values and window size and position are saved.
There's still some problems with auto starting hidden windows.

Start/Stop
Source and Output modules show a small square that can turn red.
When red, it means that module is connected (receiving or sending info).
You can start/stop all at the same time in the menu.

SOURCES

We have multiple types of sources.
They can be info from games/applications or info generated by internal code.
Current sources are:

Noise (generated noise for one or more values)
Loop (generated loops for one or more values)
Record player (soon in a future update)



SimTools (MMF) for more, see this post.
Project CARS 2 (MMF)
Project CARS 2 (UDP)
Assetto Corsa (MMF) --> Should be compatible with Assetto Corsa Competizioni
RFactor2 (MMF + DLL) --> Requires specific DLL!
Live For Speed (UDP)
RaceRoom (MMF)
iRacing (MMF)
No Limits 2 (TCP)
DCS (UDP) --> Requires Lua script! For more, see this post.

​

Where:

MMF is data received from a memory mapped file (shared memory)
UDP is data received by UDP protocol
TCP is data received by TCP protocol​

All sources generate a list of 49 values with the following info:

Lateral acceleration (m/ss)
Longitudinal acceleration (m/ss)
Vertical acceleration(m/ss)
Yaw acceleration(º/ss)
Roll acceleration(º/ss)
Pitch acceleration(º/ss)
Lateral speed (m/s)
Longitudinal speed (m/s)
Vertical speed (m/s)
Yaw speed (º/s)
Roll speed (º/s)
Pitch speed (º/s)
Lateral position (world coordinates) (m)
Longitudinal position (world coordinates) (m)
Vertical position (world coordinates) (m)
Yaw position (º)
Roll position (º)
Pitch position (º)
Front left suspension acceleration (m/ss)
Front right suspension acceleration (m/ss)
Rear left suspension acceleration (m/ss)
Rear right suspension acceleration (m/ss)
Front left suspension speed (m/s)
Front right suspension speed (m/s)
Rear left suspension speed (m/s)
Rear right suspension speed (m/s)
Front left suspension position (m)
Front right suspension position (m)
Rear left suspension position (m)
Rear right suspension position (m)
Rotations per minute of the motor (rpm)
Gear
Speed (m/s)
SimTools Axis1a
SimTools Axis2a
SimTools Axis3a
SimTools Axis4a
SimTools Axis5a
SimTools Axis6a
SimTools Axis1b
SimTools Axis2b
SimTools Axis3b
SimTools Axis4b
SimTools Axis5b
SimTools Axis6b
​

Not all sources generate all values.
Most fill only some of them. It depends on the source.
You can see the values received in the list (that can be hidden for better performance).

You have also the option to use or not gravity in the accelerations.
Some games have it included others don't.
But the FlyPT Mover, calculates gravity accelerations in each direction of the pose and allows you to add or remove it from the data.

There's a big difference compared to SimTools here.
There's no tuning center, all values are received as they are. Just converted to the same units.
And that affects how we receive data from SimTools.

So if you are using SimTools as a source, I recommend to setup the tuning center with the following values:



This way we receive the values without cropping or scale.
Rotations from -180 to 180 and accelerations up to around 10g's.
Those are not mandatory values. But a guide of what I think is best.
For more on SimTools source, go to this post.

Another important fact here, is the possibility to use more than one source at the same time.
So you can join LFS source with a noise source and mix them later on the pose generation.
Only problem here is if sources use the same ports, only one will work.

Besides the sources from applications, you can generate internal sources:

Noise - Random noise
Loops - Based on Sin, square, triangle or saw curves
​

Those effects can be generated just for one or more of the 33 values presented above. Just check them in the list shown at the right.
Don't forget you can have multiple sources of those types.
Also important is that in loops, all sources use the same timing, so you can adjust phase shifting to generate some interesting effects.

POSES

So we have our sources.
We are receiving information about positions/accelerations and we want to generate a pose.
A pose is the orientation/position that the rig will make to represent that info.
So here is where we have the motion cueing alghorithm.

Right now we have the following poses:

Pose from motion
This is where we setup the motion cueing alghorithm.
Select the source of data from the right (you can select more than one to add them).
Also, select witch value you want to use for each pose component.
Now you can select acceleration, speed, position or any other value to generate the pose.
Don't forget you can generate more than one pose and add them on the rig.



Pose from RPM
Generates a pose from the received RPM of the motor to simulate vibration due to RPM.
That's an arcade one... or maybe not.


Pose from suspension
Generates a pose from the suspension info of a car game.
Will become useful for other types of rigs besides hexapods.


So we can play with this!
Let's add motor vibration and suspension travel to the motion cueing.
If your actuators can work at high frequencies, you can even replace tactile transducers... Well, maybe in my imagination.

RIGS

For now we have:

Classic Stewart platform with linear actuators
Like the one in version 1 of the FlyPT Interface.
But with a difference.
Here we specify witch names we want to give to each axis and the bit range we want for them:
Look a rig defined to receive a mix of poses from motion, rpm and suspension, outputing info with the usual <Axis1a> to <Axis6a> (we can change the names):


Classic Stewart platform with rotating actuators
Like above, but with rotating actuators... I have a bug, can't post image for now.

I'm also thinking of developing for:

3DOF with 4 actuators (4 vertical actuators in each corner)
A kind of rig that's turning the new standard (my opinion).
Certainly limited in action compared to a Stewart platform, so some of the pose components are ignored here.

3DOF with 3 rotational actuators
Same like above. Fairly easy to add.

Custom
Where we specify how many and where are the actuators.
That's a complicated one, but I made the code to be ready for that.
So inverted, wall mounted Stewart platforms or other kinds of platforms can be generated.

DIRECTS



With directs, you pick a value from the source, treat him and create an "actuator".
That actuator can be used in the outputs to send data to the hardware.

In the above picture, is an example for wind.
We select Speed value from the selected source on the right.
Use some filtering/remap.
Convert it to a specific bit range and give it a key.

Now that key is available in the output modules.

This allows also the possibility to control your rig like we do in SimTools (or almost, needs testing).

OUTPUTS

That's where we send/receive data to/from the hardware.
For now we can only send data by serial output.
Soon, it will be added UDP and also receive data from hardware.

With serial output, we can send by serial, the pretended position of the actuators.
We add a serial output module for each board we are using.
The interface looks like this:



We can see:

- On the right, the actuators available. They come from rigs or directs.
The names/keys shown for each actuator are defined by the user on the rigs or directs.
If a key is repeated, you can't use that actuator. If you use that name, only the first occurrence of that key is accessible.

- On the bottom, we can see the sequence of bytes sent to the boards (debug).
Each value separated by spaces is the value of one byte.

- On the top, you specify the connection settings.
Port shows the available ports. Don't forget that if you change the board to another USB port, this port might change.
Interval is the time between each data sent to the board.
Type of output, can be binary or decimal.
In decimal, you convert the values to a string and send the byte values of the chars. So for example value 1234, uses 4 bytes to be sent in decimal.
With binary, you send only the necessary bytes to define the value. So 1234 fits inside 2 bytes.
See about strings bellow, to understand how binary can send values.

- Strings sent to the boards are defined in the 3 text lines.
One when you connect, one when you disconnect and the normal work string.
You can use any char to compose the string. Only < and > are reserved for the keys.
To use a key, you can drag the key from the right column to where you want her in the text.
If the key inside the <> is not recognised, the chars are ignored.
The number of bytes used for the keys are specified in the rigs and directs.
The way they are sent, depends if you use binary or decimal.
You can also send fixed values.
If you use <54>, the value 54 is sent in one byte (for binary).
But you can send 54 in 4 bytes, just put <<<<54>.
For example, 1234 doesn't fit in one byte. Send it with <<1234> it generates two bytes to hold this value.
If you send it with <1234>, the value overflows and you can't send the high byte, only the low one.

VIEWERS

3D Viewer

Add one or more 3D viewers to visualize your rig behaviour.
Don't forget, that the shown position is before applying any gain or filter to the actuators.
You can add how many viewers you want to see the rig in different perspectives.
In case you have more than one rig setup, you can choose witch one to view on the pull down menu.



Use the mouse to rotate the rig, and the wheel mouse to zoom.
Those are "heavy" tasks, so close the windows if you don't need them for better performance.


Graphic viewer



Some bug here (sorry).
Still needing work.

On the right you have all the available values to show on the graphic.
Check the ones you want to see.

Values are draw, all in the same scale, that you can define in the top left corner.
This brings a problem, because the values can have big differences in ranges. So take it into account when using graphics.

Also, for optimisation and speed, if you change selection or scale, only the new values have those new settings. History is kept unchanged, just scrolling left until it disappears (and I don't think it's going to change).
Also for optimisation reasons, values are shown in translucent areas instead of lines.

As I said, it needs work.

SPEED

One of the features of this interface is the possibility to add many items to the data processing.
There's many things happening visually, to help on the setup of the rig.
When you achieve satisfying results, you should hide all windows and remove the ones you don't need to avoid updates on the interface.
Any extra info update increases lag. So, use only what you need.
Run the program in "minimal" mode for better performance.
Also hide panels that show resulting values to avoid those updates.


SLIDERS (general explanation)

All sliders used in the interface follow a specific logic.
There's a button you can use to change the value when the control is active (blue).
When we are receiving a value, the button becomes grey, and you can't change it's value.
so if we are receiving data, the button position reflects the received value.
If the value received is beyond the range of the slider, the button shows red.



You will also notice, there's a bar behind the button.
That bar represents the output value.
If there's no filtering happening, the bar matches the button, but with filtering or gain, the bar shows a position that might not match the button position.
If the bar is red, it's because the output value is beyond the range of the slider.

Sliders are just a tool to allow the user to manually input values or to get a visual representation of what's happening.


WINDOWS NAMES

Why those names?
The name is the same for windows of the same type, but they are always appended with an ID to make easier it's identification on the input lists of each window.
As an example, two sources and one pose.
You can select witch sources to use on the pose. Even using two loop sources, the names would be different with the appending ID:

FILTERS

Maybe the most important part of Mover.
It's also important that you understand what each filter does to make it easier for you to use them.
To learn, the best is to use the graphic viewer and a loop source.
You can see the results of the filters over the original value.
Please try, it's the best way to understand them.

Mover uses a new filter system:


We can compose the filter with multiple operations and specific values.
This allows users to crop/limit values received.
And also play with a multitude of filtering solutions.
Filter can be generated in the combo boxes visually or by writing the code in the text box.
Here's a quick reference of the filtering system:



ADVANCED FILTERING

Advanced filter is composed by a series of operations.
Each operation can have parameters.
Those parameters can be numbers or other operations.

Possible operations:


VALUE
Is the value received.
No parameters available.


NUMBER
To specify a numeric value.


EMALP
Exponential moving average low pass filter.
Parameter 1 is the value we want to filter.
Parameter 2 is the number of samples used in the filter.
Use this to smooth a signal by removing high frequency variations.
Only low frequencies pass (look at figure bellow).



The number of samples define where we have the cutoff.
Cutoff is not a vertical line, only in ideal filters this happens. Reality is a progressive change like the curve shown in the figure.


EMAHP
Exponential moving average high pass filter.
Parameter 1 is the value we want to filter.
Parameter 2 is the number of samples used in the filter.
The high pass filter is the value we want to filter less the low pass filter for the specified samples.
So the number of samples specified, define the low pass filter used.
Here, only high frequencies values pass.
Low frequencies changes/smooth changes are removed, depending on the selected number of samples (see image bellow).



The formula for this filter is:
EMAHP = VALUE - EMALP(VALUE)


EMABS
Exponential moving average band stop filter.
Parameter 1 is the value we want to filter.
Parameter 2 is the number of samples used to define the start of the band (filter #1).
Parameter 3 is the number of samples used to define the end of the band (filter #2).
This filter, removes all the frequencies between filter #1 and filter #2.
So we get low frequencies and high frequencies.
Filter #1 and filter #2 define the start and end of the band of frequencies we want to remove.



The formula for this filter is:
EMABS = EMALP(VALUE) + EMAHP(VALUE)


EMABP
Exponential moving average band pass filter.
Parameter 1 is the value we want to filter.
Parameter 2 is the number of samples used to define the start of the band (filter #1).
Parameter 3 is the number of samples used to define the end of the band (filter #2).
This filter, only allows frequencies between filter #1 and filter #2.
So we remove low and high frequencies.



The formula for this filter is:
EMABP = VALUE - EMABS(VALUE)


DEMA...
Double exponential moving average filters.
Like EMA filters, but "2nd order".
Compared to EMA, those filters have less lag, but they also overshoot (see TEMA figure bellow).
Formulas are:
DEMALP = 2 * EMALP(VALUE) - EMALP(EMALP(VALUE))
DEMAHP= VALUE - DEMALP(VALUE)
DEMABS = DEMALP(VALUE) + DEMAHP(VALUE)
DEMA BP = VALUE - DEMABS(VALUE)


TEMA...
Triple exponential moving average filters.
Like EMA filters, but "3rd order".
Faster response compared to DEMA, but even more overshoot (see figure bellow).
Formulas are:
TEMALP = 3 * (EMALP(VALUE) - DEMALP(VALUE)) + EMALP(DEMALP(VALUE))
TEMAHP= VALUE - DEMALP(VALUE)
TEMABS = DEMALP(VALUE) + DEMAHP(VALUE)
TEMA BP = VALUE - DEMABS(VALUE)


LOGISTIC
Logistic is a case of the sigmoid filter.
Here we use a faster simplification.
Parameter 1 is the value we want to filter.
Parameter 2 is the range (minimum/maximum value allowed).
Parameter 3 defines the S shape. High value makes is a more vertical slope while low values make it more horizontal.
Use this filter to fit values to a specific range
Reaching and surpassing the maximum range, values are "compressed" to fit the specified range.
The S slope defines how fast and how much we compress the values.
64816


CROP
To define minimum and maximum for a value.
Parameter 1 is the value we want to limit.
Parameter 2 is the minimum value we allow.
Parameter 3 is the maximum value we allow.


REMAP
To remap a value from a range to another range.
Parameter 1 is the value we want to remap.
Parameter 2 is the start of the range where we have the received value.
Parameter 3 is the end of the range where we have the received value.
Parameter 4 is the start of the range where we want to have the received value.
Parameter 5 is the end of the range where we want to have the received value.


GAIN
Is a multiplication operation.
Parameter 1 is the value we want to modify.
Parameter 2 is the gain we want to apply.
Use this to invert values by using negative numbers.


TRANSLATE
Is an addition operation.
Parameter 1 is the value we want to modify.
Parameter 2 is the amount we want to move the value.


ABS
Get the absolute value.
Parameter 1 is the value we want to turn into absolute value.


SPIKE
It's a basic filter to remove spikes from a signal.
This filter, calculates the difference between the last value and the current one.
If the value is inside the allowed difference (defined in the second field of the filter), we let that value pass.
If it's out of the limit, than we let's pass just a certain amount of that value (defined in the third field of the filter).
If you put zero in that field, the value stays the same it was.
If you put 0.5, then the old value is added by half the difference between the old and the new value.

Looking good dude

I confess that looks awesome!!!

It looks fantastic

Impressive! Especially the modular design is smart!

That will allow users to adapt the software to their projects and you to add features anyway you like. Great!

Also great! Rad or degrees, Km/h or m/s, ...doesn't really make a difference. From a developers perspective I'd prefer Rad and m/s (because they are easier to process in the context of SI unit systems), but agreeing on ONE standard for all games would be a plus. Most people will want to see degrees and Km/h or Mph, I guess.
I'd also advocate finding a quasi-standard for data extraction would be a good Idea. Like your concept of: All slots are there, just not every Sim fills every slot.

Great to see you thinking outside the box! I thought about ceiling mounted and wall mounted as well. Probably not going to be "main stream" but allowing for custom kinematics will make users get creative

Like! I mean... L-I-K-E-!-!-!

One point I stumbled across:
Do you really want to create random (white) noise? Have you looked into Perlin noise? It's more coherent and great to generate turbulence, ground roll, etc.

THUMBS UP!!!

Dirty

Are you planning to make it as dual PC mode? Like simtools works separatable game engine and game manager applications using ethernet... DCS will work using IP address in lua script, but what about the others?
I use a laptop to controll the rig but the game runs on my desktop pc...

Looks great . Just not enough spare hrs in the day to try all this out .

This is the current state:

YES PC with game and interface ---Serial---> Boards (the standard solution)

NO PC with game and interface ---UDP---> Boards with network (almost done, in a future version - I want this one for my ESP32 Wifi boards)

NO PC with game and interface ---UDP---> PC with UDP to Serial application ---Serial---> Boards (too work, needs the UDP to Serial application, not even started)

YES PC with game ---TCP or UDP---> PC with interface ---Serial---> Boards (Works for games that output in TCP or UDP, others need application to convert shared memory to UDP)

NO PC with game ---TCP or UDP---> PC with interface ---UDP---> PC with UDP to Serial application ---Serial---> Boards (see above)

NO PC with game ---TCP or UDP---> PC with interface ---UDP---> Boards with network (almost done, in a future version - I want this one for my ESP32 Wifi boards)

Since everything is modular, I can add those features.
For now, only the green ones will be available.
The yellow one is almost done.

Yes, Perlin noise. Didn't thought of that one.

That Rad vs Degree, is something I have to change. I'm converting to degrees, because I wanted it more visual for the interface. But that brings so many multiplications ahead, that I have to change it all.
Not for now. I'm making a general cleanup and solving some stupid bugs to post the first version.

When I thought of making user defined rigs, I thought in different Stewart configs, but now I want it to be used with any kind of rig. Even 2DOF.
But it will take more time than I tough. It's not so easy. Actuators dependent on other actuators and rotating actuators not only vertical... But it will work!

I was so stuck with the old interface. This one had to be completely modular. Might be more confusing at start, but gives so many possible configs. Whatever we want.

Sorry.
Was going to release it in the end of last week, but I couldn't get time to make it.
Unfortunately, there's some problems still to solve before releasing it.

Here's a video with a new preview.
Some of the windows, might change until release. Specially that blue one, the main one. What you see is just for debug.



On this video, I show Outputs. Those are the outputs to serial. You should use one output for each board.
You can also see Directs. That's a direct conversion of a game value to an output value.
In the video,, you can see it capturing speed and generating a bit output to control a fan to simulate wind.

Also, I show keys. Keys are the names used by each actuator/output on the output string.
You can name it the way you want and use drag and drop to put them on the output string.
The bit range used is specified on the rig definition or the direct output definition.

More explanations soon.
Stay tuned.

Just take your time there is no deadline to meet at all Nice job!!!