FlyPT Mover 3.5.3

I would love to see as an addition to this list the 2nd and 3rd order of EMA for HP or at least for LP like you did in “flypt hexapod”

What you see there is the basic commands.
Now you can compose it however you want:



Here's a 3rd order with the first has a high pass.
You can now make 7th order if you want to. And you can change the number of samples used in each filter.
You can even use a number of samples that depend on the value received.
You can now make the most crazy filter on your mind.
For example add a low pass and a high pass and in the end make a logistic (see sequence text result on the control):


That TRANSLATION could be called ADD. Idea is to translate the signal by adding or subtracting a value.
Like GAIN could be MULTIPLY.

All the gains and ranges specified on the interface are there just for help and trying to simplify the use of the interface for those that don't want to go deep.
On the background, what the program does is to add those parameters as filters to the filter you specify in that field, so all the input signal is treated as a filter from start to end.
So the end filter text will have a CROP to the range and input and output GAIN.
This is the change that took more time...

Calculation loop time/precision.

In the bellow picture, you can see the CPU usage when using the high precision loop:

Here, CPU usage in my PC can go up to 20%, but we can achieve a really stable and precise loop time.
This is important for rigs that use high frequencies of data.
The graphic shows how stable we get the value (here for a selection of 10.0 ms).

But if the high CPU usage is a problem, then go with the low resolution:

CPU goes down to around 5% in this example.
But precision is on steps of 1 ms and with an error of 1 ms.
For rigs that receive data at 10 ms interval this is enough.


High precision timer allows for even lower calculation rates.
In my system, I can make a complete calculation loop in less than a 0,1 ms, keeping the value stable.
Bellow an example with 0.8 ms calculation loop (vertical scale increased):


The graphic here introduces more CPU usage, so while using Mover in a game, and after setting up everything, just hide all windows to get the best performance.
Varying the loop time, changes the filters behaviour. So sharing data between users, requires that they are able to use the selected setup for loop time in their system.

More soon...

Excellent work as ever. Is it possible to assign a thread/complete workload to a specific CPU core to spread the work if you have a cpu with many cores?

Thank's,

Some more days and you can test it.
I'm making it use the minimum possible cores/threads. We want all we can for the games/sims.
I think it's really lightweight right now.
There's no big advantage in making code run parallel. We need data from one module to use in the next one, and in reality, there are not many situations where you have more than one module of the same type (and they are really light).

Can still optimise some parts of the code to be even faster. But let's keep it for the future. There's no big impact.

On my test's I think it's running OK. But I'm sure that when I release it, there must be something...

Right now there's only two threads, the interface with the user and the calculation.
In graphics it's possible to see the load of each one in milliseconds per loop. It's easy to reach 100 ms in the interface, but we just want it to have an easy way of setting the calculation thread.

Right now I'm finalising the soft start/stop and missing some images and touches for new rigs.
Also need to review some new sources I might add. They are not finalised (Dirt 2.0, Roller coaster ad XPlane) .

Also some new outputs to memory mapped file and UDP:


Just some more days.

Hello,

Any news ?

I'm kind of waiting the next stable version to try seting up my rig with your software

Yes, almost there!
One more week maximum.

It's a big internal change! New sources, rigs, features...
Forward kinematics have to wait for next update. Having some problems there. But I think it will work.
Way faster. In my laptop, with my rig, I can make everything work under 1 millisecond.

Still some small bugs and little things I need to solve before release.

Sorry for the delay.

Here's a screenshot:



I'm working on the program right now.
I was testing graphics on the suspension module.

Running on the laptop:


Look at the cursor on the graphics.


Pointing at the peaks on calculation loop. It's 0.033 milliseconds.
So right now I'm happy with the results.

Some tuning on the soft start stop:



Also testing some of the new sources.
Need to go through all to make directions all the same.

Anyone knows the units used by F1 2019 / Codemasters games on the suspension travel/speed/acceleration?
They seem strange...

A video with some tests I'm making...



Shows the new filter system.

XPlane will come with two sources (like DCS):



One when grounded and another one when in the air.

Why?
You receive data only in one, then generate different poses with different filters for each one (with your preferences).
In the rig definition we add both poses and the rig uses them sum of the two.



That way, you can define different filters for ground or air.

New version tomorrow!

FlyPT MOVER 2.0



Many changes, to much time to make the release, and it's not perfect...
Bu I said I would release it today. So let's test and see how it goes.

ALERT!
The new version causes sudden changes each time we change the filter. Be aware of that!
I will try to implement a soft transition, but it's not an easy task.

General changes
-Big internal changes in threads.
Hope we now have a stable code.
We can now define the calculation loop frequency in the main menu options.
See explanation there and use the most appropriate method for you.
Changing the frequency, changes the filters behaviour. So keep that in mind.
-New advanced filtering system.
Allows the definition of complex filters with different values for all of them.
That's the cause of the above alert. Be careful.

Sources
-Now we have 3 new values. They are the linear accelerations with gravity.
So no more option to use gravity.
-New sources:

-Directions are not the same for all sources. Please report the ones that are different.
You can change it in the poses by using negative gains.

Poses
-Implemented the new filters.
-In pose from motion, rollover is active when you select rotations positions.

Rigs
-Added more 3DOF rigs.

Now with 3 linear actuators and 3 rotating actuators.
-New images with the actuators positions.
-Now we define for each actuator what is the default position.
This is used in soft start stop. Each time you connect to the hardware, the actuators transition from the default position to the calculated one.
Opposite happens if you disconnect.

Outputs
-Now we can also send info by memory mapped files and UDP besides serial.
So now we have 3 types of output modules.
-We now have soft start/stop.
When you connect to the hardware, Mover makes a transition from the default position of the actuators (defined in the rig module) to the currently calculated position.
The time taken on the transition is defined in the main menu "Options".
-Interval, is now Interval loops.
The change here is that you are not defining time between each send to the output.
You are defining the number of calculation loops made between each send.
So if you have a calculation loop of 2 ms and want to sente data at 10 ms, put here a value of 5.
That's 5 calculation loops at 2 ms each before each output.
There's no reason to send the same data multiple times, and that way we are synchronised with calculations.

3D Viewers
-Enhanced visual representation of linear actuators.
-Disabled thin lines that showed the calculated position/last possible position.
Now actuators just turn red.
-Representation for new rigs

Graphics viewer
-More stable. Info shown is properly scaled.
-If the interface as a low update time because of load, we start seeing bars. The reason is because we had no time to update the info there.
Those bars should have the width of the time for each interface update time.
-More info available in each module.
-Can now make a graph for interface and calculation loop times.
-Cursor showing value and at how much time was the value we are seeing.
-Vertical and horizontal scale.
Changing scale, makes the old values fade, because those values had different scales.
Changing scales doesn't change the values already shown in the window.
-Each time a grey bar appears, it's because the graphic was not update in that space of time or some changes where made in that period (like change scale).


There's so much more, specially in the internals...
Need to change guide info for this version and include info on how to config the sources.
Any question, jus ask. I will be around.

Go to the first post for download!

I wake up Saturday morning to find this!
Now I know what Im doing all weekend.
Fantastic Work! Well Done!
I'll give it a good run from a newbie's perspective. I'll let you know how it goes.

Thank's.
There are some problems with some wrong values in sources. (codemaster games)
I will correct that with a new build tomorrow.
There might be other errors... Could not test all situations.
It's 01:00 here and I'm a bit tired. If I start anything, it's just to cause more problems.

Not getting values from xplane

Is your port 4123 ?

Yes. Do you use 127.0.0.1 in the IP?
This is my settings in XPlane:



Checked network via UDP in:
#3 Speeds
#17 Pitch, roll and headings
#37 Engine rpm
#137 Gear forces
#135 Motion platform stats

You need to check those, specially gear forces to get data.
I have to make a guide for each source.

Hello,
First Thanks for your fantastic job !
For assetto corsa you have for plugin input UDP communication ( I’m noob for this ) . In your other sw you use MMF plugin ? In fact I don’t really know how to setup this . I used your direct plugin with UDP and it doesn’t work or could you tell me how to setup ?
Thx

Ouch!
I was working on the UDP version. And I activated the wrong one...
MMF is there, but hidden
UDP is not working yet. I will post a new version with this corrected.
Give me some minutes.

UDP is a network protocol. The advantage is that with UDP you can run the game in a remote PC and send data through network to the PC with FlyPT Mover.
MMF is like a file but in memory. The game updates that file with the data and we read the data from there. It works only in the same PC, but it's the fastest one when we are on the same machine (game and Mover).
If we are using a console, then we need UDP. But I don't know if any of the sources I have is compatible with data output from consoles...

Should I see the values moving with this config ?

Aha I got some if I check Nr. 17

Is it normal that if you don’t check the 17 there is nothing going in ?