FlyPT Mover 3.7

Some rigs (odrive) receive the number of turns as a position.
For example 1 turn can be 1mm
Also we need to set where is turn zero in the actuator position (min/max)

Edit: instead of mm it can be degrees

Clever. I missed that. Sorry.

Just a nasty question in between. Could we think (on the long range) if we could use Mover as telemetry source for FFB Rhino Joystick (two dof rig;-)) instead of TelemFFB Software. Maybe @smitty would be interested as well. Walmis, the designer of the Joy and various DIY kits, is doing a pretty impressive python coding with his telemetry extraction code https://github.com/walmis/VPforce-TelemFFB (I especially love automatic aircraft recognition and corresponding preset) but it would be a nice challenge to bypass it and be able to feed the stick directly from mover. @smitty , Bad idea?

Could someone post some examples of what to put into the filter fields to access different sources? I'm trying to get the Loop and noise <S0> recognised by and connected to eg a pose from filters block.

S0.LAT_A

Where S0 is the key of a source
LAT_A is the lateral acceleration of the source
I need to do a reference

Another one:
P2.SWAY

Where
P2 is the pose with key P2
and swayis the calculated sway

We can try. Can you give me some references to get more info.

Edit, just ignore me, you posted a link already

Is this the correct way to set COR? See pic, red dot is head location.

In MC, head location I put measure from COR to real head location?

With these in OXRMC config file I put zero to COR values?

I have rig where seat is below the top joints of rig.

Edit.

And in the RIG module COR values dont align with Sway, Surge and Heave

I advise one empirical solution :
Whatever you choose as center of rotation of the platform, set up slow rotational loops in Mover, start with yaw and once on the platform, move OXRMC indicator in the HMD until you find a position where it will be steady. Doing so you should find the correct spot for vertical axis IMO. Similarly you can proceed for the two others.

That is how I have set OXRMC before.

In Flypt VR MC, head location overrule OXRMC COR values? Or how to use these values?

The default COR (0,0,0) of the rig is the center of the top platform (hexapods).
The head distance to the COR can be:
x=0mm, head lateraly aligned with the center of the top platform
y=-70mm, head 70mm behind center of top platform
z=+350mm, head 350 mm above top platform

If the game physics are relative to the COG (center of gravity) of the vehicle and you know (can estimate) the head position in the vehicle relative to the COG then you might have a distance like (example of a car with driver on the left):
x=-300mm, the head is 300 to the left of the COG
y=-100mmm , the head is 100mm behind the COG
z=+600mm, the head is 600mm above the COG

To get the COR correction relative to the COG:
x=300-0=300mm
y=-100-(-70)=-30mm
z=600-300=300mm

This is good for small distances like cars, not for planes where you should use the correction in the pose.
With this, you don't need to adjust the head in the VR compensation module.

If you have an hexapod, then let's be real and simulate the position of the driver. You can't do it in other rigs where the COR is on the floor like the 4 actuators rigs. There you can make the corrections, but since there's no sway or surge, you always get those false cues.

So what is head correction in the VR compensation output?
Well for you, to fine tune the VR compensation.
Or if you want it simple, put there the head distance to the center of the top platform and ignore corrections of physics relative to COG.
For 3DOF rigs, you can just set the head position relative to the center of the 4 actuators at floor height. This corrects the rig motion for the head position.

Now, this needs testing to be sure I got it right on this release.
I have to connect the headset and be ready for some nauseas...

Instead of Mover you can use the ones in OXRMC. Not both.

Did a quick test for gt sports but not successful. But Im glad that you've tried something. Very much appreciated and thank you.

Me too. I have recently purchased a heli cyclic stick that has no real force feedback, yet. It just has stepper motors that can slowly move the trim for the centering spring of each axis. Adjusting the trim position is currently handled internally in MobiFlight and the Arduino, e.g. pressing the hat switch on the stick directly generates step pulses to the motors. There is no possibility to connect that to telemetry data from the sim software.

If I make my own controller that accepts input via UDP or VCP/USB serial com that would be already possible by simply adding a second output in FlyPT Mover, I think. I have no time for experiments at the moment because I need to get the basic things running, first. But I plan to replace the steppers with servos, later. Also for the rudder/tailrotor pedals I'll add a servo.

How does the Rhino Joystick or any other FFB wheel handle the feedback input? Is this just a bit field in the HID USB report structure? It would be cool if FlyPT mover would also support this kind of output. I think it should be no big problem with the math functions of Mover to add manual trim input and flight data (speed and orientation dependant) together for realistic FFB.

I think they take what the FFB protocol sends (this is just my assumption). I find impossible, for example, to use a custom user-defined curve for the airspeed/spring-force coefficient. Although the Rhino software is very well done (the complexity of the telemetry code is beyond my competence) with interesting advanced features (some more fancy than useful), I have been told that they have some limitations in DCS and Il2 to meet my request (they have to stick to what FFB sends, but I cannot comprehend the exact reason). I think few variables would be needed next to what we already have in Mover in order to have a complete, fully customisable solution.

Edit: …. As well for joysticks as also for DIY FFB wheels.

I recently designed a pancake heavy duty joy gimbal to fit Walmis NEMA 34 proprietary servos (which have a nice anti cogging build in feature) and clever logic board (which accepts various grips) which is part of his DIY kit combo.

Please, can you do a test?

Start gt first, go on a race and only then start mover and connect the source.
For me gt7 works but with a problem related to connecting before gt opens

Please test with both versions, but should work on the first one 3.7.0.0, not 3.7.0.1

Tried your method a couple of time with GTSports without success.
I used both 3.7.0.0 and 3.7.0.1. In the source sections it's stays yellow.

@hexpod and @Aerosmith ,

I'm interested in this (ffb), let me collect some info (hid and that stiff)

Warning, the SPIKE filter's parameter order has been changed! The last two parameters are swapped. Is this intentional?

Well, since I was the one who made the recent UI in TelemFFB, i dont think its a good idea to route it thru mover. For DCS and ILS, the in-game FFB is used directly, and additional events are added on it. And for MSFS/Xplane, its required that TelemFFB be the source for joystick input (not set up in game) so that it can adjust for trim and autopilot motion without sending the fact that the stick is moving back to the game.

Please keep these completely separate! It will make things unnecessarily complex.