FlyPT Mover 3.7

Maybe it's a bit early to ask for this kind of improvement, but it doesn't hurt to try.
It would be nice if, in the 'Motion Algorithm/Follow Pretended Pose Even If Out of Range' section, in addition to the 'Pre-Follow' parameter, there was also another parameter to choose when the deceleration curve starts, in order to minimize actuator stroke loss. This would be similar to the 'Param 2' in the 'Logistic 3' function.
Essentially, the goal is to allow control over whether the deceleration is smooth or abrupt.

this message appears when dcs source is connected topose from motion. should be easy to reproduce

actually whatever the source is added this error appears in this constellation

now its appears when I add the output. Its normal we have the path C/users/pedro in the error window?

Let me solve the main bugs first

I'm ok for that !!!!!!
I dream of making one because flypt mover knows how to manage this type of information to send in my opinion! 100% and it would be an incredible plus for flypt mover to manage FFBs in general!

I also want to help with the bugs, but I have a 2Dofs platform, and you still haven't added it to the possible Rigs........ as soon as you do it I'll test!!!

Good luck guys, what you're doing is awesome!!!

Will try for the next build.
Just solved the audio problem with iracing. Was faster than what i expected.

Maybe temporarily you can choose 3dof rig. Select 3 feet, 2 at back, one at front in your rig. Use actuator 2 and 3 in your output.

Can’t save parameters now.

Can you set the lever position in the last build or
there is something fishy?

Ignore the default position. It's not storing and I might remove it or keep it just for single actuators. Not sure yet.
But the park position should store... Did not change anything there. Just corrected a bug in rotations that might be causing that one (actuators are defined with a direction/rotation)
I will look at it right now

For you (and me !),
I found this link for stepper motor coding, in my opinion not too complicated to adapt to direct it by fly....



Good day !
and sorry for the digression on the forum topic.....

If your plan is to calculate the best possible starting position according to the geometry, we have to know how much degrees above the horizontal position it has to be in order to set this value in the hardware

If the default position is for ex. 13 deg. above the horizontal pos. I have to calibrate the sensors to get there. Parking pos. Was calculated from the default” pos. I think. It was good

@hexpod ,

Parked is for the actuator disconnected and is related to the outputs. When disconnecting outputs, actuators are moved to park. This one stays. Just like old Mover.

Default position was introduced thinking on direct actuators. The idea was to set the position where the actuator stays without data (moves around that value). But in reality it's of no use. You can set it in the vars if needed (see ahead).

In rigs like hexapods I calculate the minimum and maximum heave and use as default the actuator position to reach the middle heave wich is not the middle of the actuator. So this is kind of the default position already.
In all rigs, including the ones with just the actuator, they are positioned for poses and as such the default position is useless since the default actuator position is going to be the the one needed to achieve the default pose.
This happens with your rig. You can set 0º in the actuator to be the crank horizontal, but the default pose generates something like 20º.
To set the default position as zero, you need to increase the pitch of the crank to match the default position.
This all depends on what the rig has defined in the hardware. Is 0º horizontal?

Where the default position could have use is in directs where we don't have a default pose. We have a default position, but we can deal with that using the operations/filters of the directs.
Example, a fan default would be zero, same as minimum. Default is not the middle of the "actuator".

Note on rotating actuators:
They are defined by setting the orientation of the crank (yaw,pitch,roll). That orientation is used as 0º by Mover.

Honestlly I have still doubts in using it in directs, that's why I keep it there until I decide.
It shows in all situations, because the actuators window is a generic for all and I still have to deal with that.

Now the park bug is becoming a nightmare.... It's correctlly stored in the setup file, but somewhere it changes.

“This happens with your rig. You can set 0º in the actuator to be the crank horizontal, but the default pose generates something like 20º.”

I believe I need an exact value x.x deg. for lever-arm pitch to calibrate my 360 deg feedback sensors. Where can I find this?

“Now the park bug is becoming a nightmare.... It's correctlly stored in the setup file, but somewhere it changes.”

Yes, I noticed it.

@pmvcda Ok, I think I understood you. So first you don’t set the park position and you calibrate the lever-arms to horizontal position, than you set the parking position (which is not working properly yet). So in theory we don’t need an extra offset to be displayed to the user.

In the meanwhile I was able to save some vehicle presets (I think we don’t need a video for this as it’s pretty intuitive) which is an absolute game changer. Thank you for this feature!


Edit:
Function „auto load” doesn’t seem to work (switch automatically) while changing the vehicle in IL2 but it’s already a tremendous step in the right direction

Sorry, been a complicated day...
Yes the auto load has some problems. Made some changes to make it lighter, but caused damage... Need to look at it again.
This can become a bit confusing with the auto load and asking to save setups....

I've done some more research on FFB yokes and seem to also use trim data, so whenever you have a moment, please add
AILERON TRIM
AILERON TRIM PCT
ELEVATOR TRIM POSITION
ELEVATOR TRIM PCT
Thanks! (low priority)