Pose from motion

Allows the use of the classical motion cueing algorithm to calculate a pose.

This module is based on the classical motion cueing algorithm.

The idea here is not to go deep in theory, just search the many papers based on this algorithm and proposed variants.

Just want to note that Mover allows you to use any value as input on the algorithm, and any filter to treat the value, so you can change it the way you find more convenient.

So here's a basic diagram showing how this algorithm works:

Motion cueing algorithm, notice how it matches the organisation in the module

The pose from motion module with the default values

Linear motion and tilt coordination

So it seems complicated, but it's not.

We filter the received pose values and send them to the rig, what we have extra here, is that we mix the longitudinal and lateral accelerations with pitch and roll.

Why? Because it's a way to cheat the brain, to make us feel constant accelerations.

Let me explain with an example:

We are seated in a car, with speed and acceleration zero.

The rig is at it's default position, with all the pose values at zero.

We press the accelerator and the car starts moving and increasing acceleration.

Since what we feel is a pressure in the back, the rig moves longitudinally to the front to simulate that pressure.

We keep pressing the accelerator of the car to keep a constant acceleration.

We should move the rig longitudinally to the front, but there's no more range in the rig.

Since acceleration is constant, we replace the longitudinal movement with a tilt in pitch, so we tilt the rig up and move the surge back to zero replacing surge with pitch.

This makes the rig user feel a constant pressure in the back.

And notice, that since we moved the surge back to zero, we have surge available again to be used in acceleration changes.

We release the accelerator for one second and press it again, acceleration decreases and increases suddenly.

The rig moves in surge to represent the sudden variation. But stays tilted in pitch to represent the constant acceleration.

So in pitch we have the constant acceleration and in surge the variations.

So we can use a low pass filter in pitch to smooth the acceleration, and in surge a high pass filter to get the variations.

Now we release the accelerator and let the car decelerate for some time.

We release pressure in the back so we move the surge to the back and again we start reaching the limit of surge, so again and in the opposite directions we replace surge with a tilt down in pitch.

So this is why we mix the sway and surge in roll and pitch. The example is valid for lateral movement also.

Just as a side note, to avoid the introduction of a false cue, the return to zero should be made slowly and softly, in such way the user doesn't feel it.

The replacement of the linear motion with the rotation should not be felt by the user.

To know more about this, search the web for the vestibular system. The sensation felt by each user can vary, but there's studies that prove it's possible to use those tricks to cheat the brain, specially with VR, having visuals following the sensations.

Rotations

For rotations we should use rotation speed.

First, because with this, there's no problem of completing a turn and going from -180º to +180º.

That would cause a jump in the rig, from one side to the other.

Well, position has interest, but mainly for rigs that can rotate more than 360º , and usually full 360º.

In those rigs, the transition from -180º to +180º should be handled by hardware. Just make the rig travel the least angle (distance). If you are at 170º and are asked for -175º, the nearest path is to go over the +180º to -180º, that's just 15º angle, while going the other way, the angle is 345º.

In those rigs, we should not use filters. We get the real rotation 1:1 from simulation to the rig.

For other rigs, the important is to transmit to the user the sensation of rotation movement, not the static tilt. For that, see bellow what I say about gravity.

So if rotation speed is constant we don't feel any force, just in accelerations. That's why we use a high pass filter over the speed. It's to get the variations of speed.

That's those variations of speed that are going to make us feel forces in the neck generated by the rotation.

I know, rotating at constant speed also generates tangential and centripetal forces. But you can't do it on the usual rigs, just in 360º ones. On the usual rigs we have to count more on the visual part to help with the experience felt by the user.

So, use a high pass filter followed by a low pass (EMALP(EMAHP)), just like we do on sway, surge and heave components of the rig pose.

It will behave the same, returning to zero if the speed is constant.

Gravity

The accelerations we have from most games, don't include gravity, but you should use this algorithm with gravity included.

To solve the lack of info, Mover calculates and adds gravity to the accelerations when needed and possible.

Let me give an example to show why we should use gravity:

We are in a slow car going over big rocks making an all terrain adventure, but we park the car with some wheels over a big rock, and the car is tilted in roll and pitch.

So we should feel that roll and pitch. Seems a good idea to use the rotation position in the rotating degrees of freedom of the rig. Right?

Well you can do it, but you are spending those rotation channels in the rotation position, while you should use it with speeds.

If you are using gravity, you have a constant acceleration while you are stopped, If you are tilted, you get a longitudinal and lateral component of gravity that are also constant while stopped, and because of the tilt coordination we are representing that force of gravity in roll and pitch, so we are already representing the force felt by having the car tilted over the rock.

Resuming

For linear

When possible, use accelerations with gravity in sway, surge and heave.

Use a high pass filter followed by a low pass filter in sway, surge and heave (EMALP(EMAHP)).

To start, use the same number of samples in both filters.

Bigger the number of samples in the high pass, more movement you get from the rig.

Bigger the number of samples in the low pass, smoother the movement, and slower coming back to zero.

Coordination

Use the coordination channels, mixing surge in pitch and sway in roll.

Use two low pass filters in the coordination channel (EMALP(EMALP)).

Start with the same number of samples used in the sway, surge and heave channels.

Adjust the coordination channels in such way that:

Pitch increases at the same time surge goes back to zero slowly and smoothly in such way the user doesn't perceive it.
Surge goes back to zero slowly and smoothly in such way the user doesn't perceive it.
Small variations in acceleration around a specific value, affect just the linear motion, not the tilt.

A good way to test it is to move the acceleration slider front and back really fast in a range (A in the image).

Doing it you are varying the acceleration around a constant value, so you should get the rig with a specific pitch related to that constant, and surge changing due to the changes in the slider.

For rotations

In yaw, pitch and roll, use rotation speeds, unless one of them can rotate 360º, for that ones, use position.

Use a high pass filter followed by a low pass filter in sway, surge and heave (EMALP(EMAHP)).

Behaviour is similar to the linear degrees of freedom, but in rotations.

Some other ideas in the filtering:

Try using triple EMALP in the coordination channel instead of a double EMALP. You smooth entry and exit.
Use gain after the EMALP(EMAHP) to adjust the range you want to use. To make the washout slower, use a big value in the EMAHP.

Move slider in range A, to get a constant value in the middle of A and a variation in surge

Rig moving in surge while tilted

The module window

Like we have for all pose modules:

At the right of the window, check the sources used to get the values.

The values of each source are added when you check more than one.

At the bottom, the pose values generated by this pose module.

Specific to this module is the center area. and there we have:

Use Simtools order, just to reorder the controls with the order used by Simtools.
At the top center, the COR correction.

Here, we can change the location of the center of rotation in each rotation DOF of this pose. See more info here.

All the other controls are used to define the motion cueing algorithm.

Each line is a DOF of the pose. Notice that roll and pitch get two lines. The second line on those DOF are the sway and surge mix or tilt coordination.

In columns, we have from left to right:

The selected value used for that DOF.

Remember that sources don't have all the values. So some of them are always zero.

The current received.
The gain applied to the received value.
The slider to manually change the value if no source is connected.

If source is connected, you can't move the slider.

The slider buttons represents the current received value, while the bar in the background represents the output sent to this DOF.

Check box to force manual change of the slider, even with a source connected.

You can use it to disable the DOF and fix a specific value.

A button to reset the slider to zero (in manual mode).
The allowed range on this DOF.

You can limit how much this DOF can move. Any value above it is cropped.

Changing it, also changes the range of the slider.

The filter for the DOF.
The output gain, to adjust the gain after the filtering. Remember, anything outside of the range is cropped.
A column with the calculated values.

If values become red, it's because they are out of the defined ranges.

On the coordination channels, we receive the values of the sway and surge channels before any filtering or gain, that's why there's no value selection on those lines.

The sway/roll mix/coordination.

And marked in red you also have the surge/pitch mix/coordination.

A check box to enable/disable the mix/coordination channel.
A filter for the mix/coordination channel.
An output gain, applied after the filtering.
The calculated value of the mix/coordination.
Is the value of the DOF calculation for pitch.
Is the sum of the calculated mix/coordination with the value of 6.

Here the sum can be red also, if it goes over the specified range.

Page updated

Google Sites

Report abuse