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

Its doesnt work like that it runs on the Gaming rig not seconds PC

@pmvcda I am currently looking into what software to use for my project. This looks great and already offers many options for tinkering, but is there any chance to get the source code published (at least for non-commercial purposes), like, possibly on GitHub? It would be great to play with the code and possibly avoid a lock-in if for any reason your suite is no longer supported.

There is a post about controlled by the PS4 , and I thought if it works it could work with dual PC too.

You can use it with sim tools as normal with a second PC but not in direct game data mode.

Hopefully "not YET"

@SilentChill and @hexpod ,

Thank's for answering the doubts.
You have been helpful now and before, in testing the program and pushing for more features. Thank's.

I had some crazy days here. End of month, and travel to a software competition in Porto.
My son, was 4th in the nationals (he's better than me already), and has a good chance to represent Portugal in Azerbaijan. So a proud father here!

@Thomas Luzat
I'm not going anywhere, I will keep around. For now it's not on my plans to go open source (for now).
I have more plans for the software and I want to implement them before thinking of sharing the code.

@Gabor Pittner and @C1500
Relative to UDP:
It's implemented because many games use it.
LFS is a great one to use for testing. It runs while you use other programs and replay sends data.
I want to add UDP for consoles also and making it, it also allows for remote access.
Just needs the IP field added. But has it is, remote only works for UDP solutions.
I have no IP right now, because I have to make a different interface for PCARS and AC, since they use a different API for consoles (I have to take look).

Now, let's see what I can make this week.
Would be great to add some more games and the remote UDP for consoles.

Can you show me the rig measures.
I might have to change the way I calculate the angles.
In some positions we have more than 1 solution. So I cheated a bit to make it faster by ignoring that.

I use a laptop to control my rig. @SilentChill said some months ago that he saved about 10% CPU performance on his game PC using dual PC . And I like this mode. But no problem at all I can use simtools as before.
I just wanted to try some games directly...

Simtools has lots of strange movement that I don't like. For example the car position indicates pitch and roll movements. Its absolutely wrong when the car moves fast. There is a straight before reach O'rouge in spa. Its a slope (kind of downhill), even if I accelerate the pitch goes down to front, its weird. Or the other example in redbullring before the first corner there is an uphill, I brake hard from 300km/h but pitch keeps back. It also feels wrong. The roll effect on a tilted track driving fast feels wrong too, extremely wrong.

More or less this is it:

Sorry for OffTopic BUT:
Congratulations and good luck in Azerbaijan.

@pmvcda ,

May I ask you to develop a HPF for translations with a variable cut-off frequency depending on corresponding rotations.

Ex. More you pitch more your surge returns (stays around) to center
Same relation for heave vs. yaw and roll vs sway.

This is something I had in mind for quite a long time without being able to code it.

As I know you can, I would like to have your opinion about the idea.

Best

EDIT:
Another approach could “washout out” all translations at the same to keep the accel consistency between them.

Ex. More you increase a single rotation (or a sum of three of them) more you washout all 3 translations.

This needs to be discussed what would be more suitable for our application.

Variable HP for translation depending on rotation

I see it inverted. I change rotation depending on translation.

What I make right now is to replace a constant acceleration with a pitch.

On the limit, having 90º pitch (not possible) would give a constant 1G.
Some studies say we can't differentiate the pitch from a surge with VR.
It would be nice to achieve that smooth transition and use the constant acceleration as a pitch and then apply surge in the pitch direction for smaller variations on acceleration.

But looking at this, what we see:
-LP filter to get the constant value
-HP filter to get the variation

That's why on the mix pitch in surge, we should use a low pass filter
and on the surge an high pass.

I don't understand the heave/yaw, because there's no gravity on that rotation while that happens in the other ones.

Might be missing something there, but I don't really see a gain in adapting the HP filter for a rotation, more the opposite.

Oh thanks for quick response. Just edited my previous post.

I will read again to fully understand what you mean but intuitively, in my opinion, the rotations are more important to preserve because they are able to “simulate” also the sustained accelerations in opposition to the translations.

That’s clear.

I am successfully doing this in the simtools matrix so I can differentiate the surge (effect) on pitch (dof) with LPF and on the second slot, the pitch angular velocity is unaffected by the filtering from the first slot.
Also applying another type of filtering on surge is also possible in this configuration

I think what you are asking is already an automatic result of the current approach.
Well I have to think about it better, but on first thought, that's my opinion.

Right now you receive the acceleration to generate surge. Surge is generated by filtering with HP the acceleration.
The same acceleration sent to surge calculation is also sent to the mix to generate a pitch using a LP filter.
I allow the use of any type of filter for testing, but in theory this is what would be used.

So basically, accelerations are used to calculate translations and rotations.
Rotations from "position" are used to add to the previous rotations. Let's imagine a slow vehicle in slopes. We should feel those rotations, so they should be replicated how they are received.
In an air plane it might be different. Those rotations don't have the same impact. It depends on speed and cornering.

What I see here is that depending on the acceleration/force generated, the amount of angle can change.
Thinking of a race car in a banking corner of an oval track.
The forces generated can completely neutralise the rotations that come from "position", but the final rotation is already a result of the "position"+rotation due to acceleration.

Thanks for the answer.
The famous “last one” for the rest of the week...

While using your “mix surge on the pitch”, do the LP applied on the surge affects what you send to the pitch or those filters are completely independent?

Indeed when you check the surge “lock checkbox” the effect disappears from the pitch although mix is selected.

I thought checking “mix surge on pitch sends to the pitch a second independent effect.

Ask and request anything!
That's what makes the software better.


The filters are completely independent.
I also think that the lock check boxes make some confusion.
Think of the use surge in pitch like a lock check box for that feature.
And if you lock the surge, the pitch generated by the surge value where you locked, is kept unless you reset the value or you have a filter applied that can modify the value.

Right now I'm trying to make an auto calibration feature.
Started with gain for each component, but got to the conclusion that adjusting filters is the best way to go, but it's not easy and brings lot's of other problems.
Gain is for now reserved just for how strong you want to feel the simulation.
I think I can achieve an auto calibration that works, but it's going to take some time.
The feature I'm working right now, is a way for the user to find where we should have the washout tuned.
It's like saying to you, close your eyes and keep a key pressed while you feel movement.
I'm trying this for all the 6 DOF, so we can compare the values between sway and surge for example.

We can't control speed directly, what we can do is send small variations in position to make a slow speed.
Just looking at this, we can see that it's completely dependent on PID used in each rig.
So a specific movement in one rig, might not be noticeable while in another rig the same user might notice the movement.
Also for each user, the feeling might be different.
There are many variables, so the best way to make it is an auto calibration dependent on the feeling of the user and the limits of the rig.

Let's see how it's going to work.
But this one might take some more time.

Was testing with measures you gave me and the values I can see in the video.

You have 109º range for roll (the value you are changing).
I don't think you can achieve that value on the rig. At least with the seat mounted on the top platform.
Since you have a smller top platform compared to the bottom one, maybe it could be possible.

I can't achieve the same you have. I think the dimensions are not the same.
But I'm taking a look at the formula to see if I can limit it to the maximum angle specified. I think that in the video you have more than 85º range.

But I saw a bug already. I'm not correctly identifying when the rig is out of range. So the program is showing some crazy poses as possible while they are not possible.

EDIT:
Also you have stay in last possible pose checked.
So what happens in those jumps is that you where in impossible positions and when you reach a possible one it seems like the rig jumps.
Look at the thin lines to see it moving.
If you uncheck last possible pose, the crank/rod are shown in red, specifying an impossible pose.
I have a new build that also makes them red when you have an angle beyond the specified range (it was not happening).
I want to verify some more things before posting that build.

Yes I pushed the intensity to 109 only for testing purposes.

Also I use greater angle as 85 to use full kinematic range.

Indeed in my software I have a complex equation for out of pose which is independent from dof limitations and doesn’t need the arm limitations either.

You seems to deal differently with this