FlyPT Mover

Hello, I would like to ask,
where is the communication protocol of simtool and the communication protocol of your fly?
Because I want to write a program controlled by stm32 and share it.

Yes sorry. I will continue overthere.

First of all:
this is an absolute genius project. I'm in love with the Mover.

Secondly as it came up in a conversation recently:
Is there currently a way to do something like "gear change smoothing"? If we mix in surge with pitch (or probably high surge values in general) it tends to make gear changes very harsh.

Is there anything I could use/add to intercept a gear change event and add something like a spike filter on surge for a small period of time?

I thought about using the "Basic DOF from Value" pose but that actually delivers the gear number and is not a gear change event - I'd probably have to add a custom input module detecting the gear change from telemetry and use that to add a SPIKE filter when the value becomes "1", not sure on how to do that though.

Am I on the right track here?

Apart from that: if I add a second pose for that surge spike filter - would it even be possible to apply a spike filter in that fashion on a DOF that primarily gets fed from another pose?

Hi,
The idea of using the dof from value might be the best.
Use the gear value in a surge value.
Maybe a high pass filter to get the gear change. You can also use some gain.
something like:

EMAHP(GAIN(VALUE;100);100)

I did not test, so not sure of the results.
That's something we have talked some time ago, but honestlly I don't remember what we have done.
Using the EMAHP gives you two directions, on increase and on decrease.

Wait...
On high gears, the effect should be to high and we want the opposite, big effect in low gears.
Try something like:

EMAHP(GAIN(DIF(VALUE);100);100)

The DIF gives you the variation of value, bigger the gain, more effect.
To have lower effect on high gears, maybe subtract:

EMAHP(GAIN(SUB(10;VALUE);100);100)

So in 6th gear effect is 4, in 3rd gear is 7....
With the above filter, the high pass is made on 400 for 6th gear, 500 for 5th... so on till 900 for 1'st
But all in the same direction... damm, put the DIF again to get negatives and multiply with everything...

MUL(DIF(VALUE);EMAHP(GAIN(SUB(10;VALUE);100);100))

Since DIF is to sudden, put a low pass to delay:

MUL(DIF(EMALP(VALUE;200);........

The values in the high, low pass and gain need adjustments, but might give some effect.
New version of mover as IF and it will make this easier to achieve.

IF(DIF(VALUE);>;0;1;-1)... More soon

? Sorry, but I don't understand.

In Mover you can adjust the protocol to your needs. But give me more info on what you want to help.

I was actually thinking about wrapping/engaging a SPIKE filter on the surge axis.

My first instinct was to create a pose that just counters the surge effect (doing surge in the opposite direction) but then I just saw the SPIKE filter being available at page 1 today.

And I think that would be all we need - "if gear change, then wrap a spike filter around surge output with XX ms". Not sure if that can be done with today's version though. Am I thinking too small here?

PS: thank you for your in depth reply. Will try your suggestion tomorrow, sounds promising!

I saw that in the PC Mover, the protocol was sent in clear text through serial port.
Excuse me, what language and tools are used to compile your PC Mover, and do you need the support of. NET running package? Because I have a problem, every time I open the software, it is very slow, and when I drag every small window after opening it, it will get stuck and not smooth.

just build a Filter that creates a equal gain pulse for gear change only when engaging. But consider the gear change jerk is already included in the longitudinal acceleration.
This could be nice for an additional tactile transducer effect but could not map a pose module to a transducer.

My goal would actually be the opposite - gear changes can be too harsh when running high surge values, so I'd like to negate/limit the surge effect when changing gears.

I also have an actual "issue" that I can't seem to solve:
Thanos AMC Controller + Spike Filter+ FlyPT Mover.

Not sure if it's me but they seem broken. The values seem to read correctly from the controller in the Thanos Module but when I enable the spike filter I think that "scaling" value is ignored and it sets the spike filter to 127 instead of 127*15 (=1905).

Running latest AMC firmware.

I have to review the Thanos output.
Latest firmware updates might have changed something.

you can create 2 pose modules simultaneously, e.g. a high gain for surge (long.acc) and a low gain for gear change and map it together in rig module.

That is what I got in Thanos' Discord:

...

<@557254629122113536> there has been changes in the AMC-AASD15A firmware since last release of FlyPT mover, to add separate spike filter for TL or horizontal actuators, so its reading and writing wrong registers. I talked to <name removed> about it and he promised to update it in the next release, whenever that might be.

...

Yes, it uses .net 4.xxx (latest one)
Next version is .net core 7

How many modules did you open?
The idea is to reduce the amount of modules to the essential. I saw some people making setups for multiple sources at the same time making it slow.
Calculation should keep a good rate, but the UI suffers.

All this is going to change in Mover 4 that uses a different UI, but it will take more time. I need to conclude what is going to be 3.7 with the current UI model, but upgraded.

Not sure you saw the videos of 4, let me show again:





Runs easilly at 144 hz on my laptop.

Version 4 is taking to much time, it needs grouping or it's a spaghetti mess... (grouping modules)
Most of the 3.7 code is compatible on 4.0 right now

3.7? Did I miss something? (3.6 I mean?) Latest I can find is 3.5.3, are there any more recent builds that can be found?

@bberger 3.6 is something I did not release. The amount of changes generated nasty bugs.
So 3.7 is almost from scratch, going module by module and changing everything to latest versions instead of a big mix of ideas

Work going on, still to many things to do:



Looks similar, but many changes inside, and yes I addes the GT's

Looking strong! Can't wait for it FlyPT is an absolute monster of a powertool.

Is there a way to have the sources set up in a way to detect different vehicles and adjust the COR accordingly?

Not even sure it makes sense for vehicles but with the small frame of <2m width and typically <4m length it feels different when in a single seater vs 2 seater with left or right side steering, especially when going over curbs and stuff. Opposed to what's mentioned in the manual I do strongly feel differences (positively) for small vehicles and not just big airline carriers. Especially when going over a rough curb on the side you're sitting vs opposed to it.

I'd love to have car specific stuff auto-applied in for example iRacing. I'm not a fan of car-specific profiles but a few things make sense like width and length for the suspension module or COR in different types of vehicles like listed above.

I don't know of any game right now, that sends the info about the wheelbase, COG or where it measures the accelerations...
Only some flight sims give you pilot position relative to COG (usually from where comes the acceleration data).
Maybe some say wich car but then we need a database of cars...
I think iRacing sends the car, I will look at it and see if I can put that data in the variables received and use those in the wheelbase... and other values through a datatable. This is now easy to implement on the new structure, problem is getting the data.

I already looked at COG for iRacing some time ago when I added this to some flight sims, and to get it, only way is with this: https://www.iracing.com/commodores-garage-3-centers-of-mass/
And I think we don't get the corners wheight in the data...

Excuse me,
will your fly software be used for free in the future?
Or will it be charged later?
Is your code open source now?
I like this software very much.

I would encourage people to donate to flypt, if they can, irrespective of the answer, given it is a brilliant piece of software and to help defray the time and cost for flypt, which is probably a drop in the ocean of what effort he has put into this