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.

Writing a motion cueing software from scratch.

Discussion in 'DIY Motion Simulator Projects' started by Dirty, Feb 28, 2019.

  1. pmvcda

    pmvcda aka FlyPT

    Joined:
    Nov 3, 2010
    Messages:
    837
    Location:
    Portugal
    Balance:
    6,427Coins
    Ratings:
    +888 / 12 / -0
    My Motion Simulator:
    6DOF
    I'm sorry, sometimes I'm a bit lost, since English is not my main language.

    What you mean here, is:
    If the data received from the games, doesn't relate to the position of the driver...
    In my case, I allow the change of center of rotation...
    But with a limited range in the rigs, we can't allow for big displacements or we consume the range pretty fast...

    Is that what you mean?

    If so, I tought of correcting that with some math, but:
    Since I mainly use car games, I have no idea where is the CG of the car in most if not all of the games.
    For air planes, there's way more data in the games (the community is more aware of those problems and CG is way more important for airplanes).

    I'm trying to bring data inside my interface without any treatment (only mine).
    Right now, I want to add RFactor2 to the list and CG we receive is relative to graphical center!??????
    What is that?
    And we are speaking of RFactor2, a reference for many.

    You can see the value here (last 3):
    Sem nome.jpg

    In conclusion, I'm not sure if it's worth the trouble.
    Well it is, let's just allow the user to change it.
    • Agree Agree x 1
  2. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    310
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    3,365Coins
    Ratings:
    +296 / 1 / -0

    Yes, thats what I mean :) If you correct the rotational center of the platform it will create a nice effect, but it will limit your translational operating space.

    Yes, aircraft sims depend on CG a lot more then cars do, but still CG is important for cars as well. Any high quality driving sim should handle shifts in CG.



    I don't know about RFactor2 in particular, but I know that the telemetry must be computed for SOME point on the vehicle. If you apply the corrections I postet, then you can "move" the point of reference. Wherever this point was, after the correction the acceleration data will feel like it came from a point offset in XYZ.

    I guess that the developers
    1. use the CG as reference point or they
    2. define a reference point that somehow tries to be close to the center of the vehicle
    3. they use the camera position as reference point

    The last three lines in the telemetry look like they are giving CG information relative to the camera position. THATS MY GUESS!
    Since they calculate the CG, I assume the telemetry comes from there.
    IF that is the case(!) then you can correct the drivers offset by applying the formulae I postet (untested).

    Again:
    Not a big thing in a car. A huge deal in an airliner!

    I described to @hexpod the feeling of a crosswind landing in a 65m aircraft. If those offsets were not corrected, a FullFlightSim could not be certified for zero flight time training. In fact it couldn't even be called FULL flight sim.
    Last edited: Mar 26, 2019
  3. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    310
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    3,365Coins
    Ratings:
    +296 / 1 / -0
    ...oh and one more thing: :)

    If you think it does not matter much:
    The whole motion compensation thing for VR rigs uses these corrections already and it would not be possible without them. Anyone using Matzman666 's compensation surely entered these offset between the vive controller and the headset position. Try and see what happens if you don't :)

    Using the compensation here too would make the motion match the picture a lot better.
  4. SilentChill

    SilentChill Problem Maker

    Joined:
    Jul 19, 2014
    Messages:
    2,486
    Occupation:
    Railway Maintenance
    Location:
    Morecambe, Lancashire, England
    Balance:
    18,825Coins
    Ratings:
    +3,169 / 31 / -0
    My Motion Simulator:
    DC motor, Arduino, Motion platform, 6DOF
    The offsets are more for using your controller with a gun or something that makes the controller to be in a different place to where you want it to be. I don't think it has anything to do with Motion Cancellation as you don't want to offset your position or else you would end up in the wrong place as the controller is exactly where it needs to be when you turn the cancellation on and the whole motion cancellation is calculated from that initial position.
  5. pmvcda

    pmvcda aka FlyPT

    Joined:
    Nov 3, 2010
    Messages:
    837
    Location:
    Portugal
    Balance:
    6,427Coins
    Ratings:
    +888 / 12 / -0
    My Motion Simulator:
    6DOF

    You can forget about using this for motion compensation.
    You have to take into account the lag that exists between real rig position and what is asked by the software.
    Motors are "slow", even the best motors can't match the requests.
    Maybe for air planes it can go closer, since we have way less vibrations (should not even say that).
    There's always some filters applied to the rig actuators, at least PID.
    To make it you need feedback from the rig (I have in my program), but then the problem is that you need to make inverse kinematics and select one of the many solutions...
    You need a good computing power for that.
    It wont work, but would be great if I'm wrong. :)
  6. pmvcda

    pmvcda aka FlyPT

    Joined:
    Nov 3, 2010
    Messages:
    837
    Location:
    Portugal
    Balance:
    6,427Coins
    Ratings:
    +888 / 12 / -0
    My Motion Simulator:
    6DOF
    Before anything:
    Center of rotation is the point around witch the rotations are made on the rig.
    By default, in my program, it's the center of the top platform.
    CG is the physics center of rotation.

    I agree with you, the problem here is that in the RFactor2 case, they give you the CG relative to the 3D model center.
    Not relative to the driver position. You can change camera, but the values remain the same.
    We don't know exactly where is the driver relative to the 3D model center.
    We can estimate that and be close.
    The center of rotation should be calculated, relative to the neck level (ears), so we can make it close, but needs to be changed from car to car (3D model center vs driver position varies between cars).

    The effect can be achieved with the change of the center of rotation in cars, because the driver is near the CG.
    In airplanes, that's different, and it might be worth the calculation.
    If you are in the cockpit of a big Airbus, the CG is way back at around 1/3 of the wing cord (and to be ultra precise you need to know fuel consumption and load distribution on the plane - Doubt they go so far on "games"). This can be several meters.
    But in a small Cesna, you can achieve it, just change the center of rotation up or down depending of high or low wing. Here CG is also near the pilot.

    So, the value to insert in center of rotation, is the distance from our neck to the CG. But we need to subtract/add the distance from the center of the top platform to our neck... What a mess of an explanation (I'm preparing a manual for my program with those things, still needs some work).

    But in my opinion, the center of rotation might be enough, even for big air planes.
    You will always have to scale the values received to fit the rig.
    You can do it on my program. Adjust the Center of rotation and then you have to scale the values to fit the rig (reason for auto tune in general rig gain).
    One of the things I might change is gain resolution (one more decimal place) and allow bigger values in the center of rotation adjustment.

    Let me conclude the manual, there's way more considerations there. Might be wrong in some.
    • Like Like x 1
  7. hexpod

    hexpod http://heXpod.xyz

    Joined:
    Apr 18, 2016
    Messages:
    674
    Location:
    berlin
    Balance:
    4,434Coins
    Ratings:
    +194 / 2 / -0
    My Motion Simulator:
    DC motor, 6DOF
    As the landing gear vertical load is decreasing being compensated by the aircraft lift, it was a stupid idea willing to scale it arithmetically to the heave center. apologies !

    I am dividing the "landing gear vertical load" by the "current weight" of the aircraft which makes it independent of the type and payload having always the runway rumble somewhere around 1.

    It seems HPF is the only solution that I see for the moment.
    • Like Like x 1
    • Agree Agree x 1
  8. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    310
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    3,365Coins
    Ratings:
    +296 / 1 / -0
    OK,... hmmm..

    I admit, it is still quite possible that I misunderstood how exactly the motion cancelling software is implemented, cause I haven't seen the source code. In general, it's re-defining the position of the headset inside a reference system defined by the vive controller. Since the controller and your head are not in the same place, rotations will affect the headset differently than the controller. I thought the offsets were there to allow the software to correct for those. If the integration of the signals takes place not on sensor-level but on driver-level, I could well imagine that those offsets are indeed not used for what I thought, but instead are taken from the data measured by the Lighthouse stations.

    Thanks. :)
    Last edited: Mar 26, 2019
  9. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    310
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    3,365Coins
    Ratings:
    +296 / 1 / -0
    Well said! We agree on A LOT here! Before I comment on the part where we don't, let me say it clearly: You are an engineer, I am a physics guy and we both speak fluent Math :) So it should really not surprise that on over 99% of what we discuss here we are totally on the same page.

    Still, let me point out the two areas where I'd draw different conclusions.

    1. Self motion is perceived with more than the vestibular system. I'd put the center of the rotation closer to my belly, but this is not going to be a game changer. The reason behind this is, that if you put it closer to your ears, you will make the cues more fitting (less wrong) to the inner ear, but less fitting (more wrong) on the bowels and the haptic receptors (skin). Following a least squares approach, I'd rather have 2 small errors then one big one. I am however totally open for interesting considerations on that problem.

    2. I would strongly advise against changing the center of rotation of the rig to adapt for offset driver positions. A few somewhat educated "guesstimations":
    - An inch is not noticeable
    - A foot is a lot
    - A meter will ruin your experience
    - 3 meters will render the whole rig useless

    Since you know the reason behind this (rotations would be limited by lack of translational operating space), how severe would you judge these four cases?


    After having realised that the driver offset correction is computationally dirt cheap (no sines, cosines, etc...) and mathematically almost trivial, I will invest the time to implement it as an option, because I am simply toooooo curious to miss seeing if it makes a difference or not :grin


    Thanks for your comments, I take what you say very serious.

    Dirty :)
    • Like Like x 1
    Last edited: Mar 26, 2019
  10. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    310
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    3,365Coins
    Ratings:
    +296 / 1 / -0
    Exactly the point I argued a few weeks ago on this thread. With exactly the same arguments :) ....like I said: An engineer and a physics guy....
    No way this is going to replace motion cancelling based on hijacked controllers. I just wanted to mention that in one form or another the cancelling uses the same mathematical approach.
  11. SilentChill

    SilentChill Problem Maker

    Joined:
    Jul 19, 2014
    Messages:
    2,486
    Occupation:
    Railway Maintenance
    Location:
    Morecambe, Lancashire, England
    Balance:
    18,825Coins
    Ratings:
    +3,169 / 31 / -0
    My Motion Simulator:
    DC motor, Arduino, Motion platform, 6DOF
    That's exactly what I thought until the author told me straight that the offsets have nothing to do with motion cancellation. Its all documented on the github:)
    • Like Like x 1
  12. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    310
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    3,365Coins
    Ratings:
    +296 / 1 / -0
    now, that's an argument I can't refuse! Thanks :)
    • Funny Funny x 1
  13. pmvcda

    pmvcda aka FlyPT

    Joined:
    Nov 3, 2010
    Messages:
    837
    Location:
    Portugal
    Balance:
    6,427Coins
    Ratings:
    +888 / 12 / -0
    My Motion Simulator:
    6DOF
    But... You can calculate everything, but there's no need for that.
    Changing the center of rotation, automatically scales the values. No need for more calculations.
    Tangential speed is proportional to the radius. Further we go, bigger the speed.
    We just have to scale them to fit the rig.
    We can look at it however we want, but we have to scale it. there's no other way.
    Using the center of rotation, gives you real behaviour.
    If you are to far from CG, you almost feel a yaw as a sway, because radius is too big.

    Like I said before, that's the reason I use auto gain. It's to scale the values to fit the range of the rig.
    And it will fit the values proportionally as it should.
    In my program, I let people play with values, but the correct way is to use 180º range in rotations and the same value for all translations.
    Same with individual gains, they should be the same for rotations and the same for translations.
    1G in one direction should feel the same as 1G in a completely different direction.
  14. hexpod

    hexpod http://heXpod.xyz

    Joined:
    Apr 18, 2016
    Messages:
    674
    Location:
    berlin
    Balance:
    4,434Coins
    Ratings:
    +194 / 2 / -0
    My Motion Simulator:
    DC motor, 6DOF
    Very interesting discussion.

    @pmvcda let’s imagine the scenario of 747.

    “You feel the Yaw almost as Sway” is a very good example.

    Actually maybe the serious simulators should do this job by outputting corrected forces from the vehicle CoD to the pilot location inside the vehicle (aircraft)

    Only to say that if you put your CoG 25 meters behind like in reality, you will most propably transform your 6-dof in a 4-dof

    EDIT:
    Imagine, since we have 6-dof plugins, almost everybody is mixing the surge to the pitch building kind of « classical washout »

    If you set CoG longitudinal far behind you, (like in reality), you would loose almost all Pitch resources for your “classical washout” algorithm.

    Still I have no idea for the moment what would be the most clever idea to get the best results
    Last edited: Mar 27, 2019
  15. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    310
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    3,365Coins
    Ratings:
    +296 / 1 / -0
    Is it OK, if we continue this in its own thread?

    I have some interesting posts prepared for the software already and it is going to get cluttered.
  16. hexpod

    hexpod http://heXpod.xyz

    Joined:
    Apr 18, 2016
    Messages:
    674
    Location:
    berlin
    Balance:
    4,434Coins
    Ratings:
    +194 / 2 / -0
    My Motion Simulator:
    DC motor, 6DOF
    • Like Like x 1
    Last edited: Mar 27, 2019
  17. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    310
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    3,365Coins
    Ratings:
    +296 / 1 / -0
    • Informative Informative x 1
  18. Dirty

    Dirty Active Member Gold Contributor

    Joined:
    Oct 15, 2017
    Messages:
    310
    Occupation:
    All the way up front.
    Location:
    Germany
    Balance:
    3,365Coins
    Ratings:
    +296 / 1 / -0
    Hey :)
    Would like to keep this brief:

    We could better utilise our rigs if we knew in advance where the limits of the DOFs (as opposed to the actuator limits) are at any given point in time.

    I found a way to describe the translatoric operating space of a 6DOF Stewart type platform with linear actuators. Translatoric means that yaw, pitch and roll are all zero for those considerations.

    So far, I only have a graphical approach and I am unsure if I will develop it further. An analytical solution sure would be nice to have,... so, if YOU, yes YOU! :grin ...like a good Math puzzle, PM me. I can point you off in the right direction :)


    Each actuator is represented by a color. The colours of the surface indicate which actuator is most limiting if the platform approaches that respective surface. The body represents all possible positions THE CENTER of the platform can have.
    Bildschirmfoto 2019-03-29 um 14.43.14.png

    There is another set of possible solutions below the ground. I'm mentioning this, because I am cautiously evaluating the option of mounting the actuators to the ceiling. With "real" actuators, I think these two bodies are the only sensible solutions:
    Bildschirmfoto 2019-03-29 um 14.43.53.png

    Slicing the body from the top...
    Bildschirmfoto 2019-03-29 um 15.11.20.png

    ...starts with an almost round hexagon-ish shape.
    Bildschirmfoto 2019-03-29 um 15.11.35.png

    It will reach its maximum lateral and longitudinal expansion around a height slightly above the midpoint between top- and bottom-most tips.
    Bildschirmfoto 2019-03-29 um 15.12.03.png

    The lower half has a lot less volume and turns into a star-ish shape...
    Bildschirmfoto 2019-03-29 um 15.12.20.png

    ...that ends in a triangular tip.
    Bildschirmfoto 2019-03-29 um 15.12.38.png

    There are combinations of parameters that lead to somewhat strange shapes. As far as I could tell those are not within the limits of what a normal actuator would be able to achieve range-wise. So, no need to worry about getting stuck on an "island" with the rig.
    Bildschirmfoto 2019-03-29 um 15.16.23.png

    Noteworthy: Sometimes two valid positions can't be connected with a line. In actual use it is highly unlikely that this aspect will ever become a factor.

    Dirty :)
  19. hexpod

    hexpod http://heXpod.xyz

    Joined:
    Apr 18, 2016
    Messages:
    674
    Location:
    berlin
    Balance:
    4,434Coins
    Ratings:
    +194 / 2 / -0
    My Motion Simulator:
    DC motor, 6DOF
    I like your borderline ideas. It stimulates the imagination.

    F53CE880-F43B-45F2-8C21-CF89FC54E630.png

    I do intuitively limit the heave of my rig by limiting its travel. Although my capabilities are over 350 mm for the heave only, I use 200 because the heave is what eats the most of other resources.

    The washout and travel limiter on heave is the step number one on the practical side.

    I guess it crops the workspace in similar way like in the picture above.

    This workspace representation:
    61F591D9-8A40-43D2-80C4-0E3EE2F794CE.jpeg
    is when you use full possible travel for each dof which in reality is not a good solution.
  20. hexpod

    hexpod http://heXpod.xyz

    Joined:
    Apr 18, 2016
    Messages:
    674
    Location:
    berlin
    Balance:
    4,434Coins
    Ratings:
    +194 / 2 / -0
    My Motion Simulator:
    DC motor, 6DOF
    As test, could you please limit your degrees of freedom in a way that every combination is possible? (No out of reach state)

    How would it appear on the graph?
    Last edited: Mar 30, 2019