FlyPT Motion cancelling project (trial)

I lost the wife, and highly recommend it!

@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.

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.

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...!

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!

@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...

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.

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.

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...

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.

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

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...

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. =)

Wow... Just.. wow. That looks so impressive. Excellent!

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?

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.

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.

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.

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.