FlyPT Mover

Ace Battle 7. No problem. It stops when I switch windows.

Not problem game. Problem is stop when switching windows.

Ace combat 7.

So I finally got my hexapod working (MotionXP PRIME) and it's amazing. I mainly do iRacing and Assetto Corsa so for me it's all about racing profiles.

I watched the YT video of setting up FlyPT for Dirt 2.0, it was very informative and gave me some really good ideas that I improved upon and made my profile even better, however I'm still looking for some answers as things likely have changed since that video and there may be better way to do things.

1) First of all, I think profiles are far more rig specific than car/game specific. Sure, there are some things that can be tweaked for a better experience with some vehicles/games but ultimately the telemetry should be correct and that would mean that the motion is really just down to what your rig is capable of and tune to that. Thoughts on this point?

2) The only exception would be if you have vastly different cars where the rig's capability is either not utilized by the "tamer" cars and/or it's past the limit by some of the more extreme cars. Case in point, if you drive around a Mazda Miata MX-5 for the most part but you tuned your profile to be able to handle the G forces of an F1 car then the Miata will feel very muted, which might be what you want so you have relative feel between cars to, or you can dial up the forces on the Miata to use more of the rig's capabilities when you know you wouldn't be hitting 3-4 Gs in the corners, not on purpose anyway.

3) The video does the following mapping:
Sway - Lateral Acceleration
Surge - Longitudial Acceleration
Heave - Vertical Acceleration
Yaw - Yaw speed
Roll - Roll position
Pitch - Pitch position

So the question I have is, is there benefit/reason to use lateral, longitudinal, and vertical acceleration with gravity instead of without? What would that change here? Why was that not used in the Dirt Rally setup demo?

I think pitch and roll position in its absolute is perfectly fine for racing simulators without any washout as I'm not expected to do barrel rolls or go over the limit of my rig (I have 30 degrees of pitch/roll with this rig). Any opinions on this?

The yaw is using yaw speed with a doubly LP filtered CUBIC3 which means I will start feeling the rear letting lose only at around 12 degrees/second which gives me a feeling of completely losing traction but I don't get the "about to lose" traction feel. What are people running here usually?

4) So I think on the directional forces axes moving the rig more because there is bigger acceleration is not the right solution/thing to do, but that is precisely what every PT mover profile seems to do and then wash it out (fairly fast, way too fast imho on profiles I have seen).

I think what should happen is:
a) The lateral move should completely follow the forces we're experiencing (we should accelerate through the movement and it should gradually slow down as the rotational mix is added in to overtake the initial lateral force simulation and eventually wash out in as long of a time as possible without compromising lateral move readiness for the next lateral force change.

Instead we merely tell the rig how far to move laterally depending on the force. What we should be doing is telling how fast it should be accelerating and it should be for as long as it takes the rotation to take effect. I found no easy way to do this with PTmover, meaning I can't really control the speed/slope of the output signal I can only control the distance. I feel like we need second derivatives here with some filtering to accomplish this.

I can share my profile for dissection, but I want to hear general opinion from experts/smarter people than me.

Note that this is for racing cars, for flights the situation is probably different and I will tackle once I get a HOTAS and give it a shot.

Only with the speeds for the 3 rotations (not the position angles) and the 3 accelerations with gravity can a “classical washout” algorithm and eventual derivates be correctly constructed. Unfortunately, it happens often that the game only gives access to angular positions and accelerations without G. Assuming that a racing game gives you the speeds for yaw, pitch and roll, the philosophy of the cueing algorithm shouldn't be any different between a car and a plane, in my opinion. If the game doesn't natively provide accels with G that's okay, you can add gravity alone in the mover, taking care to do it in the right direction, or use "accel with gravity" and hope that gravity works correctly. I remember it was quite difficult to get them right and a big help from @pmvcda was needed as many games use different coordinate systems.

To answer your question about different vehicles or aircraft, if you're looking for an optimal platform response, you would need to create a different profile for each type of vehicle, especially if the difference is extreme, like between a Cessna and a fighter jet, or an Opel Mondeo and an F1 car.

edit:
I believe with all filtering possibilities mover offers you, only your imagination is the limit.

cheers

So I've read some academic papers and while the "Classical MCA" seems to agree with you and that is what FlyPT Mover can and does execute, there have been some developments/improvements using different approaches. I don't think I have the energy to deep dive all that, I think I'll try to work on a profile that implements the Classical MCA granted I have access to the source data required (I think most sims do provide the required data).

Having said that, the profile I have, which as you can tell is not using the Classical MCA as it's using different inputs seems to fool me and my family fairly well in general .

Oh, one more question: I noticed that people tend to do both "From Motion" and "From Suspension" for the same rig. Why would anyone do that? I would assume Motion already has the suspension impact/effect baked in.

I guess I'm going to answer my own question: since the motion pose uses filtering you'd lose the suspension data so you have to mix it back in by isolating and adding t onto the motion data, is that correct?

Also there's many tastes. I get asked many times on how to get more punch on gear changes, that's the same as you say, it should be already in the chassis motion...
The idea of Mover is to allow you to do whatever you want to try.
Next release is going to have plugins so anyone can add custom alghorithms in code if they want to... but only when it's released I'm already ashamed of the delay.

I'm working on it...

Totally agree.

I disagree here. But that might be because I follow a different philosphy, see below. What data are you getting from your chassis that gives you information you are pulling 1 g vs 3?

Totally agree. In fact I think it important to only use pitch and roll position with a fairly high range of motion. Especially for rally. Ideally with a center of rotation at the center of gravity of your body.

I think to be accurate any chassis can only truely give you high frequecy acceleration data in the translation axes. There is frequency and amplitute that the chassis must provide. This data is delivered to the driver one to one with the data from the game and should be measurable with an accelerometer and have the exact same waveform as the game data with a lowpass filter applied. The amount of filtering your accelerometer measures is indicitive to your sims performance. Any ringing in any axis is a false cue that should be minimized (stiffer construction/stronger motors, or slower motion/more filtering).

If you want to mix in rotations to use gravity to make you feel like your acclerating then you should have a minimum angular acceleration to avoid false cues. The literature says humans can detect angular acceleration starting at ~0.5°/s² (ref top of page 46). So if you rotate your chassis faster than that minimum rotation you're going to notice and it will be a false cue. This false cue is worse when the center of rotation is far from the center of mass of the driver. When racing, accelerations happen way too fast for "motion cuing".


My opinion is not popular because, for racing I believe that no low frequency translational accelerations should be delivered to the driver via the chassis. Its false cues produce too much bad data. Instead all low frequency data should be delivered to the driver via pressure based gbelt, gseat, ghelmet, etc. Most people ignore these tools and dont even realize how effective they can be.

Please dont be ashamed! Take as long as you need!

Thanks for the response and confirmation of what I thought, my cognitive dissonance is disappearing as I write this.

This is simple. An F1 car will undoubtedly have much more G forces than a Miata. You can really brake hard and with the downforces from aero turn much harder than your usual 1G limit of race tires without downforce. So If I tune my rig to be able to handle the 3-4 G forces of the F1 car then when I'm only pulling 1G in the Miata I'm not going to utilize the full movement envelope of my motion rig, which may or may not be fine.

My hexopod can attain 30+ degrees in roll and pitch, honestly that level of tilt without visual cues is quite uncomfortable. The only caveat using all of that 30 degree envelope for static angles is that you have nothing left for acceleration force emulation.

I guess I can mount my phone onto the rig and record the output data and compare it to the telemetry coming from the car in the sim. This way I can really see what those acceleration cues are doing and whether they're proportional to reality or false cues.

This is very interesting. I think I do feel the angular rotation during braking which later converts into just pressure but this makes a lot of sense! 0.5°/s² seems very low and doesn't allow you to do a solid persistent acceleration transition without the false cue, just like you stated.

Very interesting! I do have a belt system and it adds a ton of immersion to my experience already. It's incredible just how much more the g-forces feel more real with the belt pulling you against the seat during hard braking.

Thanks for all the insight, a lot to learn but overall very excited!

But if your rig can only accurately deliver high frequency data with the chassis, and you want high quality data delivered to the driver, then these low frequency effects (longer acceleration than a bump) are filtered out. Essentially your chassis can only deliver bumps and vibrations in the surge sway and heave axis. Thats why I asked what data you as a driver are getting from your rig that shows your accelerating 3 gs. The only way to deliver that with a chassis is by tipping the user and letting a very small portion of gravity tell you what gs your accelerating. This is full of false cues so I say we shouldnt do this. But if you think you should endure the false cues to allow gravity to give you low frequency information, consider how small the max force will be. Its absolute max for your rig is sin(30°)=.5G. So now you are stuck with half a g as the most you can feel accelerating. But to get it you have to rotate 30 degrees. Well snapping 30 degree quickly feels terrible. So you would likely reduce it even more to make it work.

If you consider a g seat like the one I link to in my signature, you would be able to deliver up to 170lbs of force per paddle (instantly and for however long you want). That allows a user to feel a large resolution of force for anything from f1 to a miata and all the nuance in between and not change the tune at all.

Back to the chassis, if you dont put rotation into your surge, sway, and heave degrees of freedom then you can give a 3g bump or a 1g bump for any car and never change the tune for each vehicle. The downside of course is that you must build a g seat! (but its worth it)

See above about not mixing rotation into the surge sway and heave degrees of freedom. But also consider a large range of rotation (±30°) for pitch and roll. Assign pitch and roll position to the rigs pitch and roll position 1 to 1. Now you can feel the climb of a hill, feel the suspension load up at a launch off the line, understand how the car upsets on huge curbs at the nords. Its fantastic data to the driver, especially in a rally car.

I recommend turning off all motion and do one translation axis at a time. Surge, then sway, then heave. Assign a couple of inches of travel to these axes and no more (experiement with it to see what your rig can do). You can only deliver fast bumps to them (high frequency data), so there will be no time to move farther than the few inches.
Then do this for the rotation axes, but open the range up all the way. Find some elevation changes to drive over, jumps, or bumps, or curbs. Record pitch only and see how it compares.

This would be infinetely easier to do if/when we get a csv output for recorded mover telemetery so we can pop it into excel and see the data right on top of one another.

Check out my gseat thread and imagine what that feels like. I feel like a gseat evangelist over here but ... it's a big freaking deal!

Love geeking out on this stuff.

Finally working on the main window...



Kind of a future Mover4.0, just for visualization. (WIP)

Pedro, that's wonderful! Would be plausible for you that you will release directly the 4.0?

Sorry, but no. Impossible to release at the same time.

Hi all,

Just a few questions. Does the @Thanos Tronic DIY controller work fine with FlyPT. (AMC-open-hardware-servo-controller-4DOF)?

Is the file sharing still working? I can only see like 6-7 files in total.

I believe there is a new release coming to include EA WRC source, is that right? and if so, where is the best place to find out when it's out, their website?

Thank you!

Hi,

Yes, Thanos works with Mover. Any serial output is possible, but Mover includes a dedicated Thanos output.
File sharing should be working. I had a problem with the server and lost all the data. For the new release I will be using an external server so those problems should be solved.
EA WRC and others are included in the new release. Keep an eye here and on the site.
I think I will create a new thread here for the next release. This one is too big and might cause confusion with some of the changes coming for the next release.

It's almost done. Need some more time to solve some bugs and be sure there will be no major changes to solve any problem that might come with the new release.

Awesome, thanks!