Trip's treatise on motion compensation and enclosed simulators

As you are familiar with a standard motion simulator, I don't think you will be that happy with a 1DOF sim, even with paddles/harness. The initial real on-set movement that my sim seat gives (5DOF) is essential to trick the brain before the paddles/pressure plates gain effect. I would design you rig to be able to grow more DOFs if required. These small on-set movements in various DOFs mimic how your body actually moves in a real car/plane etc, so there is no need for them to be cancelled for VR.

@SeatTime , maybe I'm missing something but I think that my G-seat is going to functionally be very similar to yours for the most part. Once I think I've got it finalized I'll be sure to run my design by you before I commit though just to be safe.

I am (for now) limited to four motors for the G-seat so a little less customization but I plan the following features:

Seat back nearly identical to yours. Heave, sway, and surge with basically the paddle arrangement you use.

Seat bottom with paddles like yours for heave. It will also have surge. Sway/Roll on the bottom cushion is going to be ACME style, where the bottom tilts.

G-vest. Thigh G-loading, Head G-loading

Motor assignment for G-seat:

Motor 1: G-Surge.

• seat back surge (with parasitic paddles)
• seat bottom surge
• G-vest surge
• head loading surge

Motor 2: G-Sway.

• seat back sway
• G-vest sway
• head loading sway

Motor 3: G-Roll/G-Sway

• seat bottom roll tilt (Acme style)

Motor 4: G-Heave

• seat bottom heave (with parastic paddles)
• seat back heave
• G-vest heave assist
• Thigh loading heave

Motor assignment for platform:

Motor 5 and Motor 6 in tandem: Motion Heave ( 1DOF elevator)

• Heave elevator (1DOF) straight up and down 1000 mm or a little more powered by two linear actuators and running on four 16mm bearing guide rails.

Does this not sound like a decent design for flight SeatTime?

Later on I may add a smallish surge and/or sway table to the elevator, and I may add more motors to the G-seat to further separate the different functions so they can be tuned separately via software profiles.

Ok, thought you might have change tack. Mine is certainly not a pure 'G-Seat'.

Ah I see LOL. Now I understand. I usually refer to it as a "highly advanced G-seat", not knowing how else to describe it. In this case I misspoke.

What I meant by "pure" was that all the other cues were going to be handled "purely" by the "highly advanced G-seat" I'm going to build.

Thanks for calling me to question though, all too many people keep their mouth shut when they see you making a dumb mistake and let you suffer the sometimes significant consequences rather than hurt your feelings by challenging your ideas or pointing out your ineptitude! By "your" I mean "my". =P

Dear everyone; when I'm wrong tell me so! I will always reciprocate, which you may or may not appreciate. =P

Though I understand the objections by Noorbeast and Trip I think we shouldn't skip that idea on first pass.
The real big deal with that solution will be CALIBRATION. Because every single one of our motion platforms behaves differently, even if they are the same brand. The individual behaviour of a platform depends on weight and location of seat, the user himself and all the other attached gear. Jorant, unfortunately this is not just a slider we'd need for that!

But it's feasible! And since it's all about calculation it'd remain an «elegant» solution.
Let's have a look at it, how I imagine it:
With a Tracker, a Wand or another controller inside the Vive ecosystem attached to the platform, the calibration software would need to go thru the whole lot of possible changes in telemetry, all 6 axes, many speeds and MANY combinations of them. With the user sitting in his seat that calibration process would probably move and shake for several minutes, while pairing thousands of telemetry CHANGES with the actual input readings of the tracker's position/movement.
Note: in this process all latencies caused by the platform's inertia or the tracker's readings would automatically be considered.
In the end we'd have a USER PROFILE that controls a motion compensation software slipped in somewhere in the chain (where we now have OVRIE).

See another big benefit of such a solution? Once the profile is done you can throw away the tracker and crank up your subwoofers and buttkickers to the max! In fact, you can do without the whole Vive ecosystem and go for any other HMD, e.g. a WMR!

One tricky point in this solution will be: you can't just add up movement and correction data in a raw, after some cycles you need a "reset". But I think we'd have several options for that.

The big thing about such a solution will be the programming effort. OVRIE has to be adapted (or rewritten from scratch) to work with telemetry data and a profile, but even bigger may be the efforts to build the calibration software that creates that profile. And all the thinking behind it...

One last word to "latency". I think, please correct me if I'm wrong, the latency we have to deal with is kinda "negative latency": the actual position of our head/HMD is always BEHIND (respectively lies in the future) of what we ALREADY KNOW where it should be. Such a "negative latency" is easy to deal with. And as I said above, it should actually automatically be integrated in the "profile".

A rather obvious afterthought: Rather than taking each games raw telemetry data as input, this software should take SIMTOOLS' output.

Ok I see what you are saying here. Well said, thanks for setting me straight. I wonder how bad the error actually is for given types of movements.

You can use the current OVRIE for this. Just put the tracker on a stiff part of the rig. Right?

Wouldn't this compensation be non linear and include many variables? Sounds like a good problem for machine learning. If you change the rigs mass (different user) I wonder if you'd have to retune.

That's a fairly brilliant concept. I'm not sure if it's as practical as it sounds or not, but it seems like this idea should be given a serious look.

I'm glad my explanation was clear enough. =)

You are correct. That's the current way to do it, and most likely what I'll be using only because I'm not going to ask anybody to go to any significant lengths to develop something only useful for my simulator.

Plan "A" is to create a mount for the tracker on my elevator that is well isolated from vibration. If I can't isolate it well enough, I may try to use the linear motion (via a belt or something) from the elevator to drive a separate elevator that has only the tracker on it.

But it sure would save a lot of complexity, small tracking errors, etc. if I could just read the height of the elevator with a single rotary hall sensor driven by a belt or whatever. It seems simple to the point it might only take someone fifteen minutes to implement it. It probably isn't that simple, it rarely is!

It would indeed be non-linear and include many, many variables. As for whether or not a re-tune would be needed for a different rider weight; that would probably depend on many variables itself. How fussy the operator is, concerning "small errors" would not be the least of them!

I don't 'think' the idea is practical, but it's a new concept that is worth at least bringing to the table.

I think one problem is that even if we measure the exact results of a calibration sequence, the conditions the sim will experience in actual use are infinitely variable in ways that I think would likely cause constantly different results from the same pose request at a certain point in time.

Measure exactly where the sim is in basically every possible pose, and even then what happens when that pose is requested during a really hard heave movement vs. the same pose requested during a really hard sway movement vs. during very smooth operation etc. That's without taking platform variables into condition such as changes in player weight and motor temperature.

My point is I think the proposed calibration procedure, in order to be truly effective, would take an incredibly long time and then I'm almost certain the result would be "42". =) Still I'd like to see what our geniuses think before discarding the idea. Even if I'm right I think the general concept might well be useful as one component of some kind of solution.

I just figured out one such scenario! All theoretical of course.

Say we use @J-1775 's calibration procedure with a tracked controller rigidly mounted where the pilot/driver's head would normally be.

Rather than try to take that data and use it relative to the requested simulator poses from the software, make it proportional to hall sensors on the actuators.

Sensors on the actuators will by physically compensated for ALL variables in real time for obvious reasons. =) The only deviation would be flex/deformation of the rig.

This would still be incredibly complex to apply in a useful way on Stewart platforms and similar, but it seems to me very likely that this would work great for any sim that has a consistent linear relationship between a given actuator and it's correlating DOF.

For example, a pitch/roll/yaw 3DOF with one actuator (or actuator axis) per DOF, placed on a surge, sway, and/or heave table with one actuator (or actuator axis) per DOF.

*By one "actuator axis" per DOF I mean you could have more than one actual actuator to add more power if needed, but all actuators for that DOF would be running off the same signal.