OPEN VR CODER NEEDED !! PLEASE HELP !!

Very good idea, thanks Avee!
I have one caveat, wrt 3rd notion "Motors move at a predictable speed with predictable accelerations". Speed and accelertion may vary depending on weight and position of stuff attached and especially the body weight and the seat position (some have seat sliders).
Therefore I came up with the idea of a plugin to help calibration of ANY platform, even when completly lacking factory data. The plugin would write the results of given axis cues in a kind of lookup table (.json ?) which then could be used by the "main" tool. Maybe you can think of it as an expanded "tuning Center"?

Another thought just coming thru my brain: "Head lag". Should the tracker of a calibration/compensation tool be attached to the seat's headrest or rather to your head/HMD? In other words: do we need to comensate for head lag or rather not?

I'm not as sure as you about this, noorbeast. I rather go with Avee

My personal exprience is this: with NO compensation (e.g. using my Reverb) I can quite easily go as long as my 6DoF platform is reduced to 20% - 30% of overal strength and envelope. For this reason I think our brain is able to compensate quite a bit ─ at least when the brain knows that the body is moving.
Of course and as always, your personal mileage may differ!

Appreciate your concern, Dirty. Do you think a calibration plugin with a lookup table might be an easier and more feasible solution?

Not sure I understand. I wouldn't know how to fill that table or what to look up in it. Can you explain?

My personal list of preference would be:

1. Tracker --> OVRIE --> OpenVR API
2. Tracker --> Custom software --> Simulator
3. Compensation data extracted from motion cueing software --> OpenVR API
4. Compensation data extracted from motion cueing software --> Simulator
   
5. Any other mathematical method promising enough to invest some work into

...but keep in mind that I am not professionally involved in these matters and can only give an intuitive opinion. I am absolutely convinced that motion compensation is an essential part of VR motion simulation. I wouldn't want to use a sim without it. Therefore I am quite concerned that at some point existing compensation methods might stop working. Since OVRIE uses the OpenVR API, I think it is possibly our safest bet.

A few thoughts on motion compensation with HP Reverb: I think it is quite likely that there will be people who want to keep using their Lighthouse stations and tracked controllers. So, I am hopeful that even with the Reverb a classical tracker based motion compensation will continue to work.

Dirty

What I'm considering lately, is to use the requested pose by the motion software.
But we have a problem, the lag of the hardware relativelly to the software.
To solve it, the idea is to use a filter to simulate that lag.
I'm incorporating filtering in the pose we send out of the motion software (FlyPT Mover) to try it, but still need to make a good filter to simulate that lag, althought we can play already with current filters (in version 3.0 to release soon).

First things first: I'm not a professional in these matters, just a barebone user. I don't know how telemetry output by SimTools is formatted, but I IMAGINE in the end we have a 3D movement vector for each time intervall defined by the update frequency of the (game software's) API?
Now my idea of a calibration tool with lookup table is: the tool transmits a great number of possible movement vectors (number restricted by a defined increment) to the platform (with attached tracker/controller and actual load!). For every vector, big or small, it records the new position of the attached tracker and the delay for getting to that position in a table that is saved.

Now with the game software running, for each movement vector calculated by SimTools the compensation software looks up that vector in the table and uses the recorded, true changes of the platform for the forward compensation of the displayed frames.

Of course, for optimization as much of the calculation as possible is done during calibration in order that the lookup table contains values that can be quickly processed.

There's many open questions to be answered. E.g. big table vs. realtime calculation of in-between vector values...

Uhhhh, VERY difficult to understand? Or am I completely wrong?

What you have wrong, is that simtools has no "motion vector".
That's why I made Mover, where all motion is based on that and for that reason it allows us to use the motion for cancelation.
I have considered to get feedback from the rig, to know the actuators position and calculate the actual pose, but that calculation is slow, and in the end when you get it, the real one is already different.
So, Althought I'm adding feedback from the rig for other tasks, I think the best solution is to send the calculated pose by the software, but affected by a filter that simulates the hardware lag.
If you have heave=0 and request heave=100mm, it will take some time to accelerate and move the rig to 100, so what you request is not the real value in the rig and making motion compensation with 100 is wrong.

I see and agree that this might be the overall best solution. A compromise, but it may be good enough. Certainly worth a try.
However, with a solution like this a lot depends on the accurateness of the filter (offset values). And this filter needs to be adjusted individually to every platform.
This adjustment can be made by trial and error, by practical experience ─ or by some kind of one-time calibration software that uses the actual feedback from the rig. Like you did. But it took too long to calculate in realtime? For a one-time process it wouldn't matter how long it takes to calculate the filter values, does it?

Greetings all. For those who do not already know, we have been saved by Dschadu!

This even works without lighthouse! Confirmed working on Reverb with it's own included WMR controller mounted in front of you.

@Dirty In addition I understand there is a compatible experimental feature from FlyPT Mover to create a virtual reference controller that is 100% software based.

Motion Compensation: https://tinyurl.com/motion-compensation

I am also taking it upon myself to provide to you all a link to our modest friend Dschadu's PayPal donation link for those who wish to thank him for his awesome work in this way:

Donate: https://tinyurl.com/OVR-motion-compensation-donate