OPEN VR CODER NEEDED !! PLEASE HELP !!

Sure, but what has that do do with a rotational speed? 10 Hz on a transducer doesn't mean 3600 deg/s. The transducer doesn't cause full rotations. Will be more likely a translational movement with amplitudes of a few mm.

The degree/s is about rotation, but the Hz value of the transducer is not about rotation, but its the frequency of vibration. If you have something rotating with 18000deg/s it you could say it has a frequency of 50 Hz. If a transducer vibrates with 50 Hz it's a totally different thing, no rotation involved. You can't simply equate those two things like you did. In the link you provided they are talking about "turning the wrist", so clearly angular movement (rotation).

I think it's entirely possible (even likely) that you are correct. I just think that it's worth testing if possible, rather than assuming it won't work.

The tracked controller is basically the vehicle, the HMD is the head. I think quite a bit of error may be hidden by the fact that our brain perceives that we are just moving independently of the 'vehicle' which is naturally true. This is also what makes the error caused by the offset of the tracked controller from the driver/pilot head position tolerable.

I don't need motion cancellation anymore, but are the V2 Base stations/index controllers any better in regard to tracking and being effected by vibrations etc?

This is important stuff, very nicely said.
I really appreciate that Noorbeast is "playing the devil's advocate", we need that! But some of the above threads have really been theoretical. E.g. when some platforms go beyond the limits of what a Vive Tracker in a Vive ecosystem can measure or be followed, then we ALSO have a problem with the headset, at least, when it's a Vive or Vive Pro (using the exact same hardware as a tracker). That's what I mean by "theoretical": by the time we have a problem with the tracker, we'd already have one with the HMD, too.
Of course, I assume that the tracker is not fixed to the platform, but damped in a similar way to what our head is damped.
As you, Trip, I think there's quite A LOT of error our body and brain can take without getting nausea or loosing immersion. Just have a look at one of those "chicken head" videos. We can easily read in a car, a train or on a motion platform. When I limit my 6DoF system to 25% I can play any racing game or flight sim without a problem. But with 80-100% when my head sinks into the headrest or touches the stick, it's getting weird.
In fact, I therefore think we should rather smoothen or deadzone some of the compensation input, than going for insanely high refresh rates and ─ vice versa ─ compensating tiny little bits of movements in display.

I like to think about having the tracked object virtually anchored to the playspace. With advanced settings you can move the playspace all the degrees of freedom easily except for pitch and roll. There is even a branch that uses this to make consistent locomotion between games, it just can't manipulate pitch and roll. I assume they don't want the floor unlevel, which is what we want to be possible. I think this way you could just set the offset from the center of the playspace floor and the tracked object attached to your motion platform. Doesn't need to be close to your head or changed for another person of a different height.

The Yaw VR motion sim has some software motion cancellation, but they are tracking the rotations of the chair with an imu, which I imagine most sims don't.

For anyone's info: yesterday when I used the $10 Steam app called "natural locomotion" I stumbled across a function reading like "playspace synchronization". Since I am currently deprived of my WMR headset (Reverb) I postponed delving into it. "Space Calibrator" never worked for me...

Oh one more thing. Have you read about the new gen of Steam VR trackers resp. tracking dev kits? What do you think about that?
With such tracking devices getting smaller, cheaper and easier to use, the Vive ecosystem with a primary investment into a couple of lighthouses might become a "sine qua non" for people who want or need to go a little beyond of what their standard package offers. A universal compensation method using a tracker attached to the HMD and the other behind your headrest now just got cheaper.

This probably has been mentioned back there somewhere but I did not find it.

One way to get rid of the vibration shake is to find a way to turn off X, Y, and Z head tracking. This means that motion canceling software is not needed at all.

I accidentally did this today and was able to enjoy an afternoon of F-86 flying without any extra motion in the simpit. I do not actually like it as I do use the other three D0F (head tracking) in flight but I was thinking that it would not matter in a racing game. I have not yet tried it with my 3DoF driving simpit though.

Of course, I have not been able to replicate this. I am using a Reverb (WMR) and I had started SteamVR before starting the WMR portal. So there must be a way to make it happen.

Just put something over the cameras on the headset and you will lose the surge heave and sway , I've had to do that for a while. Only problem you can get some drifting going on either left or right and have to keep recentering

WRT the problem with the bass shakers that disturb motion cancellation with Vive trackers and most controllers, I have found MY solution: It's simple: I use Andre's Jetseat instead of "shakers". I (still) have both, a BK Mini LFE and an early version of what is now called "SimShaker JetPad FSE".
In early times I had missed in the pad the engine vibes and therefore needed the KB. But Andre's software has very much developed and, at least in his Simshaker Wings software, gives you now even more than just one option to feel the engines rumble. For me, flying WWII piston aircraft, it has made the use of the KB completely obsolete.
I don't know why Bass Shakers corrupt the trackers and why the Jetseat pad does not. I assume it is the range of the frequency. And the 8 motors of the Pad deliver the rumble directly to your body and not thru the the seat's skeleton.
Of course, the Pad offers more than "disturbance free rumble". Because it is "event driven" thru an API and not "sound driven" thru the soundcard you can feel events like landing gear, flaps, opening the canopy, g-forces, stall shaking, ground bumps and so on even if they don't come with loud noise!

For those who want to stick to their KB gear, maybe Andre's software offers a solution by way of the so called Sound module addon. As I understand it it will drive a bass shaker thru a dedicated soundcard, but does not use the game's soundtrack, but takes sounds from its own library. You can edit and replace the sound files in this library. So you could experiment and filter/limit/cut those sounds with the effect that they don't corrupt your tracker or controller anymore ─ maybe. Just loud thinking.
If anyone has experience with these options in the Simshaker software, please correct me!

Disclaimer: I paid the full retail price for my two Jetseats, which I have in use for years now. I'm certainly a fan of the Jetseat and Andre's support and must have belonged to Andre's first batch of Western/EU customers, but I am not affiliated to his shop in any way.

I did not get any drifting. I found that I can replicate it by not calibrating in WMR.

I use Andre's software, it works very well. The Jet Seat looks good but I will stick with transducers.

I would like to warm up this discussion again, as I am not completely happy with tracker based compensation. I just can't cancel vibrations enough.

So why not do it synthetically???

• Simtools can output all values via UDP, there to pick up by software
• All motors on all platforms have a fixed mechanical connection to the chair. Meaning - when I add up all the motors I know exactly where my chair (and my center view point) are supposed to be.
• Motors move at a predictable speed with predictable accelerations.

So what a motion compensation software without any sensors needs to do is:

1. Translate motor positions in to head positions and combine them
2. Keep track of where the motors were and where they are moving towards
3. Model the movement of the motors by means of time, speed and acceleration factors

And that is basically it!

For point 1, the user will need to configure a translation value for each motor. This will likely be some kind of a rotation rate and direction. Also for 6 dofs, horizontal motion is caused by addition and cancellation of rotational movements. The rotation rate will be complicated by linkages, so for non linear actuators there will be a combination of two sinus functions to properly describe the actuator movement. And then there has to be a translation over the center of rotation. So this might not be easy, but these are fixed configurations for a platform's geometry. Only needed to be calculated once per platform.

Point 2 is simply listening to Simtools over UDP and keeping books about commands given with a time stamp.

Point 3 then calculates where a motor should be at a given point in time, taking into account the last command and the motor position at that time, and then modeling the movement of each motor. The speed of the motor should be quite easy to model, using an acceleration factor to account for the fact that a motor has inertia. Maybe also a system reaction time should be figured in.

Then you add up "motor positions" multiplied with "translation to head movement curves". And you arrive at a model of what pose the viewpoint is currently in, which you can feed into steam VR the same way the current motion compensation software is doing it.

Any comments?

I believe FlyPT Mover has a virtual tracker like you are talking about. I also remember yobuddy asking long ago what we'd need to solve the motion cancellation problem like this and everyone unfortunately jumping in saying don't bother, not gonna work well enough.

I don't think it needs to be completely accurate on the time scale, just reasonable would be enough. In real life, your head doesn't move completely according to accelerations and rotations either, you automatically always try to stabilize your head. Also the body and seat cushioning are flexible systems that don't immediately transmit all motion to the head. So I think there can be tolerance for slight inaccuracies in the position and in the time synchronization.

In practice, when for some odd reason my motion compensation stops working, I usually don't notice it immediately. It is mostly the larger viewpoint offsets that get me annoyed then, but I don't have an intuitive feel for it.

I think back then I was one of those who said it would be problematic. But now I'd almost say: It's certainly better then no compensation at all.

The forward kinematic approach that you suggested (going from known motor positions to platform pose) is cumbersome and painful for a 6DOF Stewart platform. And that is coming from someone who really really really really loves math. Even if you had the correct equations, you'd get up to 24 valid solutions.

But you CAN get the necessary data out of the motion cueing software. I think @Dschadu did something for Mover and I will implement it as well in Nutkicker as soon as the existing motion compensation methods run dry.