FlyPT Mover

You should see values.
But you are showing the window for air.
If your plane is in the ground, only the ground window is updated.

The 17, is strange... But you have to check the values I said above.

Small update. Ignore the post above.
Ok, everything goes in to the “ground” window but 0 everywhere in the “air” window

Got it thanks

Brilliant. I am going to like it !

It opens endless possibilities... bravo

FlyPT Movers 2.1

New version in the first post.

- Corrected Assetto Corsa source (for AC and ACC)
- Corrected some directions in other sources
- Corrected small bug when disconnected from a source

So you can use different filters (poses) for each source and add them in the rig:


Or just join them in one filter (pose) and use that pose in the rig:

Thx for clarifications !

Clever.

I would like to talk about additional data and one issue in xplane

Issues first:

Issue Nr. 1 is a back longitudinal kick at the very end stop. It concerns the ground speed below 2.1kt. It produces a huge sharp corner (up to 0.5, - 0.8G) when the braking force is above 0.1




I talked with A. About this problem and he advised to apply a LPF on those.

Maybe in the future it will get corrected but I am afraid it will take ages.

There is also some lateral spikes at very low speeds which would need to be filtered or skipped.

We want the longitudinal and side accels to be filtered or skipped only in particular conditions in order not to destroy the overall ground behavior.

Concerning the additional data for effects I experience that the:

1. Stall shakes construction
2. Motor vibrations
3. Engine torque effect for single engine planes (on roll)

.... giving me a much needed addition for an overall immersion.

Do you have a will to get into those details?

Best

For a better control of the brakes I advise a custom curve as natively, from at least a half of pedal course a full braking force is applied. (For Austin this is a realistic behavior.)

The spike...
Does this happens in all situations under that speed and braking force?
If so, it might be possible to ignore the spike in the source. I can try to see if I achieve that effect.

For the extra inputs. I can add them.
Engine torque is #36 right?
And the others? (including brake pressure)

How do you know yo are in stall?

Sorry, but I'm a bit noob here. Although I like air planes and made RC ones years ago...

Sipkes first maybe. This should give you a better idea about what I have in mind:



It happens mostly with a braking force above 0.1 and affects the ground speed up to 15-20 kt

It’s pain in the ass because we need a coherent behavior especially the longitudinal one also at low speed.

I would try

- a “triple order EMA LPF” on side acceleration below 20kt only if brakes are applied greater than 0.1

- a “triple order EMA LPF” on longitudinal acceleration below 5kt only if brakes are applied greater that 0.1

Do you have a better idea ?

Best

Under “warnings” you have a variable going from 0 to 1 ( 1 is a complete stall )

I was clearly told that in Cessna, not only the controls but the entire plane is shaking.

You could build up a sine with a fast period / very low amplitude just after it starts (let’s say from 0,3 stall variables at 20Hz ) and increasing the amplitude and decreasing the period as it reaches a full stall. (At 5Hz for ex.)

When I get a chance I will mesure it with phyphox in Cessna until now real pilots like @Dirty could maybe share their experience.


EDIT:

The sine for RPM could start at 30hz at ilde with higher amplitude and increasing the Hz rate as RPM goes up

Btw. The RPM code left by @yobuddy has made many users happy

For RPM we have already a pose calculation:

Add -> Pose -> From Motor

I didn't test it much.
Give it try and see if we need anything more.

Don't forget to add it to the rig:

ok so far i have the rig moving just 2 questions (I'm using simtools)

- I have 30% CPU usage with the base settings 2ms and high resolution, is it normal ?
I have yet to make the rig move with a game, so I have no filtering for the moment ..

- in the pose section => in gain / flip I had to set YAW ROLL PITCH to 0.055 to match the data comming from simtool which seems to be plus or minus 180, is it correct ?

Thanks for you huge work ..

I'm on my phone, so I can't see the SimTools part.
The load is normal for the default options.
Go to the menu and click options.
Uncheck the top left checkbox and see what load you get.

Yep down to arround 10%

I don't know what type of interface you are using, but if you are updating serial at 10 ms, then you can increase the calculation loop time from 2 to 10.
This should lower the CPU load.
But when sharing/comparing filters, this should be referred, because it affects the filters behaviour.

In the outputs, the time specified is always a multiple of the calculation time.
The lowest load is always a relation of 1:1


Edit:
Can't start SimTools?!
Don't know what has happened. Anyone with the same problem?
Made the last Win 10 update and it doesn't start any of the SimTools programs.

Edit#2: Solved, it was the windows antivirus...

Related to SimTools:

Don't forget that data coming from games is affected by the tuning center.

You are correct in relation to -180 to 180.
Why are you using that value in gain/flip? To limit the input to your range?
You don't have to. The range is the limit you want in the rig.
You should use some kind of filtering to fit the -180/180 inside your range.
OK, the simplest one is using gain, but you could use other types of filtering with return to zero to optimize the your ranges.
Also notice there are two gains/flips, one on the input and another on the output. This was just to simplify the use of the interface and have a fast way of limiting values instead of messing inside the filter control.
The sliders min/max are related to the range you define, not the input values.



Just as reference to others, this is the way I setup both programs: (image is a composition of 3 images)



In FlyPT Mover:


With this I get a relation of 1:1.
Simtools gives a range from -180 to 180.
In FlyPT Mover, I have the range defined to 10, so it limits output to -10 to 10.
Since the slider is limited to -10/10, it's red because input is larger than 10 (it's 63.734 in the image).
Also in the right, we have the value red, because the result is out of range.
On the lower left are the values sent to the rig. We can see that Roll is 10. That's the range we defined.

Now I could add a filter to limit it to the range like: (Changed from roll to sway because of scale in the graphic. It's easier to visualize the effects)


Just try.
See the graphic? Grey is the input, green the result.
It makes the rig return slowly to zero but also represents the inputs you receive.
Even so it could go out of range.

We could also use a logistic filter:


This is limiting range to 50.
The factor is how "fast" it reaches limit.
It's an exponential. Far from limit, the behaviour is almost 1:1, while as value reaches limit, it's compressed to fit the limit.
Basic explanation...

In the graphic, we can see the behaviour is retained, but inside the limit.
Kind of a gain but exponential with a limit.




It's a bit complicated to explain. Sorry.
I'm trying to make a manual. Hope it helps when it's done.

Ok did my first test, so far it seems promising

I use simtool and my test was with dirt rally (it tried direct source dirt rally but nothing)

I send traction loss in axis4 (instead of yaw)

I've setup as seen on the pic included

The simtool tuning center value were left untouched

My rig gain was 0.5

EDIT : i just saw your reply, i'm gonna read it