Understanding the "Center Of Rotation" (COR)

There have been several attempts to figure out the exact meaning of "Center Of Rotation" (COR) in FlyPT Mover, as in
COR on FlyPT mover and
setting up mover profile first time for 6 dof hexapod
and maybe somewhere buried in the 180+ pages long
FlyPT Mover
thread. Since I am currently configuring Mover for my motion rig, I want to make sure I fully understand all the COR related settings.

1. The Hardware COR

Let's assume we have a 6-DOF hexapod with linear actuators (of course the following applies to any other type of rig accordingly):

With all actuators extended at 50% (i.e. the platform is in its "neutral" position), the COR of the platform is at the point marked with a red dot in the above image. If there is only movement around the pitch, roll or yaw axis, this point will not move relative to the ground. The actual location of this point is defined by the physical measurements of the rig (L1, L2, L3, L4, Middle and Range) and needs no further parameters. I'll call it the "Hardware COR" or "H-COR".

2. The Vehicle COR

As described on FlyPT Mover's page Center of rotation, a simulated vehicle (be it a car, aircraft or whatever) has a "Center of gravity" (CG), and the rotational motion data (pitch, roll, yaw) is given relative to that CG (which makes it the "Vehicle COR" or "V-COR"):

While FlyPT Mover has three places in which this offset can be defined, the only one that really makes sense is the one in the source module:

There is no documentation regarding the sign of these three values, so I can only guess that "forward", "right" and "up" are the positive directions. The above page says that these numbers "define the position of the pilot". However, it doesn't say which part of the pilot. Is it the head, the center of gravity, the seat, the floor? Of course the (center of the) head would make the most sense, since motion simulation is all about stimulating the vestibular organs of the inner ears.

3. The Pilot's Position

So in 2. we learned that the correct setting of the V-COR is important to get realistic motion cues. Now let's go back to 1. and consider an actual pilot (or driver) sitting on the motion rig. Depending on the construction of the rig, the H-COR can be at the floor of the virtual cabin (if the seat is mounted on top of the moving platform), or somewhere around the level of the seating area (if the seat is mounted in a "cradle", as is the case in many home motion rigs, due to height limitations). And depending on the position of the seat in surge direction, the H-COR can be in front of the pilot's head, behind it or dead center. While the pilot's position relative to the H-COR is small compared the the V-COR of an airliner (which can be in the range of tens of meters), it is my understanding that it does matter a lot when it comes to getting realistic motion cues. Imagine the platform making a pitch up movement: the further away from the H-COR the pilot's head is in heave direction, the more it will move backwards, and thus more negative surge will be added to the positive pitch. To illustrate this even more, consider the (theoretical) case where the whole cabin is mounted below the H-COR (like if the rig is mounted to the ceiling of the room). In that case a positive pitch would even add a positive surge. Now consider a movement around the yaw axis: depending on whether the pilot's head is in front of or behind the H-COR, the movement will be perceived as either clockwise or counterclockwise, which makes a huge difference.

4. Motion Compensation

When using a VR headset, motion compensation is important to keep the visual sensations coordinated with the motion cues. Interestingly here the position of the head relative to the H-COR is very important, which is quite obvious for the same reasons described in 3.

5. Conclusion

It would appear that the same offset (of the pilot's head from the H-COR) that is important for motion compensation should also be taken into account when generating motion cues. However, no such setting exists in FlyPT Mover (or at least I could not find it).
@pmvcda can you please shed some light on this?

@Klaus Schmidinger ,

My fault for not explaining it well.

So most of it is correct. Let me point the following:

#1 Directions
sway direction is positive to the right (X in Mover)
surge direction positive forward (Y in Mover)
heave direction positive up (Z in Mover)

#2 COR/COG
The center of rotation and the center of gravity can be different, but most of the time we don't have enough info to know about that.
In my opinion, most of the physics calculations are made for the COG. So I should have named them COG everywhere.
In the rig, I like to call it COR, it's the point around which the rotations are done.

#3 Correction in sources
When correcting in the source what happens is that Mover corrects the calculations for the position you set.
Imagine a plane where you sit 20 meters in front of the COG, you need to put 20 in the surge field.
The calculations correct the linear and rotational accelerations and speeds for that position.
A good example is that turning that plane in the track would introduce some sway accelerations that you wouldn't feel if located in the COG.
This has nothing to do with the rig COR (I like to call it COR in the rig).
What we have now, before the pose, are corrected values.
Note: Some sources miss values needed to do the correction, that's why the correction is not available in all the sources.

#4 Correction in the rig
So the rig is making rotations. We can say around wich point it makes those rotations.
In hexapods, we can set the point anywhere, and by default, it's the center of the moving platform, but in rigs with feet, the rotation is made on the floor plane. You can change sway and surge positions with effect in pitch and roll, but not in heave.
To correct in heave the feets would need to slide on the floor. Those limitations apply to other rigs in diferent ways.
Sometimes I say we can make the correction we do in the source inside the rig module but only for short distances (maybe 50 cm maximum). That's what happens with cars, where, for example the COG is in the middle of the car, and you sit on the left or right.

#5 Correction in the pose
Here the objective is different. I added this because some people want "strange" behaviors.
Example:
Traction loss is a good example. Many people want the rotation to happen around an axis located way ahead of the seat. Here you can set that COR just for yaw without changing the COR for pitch and roll.
So you correct the output to have some sway besides yaw when putting the COR to the front.

#6 VR
In the 3.5.3 version, you can't do much, but you can adjust the values in the rig to make the experience better.
I took into account that the software making the correction would ask for your head location relative to the COR. That's where we should make it. But for the next release, I have that correction incorporated in Mover as well (in the VR output module).

Thanks for the clarification.

I fully agree.

I understand that. What I'm wondering is from what point in the cockpit do you measure the distance to the aircraft's COG? Is it the center of the pilot's head? Or the floor of the cabin? Or somewhere in between?

Let's keep it simple and stick to hexapods with the COR at the center of the moving platform ;-).

I'm mainly interested in a most realistic simulation, so "strange" behavior is not a requirement for me ;-).

That's great news! Looking forward to the next version!

@Klaus Schmidinger ,

The position you set there will match the COR of the rig.
So, if in the rig the COR is the floor of the cabin, then try to set the correction in the source for the floor of the cabin.
If the COR of the rig is your head, set the value in the source to be the head of the pilot. That way you have VR corrected also.

OK. Now there's a checkbox "Use XPlane pilot position" in the "SOURCE::XPLANE 11" window. Obviously XPLANE 11 knows nothing about the actual construction of the simulation platform in use, so what are they referencing?

@pmvcda I don't know if you know this document:
https://repository.tudelft.nl/islandora/object/uuid:45b071c0-0568-4e8f-948f-dfa52d350665
It appears to be a pretty fundamental paper on motion simulation. While I don't claim to understand even a fraction of it, I find the information in chapter 2 quite interesting:


The most interesting parts here are the vectors Ra and Rs (A and S are indices, but since I can't write indices here I made them lowercase). Let's, for simplicity, assume that Fa=Fc and Fs=Fd, then it becomes clear that FlyPT Mover is lacking the value for Rs (the offset of the pilot's head from the COR of the motion platform).

This sounds to me like you would just hand this data over to OXRMC, but not include it in your own calculations. From the above definitions I believe that Rs always needs to be taken into account when generating motion cues. Not only for Motion Compensation in VR, but also if there is no VR, but rather an enclosed cockpit with monitors or projectors.

With all this in mind, I'd like to make the following suggestions:

• Rename the "Center of rotation" entry fields in the RIG module to "Pilot's head position" (or words to that effect), which is the distance between the COR of the motion platform and the center of the pilot's head.
  
• Have any COR correction done in the SOURCE module, where it belongs (COR corrections in the POSE module may be left untouched).
• Take the "Pilot's head position" into account when processing motion cues, regardless of whether the simulator uses VR or monitors.
• Make the "Pilot's head position" available to the motion compensation software, so we don't have to enter it twice (apparently already planned for the next release).

What do you think about this?

Yes, some sims have the driver/pilot position relative to the COG. (well almost none)
When they have it I try to fill the info automatically in the source module.
If you change plane, the info changes also.

Let me think about it. I'm a bit busy right now. I need to conclude the next release; I'm already delayed by a mile... and I have my monthly pay check work waiting for me.

But, you can already compensate for the head. When you correct the source, you have to think that the correction you are making is for the COR defined in the rig.
So, set the COR in the rig for the head, and in the source, set the correction for the pilot's head.
The problem is that we lack info to get the correct pilots head in the game relative to the COG, but it's possible to get a good approximation.
In XPlane11, I don't remember now, but I think the values they give us are for the floor of the cabin.

I have now set the COR in the RIG module to the position of my head (0, -400, 800) and ran some tests with only surge accelerations (i.e. accelerating and braking the aircraft while taxiing), with all DOFs except Surge set to Manual in the POSE module, and "Mix surge in pitch" checked. With this accelerations in surge direction feel a lot more realistic, because the head is not rotated so much in the wrong direction (which would result in a false motion cue with the default COR). This leads me to the conclusion that the COR in the RIG module really is the "distance of the pilot's head from the rig's COR, and not the COR of the simulated vehicle. It also makes sense because with the default COR (0, 0, 0) the pilot's head would make different movements in different types of setups (seat on top of the moving platform vs. seat in a cradle). FlyPT Mover really needs to know where the pilot's head is in relation to the COR of the rig in order to generate realistic motion cues.

I would even go so far as to claim that the section


in the Center of rotation section is misleading and can result in widely false motion cues.

Please correct me if you think I'm totally wrong here.