FlyPT Mover

“In classical mechanics of rigid bodies, there are no forces associated with the derivatives of acceleration; however, physical systems experience oscillations and deformations as a result of jerk.”

If I can read well, no forces BUT deformations, very non-intuitive.

On the top of it, we have to do with human
active muscle control.

“When braking suddenly or during collisions, passengers whip forward with an initial acceleration that is larger than during the rest of the braking process because muscle tension regains control of the body quickly after the onset of braking or impact. These effects are not modeled in vehicle testing because cadavers and crash test dummies do not have active muscle control.”

I know a guy who says "my sim behaves much better since I'm dead..."

I think the point was that there are some noticeable "motion-effects" that stem from the fact that humans have a bunch of motoric reflexes.

Logically, a research paper must mention that those effects are obviously not reproducible with corpses or crash test dummies.

There are no forces associated with jerk ALONE, that's correct But since jerk is always accompanied by some acceleration it is safe to say that "without acceleration, no jerk AND no deformation"

A few notions I would like to add to the discussion:

1)
The "kick" @alex928gt is talking about is not just a kick! It is always a kick and an immediate "kick back". If your actuator creates a displacement it must provide an acceleration AND a deceleration.

That's why a HP1LP2 (yellow) or HP1LP1 (blue) is being used to filter the acceleration signal. The resulting step response curve will look like this:


The idea behind this response curve is to allow the start of the motion to be perceptible, but suppress the second (and in this case even a third) kick below the threshold of perception. In this diagram the gradient represents velocity, curvature represents acceleration.

2)
Let's not compare apples with oranges. @alex928gt is pretty much talking about a "surge only" scenario. Those racing rigs do have a little tilt, but they are anything but tilt-coordinated. The surge back when releasing the throttle may feel wrong in this scenario, but it does not when on a properly tilt-coordinated 6DOF rig.

On those rigs you have a significant tilt during an acceleration. Say 20°. The earth accelerates you upwards at 1G. That means you feel an acceleration of sin(20°)= 0.34G (positive) in the longitudinal axis. Now, when the surge channel creates that "kick back" (ambiguous description, btw) that you perceive as inappropriate, it just "neutralises" these 0.34G.

On a properly tuned 6DOF (like @hexpod's) with all outside references removed (like @hexpod's) it actually doesn't feel all that wrong.

3)
"Be careful what you wish for. It may come true!" You are mainly considering braking, gearshifts and closing the throttle. And you want to change the behaviour for those. That's an honorable endeavour! But the sim has to cover a much wider range of scenarios. Admittedly, in a race car, shifting gears during acceleration and braking is much of what you do with it, nonetheless you have to also consider what it does to all the other scenarios where the acceleration signal might look something like this:


Again, I am not yet being solution-focused here yet, rather still very much problem-focused. But if the problem is not understood sufficiently deep, my fear would be that the outcome might very well be a motion rig that does shift gears really well, but shows some very weird behaviour in other scenarios.

For example the video that @hexpod posted where he shows the pumping of the actuators into the end stop.

I'm not saying it couldn't be done, but I would expect plenty more similar surprises on the way

Cheers,...

FlyPT Mover 3.4.0 ALPHA

Finally a new release...

Again, this is still Alpha, and I'm posting it to get some feedback.

Biggest changes:

- Help buttons marked with ?, directing the user to a specific section of the online help at flyptmover.com
- New sources like VTOL VR, Warthunder and FS2020 (no more need for an extra exe file).


- New low pass and high pass filters:


New circular Stewart platforms:




- New output just for motion compensation:

We can now use custom filters for each DOF in conjunction with the OVRMC ones.

And many other small features and bugs solved.

For download, please visit: https://www.flyptmover.com/downloads

Thanks for the recent update !

I have 1 question regarding the filters.
Is it possible with mover to have an effect similar to the "washout" of simtools ?

What I'm after is that the actuator will go into 1 direction, once it reach it's destination, this current position should be considered as it's new "default/ center" position and the actuator should slowly return to the "REAL middle / default" position. Note: when the actuator slowly come back to the real middle, each of its new location based on the return should be considered its *new* default/center position.
Mostly for surge usage for having some room left on the actuator when accelerating.
Hope it's not too confusing. anyway it's the same thing the "washout" filter does on Simtools.

That's what I do with the high pass and low pass filters.
This is a square wave with a BUTTERWORTHLP(BUTTERWORTHHP(VALUE;0.5;1);1;1)
LP=Low pass HP=High pass


Now with noise:


There's been some discussion around making a washout filter, but honestly, been trying to make something different, but without good results.
There's even a WASH filter, just for my testings, but it's not good.
The problem is that we keep getting data at high rate and we need to deal with it and represent it. Tried the WASH accepting values going away from zero and washing to zero anything lower than the current value. But it's completely wrong.
I lack ideas to achieve such a filter. Might be to much into the low pass/high pass solution to even see anything else right now.

The features are raining from the sky like biblical manna.

Thank you very much for those valuable additions.

Might be not realizing something, but:

How about overlaying an ever present slow movement towards the middle which is interrupted for movements that have a larger acceleration than this slow pull?

hi ,
thanks for your new release
tested with 6dof rotating hexapod . used the alpha335 setup and recreate a new 6dof rotating hexapod but both surge and sway movement are roll and pitch . I disabled the mixing roll and pitch into sway and surge and the movement aren't flat . there something's wrong
Thanks

THANKS so much for your latest release! Thru JUST POSE module Mover is now fully working on with my GForceFactory rig! On all 6 DoF with full envelope! With hardly any tuning (yet!) I could test it with my favourite flightsims.
I couldn't withstand to try the new MC output module. I wasn't surprised that with compensation applied I drifted far more away in and out of the cockpit than with no compensation at all: @Dschadu on his website warns of an overcompensation issue.
However I asked myself, how you (or Dschadu?) can do your calculations when you don't know the vectors of how far away my head is from CoR? Or do you? But the JUST POSE module gives no such indication...

For the virtual tracker to work properly you have to adjust all measurements and check if 100mm in Mover equals to 100mm in real life. Also be sure that the VT is placed at the COR.
Offset to the HMD is handled in the compensation algorithm.

Thanks. Are you aware that the RIG::JUST POSE module lacks the "center of rotation" input values and, of course, all rig measurements?
Would I need to use the "Yaw/Roll/Pitch COR displacement" fields (in the POSE module) instead?
EDIT: The "range" values are now correct in both modules (not like in screenshot!).
But maybe I should add that I use a WMR HMD (G2)?
>>Also be sure that the VT is placed at the COR.
Using @pmvcda 's new Output module as VT I am no longer asked to interactively place the VT.
Do I miss something?

That is what I'm working on. But when we change direction we get an amplitude bigger than the desired one.
Not sure I'm explaining well. I think I have a solution. Let's see.

Can you share the setup please?

I think I have worked it out: Motion cueing is a bit of a different paradigm from the current pose based approach. You will need extra axes! Let me explain:

Currently every metric gets converted straight into a pose. Poses serve to shift gravity to make our vestibular system experience a different, constant acceleration like centripetal force or braking force.

Motion cueing is a bit different. We trick the brain by feeding it with perceptible changes and then wash out these changes so slow that it can't be felt. This is useful for simulating changes in constant accelerations like slamming the brakes or rolling an aircraft into a different attitude without causing centripetal force. You can't just translate a metric into a pose here, since we don't want a certain pose, we want a change in pose.

So we need an extra set of axes. On top of the absolute pose axes we already have, we need extra differential axes for motion cueing. Both sets of axes still are simply added to put the rig into a known pose. But the cueing axes are not static, they are dynamic.

First of all, the cueing axes will by default have a high pass filter that rolls off the motions just below the perceptible threshold. The vestibular system will feel the intial push, and the rig will decrease the acceleration of the head below the perceptible threshold so that in our minds, the acceleration doesn't stop. Until it does, because then the high pass will react to the fall in e.g. roll rate and will generate an opposite jolt. Under braking for example, we would want the nodding of your head when you start and finish braking to a stop.

To limit the offset of gravity (that is to be defined by the absolute pose axes) and to account for the fact that we don't have unlimited mechanical movement, the cueing axes will also have a constant imperceptible movement towards neutral. Not rig neutral, but cueing axis neutral, so there is no effect on the normal axes. This movement towards neutral has to be dimensioned according to the characteristics of the "roll off" of the high pass filter, so that both together will not go beyond the perceptible threshold.

So in your software, you could provide extra axis with these features. Or, if you think that is easier for the end user, a checkbox "motion cueing" which will cause the software to use the cueing axes in the background in stead of straight poses.

Useful info:
https://bmcearnosethroatdisord.biomedcentral.com/articles/10.1186/1472-6815-5-5

For absolute perfection, you could even try to compensate for changes in pose, which are also accelerations. E.g. in braking, the pose will also pitch forward to simulate the braking force. in stead of having both accelerations at the same time, the cueing axis could already take into account accelerations from changes to the corresponding pose axis. And vice versa the pose would be compensated in case the cueing axis is already helping it. But I think that is another level of complexity. You would basically be handling accelerations and poses in a wholistic way and try to use perception thresholds to satisfy both requirements without false cues. Lets leave that for a later version.

Or maybe it is as simple as limiting pose accelerations below the perception threshold. I have to think about that for a while.

@benmax ,
Do you notice it in the rig, but not in the 3D view?
If so, you might have some dimensions wrong.

Been testing and I don't see anything wrong (used ACC source).
What I see wrong is the pitch direction in ACC.

But...
This is all the purpose of Mover.

You can use multiple layers of Poses in one rig.
And the filtering allows you to make the motion cueing.
Something similar to this:



Visually, you almost have the classical motion cueing alghorithm in the pose from motion module:


By default, filters are not filled, but you can put them however you want. It's customizable, because it all depends on what we have from the sources.