FlyPT Mover

This and allowing rotations in axis that don't cross at the same location (well hope it's understandable what I mean).
In previous versions I had the option to use translation in world or local coordinates. I removed it.
Now I could add the option for each translation.
Let's see what comes in 3.0

I am afraid your assumption is wrong. Actually we use the “coordination tilt” because your brain can’t make a difference whether you are accelerating or being tilted. The vertical motion from tilt/bank state takes the LOCAL vector. That means that the translations are dependent on rotations and not WORLD coordinated. Even if it looks counter intuitive, I believe that’s the most correct way to get the forces “right”

Best.

Just a note to say I was experimenting with writing my own motion for a cool space sim(game) "reentry" which dosen't have any physics output yet. I noticed that new files exported from phyphox (comma, decimal) no longer load in Mover player. The .MoverRec format doesn't appear to be ascii readable, any pointers for writing a csv or getting phyphox files to load would be much appreciated

Phyphox files should load correctly, unless there's some change in PhyPhox I'm not aware.
MoverRec is binary to use less space, it's more versatile compared to Phyphox, but it might change in the future
If you want to use the MoverRec format, here's an explanation of it's format:

Code:

MoverRec format:
8 bytes for a Int64 specifying the number of frames
1 byte for the number of sources recorded (usually 1, 2 in some fight simulators)
1 byte for the number of values in each frame (n)
n bytes with the index of the values recorded (see list of values bellow)
4 bytes with a float specifyint the frame rate (time between each frame in ms)
1 byte with 0 for low resolution timer and 1 for high precision
2 byte Int16 with the indes where the frames start on this file
s bytes with any string we want (description, autor...)
f bytes with the frames info, see bellow

Each frame is stored this way (if we have two sources):
4 bytes with a float storing the frame time (frame zero as time zero)
4 bytes with float for value 1 of source 1
4 bytes with float for value 1 of source 2
4 bytes with float for value 2 of source 1
4 bytes with float for value 2 of source 2
4 bytes with float for value 3 of source 1
4 bytes with float for value 3 of source 2
.
.
.

So f size is going to be:
4(float) * number of values recorded * number of frames recorded + 4(float to store frame time)

Index of values:
01 Lateral position
02 Lateral speed
03 Lateral acceleration
04 Lateral acc. with gravity
05 Lateral gravity
06 Longitudinal position
07 Longitudinal speed
08 Longitudinal acceleration
09 Longitudinal acc. with gravity
10 Longitudinal gravity
11 Vertical position
12 Vertical speed
13 Vertical acceleration
14 Vertical acc. with gravity
15 Vertical gravity
16 Yaw position
17 Yaw speed
18 Yaw acceleration
19 Roll position
20 Roll speed
21 Roll acceleration
22 Pitch position
23 Pitch speed
24 Pitch acceleration
25 Front left suspension position
26 Front left suspension speed
27 Front left suspension acceleration
28 Front right suspension position
29 Front right suspension speed
30 Front right suspension acceleration
31 Rear left suspension position
32 Rear left suspension speed
33 Rear left suspension acceleration
34 Rear right suspension position
35 Rear right suspension speed
36 Rear right suspension acceleration
37 Clutch
38  Brake
39 Throttle
40 Steering
41 Gear
42 Engine torque
43 RPM
44 Speed
45 Stall
46 Flaps
47 Landing gear
48 Speed brakes
49 Canopy
50 Wind
51 SimTools Axis1a
52 SimTools Axis2a
53 SimTools Axis3a
54 SimTools Axis4a
55 SimTools Axis5a
56 SimTools Axis6a
57 SimTools Axis1b
58 SimTools Axis2b
59 SimTools Axis3b
60 SimTools Axis4b
61 SimTools Axis5b
62 SimTools Axis6b
63 Front left surface
64 Front right surface
65 Rear left surface
66 Rear right surface

You're right, for tilt coordination the order is correct as it is now, so it was a bad example. And I generally agree that the forces should be applied after the rotation. But, as I said, there are other scenarios where changing the order would be useful, e.g. I'd like to use the "vertical position" value for my up/down movement (I'm intentionally not saying "heave" here because "vertical position" will be in world coordinates, not local). Also I'd generally like to have the option in order to be able to experiment, even if it would be theoretically right or not, just to see what you get.

Good to hear 3.0 is still in the works. Thought you might have jumped straight to 4.0

I made a post regarding motion and feeling grip under/oversteer. Id love to hear your input on this and what for example mover could do. Spesificly regarding the tire slip ive mentioned earlier.

https://www.xsimulator.net/communit...he-feeling-og-grip-dual-actuator-motor.14973/

Cheers!

I will look at your post, but for 4.0, we are going to have way more telemetry info, including tire slip and other parameters.

Hi all!
Today I bought x plane and its running so far in VR and with the mover interface , but I didnt find any mover setting file for xplane. My assetto corsa setting feels strange with planes . So anybody out there who would share a xplane 6DOF setting with me?
Thanks a lot!!

Who want interface program for war thunder telemetry? I made rotataed hexapod and selfmaded software for it. Writed on Delphi.

Every game I know outputs local forces. „body accelerations“ is what you need.

if you want to experiment, you can try previous versions of mover where „world“ option was present.

But "vertical position" is not a force, it's a world position

I’ve never heard about vertical position being used in motion cueing.

Usually we deal with with 3 translational (linear) accelerations in m/s^2 and 3 rotational speeds in rad/s or deg/s.

When the rotational speeds are not available, we take the angular positions in deg filtered with a high pass.

Why not? If you had unlimited range, that's what you'd use (world position) because that's the real position. If you have that right, you wouldn't need to think about forces, would be automatically right. So if you have a platform with 50cm vertical range you may well use directly absolute vertical position, on an almost flat racetrack the real position range wouldn't be bigger, for tracks with elevation change you could use highpass filtering

Will the next version also contain documentation for custom actuator definition?

I have a dofreality 2dof platform. It does pitch and roll. The two actuators are mounted in a triangle, where one end is the center of rotation. It sits below the seat. This means pitch=average of the two actuators and roll=differential between actuators. Since the actuators are rotary motors with a crank, possibly a sine translation from rotation to movement needs to happen, but I am not sure yet whether that is done in firmware or not.

I would be very happy to provide geometry and to research the protocol to help you make it into a standard preset. The dofreality 3dof is very similar, it uses an extra motor to pivot the whole 2dof platform to add sway.

Right now, I am struggling with the actuator definition, not really sure how to add correct geometry to the custom actuators. I guess some mixing needs to happen somehwere to translate roll and pitch into this triangle geometry.

Hi,
get the measures in a photo and I can setup the rig to use in Mover.
Tell me also what model are you using (M2, H2, P2?)
You can use custom actuators, but only with linear actuators for now.
To setup rotating ones, I have to make it in code right now.

Just added some rig variants yesterday:


I'm still working on 3.0 and at the same time in the future 4.0 that will be way different.
Still have some things I want to add and test in 3.0.
But 4.0 is going to include all I have in current versions with more customisation.

By the way, seems the last windows update (2004) is causing problems with serial in some hardware, so, please be aware of that if anyone notices the rig moving erratically or in low resolution.

« If » well.. I am afraid you are always limiting your variable through scaling in order to fit your physical range. Data elevation would force you to adapt the scaling not only to different vehicles but also accordingly to every track, that would be pain in the neck.

I really don’t understand what would be the benefit of using linear position over linear acceleration.

@hexpod is right, I'm even considering removing linear positions in the 4.0 version.
What I understood of your post is that you want to separate the "mix" in roll and pitch and apply the vertical only in the pure roll and pitch.
But even that, I don't think it's a good idea, because the vertical motion/acceleration should be vertical relatively to the user or we are inducing a wrong cue when using the mix to get constant accelerations.

I am using the H2. I think that in the P2, the only geometrical difference is the slightly longer crank arm.

My measurements for the H2:
Crank arm: 65mm
Linkage: 123mm
Actuator distance: 460mm
Actuator centerline distance from pivot: 370mm
The crank arm moves 38 degrees up and down, so total range is 76 degrees.

The platform uses an Arduino with SMC3 command set, hope that helps.

I am looking forward to 4.0, stringing things up like in node should make this super powerful.