Correction of motion data for driver position offsets

Hey

This is a continuation from another thread. As discussed in the thread on my software, I want to correct the motion data stream coming from the simulator for the offset between the driver/pilot and the center of gravity (CG). I wanted to give this topic its own thread to be able to have a more in-depth discussion. I think this is worth being considered in motion cueing software. Especially for larger vehicles.

The problem is this:
The motion data the sim exports describe the motion of the vehicle as measured in the CG (best case scenario) or another fixed reference point. The driver/pilot however does not sit perfectly in the CG and thus feels different forces. I mean, he does feel ALL of the forces and moments present in the CG, but he feels some forces ON TOP that result from the angular velocities and angular accelerations of the vehicle around the CG.











If you want a motion data stream that represents the accelerations in the driver/pilot position, you will have to calculate those forces and add them to the accelerations in the exported stream.

These forces are proportional to the distance between the driver and the CG (∆x, ∆y, ∆z). If your vehicle is a car, you might be so close to the CG already that you will barely be able to notice any change. However, as the distance to the CG increases, this effect becomes easily noticeable.

When taxiing an airliner for example I’d even go as far as saying: These effects can become bigger than the „actual“ accelerations that result from curved CG trajectories:


My approach is to correct the data stream for those effects and then process the corrected data stream in the motion cueing software. There are others, like @pmvcda 's idea to use a different center of rotation on the rig to create the same effect.

I am however open for other interesting ideas...

Dirty

Yes, it will indeed autocorrect But the further we go, even small rotations will eat up your precious operating space. This "just scaling the rig" is effectively shrinking your DOFs.

Oh yes Correcting the stream at the source would circumvent that problem. We can utilise our full DOF ranges to cue motion to the user. It is just motion from a different location on the vehicle.

- Offsetting the CoR (rig) will give you the sensation as if you were in another position on the rig!
- Correcting the data stream at source will give you the sensation of being in another position on the vehicle!
These two claims are important! Please tell me we're on the same page for both. Or tell me where I am wrong. I know it is hard following someone elses thoughts, but this is a distinction that will make a huge difference in the result.

Spot on!!! You're right!! That's EXACTLY the effect I'm looking for! If you think that's unrealistic, let me take you on a flight. I will show you in the cockpit. Look at the drawing in the previous post. THIS IS IT! And here is something else: If you use rudder in flight it will be exactly opposite. The CG will wobble, while the pilot will make the steady turn!

Auto gain is a great feature and I have a couple of ideas on that too. But what does the auto gain do if you set the CoR 3m off to the side ? It will reduce your surge and heave, I guess.

This is a premise I threw out the window. I am still undecided. Using the same "scale" for accelerations in all directions has pros and cons. I will go into those at a later point in my software thread. There lies A LOT of potential for good and evil in THAT question. I could hold a 2h lecture on this question alone! I'd love to hear your considerations.

Dirty

They are the same thing...
Here's a video on my program:

Rotation with center on the rig.
Rotation with center in the back at 2 m.
Using auto gain to fit movement to rig.
Look at actuators values adjusted.
Auto gain in my program is:
Adjust the gain to fit movement to the range of the rig.
It acts on the actuators.
0,5 gain, makes actuators move half of what was calculated

OK, I know further we are less we have. We start loosing definition because we have to reduce scale on the rig.
Now, we can make different forces act with different scales, and that's why I have gains for independent forces.

To all kinematics software developers, plugin writers and those who care :
@yobuddy @value1 @pmvcda

With the help of the community I could finally review my initial assumptions which lead me to file a bug in the last version of X-Plane (in some airliner aircrafts) which will be corrected in the next version.

Through @Dirty 's physical knowledge and the issues he raised up concerning dealing with telemetry, CoG etc. we have now the possibility to approach our motion with a incomparably other level of realism. (at least for X-Plane)

Here is a part of conversation with the X-Plane designer, concerning the motion platform data:

I wrote:

In the inverse kinematics software which poses different degrees of freedom, we have a option to use either “local kinematics” (sorry it’s my own terminology) where the translations are dependent on rotations, or “world kinematics” where the translations are independent of the rotations.

As the forces in xplane seems to be local, it’s logical to use our “local kinematics” as well, and it’s giving us fantastic result.

Now to the point.... we’ve had long discussions how to use our platform's “center of rotation”

Intuitively we are shifting it so it’s corresponds where the human belly is positioned (usually 300-500mm)

The issue is, how we have to proceed with aircrafts like 747 where the CoG or center of rotation is about 20 meters behind the pilot?

Putting our center of rotation like in reality, makes our pitch and yaw practically unusable.

Does it means that your approximation for “motion platform stats” does all those corrections for us, and we don't need any shift of our gravity center?

Thank you very much for all those indispensable informations.

Austin Meyer response:

(...) the accelerations are at the floor of the cockpit between the pilots two seats… my best approx for the accelerations at the center of the floor of the platform
(...)
Right, the acceleration due to being far from the cg is indeed applied to the accelerations presented there.

deleted

can you take a look at this? Am I wrong? Shouldn't auto gain scale down the representation of the platform? How can the platform still be yaw'd 10° when the actuators are being scaled down...?

Greets... Dirty

Read your post and saw the videos...
Nope.

I'm not getting what I need to eat... honestly, not liking the tone of it.
Seems you have an appropriate nickname
We are speaking exactly the same! Sorry if you don't understand.
Maybe because we are not speaking of how we are going to treat the resulting values...

It's not the first time I or others might feel the same about your posts.
So, keep your ideas, they are good ones.
If you need anything and think that in my limited knowledge I might help, just ask.
But since you are so enlighten, doubt you need it.

Hey,

"Eat this" is an expression from slapstick movies and I didn't ever expect anyone to take offence from it. I formally apologise for it! And I will remove it.

like I said: didn't mean to step on any toes here.

Dirty (who got his nickname from a Pearl Jam song)

I do need it! Which is why I try to resolve where exactly we differ.

So, here's something on topic:

I'm gonna put a few claims out there and they are open for anyone to bust, confirm, doubt, support...

1. The motion data we get from simulators is from some point on the vehicle.

2. The data stream from different positions on the vehicle can differ substantially. Quantitatively and qualitatively. I argue for this point here:
during taxi
in flight

3. The differences stem from centrifugal and tangential forces which result from angular rates and angular accelerations.

4. You can correct those differences for other points on the vehicle with those formulae:


5. You can apply these corrections to the motion of the vehicle.

6. You can apply these corrections to the motion of the rig.

7. The resulting motion from 5. and 6. are not identical.

I put those out there for others to find elegant proofs or disproofs. Both will be equally interesting to read. I will not feel offended, I am not personally attached to any of them, because they are just that: Claims!

In fact, you will see me adopt better claims like a greased lightning, if based on rational arguments and reasoning those new claims prove to yield better results or less conflicts with other proven claims.

But arguments it must be! Not a popularity contest.

To use John Cleese' words: We need a fierce battle of ideas, not people!

Dirty