1. Do not share user accounts! Any account that is shared by another person will be blocked and closed. This means: we will close not only the account that is shared, but also the main account of the user who uses another person's account. We have the ability to detect account sharing, so please do not try to cheat the system. This action will take place on 04/18/2023. Read all forum rules.
    Dismiss Notice
  2. 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 Now a Download Plan!
  3. 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
  4. 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. Do not follow these rules can lead to permanent exclusion from this website: Read the forum rules.
    Are you a company? Read our company rules

FlyPT Motion cancelling project (trial)

Discussion in 'VR Headsets and Sim Gaming - Virtual Reality' started by pmvcda, Jun 19, 2019.

  1. Trip Rodriguez

    Trip Rodriguez VR Pilot

    Joined:
    May 8, 2016
    Messages:
    675
    Location:
    Lake Ariel, Pennsylvania
    Balance:
    3,920Coins
    Ratings:
    +330 / 6 / -0
    My Motion Simulator:
    6DOF
    I lost the wife, and highly recommend it! :grin

    @pmvcda I have a very selfish question, no hurry to answer it.

    My new motion simulator will be only 1DOF! Just heave. If it's just a straight linear actuator 1DOF, how easy would it be for you to make it so I can use a single hall sensor instead of having to use a whole optical and IMU tracked motion controller to measure a silly 1DOF?

    I assume this would be too much trouble since it would basically not help anyone except me (unless others decide to copy my design idea!). I thought I should ask just in case it really is as simple as it seems it might be.
  2. cubexxx

    cubexxx Member

    Joined:
    Oct 4, 2019
    Messages:
    69
    Balance:
    532Coins
    Ratings:
    +41 / 0 / -0
    My Motion Simulator:
    3DOF, AC motor, Arduino, 4DOF
    Why not use the encoder count from the drivers and calculate the pose from the actuator position? For the AASD drives you can use modbus to read the current position. Would be easier (and probably have higher precision) then having some additional sensor.
  3. Thanos

    Thanos Building the Future one AC Servo at a time... or 6

    Joined:
    Jul 6, 2017
    Messages:
    1,346
    Occupation:
    Electronics Engineer
    Location:
    United States
    Balance:
    2,692Coins
    Ratings:
    +1,043 / 9 / -0
    My Motion Simulator:
    AC motor, Motion platform, 4DOF, 6DOF
    No need to read anything back. If you can read the position data from Simtools axis, this is where the motor/actuator will be. The AASD servos don't play around, they will go to the commanded position ASAP...! :)
    • Informative Informative x 1
  4. Trip Rodriguez

    Trip Rodriguez VR Pilot

    Joined:
    May 8, 2016
    Messages:
    675
    Location:
    Lake Ariel, Pennsylvania
    Balance:
    3,920Coins
    Ratings:
    +330 / 6 / -0
    My Motion Simulator:
    6DOF
    I don't know much about these servo systems, wasn't sure we could get that data easily back to the PC but that would be even better!

    Seems like it should be easy on the programming end, but it often seems easy and isn't!
  5. cubexxx

    cubexxx Member

    Joined:
    Oct 4, 2019
    Messages:
    69
    Balance:
    532Coins
    Ratings:
    +41 / 0 / -0
    My Motion Simulator:
    3DOF, AC motor, Arduino, 4DOF
    @Thanos There is a of course some lag, especially for large movements. Everything > 5ms may not be acceptable for VR, some say even <= 1 ms is needed...
  6. Trip Rodriguez

    Trip Rodriguez VR Pilot

    Joined:
    May 8, 2016
    Messages:
    675
    Location:
    Lake Ariel, Pennsylvania
    Balance:
    3,920Coins
    Ratings:
    +330 / 6 / -0
    My Motion Simulator:
    6DOF
    Even more better! =D

    I really hope it's easy enough that we can do this. I'm actually adding a bit of sway and surge now to the sim but the same thing applies. It's just a straight shot for each, completely linear and no funky interaction between them.

    Just need to send those three axis positions to motion compensation and done. Man I really hope I can get this done. I'll be very, very happy.
  7. pmvcda

    pmvcda aka FlyPT

    Joined:
    Nov 3, 2010
    Messages:
    1,846
    Location:
    Portugal
    Balance:
    14,096Coins
    Ratings:
    +2,169 / 16 / -0
    My Motion Simulator:
    6DOF
    There's always lag.
    Not only from the servos, but also on the calculation side, because doing the forward kinematics for a 6 dof rig is not something easy to do in real time.
    That's why I thought of doing an external sensor that could send the current pose of the rig.
    I have all parts, but no time to do it (for now), and honestly, I doubt it will work.

    In my rig, since I handle all the code, I can send the position to the pc, but then, like I said, we have to convert it to a pose with some nasty calculations.
    I'm preparing Mover for my rig with position feedback, to allow me to setup PID in Mover (just for my rig). I also have some code done for forward kinematics and might test it all, but it's going to take some time.
  8. Thanos

    Thanos Building the Future one AC Servo at a time... or 6

    Joined:
    Jul 6, 2017
    Messages:
    1,346
    Occupation:
    Electronics Engineer
    Location:
    United States
    Balance:
    2,692Coins
    Ratings:
    +1,043 / 9 / -0
    My Motion Simulator:
    AC motor, Motion platform, 4DOF, 6DOF
    If you use external sensors the lag will be even greater. I guarantee it will be somewhere between 20ms to 50ms. The sensors need time to settle measurements (might take longer for accelerometer/gyro as filtering is required ) and then you need processing time to encode the sensor results to data you can use and transmit them back to PC.

    Why not reading the position data directly from the source (game)? Unless you have too slow actuators the servomotors will position to positions commanded fast (500mm/s)... and do you really need that much speed? The latency for single step positioning is 2ms, but it will be still be 2ms for even 1 full rotation of the servo (10mm stroke advance) or 500 pulses, as the servo positioning is executed asynchronous from the AMC controller...

    See here for example the reaction timing of the servo...
    • Agree Agree x 1
  9. pmvcda

    pmvcda aka FlyPT

    Joined:
    Nov 3, 2010
    Messages:
    1,846
    Location:
    Portugal
    Balance:
    14,096Coins
    Ratings:
    +2,169 / 16 / -0
    My Motion Simulator:
    6DOF
    I'm implementing a solution to avoid forward kinematics calculations using Mover.
    I have to remove actuators filters. They will be replaced by pose filters.
    This allows us to have the final rig position and use it for motion cancellation.
    But! It needs ultra fast rigs to achieve a good result.
    Let's try it.

    Mover 2.9 is going to have that change. Let me see how we can use data for motion cancelation.
    • Like Like x 3
  10. cubexxx

    cubexxx Member

    Joined:
    Oct 4, 2019
    Messages:
    69
    Balance:
    532Coins
    Ratings:
    +41 / 0 / -0
    My Motion Simulator:
    3DOF, AC motor, Arduino, 4DOF
    You are talking about the pulses the controller sends to the drive. That of course doesn't mean that the motor will react with the same speed! The motors commonly used can do 50 rps, therefore one rotation takes at least 20 ms, not 2ms. Also the video framerate is way to slow to see or measure these delays
    • Agree Agree x 1
  11. pmvcda

    pmvcda aka FlyPT

    Joined:
    Nov 3, 2010
    Messages:
    1,846
    Location:
    Portugal
    Balance:
    14,096Coins
    Ratings:
    +2,169 / 16 / -0
    My Motion Simulator:
    6DOF
    I agree with you, but nevertheless, I will output the pose from Mover. That way we can test it. Just need to see what type of info I need to send to the openvr input emulator...
    • Winner Winner x 1
  12. Trip Rodriguez

    Trip Rodriguez VR Pilot

    Joined:
    May 8, 2016
    Messages:
    675
    Location:
    Lake Ariel, Pennsylvania
    Balance:
    3,920Coins
    Ratings:
    +330 / 6 / -0
    My Motion Simulator:
    6DOF
    I won't be able to do a real test until I get this new simulator built but I'm trying hard to make that happen!

    I have it to the point where I am almost ready to buy the steel and start building but I want to finish the drawings first to ensure there are no design problems I'm not seeing. I plan to be less active on forums the coming days to try to make this happen faster. =)
  13. ryanosman

    ryanosman New Member

    Joined:
    Sep 15, 2019
    Messages:
    22
    Occupation:
    Commercial Recreational Sim Owner/Operator
    Location:
    Western Canada
    Balance:
    272Coins
    Ratings:
    +9 / 0 / -0
    My Motion Simulator:
    3DOF, DC motor, AC motor, Arduino, Motion platform, 6DOF
    Wow... Just.. wow. That looks so impressive. Excellent!
    • Like Like x 1
  14. Avee

    Avee Virtual Pilot

    Joined:
    Jul 5, 2020
    Messages:
    125
    Location:
    Germany
    Balance:
    1,020Coins
    Ratings:
    +26 / 0 / -0
    My Motion Simulator:
    2DOF
    Assuming we use your FlyPT mover, you always know the last commanded position of an actuator and the next one. When you have a stored value for the speed of that actuator, you can model the position of that actuator at any point in time.

    In stead of doing all kinds of translations of the platform as a whole, calculating poses etc, would it speed up the calculation if you pre-calculate a profile for each actuator, how it moves the head position? The head is always in the same relationship to the actuator, so basically you should just need one translation per actuator, and then add all those up for all actuators present.

    So step 1: set up a compensation profile, where you make a "formula" what the effect of an actuator on the head is. Basically, this is a vector in each dimension. For this, you would calculate poses of the platform, and translate that into positions of the head, which is always in a fixed position above the platform.
    Step 2: in real time, simulate the actuator speed, and keep its effects on the head updated, summing up all the vectors for each dimension.

    So we are not constantly calculating poses, but just modeling the position of moving actuators (which is linear or a sine), and adding up the vectors of all actuators. It could be done without real time calculations, if you pre-calculate a table of vectors per actuator movement.

    Or is there an error in my thinking somewhere?
  15. pmvcda

    pmvcda aka FlyPT

    Joined:
    Nov 3, 2010
    Messages:
    1,846
    Location:
    Portugal
    Balance:
    14,096Coins
    Ratings:
    +2,169 / 16 / -0
    My Motion Simulator:
    6DOF
    Mover works with poses.
    We calculate the pose for the data we receive.
    Then we calculate the actuators positions (fast calculation)
    We send the positions to the hardware, and they respond.
    There's always lag, and actuators respond "slow", so in vibrations with high amplitude, the actuator will never reach the pretended position, because we ask it to go to 100 and 2ms after to -100, the actuator has no time to make the move and before reaching 100 it already as a new order to go to -100.

    Right now, I send the pose data outside to be used for motion compensation, the problem is what I said above.
    To overcome this, we can use a slow down filter (might come in 3.0) that simulates the lag of the actuators on the pose we send out.

    The other solution is to receive feedback from the actuators with their current position and make the calculations in the opposite way, calculate the pose from the actuator position (this is to slow).

    In conclusion, the first solution might be the one using less resources and faster .
    If we can create a good filter to simulate lag it might work well.

    I have the hardware in a box, waiting for some free time. The idea here was to make something that got the pose with sensors avoiding calculations. A replacement for a VR control, but there are other priorities right now.
  16. Avee

    Avee Virtual Pilot

    Joined:
    Jul 5, 2020
    Messages:
    125
    Location:
    Germany
    Balance:
    1,020Coins
    Ratings:
    +26 / 0 / -0
    My Motion Simulator:
    2DOF
    Ok, sounds more complicated than I thought.
    So the first task to solve is to get a reliable way of measuring things. And I guess it would have to be processed in 10ms or so to not produce a visible lag. I am using lighthouse tracking, and although it is very accurate, it is not super robust. It measures my Buttkicker as well, and it can lose track if vibration is too strong. I was hoping FlyPT mover would have enough information to provide perfect cancelling in real time without extra hardware.
  17. pmvcda

    pmvcda aka FlyPT

    Joined:
    Nov 3, 2010
    Messages:
    1,846
    Location:
    Portugal
    Balance:
    14,096Coins
    Ratings:
    +2,169 / 16 / -0
    My Motion Simulator:
    6DOF
    Do you know this?
    https://www.xsimulator.net/community/threads/openvr-motioncompensation.14576/

    You can use Mover for motion compensation, but also the lighthouse.
    It has a DEMA filter that filters those vibrations, and seems to work well, at least for some people.
    You should try it.
    • Like Like x 1
  18. Avee

    Avee Virtual Pilot

    Joined:
    Jul 5, 2020
    Messages:
    125
    Location:
    Germany
    Balance:
    1,020Coins
    Ratings:
    +26 / 0 / -0
    My Motion Simulator:
    2DOF
    Yes, it is working, but I had to dial down my vibrations a lot. I will experiment more with the filter settings to find out the sweet spot.