FlyPT 6DOF/Stewart/Hexapod Interface for linear and rotating actuators

Trying to make it, but it's not possible.
Each time you move the slider, you send a value.
In HPF filter, he goes to zero, but he might be receiving a constant value. If I make the slider go to zero, but the real value is another one, then people will see an error there.
I come up with another solution, and I will put it in the new build:

Just some bars to show the filtered value.
Needs some work still, and I'm also adding LFS and RFactor2 direct support.
I know it's not very well visually, but I'm a bit lazy right now to make my own control...

Direct rF2!!! woahhhh cant wait

Version 1.8.3
New build for download on the first post of this topic.

What's new?

-Bars showing current filtered value on the sliders.
-Added RFactor2 and LFS direct connections.

The read-me:

Some settings I tested (be careful with the 180º in yaw - LFS - just for testing):





Will make a post later explaining some things. Manual still not concluded...

Just fyi mini mode displays the menu on top of frame.

AWESOME !!!!
But still some questions.
I have not tested the new version jet, but will it also work with UDP Data from PS4?
Would it possible to set the IP for the UDP?

kind regards
Peer

UDP is only for LFS right now, but I will add it to PCARS1/2 and AC
And yes, it needs the IP

Dead translations in the last one??

Already noticed that problem.
Changed the checkbox to a combo box... not saved correctly.
Please select the type of translation world or local on the combo that replaced the checkbox (might go back. New build close, because there are more errors)

Version 1.8.4

In the first post for download...

-Corrected bug in UDP connection of LFS. Caused a crash when disconnecting.
-New custom made sliders.
-Corrected bug on type of translation selection (changed to combo box for better understanding)
-More range in center of rotation.
-More resolution in gains.
-While minimised, menu is now disappearing.
-Some other glitches corrected.

-And probably added some more bugs...

Awesome work @pmvcda , tested rF2 and it works great however I have no idea how I should be setting it up to be honest. What felt ok before doesnt feel good now.

Can you give me any pointers as to what to do

Sorry for taking some time.

So, the big difference here is that there's no tuning center like we have in SimTools.
Values received are full rotation for angles and 90m/s^2 on linear accelerations.
Looks like nothing interesting right now, but I have my ideas for the future

Well, rotation should be the full turn and speed doesn't go above those 9G's usually, only in crashes.
So here we have less calculations.
The idea is to get the same from other games, so with the same settings they should feel the same (they don't, but we can compare).

Getting direct feed, also reduces the load of having SimTools, and we have less steps to get the info.
It's now easier to share setups and compare results between users.

But how should we use those values?

ROTATIONS
We receive 180º, but we want to use just 20º on the rig.
For that, we put 20 in the range and a gain of 9 (9*20=180).
Using this, we crop values to 20º, but we still receive the original value up to 20º.
This if we want to use the original value. (right now it's just position, not speed or acceleration).
Values should be the same for pitch and roll. That way we feel angles the same way in any direction.

YAW
This one is special.
I'm using a range of 40º (want to feel traction loss) with 4.5 in gain (with roll over and washout filter).
Put 10 in low pass to make it softer and 20 in high pass to make return to zero faster (adjustment depending on track and amount of corners).
Traction loss is not artificial, should be felt as a result of the forces and rotations.
Use a value of high pass that doesn't allow yaw to clip. Big value, accepts bigger angles and is slow returning to zero.
Low value for fast return to zero and only accept low values. We can use the low pass to soften and make everything slower.

LINEAR ACCELERATIONS
We receive a value up to 90m/s^2.
But we just want to use 120mm range in each direction.
Then put 120mm on range and to have the 90 at 120 mm use gain of around 1.4.
The idea of this is to map the maximum force to the maximum range.
If we want to feel small variations, we have to increase gain, but then we clip all the big values.
Use same values for all forces (sway surge heave)

Filters, use washout in yaw as said above.
Others try without filter.
If to harsh, use a low pass in the forces.
If rotating to much, use a high pass in rotations.
Linear forces are already accelerations, so they behave just like having an high pass.
While rotations are absolute values.

MIXING SURGE AND SWAY IN ROTATIONS
After tuning the others, let's try to mix those.
Start with low values of gain (0,10) and increase until it's OK.
Again, they should be the same to feel the same effect in all directions.
Also use a low pass to make it softer.

After setting those, use auto gain to adjust rig. Start with a value of 2 and let it find the minimum (use just the program, don't connect to the rig).
Then increase until you start feeling clip is damaging the experience (with the rig connected).

This is not a good setup, it's a way of explaining the values and the effect they have.
The settings applied for a clio:

Amazingly I actually understood all that it makes sense and is nice and simple, exacty what we need.

I will test again tomorrow now I know what to do.

I must say, that the above description was a fast explanation to accomplish some setup on the interface.
In the future, I want to implement some more features related to the motion cuing. That's the reason I need more info from the games.
The above is considering just linear accelerations and absolute rotations.

May I ask what happens if you uncheck the feature “stay in the last possible pose” because I didn’t dare to try it out ?

If unchecked, and you ask for an impossible pose for the rig, actuators that still have range can keep moving, but the pose is not what you asked for.
If checked, and you ask for an impossible pose, the rig stops at the last possible one.

Oh I see.
Is there any chance to modelize this in a way so your 3D model displays also this “fake pose” so it is not completely unpredictable for the user ?

I would guess intuitively that its a dangerous experiment when you start to send an actuator while the others are in “out of reach” state.

If you continue the motion while one actuator is blocked, for the moment, you are getting out of any math. Right?

Bellow without stay in last pose:

The thin lines show the last possible pose for the rig.
The bold ones, the filtered pose (not the one produced by the scaled actuators affected by actuator gain)
Possible pose is a pose that is allowed by the range of the actuator. So if you have a low gain in the actuator range, it's harder to reach an out of range situation.
That's the reason for auto gain. That gain is just like the scale we talked way back.


In this picture, same pose but with stay in last possible pose:

Now, thin lines are the pose you are requesting.
Bold ones the current rig pose. And that was the last one possible.
Moving "inside" a possible pose, makes the rig stay at the last possible pose, so she doesn't move.

In this last case, the rig stops moving while you are "clipping".
In the other one, the actuators keep moving while there's still range for that, but the actuators that don't have range, are stopped.
So the resulting pose is not what you asked for.

To model the resulting pose, we need to make inverse kinematics, and that's slow, we want it to be fast and we are interested in keeping inside possible poses to have fidelity to what is asked (that would be the only way to show the resulting position of applying actuators gain).
It's loosing CPU to something we don't want to happen. That's my opinion for now, but I might add that in the future.
There are other priorities and features I want to add.

If I had more time...

Thank you for the info.

Do we agree that having a pose “you didn’t asked for” makes your vectors totally wrong?

Ex: once you drive with less than 6 actuators, you can get a “kind of strange pitch” while actually asking for surge and so on into all others.

Imho its obvious that you never want a condition where an actuator maxs out to soon since it will effect motion in one way or the other so we really don't even need a way to opt out or to waste his time further discussing it.

Why do you think I made:

-the out of range detection,
-the gain adjustment,
-allow the user to select what he wants,
-add the filters and all that you see in the program to
-implement a simple motion cueing algorithm,
-that I want easy so anyone can easily understand and use,
-or that can even auto adjust.

It's not there yet,maybe at 60%, but that's what I want and I will try.