1. For downloading SimTools plugins you need a Download Package. Get it with virtual coins that you receive for forum activity or Buy Download Package - We have a zero Spam tolerance so read our forum rules first.

    Buy Download Package Now!
  2. Do not try to cheat our system and do not post an unnecessary amount of useless posts only to earn credits here. We have a zero spam tolerance policy and this will cause a ban of your user account. Otherwise we wish you a pleasant stay here! Read the forum rules
  3. We have a few rules which you need to read and accept before posting anything here! Following these rules will keep the forum clean and your stay pleasant here. Do not following these rules will lead to permanent exclusion from this website: Read the forum rules.

Correction of motion data for driver position offsets

Discussion in 'Miscellaneous' started by Dirty, Mar 27, 2019.

  1. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    139
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    1,554Coins
    Ratings:
    +132 / 1 / -0
    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.

    Motion Cueing.018.png

    Motion Cueing.019.png

    Motion Cueing.020.png

    Motion Cueing.021.png

    Motion Cueing.022.png

    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:
    Motion Cueing.001.png

    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
    Last edited: Mar 27, 2019
  2. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    139
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    1,554Coins
    Ratings:
    +132 / 1 / -0
    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.
    Bildschirmfoto 2019-03-27 um 09.38.25.png


    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 :)
    Last edited: Mar 27, 2019
  3. pmvcda

    pmvcda aka FlyPT

    Joined:
    Nov 3, 2010
    Messages:
    385
    Location:
    Portugal
    Balance:
    2,814Coins
    Ratings:
    +425 / 2 / -0
    My Motion Simulator:
    6DOF
    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.
  4. hexpod

    hexpod http://heXpod.xyz Gold Contributor

    Joined:
    Apr 18, 2016
    Messages:
    307
    Location:
    berlin
    Balance:
    2,202Coins
    Ratings:
    +101 / 1 / -0
    My Motion Simulator:
    DC motor, 6DOF
    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.
    • Like Like x 1
    • Winner Winner x 1
  5. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    139
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    1,554Coins
    Ratings:
    +132 / 1 / -0


    :grin:grin:grin
    • Winner Winner x 1
    Last edited: Mar 28, 2019
  6. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    139
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    1,554Coins
    Ratings:
    +132 / 1 / -0
    deleted
    Last edited: Mar 28, 2019
  7. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    139
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    1,554Coins
    Ratings:
    +132 / 1 / -0


    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 :)
  8. pmvcda

    pmvcda aka FlyPT

    Joined:
    Nov 3, 2010
    Messages:
    385
    Location:
    Portugal
    Balance:
    2,814Coins
    Ratings:
    +425 / 2 / -0
    My Motion Simulator:
    6DOF
    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 :D
    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. :thumbs
  9. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    139
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    1,554Coins
    Ratings:
    +132 / 1 / -0
    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)
    Last edited: Mar 28, 2019
  10. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    139
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    1,554Coins
    Ratings:
    +132 / 1 / -0
    I do need it! Which is why I try to resolve where exactly we differ.
  11. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    139
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    1,554Coins
    Ratings:
    +132 / 1 / -0
    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:
    Bildschirmfoto 2019-03-28 um 21.10.51.png

    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 :)
    • Like Like x 1
    Last edited: Mar 28, 2019