Occupant Position Correction

Pasting here this Occupant Position Correction (OCP radial and tangential) build in x-plane.
Hoping we could sort out how to shift the driver/pilot position in Mover, from the Center of Rotation to the cockpit/driver seat location.



Welcome to any math ideas. If you give an equaton example, please use the names easy to comprehend.

Thanks

So, for who as followed this, there was some discussion about this problem in @Dirty topics.

So before going with the above (that I'm trying to implement in Mover), I want to explain the current solution in Mover.

Most if not all games, output data relative to the COG (center of gravity) of the vehicles. This happens, not only in planes, but also in cars.
So when they send out pitch, that pitch is around the COG.
In the example by @hexpod , the pilot is way in front of the COG so what is happening here is that rotations are the same, but besides the accelerations received from the game, the pilot seated so far ahead, should also feel centripetal and tangential forces due to the fact that he's so far from the COG.
Those forces are generated by the rotation variation. If you keep the rotation still, there are no centripetal or tangential forces.

OK, so what I do in Mover to solve this?
I allow the user to set the COR (center of rotation of the rig).
When the rig rotates, she rotates around the center of the moving platform by default.
Keeping the default, is like saying that the game COG is on that location.
You can change it and say where you want that COR to be in relation to your seating position.
Aircraft's are extreme in this problem. The COG can be far from the pilot, while in cars it's close and easier to just adjust it in the COR of the rig.
But you can do it for aircraft's also.
Now you say that the tangential and centripetal forces are not present...
Yes they are. Because if I move the COR far from the rig, and ask for the same rotation, I will get the same effect in forces felt. A far COR will produce an almost linear movement and the tangential force is there, but at a big scale.

TangentialAcceleration(m/ss) = Radius(m) x RotationAcceleration(rad/ss)

And centripetal?
She's also there, we are rotating at the correct radius and speed, the force should be generated (but we have a small range)

CentripetalAcceleration(m/ss) = Radius(m) x RotationSpeed(rad/s) x RotationSpeed(rad/s)

And since we are at it:

Tangential speed(m/s) = Radius(m) x RotationSpeed(rad/s)

We have those equations for 2D.
We have to add the effect of other rotations and add the components.

So:
- Yaw generates accelerations in the Sway/Surge plane/directions
- Roll generates accelerations in the Sway/Heave plane/directions
- Pitch generates accelerations in the Surge/Heave plane/directions

But depending on the direction is the distance used.
So consider that:
- DSway = Distance in sway direction to the center we want
-DSurge = Distance in surge direction to the center we want
- DHeave = Distance in heave direction to the center we want



We are going to use:
- Sway component of tangential acceleration generated by yaw uses DSurge
- Surge component of tangential acceleration generated by yaw uses DSway
- Sway component of centripetal acceleration generated by yaw uses DSway
- Surge component of centripetal acceleration generated by yaw uses DSurge

- Sway component of tangential acceleration generated by roll uses DHeave
- Heave component of tangential acceleration generated by roll uses DSway
- Sway component of centripetal acceleration generated by roll uses DSway
- Heave component of centripetal acceleration generated by roll uses DHeave

The acceleration in the sway direction generated by yaw would be:

SwayAccelerationByYaw = DSurge x YawAcceleration + DSway x YawSpeed x YawSpeed

The acceleration in the sway direction generated by roll would be:

SwayAccelerationByRoll = DHeave x RollAcceleration + DSway x RollSpeed x RollSpeed

Adding everything:

SwayAcceleration = ReceivedSwayAccelerationFromGame + DSurge x YawAcceleration + DHeave x RollAcceleration + DSway x (YawSpeed x YawSpeed + RollSpeed x RollSpeed)

OK, now do it for other rotations and directions...
Calculation is fast, the problem is that speeds and accelerations coming from games are not smooth, they are full of noise and generate to much noise in the output (might have something wrong in the code, I have to review the code).
Solution is to use filters, or use the center of rotation in the rig.

Making this calculations in the source makes it easier to use the filters in the motion cue algorithm, while in the rig, we have the final movements, and we have to play with a general filter for the rig.
Using the rig filter keeps the forces proportional, while playing with them in the pose module of Mover allows you to work on the separately.

As we say here, let the devil choose!

I will have both options, and would say:
Use rig for COG near the driver/pilot
Use the sources for COG far from the driver/pilot

Unless I can solve the noisy results...

In the end, forces increase, using the calculation or the rig center of rotation, and we have to scale them to fit the rig. Results are similar if not equal.
Just think: Far COG, sway rotation is almost sway, movement in rig is more sway than rotation

NOTE!!!!
I think the above is correct, but I will review it later, just to be sure...
I need to eat something, lunch time

Another think to note:

Calculating in the source allows a different scale of forces we don't achieve in the filter.
Having both is maybe the best.
Use the rig COR to define your head position. It's fixed for each rig.
Use the COR on the source, depending on vehicle COG.

Hmmmm, from my point of view, using the “rig CoR” is a no go for a simple reason, that in this approach, we have the same CoR correction on the mix channel (tilt coordination). It can’t work properly like this.

Also, maybe I am wrong, but I feel that by doing so, we don’t generate the needed radial force (centripetal).
So I think the valid solution here is to have a second CoR independent from the “rig CoR” which includes the radial force.

For the jitter, I can say anything why it is so strongly present, like you said maybe an error in the code or a wrong approach for conversion.

good luck

Best

Hey there

nice to see this boil up again, since I think this is a feature that is important (at least for flightsims) and super easy to implement. I have a sneaking' suspicion this post will get kinda technical, but none the less: It is relatively easy to implement and I already have code running, tested and found to work nicely in Nutkicker.

Fully agree! This sums it up completely! THIS is the problem and the solution at the same time.

All we gotta do, is...

1. Calculate those accelerations resulting from the pilot/ driver having an XYZ offset to the C.G.
2. Add them to the accelerations that are acting on the C.G.

...and we have the total accelerations present at the pilot position. Those will then go into the motion cueing algorithm and are henceforth the only accelerations to be considered.

I posted those pics before, but just to be on the same page:


How do we calculate those accelerations?

In essence, this is it! Doesn't matter which direction x/y/z represents in your reference system. You can use them anyway you like, as long as you use them the same everywhere.
∆x, ∆y, ∆z are the offsets. So, if your fwd direction is x and your pilot is sitting 4m fwd of the CG, then ∆x = 4.
wx,wy,wz are the angular rates [rad/s] around the vehicle x/y/z axis.
w°x, w°y, w°z are the angular accelerations [rad/s^2] around the respective axis. I haven't seen them exported directly on any simulator other then X-Plane. They are available there as Datafrefs "P_dot", Q_dot" and "R_dot". They can be calculated relatively easy.

If by "rotation still" you mean a constant angular rate, then I (and with me Sir Isaac Newton) disagree. Centripetal force is generated from the square of the angular rate[rad/s] while tangential force is calculated from the angular acceleration [rad/s^2]. So while having a constant angular rate, you will have centripetal accelerations, but will not have tangential accelerations.
--> Constant angular rate will generate constant centripetal acceleration. And because the square of the angular rate is used, its sign is always in the direction towards the CG.

Of course, if by "rotation still" you mean an angular rate [rad/s] of zero, then yes, they are all zero then!

They do indeed! Here's a picture of it:

Background info: Some of the equations that are solved in a simulator are transcendental. That means that over time their output depends on their own output. Kinda like: More speed --> more Drag --> less speed --> less drag --> more speed. Those equations need to be solved iteratively. I suspect that the way in which flightsims approximate those solutions creates those oscillating values. After all, do you really want to wait for 12 iterations to get a result that is 99.99999% accurate instead of just 99.999?

They are not a problem on their own, but become a problem (even more jittery data!) when derived. Here's what I did to deal with them:

1. Use a gentle low pass filter to smoothen them out
2. Keep processing rate and game frame rate not too far apart. I use 100fps for processing, 70fps for the sim. You can still do processing in a whopping 0.1ms after the frame comes in, just let the program idle for 9.9 ms after that. It's gonna take 14ms for the next frame to arrive anyways. Lightning fast processing is an honorable goal to have, but be aware of the theory of marginal utility. Eventually the utility approaches zero but the problems approach.... a lot!
3. Use a HP filter instead of a derivative. Butter smooth and computationally cheap. Mathematically it is only an approximation, but a good-enough one at that.

I don't quite remember which combination I eventually used, but all of them worked somewhat.

Will continue later, gotta go to dinner

Cheers, Dirty

I mean having a fixed value of rotation, no variation, no change.

You are right to some extent. In the scenario from the photo above, on the theoretical level, moving the “rig CoR” gives you indeed a „corrected“ pitch/heave-surge relation but as the heave is so disproportionate, to get this radial force you should have a platform able to reach almost real life workspace. As our workspace is ridiculously reduced, in practice there is no way to feel the radial force with +-10cm heave. So I must disagree that “I will get the same effect in forces felt”. The sacrifices to stay inside our workspace are simply to enormous.
BUT, it’s not because of this limitation that we have to sacrifice big cues, that we must at the same time to skip the small additional ones which are IMO extremely important.

Yes, at the end, we will be forced to fit the new linear cue inside our dof limit but having a proper math equation will keep the radial forces in each direction. Ok, not really in relation to the tangential force but still well present.

Despite the argument which obviously destroys the “mix channels” I wouldn’t underestimate the importance of sustainable radial forces like in “yawing the aircraft on ground” scenario, where the radial force will be pushed through the tilt coordination to transcribe a negative pitch.

best

This is also where I have to respectfully disagree. Here's why:
The formula is correct. Just like all other formulae you use are correct. It's just that he angular rate you're using there is highpass filtered already! That means that the continuously present centripetal force in a turn during taxi or while spinning an aircraft was filtered out as well. It is simply not present in the signal for any period longer than ~500ms.

Correcting the data stream at the source would transfer the long term effect of this angular rate [rad/s] over to the accelerations channel, where it would still be present, because that channel - at least the part that goes on to the low frequency content - is only filtered with a (hopefully 3rd order) lowpass filter. It can pass the LP filter completely unharmed

Here's the processing flowchart of my software.

The red arrow indicates where the angular rates are transferred over. They will show up in the two tilt-coordinated channels as pitch DOF and roll DOF.

--------------------------------------------------------------------------------------

Here is where we agree:
AFAIK, Mover as it is right now is completely able to implement these effects if the user knows how to set it up properly. It would require to create 6 additional poses from motion and a little creativity, but it is possible! E.g. Instead of specifying an offset directly, you would have to (ab-)use the gain to "symbolize" the amount of offset.
Actually, it was @hexpod 's idea who showed it to me in March. Initially I thought "hmmm, that could be a nice workaround" but now after looking into Mover a little, I realized that the softwares modular design is so incredibly flexible already that it can be implemented fully and correctly.

@hexpod ,

It's going to be in all sources.
Making changes in some that miss the accelerations:


You can see lateral acceleration with and without correction, simulating the driver 10 m ahead of the CG.

@Dirty and @hexpod

OK,

In your opinion, should we keep the original linear accelerations available at the same time we have the corrected ones?
Do you think we can have some advantage from it?
(I don't think it's worth, but if you see any advantage, I could keep them, can't think of any for now)

EDIT: And people get so lost already, that 3 more values might be really confusing.

I don’t fully understand ? With OPC value 0 on 3 axes, the accelerations should be unaltered, right ?

That's a good question!!

TBH, I have no idea! I have three simple input field to specify the pilots xyz offset, and if I don't want to use it, I just set them to zero.
But I have to admit, I have never thought about wether I would ever want both...!

I would have to construct some pretty silly/freaky case where someone would want to generate over-G warnings (which should come from the CG data!).... but that is a bit far-fetched indeed.

Probably worth mentioning: If you use a g-load to trigger the crash detection, then the smoother CG data are better suited.

Good question!!

Yes.

I meant to have the original value at 0,0,0 and the corrected value.
Just ignore me. It's useless.

The crash detection is better on the final output, after all calculations.
We want to protect the rig and user, so I think it's there it's place. Or even at hardware level like we have in the @Thanos controller.

Interesting! This is a good point!

I have to admit, I followed a totally different approach, and came to somewhat satisfying results with it, but the argument is very valid: "We don't care for the simulated vehicle, we only care for the occupant and rig"

Kudos!

A little story on a side note:
Around 2004 a major German airline and operator of A340-600s (cough-cough) had a high number of "under-rotations" on Takeoffs, Landings and GoArounds. It showed in the data so clearly, that the German Luftfahrtbundesamt (German FAA) issued a training requirement for all pilots flying the A340-600 to undergo special rotation training in the simulator to be prepared for the peculiarities of the 75m long aircraft.

What happened was that the pilots on rotation rotated like they did any other plane, but since the cockpit is some 40 meters in front of the point of rotation (main gear) it momentarily generated huuuuge vertical g-loads. It really felt like you were going up way too fast. Which was actually the case! THE PILOTS were going up at 1.6G, but the CG was not. IT was just rotating. Intuitively the pilots reduced the stick input which eventually resulted in the frequent under-rotations. Sometimes even oscillatory up-down-up rotations.

This rotation training was still in effect when I left the fleet 2017! In 13 years of trained professionals flying the thing, being trained to rotate correctly 4 times a year, it was still an issue that needed to be addressed!

Thought it would fit here

Cheers,. and night!

We can easily call it “Top Gun feature“ following the Austin’s comments for centrifugal component in the code above which are, I was told, most probably related to the famous movie.

// centrifugal force at the end
// well do you wanna do the spin in top gun or not?!??!
// of COURSE you do. of COURSE you do.

If you like the flavor of the Hollywood style from the 80s, go for a short sequence :

I think it’s easy to understand for everyone:

- “Rig CoR” is your position (belly or head) on the platform.
- “Occupant CoR Correction” is your position in virtual vehicle usually according to its Center of Gravity.

Best