FlyPT Mover 3.5.3

I think the problem is the missing vertical cue that make the lateral cue stick out unrealistically. And you want to dial down the lateral cue to have it "match" the vertical cue? Is that correct?

You could add a harness tension system to increase the vertical load, or you have to accept this as an edge case that a 6DOF Stewart type platform will have to live with.

Another suggestion. Would it be possible to add a "shot down" or crashed trigger to DCS profile in the future. Its almost as scary as being shot down. One can use spike filters but i feel like it does reduce what the rig can do by a fair bit

Cheers!

I find all this very interesting and would like to know in detail how to setup those HP an LP filters correctly in mover. Or maybe there is already another thread which explains which values/filter types to use and how those values should be related to each other? In other words, what's essential and what could be adapted "to taste"? Also, if this is the generally agreed consensus of a correct motion cueing it would be very nice to be available as a starting point in mover, because right now when you click "Add->Pose->From motion" or "Add->Pose->Basic from motion" you get different default telemetry values/filters

Applying a properly constructed classical washout or derivative is valid ONLY under specific conditions :

1. Accelerations have to contain gravity component
2. Rotations velocities have to be available

It might be important to point as it’s not necessarily the case in all titles.

Once you have an access to those, it’s really super simple. You really don’t have to think about specific scenario, whatever you do, the force vector will be applied correctly across heave/surge/sway.

Last thing to mention is that you can use gravity to simulate sustainable lateral or longitudinal accel up to 0.5G, (don’t use HPF for this) BUT you CANNOT do anything for heave what concerns Stuart platforms therefore additional pressure systems (Especially for heave) make sense.

I also highly advise to apply a logistic function as it can dramatically increase your workspace like I did in a quick Cessna profile for xplane you can find above.

Have fun - cheers

Wouldn't it be possible to calculate those values from the "standard" ones (euler angles + accel without g)? Angular velocities by using first derivative (spatial) and "accel+g" by adding g to the acceleration vector (rotated correctly)? My understanding was that mover already does this for certain titles?

That’s what mover is doing on some titles. A good example is Il2 Sturmovik where the gravity was added. Dcs and xplane have it natively.

I believe, the fact that classical washout doesn’t comes as standard is that the games are really different in terms of telemetry and each rig has different geometry, max speed and acceleration capabilities.

I guess that many racing games doesn’t have gravity component embedded and that’s the reason why mover is starting with simple accelerations and Euler on pitch and roll.

When accels with gravity and velocities are not present, you have to double check multiple times in order to not mess up with directions before mixing them. That’s because there is many different coordinates systems in use by different developers. So the process of adding gravity can’t be applied automatically.

The good thing is, that for hardcore users, it is possible to add missing gravity through modules for each dof.

@pmvcda correct me if I am wrong.

My point of view is that it’s easier to construct a well working profile from scratch that modifying an existing setup. It is less dangerous because everyone knows his own rig better than anybody else. It’s also more fun.

Maybe in time mover could be able to provide a crossover “classical washout” as a starting profile for all games but I don’t think it could be done with one config file for all titles.

Best.

I looked at your X plane profile and this flow chart Im a little curious on the use of double and triple EMALP.
What is the reason for this?

1st order ema, whatever the amount of it, will keep “a corner”. The impulse will remain instantaneous. Superposing two “emas” one on the top of another (ema second order) changes drastically its behavior. Basically speaking, you add a ramp. It’s also instantaneous but much more fluid and it is keeping a certain dynamism.
Third order is good for coordination channel where you have to tilt the platform as quickly as possible without feeling the tilt.

xplane telemetry by nature is pretty rough with a lot of details. Ordering helps also to get rid of some artifacts.

@pmvcda , I have a theoretical question concerning mover. Do we really need output gain ?

I am constructing profiles only with entry gains on all axis except tilt coordination.

I am not sure we need both.

Okay, I believe I got it now... I think

In hexpod's setup, everything uses the EMAHP (HP1 shown in image below) filter to return the In/Out values to zero, with the exception of the mixed in sway and surge into roll and pitch. This is perfect for accelerations and rate of change.

Rhetorical Question:
You're holding a stable climb rate and stable KIAS, so there is no acceleration or rate change. What pitches the aircraft upwards to simulate gravity vector?

The Answer (I think): The simulated "orientation/positional (°)" values for Pitch and Roll are coming from... It's subtle but from within those Sway and Surge accelerations. That's because they include that little word... GRAVITY. Then if you mix those Sway and Surge accelerations into Pitch and Roll (without EMAHP filter), the rig will position to simulate the gravity vector using Pitch and Roll... It was an EUREKA moment for me ! ! !





@Dirty
Your image was perfect and really helped out a lot, thanks for sharing...


Okay, next subject I could use some help understanding if you guys don't mind, what is this doing in hexpod's setup...


__________________
Best regards,
Mark

HI,

First, thanks for helping here!

The two gains are different, the first one (left) acts before filters and the last (right) after the filter.
Example: if filter has crop, the left gain increased the value that enters the filter, but after filtering it will be cropped to the defined value.
The right filter will increase the result and the crop looses effect, or is also affected by the right gain.
In reality they are added to the filter this way:

RightGain(Filter(LeftGain(value)))

I did this profile quick and simple.
If I recall well, I selected this window to act ONLY for ground. That means it’s triggering off when the wheels are lifting from the ground.

As I use pretty high gains and a relatively big amount of smoothing for heave in the main window, this small addition is here to compensate the runway roughness. It is tuned with a smallest possible smoothing value and it’s cropped to act with a minimum of amplitude so it doesn’t destroy the landing effect.

Bravo for the Eureka ! Indeed, orientation (through gravity vector) and body accelerations once combined together, gives you a proper cueing.

You have to make your reverence to Albert, as he made gravity and acceleration equivalent.

EDIT:
Remember, a free falling object doesn’t accelerate. That’s all what you have to understand.

What I do is the following: once I apply or increase the value of a LPF of HPF, the output signal (Blue Bar) gets strongly reduced. That’s normal. To fulfill the axis I use entry gain to compensate it.I see the slider topping the boundaries but as soon as the filtered signal (blue bar) remains inside the range, I don’t have any cuts.

Sorry but I still don’t see for what purpose I should use the output gain.

if you could illustrate a specific scenario where the right gain could take an advantage over the left one, I would be thankful

I can remove it. In reality, I never use them also.

I can confirm I found the separate in and out (or what I call; before and after) filters extremely useful on my "jerky" Stewart.

@hexpod I'm afraid I do not remember exactly why as it was some time ago, but I was very glad they were there so would not want them to go away unless there is something significant to be gained by removing them. It may have been a situation unique to a sim that has some issues.

For those who don't know or don't remember: My big AC powered 6DOF Stewart was ok for racing, but never nearly smooth enough for flying IMO. The culprit was a combo of backlash in the gearboxes and motors that were unable to manage a slow enough speed so for tiny movements they stopped as soon as they started, working in an on/off type of manner that made level flight feel "notchy".

Pity you can’t remember why it could have been useful.

@Trip Rodriguez

I just wanted to avoid an unneeded confusion through redundant settings that when they are not fully understood, could greatly mislead the user.

If I understand the things correctly, by using entry gain, the math (filters) you apply, stay inside the range on your axis. Functions like logistic, crop etc. will be properly scaled.

On the other side, “out gain” <1 will act like a range reducer and “out gain” >1, will stretch the signal and will crop (destroy) the math you applied in the filter.

I believe you can achieve the same effect with “crop” function or by limiting the range of your axis, which are much more reasonable methods than doing a blind kitchen finding a relation between in and out gain.

Do you think we need this redundancy ?

Edit:
IMO simpler software doesn’t mean less powerful software, quite the contrary.

You might well be correct, I suppose if all the knowledgeable folks here agree that it probably has no utility it would be a good idea to remove it.