FlyPT Mover

Hey @Trigen,

TL,DR: DCS and Mover are both correct. You have a misconception.

I'm in a bit of a hurry just now, and I don't want to spam the thread full with explanations, so I'm gonna keep it short: "Acceleration" is not necessarily the change of speed over time. And even less the change of AIRspeed over time!

- You yourself the answer, have just given.
- Only recognise it, you must.
- The seed of a deep truth, in your very sentence lies.
- If understanding you want, then letting go of your assumptions you must.

...that, and start a new thread on the topic. I will certainly chip in! I have made some long posts on the subject here and there, but if there were a dedicated thread like: "What does acceleration even mean", then I would try to scrape together a few graphics with explanations. I think it's totally worth understanding.

Cheers,... Dirty

Complex stuff this force vectors. Once you start to combine them, varying your push and orientation with gravity on the top of it, it’s easy to get lost.

Edit:
I might be wrong but by pulling such big G’s like you do in your example you convert a part of your push in vertical accel.

It would be cool to « visualize » how those vectors are « chasing » each other

Hey Peter

Generating you own motion is a double edged sword, I would say. You can generate increbibly credible turbulence through noise, but as you already mentioned, the motion generated this way will not be "related" (for lack of a better word) to what's going on in the sim. You will feel the turbulence even when the aircraft is standing still in a hangar. Or you might feel a little pitch up, while the aircraft pitches down.
Now, you can try to create that relation by making the turbulence dependent on certain parameters, but that is an uphill battle Not impossible, just tedious. You will need more and more parameters to "shape" the motion, but will still be left with some inplausibilities.

I couldn'd test any of this, because I am currently building my new rig, so take this just as more of an intuitive approach here:
First and foremost I will try to tune the motion such that accelerations are correctly (however you want to measure that) displayed. It really doesn't matter what causes those accelerations. As long as they are present in the export data stream, they will also be present in the motion of the rig.
If the accelerations are properly cued, then the turbulence in the flight model will also be properly cued with them.

But, if I understood you correctly, then your problem might be more like:
I can feel those turbulences, but they are very light and the motion generated due to actual aircraft manoeuvring is much stronger. If I increase the heave, then those bigger movements will simply smash the rig into it's endstop.

If THAT sounds like your problem, then some signal compression might help.


If you multiply the signal with a Logistic or TanH function (or similar) you can keep (or even increase) the sensitivity of the output for small values, but the larger values will get reduced. I would not over do it, but with good measure it should make small movements bigger and larger movements smaller.

--> Just like a frequency filter "shapes" the frequency distribution of a signal, a compression "shapes" the amplitude distribution.

I have seen a logistic function in Mover somewhere. Just wrap your current filter setup in this function:

Code:

LOGISTIC([Your filter here];[Limit];[Gradient])

It also makes any "Crop" redundant, because it asymptotically approaches the limit.

Signal compression would certainly be my weapon of choice

Even if I'm 1.5 years late for the party Nice code! Elegant code!

One minor thing to mention: On a higher order EMA, you don't need to keep track of the individual "weighting factors". They can all be the same variable.

Cranking one up and leaving one set will be the same as if you had cranked both up, just a little less. You will not change the filter response characteristic by giving them different values.

LowPassModule:

Code:

public class LowPassModule
    {
        public float Output { get; set; }
        public void Push(float NewValue, float Alpha)
        {
            Output = NewValue * Alpha + Output * (1 - Alpha);
        }
        public void Set(float f)
        {
            Output = f;
        }
    }

LowPassNthOrder:

Code:

public class LowPassNthOrder : Filter
    {
        private LowPassModule[] LP_Array = new LowPassModule[4];
     
        //Constructor
        public LowPassNthOrder(int order = 1)
        {
            Order = (FilterOrder)order;
         
            for (int i = 0; i < 4; i++)                         //initialise all four filter instances
            {
                LP_Array[i] = new LowPassModule();
            }
        }
     
        public override void CreateOutput()
        {
            float temp = InValue;                            
            float adoptionrate = 1 / FilterVariable;            //The LP filter internally uses adoption rate!
         
            for (int i = 0; i < (int)Order; i++)                //Push it through as many LP-filters as the filter order
            {
                LP_Array[i].Push(temp, adoptionrate);      
                temp = LP_Array[i].Output;
            }
            OutValue = temp;
        }
        public void Set(float f)
        {
            foreach (LowPassModule lpm in LP_Array)
            {
                lpm.Set(f);
            }
        }
    }

Especially on higher order filters this saves a lot of lines. I can just create a 100th order LP by calling...

Code:

LowPassNthOrder EMA_100 = new LowPassNthOrder(100);

Hi all,

Very intested by this thread.

FlyPT looks great, what an incredible work !

I'm currently using 5 PT-actuator actuators on my rig: 3 vertical ones (1 front and 2 rear) for 3DOF, 1 horizontal one for surge and 1 horizontal one for Traction Loss.

I'm pretty happy with Simtools for the management of the 3DOF and TL actuators but can't find a way to manage the surge actuator in a way that seems consistent (I already posted on the forum last year on this topic but unfortunately was not able to find the right solution through Simtools).

I'm therefore turning myself towards the more flexible (but also more complex) FlyPT solution to manage the surge actuator and maybe the other ones as well in the future.

To do so I would like to be able to replicate in FlyPT the Simtool's TL behavior that Yobuddy described in a post back in July 2019:


It's a washout filter that ignores input from the data returning to zero.
Or you could say, it captures the acceleration data only when it growing either in a positive or negative direction.

For example,
Input jumps from 0 to 100, output = output + 100 steps
Input jumps from 100 back to 0, output = output - washout
Input jumps from 0 to -100, output = output - 100 steps
Input jumps from -100 back to 0, output = output - washout


I'm still not an expert with the FlyPT filters but do you think this type of behavior could be replicated there without hardcore coding ? If so could you please provide an indication of how I could code this based on the FlyPT filter language?

Thanks a lot in advance. I believe this could be useful to other members to actually manage their horizontal surge actuators in a more realistic way than just having the actuator's position directly driven by the longitudinal acceleration input.

Alex

It’s a mystery how you do want to deal with surge on a 3 dof. You have only roll pitch and heave. Is that correct ?

I have 3DOF (3 vertical actuators) + 1 surge (horizontal actuator) + 1 TL (horizontal actuator).

I probably did not make it clear but my rig is a sim racing gear, not a plane sim rig.

The 3DOF can indeed account for roll/pitch/heave and can also do a bit of surge and sway through fast front/back or left/right inclination moves.

But my question relates to the separate horizontal actuator that can move the whole structure forward and backward. I would like this horizontal actuator to provide a second and stronger surge move in addition to the subtle inclination move provided by the 3DOF. So same input source coming from longitudinal acceleration, feeding the 3DOF inclination moves on one hand and also feeding the horizontal actuator backward/forward move on the other hand.

If I understand well you are talking about so called « coordination channel » mixing surge in pitch or mixing sway in roll

Hey @alex928gt,
Yes, in general that is possible in Mover. I don't know if your particular sim setup is featured, but from a filter perspective it's no problem to process the data.

As input data for "Surge" (2nd row) you should select "longitudinal acceleration with gravity" and apply a single high pass filter (EMAHP) followed by a 2nd order lowpass. In Mover that should be a EMALP(EMALP(EMAHP(Value)))


then use the data that comes out of that channel to drive your surge-actuator.

Because you also want that same acceleration data to tilt your rig, you want to set the tick mark in the bottom line "Mix surge in pitch". Here you should use a 3rd order lowpass filter. That is a EMALP(EMALP(EMALP(Value)))


then use the data that comes out of that channel to tilt your rig.

I can't give you more detailed instructions, because I am not a Mover-user, just a Mover-understander I'm sure there's people here able to tell you in greater detail how exactly to set up Mover so that the correct data goes to the correct actuator(s).

Two more things:
- The filter setup I recommended is the "classical" filter based motion cueing setup, but feel free to experiment. Let your butt be the judge!
- The LP filters in these two channels look similar but serve very different purposes. The 2nd order LP in the surge channel converts the acceleration signal (input) into a position signal (output). Whereas the 3rd order LP is meant to conceal the rotation of the rig from your perception.

Have fun

To clarify, I'm talking about the actuator circled in red in the pictures below.

Thanks a lot Dirty.

I understand your point on filters but will this allow the effect described by Yobuddy, i.e. ignoring the input from the data returning to zero?

It's a washout filter that ignores input from the data returning to zero.
Or you could say, it captures the acceleration data only when it growing either in a positive or negative direction.

For example,
Input jumps from 0 to 100, output = output + 100 steps
Input jumps from 100 back to 0, output = output - washout
Input jumps from 0 to -100, output = output - 100 steps
Input jumps from -100 back to 0, output = output - washout

When I tried different effects that's really what I'm missing, i.e. I expect acceleration (i.e. longitudinal acceleration jumping from 0 to X) to kick forward the actuator position and braking (i.e. longitudinal acceleration jumping from 0 to -X) to kick it backward, but throttle release (i.e. longitudinal acceleration getting back from X to 0) as well as brake release (i.e. longitudinal acceleration getting up from -X to 0) should not provide a kick. Otherwise the feeling is not natural in my view.

Do you proposals actually provide for this difference of behavior depending on acceleration jumping from 0 to X or returning from X to 0?

Thanks
Alex

Yes. That's what the highpass filter in the surge channel is for

I know that "washout" is a term that is frequently used around here, but there are different ways to implement it, depending on the input data that is being used and the channel you want to drive.

For example, if you use angular rate on the roll channel, then you would use HP1+LP1 to create a "washout". So, I am always specifying the input data, the filter combination and the driven channel to be unambiguous. Also in research papers that data is always provided.

There is one caveat when using the "classical" filter setup on a rig with relatively small operating space. While technically correct, those LP filters might actually dampen the motion to a point where it looses it's "snappiness".
That's not really an issue if you are simulating a plane and have like 700mm of surge, but does play a role if you are simulating a high performance car and have only 100mm. Also car racing has some really high frequency stuff going on in the signal, so probably try one order less on the LP filters.

You can look at the bar diagram (blue bar) of the output signal. That should give you a very good idea of what your surge actuator is going to be doing

Cheers... Dirty

Wait,... I just read that again,...

If that is what you want (a distinction between braking and releasing the throttle), then no, it does not provide exactly that! Are you sure that this is the behaviour you are looking for? Cruden do follow a very similar approach, but they have an engineer and a PhD working on this. Technically it is of course possible, but it would require you read the brake and accelerator signal.

I can hardly imagine that this could be implemented in SimTools. I wouldn't know how. I am interested in understanding this problem better, but just off the top of my head, I don't think it can be done without writing custom code for that particular scenario.

Maybe @pmvcda has something running in his secret underground coding lab hidden inside a Caribbean volcano,... Now, THAT would be a reason to switch to Mover for sure!

Cheers, Dirty

In my "secret lab", latest developments are new filters


Now trying to conclude the spline filter that allows us to define control points and customize the response.
Want to allow filters on the points coordinate not easy right now.
But the filters are interesting. Need to test more.

@alex928gt ,
The accelerator thing... We can use the joystick source in Mover to capture the accelerator axis if that's what you want. Some games have it in the source values also.
But I don't think you want it.

So tell me,
You want to feel more gear change in surge? Same with the accelerator pedal?
All this makes is change the longitudinal acceleration of the car, so the logic is to use that as a source of data.

For traction loss, like @Dirty says, the high pass filter should be used for that.
Try it with yaw speed and yaw acceleration. Put a low pass over the high pass to smooth it.
Increase the samples in the high pass to get more movement and a slower return to zero.
If movement is to much, use a gain to lower the value, but it will keep the time to go back to zero.

Been looking at tire slip to generate the traction loss (front and rear), but I still don't have something usable. Not even close unfortunately.
Need to clean some important parts in Mover before diving into it.

Thanks a lot for your replies. Let me try to provide more clarity on what I expect.

I indeed would like a distinction between braking and releasing the throttle and I'm not sure this actually needs distinct brake and accelerator signals. Let me try and explain.

My feeling is that when you release the throttle you actually get acceleration back from positive to 0 whereas braking actually generates a negative acceleration, which is not the same. Likewise, releasing the brakes just gets the negative acceleration back to 0 which is different from accelerating which would involve getting acceleration from 0 to positive.

What I expect from my surge actuator is :
- a forward kick when accelerating
- a backward kick when braking
BUT
- no backward kick when releasing the throttle
- no forward kick when releasing the brakes

I could maybe encounter a slight backward kick when releasing the throttle but this should not come from releasing the throttle itself but more from actual engine braking and road/air friction generating an actual braking i.e. an expected backward kick.

This reflects the asymmetry we clearly feel between an increase of acceleration in absolute value and a decrease in absolute value. Both are acceleration changes but the impact on the driver's body of an increase in absolute value is not the same as the impact of a decrease in absolute value. Therefore the impact on the surge actuator should not be the same either.

I tried to summarize this in the charts below.

Chart1: Here is what I would typically get when using LP1+HP1 filter applied to acceleration input source.

- On throttle and braking the move is ok, i.e. forward kick on throttle and backward kick on braking
- I then get a nice wash-out effect
- But when releasing the throttle I get a backward kick and a forward kick when releasing the brakes, which is not what I expect



Chart 2: to make it clearer I separated the throttle and braking phases, still using LP1+HP1 filter. Otherwise there is confusion between the "releasing the throttle" and "braking" phases or between the "releasing the brakes" and "throttling" phases, which are often combined when actually driving but not always

- If I throttle strong and immediately release the throttle without braking yet I will get a strong forward kick but also a strong backward kick right afterwards, which is not what I would expect
- Likewise if jumping on the brakes and releasing them, I will get a strong backward kick but also a strong forward kick right afterwards, which is not what I would expect either


Chart 3: What I would expect, consistently with Yobuddy's description of what he did on TL in Simtools:
- When throttle is applied I get a forward kick
- When I release the throttle I just get a nice backwards washout movement on the surge actuator
- Then I jump on the brakes and the surge actuator kicks backwards, starting from its current position
- When releasing the brakes I just get a nice forwards washout movement on the surge actuator
- Please note that the 0-position from the surge actuator is here clearly more de-correlated from the 0-value of the acceleration input than in the case of the LP1+HP1 filter since a decrease of acceleration in absolute value does not force any more the centering of the actuator that just nicely washes out. Whereas an increase of acceleration in absolute value forces the actuator's move.

Does this make sense?
Do you believe such behavior/asymmetry is actually manageable with current Mover filters?

Another way to express it like Yobuddy did is "It's a washout filter that ignores input from the data returning to zero."

Thanks a lot, you are all doing a great job !
Alex

By the way, been considering if the use of shelf filters is interesting.
A shelf filter is like a low pass or high pass. But instead of removing part of the frequency spectrum, it applies a gain, so you can attenuate or increase a specific range of frequencies.

Don't know if useful... What do you think @Dirty ?

What input should we use? Pedals or accelerations?
In my opinion it should be accelerations, that's what we feel in reality.

The problem here is that you don't want to feel "decelerations", but they are there.
Let me think how we can do it.

The goal is to still use the longitudinal acceleration input but differently.

Yes I want to feel actual decelerations i.e. acceleration getting away from 0 on the negative side. I however do not believe we should feel "inertially speaking" the decrease of acceleration in absolute value.

If you get pushed strongly in the back you strongly feel the push, but not really the stop of it. Then you just continue your standard move and conversely feel if you hit a wall i.e. the actual negative acceleration...

Happy to get other people's views but it really feels weird when I get a kick forward after releasing the brake pedal or conversely get a kick backward as soon as I release the throttle.

Thanks
Alex

I am not sure if I understand well the problematic but why you don’t use the accel in non symmetric way ?

If you judge the accel or decel kick is to strong on one side, just filter or skip it.

Edit:
It might be “crop” filter could help you.
You can adjust the direction you want