Writing a motion cueing software from scratch.

I'm sorry, sometimes I'm a bit lost, since English is not my main language.

What you mean here, is:
If the data received from the games, doesn't relate to the position of the driver...
In my case, I allow the change of center of rotation...
But with a limited range in the rigs, we can't allow for big displacements or we consume the range pretty fast...

Is that what you mean?

If so, I tought of correcting that with some math, but:
Since I mainly use car games, I have no idea where is the CG of the car in most if not all of the games.
For air planes, there's way more data in the games (the community is more aware of those problems and CG is way more important for airplanes).

I'm trying to bring data inside my interface without any treatment (only mine).
Right now, I want to add RFactor2 to the list and CG we receive is relative to graphical center!??????
What is that?
And we are speaking of RFactor2, a reference for many.

You can see the value here (last 3):


In conclusion, I'm not sure if it's worth the trouble.
Well it is, let's just allow the user to change it.

Yes, thats what I mean If you correct the rotational center of the platform it will create a nice effect, but it will limit your translational operating space.

Yes, aircraft sims depend on CG a lot more then cars do, but still CG is important for cars as well. Any high quality driving sim should handle shifts in CG.

I don't know about RFactor2 in particular, but I know that the telemetry must be computed for SOME point on the vehicle. If you apply the corrections I postet, then you can "move" the point of reference. Wherever this point was, after the correction the acceleration data will feel like it came from a point offset in XYZ.

I guess that the developers
1. use the CG as reference point or they
2. define a reference point that somehow tries to be close to the center of the vehicle
3. they use the camera position as reference point

The last three lines in the telemetry look like they are giving CG information relative to the camera position. THATS MY GUESS!
Since they calculate the CG, I assume the telemetry comes from there.
IF that is the case(!) then you can correct the drivers offset by applying the formulae I postet (untested).

Again:
Not a big thing in a car. A huge deal in an airliner!

I described to @hexpod the feeling of a crosswind landing in a 65m aircraft. If those offsets were not corrected, a FullFlightSim could not be certified for zero flight time training. In fact it couldn't even be called FULL flight sim.

...oh and one more thing:

If you think it does not matter much:
The whole motion compensation thing for VR rigs uses these corrections already and it would not be possible without them. Anyone using Matzman666 's compensation surely entered these offset between the vive controller and the headset position. Try and see what happens if you don't

Using the compensation here too would make the motion match the picture a lot better.

The offsets are more for using your controller with a gun or something that makes the controller to be in a different place to where you want it to be. I don't think it has anything to do with Motion Cancellation as you don't want to offset your position or else you would end up in the wrong place as the controller is exactly where it needs to be when you turn the cancellation on and the whole motion cancellation is calculated from that initial position.

You can forget about using this for motion compensation.
You have to take into account the lag that exists between real rig position and what is asked by the software.
Motors are "slow", even the best motors can't match the requests.
Maybe for air planes it can go closer, since we have way less vibrations (should not even say that).
There's always some filters applied to the rig actuators, at least PID.
To make it you need feedback from the rig (I have in my program), but then the problem is that you need to make inverse kinematics and select one of the many solutions...
You need a good computing power for that.
It wont work, but would be great if I'm wrong.

Before anything:
Center of rotation is the point around witch the rotations are made on the rig.
By default, in my program, it's the center of the top platform.
CG is the physics center of rotation.

I agree with you, the problem here is that in the RFactor2 case, they give you the CG relative to the 3D model center.
Not relative to the driver position. You can change camera, but the values remain the same.
We don't know exactly where is the driver relative to the 3D model center.
We can estimate that and be close.
The center of rotation should be calculated, relative to the neck level (ears), so we can make it close, but needs to be changed from car to car (3D model center vs driver position varies between cars).

The effect can be achieved with the change of the center of rotation in cars, because the driver is near the CG.
In airplanes, that's different, and it might be worth the calculation.
If you are in the cockpit of a big Airbus, the CG is way back at around 1/3 of the wing cord (and to be ultra precise you need to know fuel consumption and load distribution on the plane - Doubt they go so far on "games"). This can be several meters.
But in a small Cesna, you can achieve it, just change the center of rotation up or down depending of high or low wing. Here CG is also near the pilot.

So, the value to insert in center of rotation, is the distance from our neck to the CG. But we need to subtract/add the distance from the center of the top platform to our neck... What a mess of an explanation (I'm preparing a manual for my program with those things, still needs some work).

But in my opinion, the center of rotation might be enough, even for big air planes.
You will always have to scale the values received to fit the rig.
You can do it on my program. Adjust the Center of rotation and then you have to scale the values to fit the rig (reason for auto tune in general rig gain).
One of the things I might change is gain resolution (one more decimal place) and allow bigger values in the center of rotation adjustment.

Let me conclude the manual, there's way more considerations there. Might be wrong in some.

As the landing gear vertical load is decreasing being compensated by the aircraft lift, it was a stupid idea willing to scale it arithmetically to the heave center. apologies !

I am dividing the "landing gear vertical load" by the "current weight" of the aircraft which makes it independent of the type and payload having always the runway rumble somewhere around 1.

It seems HPF is the only solution that I see for the moment.

OK,... hmmm..

I admit, it is still quite possible that I misunderstood how exactly the motion cancelling software is implemented, cause I haven't seen the source code. In general, it's re-defining the position of the headset inside a reference system defined by the vive controller. Since the controller and your head are not in the same place, rotations will affect the headset differently than the controller. I thought the offsets were there to allow the software to correct for those. If the integration of the signals takes place not on sensor-level but on driver-level, I could well imagine that those offsets are indeed not used for what I thought, but instead are taken from the data measured by the Lighthouse stations.

Thanks.

Well said! We agree on A LOT here! Before I comment on the part where we don't, let me say it clearly: You are an engineer, I am a physics guy and we both speak fluent Math So it should really not surprise that on over 99% of what we discuss here we are totally on the same page.

Still, let me point out the two areas where I'd draw different conclusions.

1. Self motion is perceived with more than the vestibular system. I'd put the center of the rotation closer to my belly, but this is not going to be a game changer. The reason behind this is, that if you put it closer to your ears, you will make the cues more fitting (less wrong) to the inner ear, but less fitting (more wrong) on the bowels and the haptic receptors (skin). Following a least squares approach, I'd rather have 2 small errors then one big one. I am however totally open for interesting considerations on that problem.

2. I would strongly advise against changing the center of rotation of the rig to adapt for offset driver positions. A few somewhat educated "guesstimations":
- An inch is not noticeable
- A foot is a lot
- A meter will ruin your experience
- 3 meters will render the whole rig useless

Since you know the reason behind this (rotations would be limited by lack of translational operating space), how severe would you judge these four cases?


After having realised that the driver offset correction is computationally dirt cheap (no sines, cosines, etc...) and mathematically almost trivial, I will invest the time to implement it as an option, because I am simply toooooo curious to miss seeing if it makes a difference or not


Thanks for your comments, I take what you say very serious.

Dirty

Exactly the point I argued a few weeks ago on this thread. With exactly the same arguments ....like I said: An engineer and a physics guy....
No way this is going to replace motion cancelling based on hijacked controllers. I just wanted to mention that in one form or another the cancelling uses the same mathematical approach.

That's exactly what I thought until the author told me straight that the offsets have nothing to do with motion cancellation. Its all documented on the github

now, that's an argument I can't refuse! Thanks

But... You can calculate everything, but there's no need for that.
Changing the center of rotation, automatically scales the values. No need for more calculations.
Tangential speed is proportional to the radius. Further we go, bigger the speed.
We just have to scale them to fit the rig.
We can look at it however we want, but we have to scale it. there's no other way.
Using the center of rotation, gives you real behaviour.
If you are to far from CG, you almost feel a yaw as a sway, because radius is too big.

Like I said before, that's the reason I use auto gain. It's to scale the values to fit the range of the rig.
And it will fit the values proportionally as it should.
In my program, I let people play with values, but the correct way is to use 180º range in rotations and the same value for all translations.
Same with individual gains, they should be the same for rotations and the same for translations.
1G in one direction should feel the same as 1G in a completely different direction.

Very interesting discussion.

@pmvcda let’s imagine the scenario of 747.

“You feel the Yaw almost as Sway” is a very good example.

Actually maybe the serious simulators should do this job by outputting corrected forces from the vehicle CoD to the pilot location inside the vehicle (aircraft)

Only to say that if you put your CoG 25 meters behind like in reality, you will most propably transform your 6-dof in a 4-dof

EDIT:
Imagine, since we have 6-dof plugins, almost everybody is mixing the surge to the pitch building kind of « classical washout »

If you set CoG longitudinal far behind you, (like in reality), you would loose almost all Pitch resources for your “classical washout” algorithm.

Still I have no idea for the moment what would be the most clever idea to get the best results

Is it OK, if we continue this in its own thread?

I have some interesting posts prepared for the software already and it is going to get cluttered.

Post moved to this thread:
https://www.xsimulator.net/communit...otion-data-for-driver-position-offsets.13250/

Hey

In motion cueing systems we are "dancing" along the fine but blurry line of human perception. You can (and should) carefully tune the filters in a way to distinguish between cues that are above and below the threshold of human perception.

The NASA Technical Reports Server might give you a hint on what those are:

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19690013275.pdf


Dirty

Hey
Would like to keep this brief:

We could better utilise our rigs if we knew in advance where the limits of the DOFs (as opposed to the actuator limits) are at any given point in time.

I found a way to describe the translatoric operating space of a 6DOF Stewart type platform with linear actuators. Translatoric means that yaw, pitch and roll are all zero for those considerations.

So far, I only have a graphical approach and I am unsure if I will develop it further. An analytical solution sure would be nice to have,... so, if YOU, yes YOU! ...like a good Math puzzle, PM me. I can point you off in the right direction


Each actuator is represented by a color. The colours of the surface indicate which actuator is most limiting if the platform approaches that respective surface. The body represents all possible positions THE CENTER of the platform can have.


There is another set of possible solutions below the ground. I'm mentioning this, because I am cautiously evaluating the option of mounting the actuators to the ceiling. With "real" actuators, I think these two bodies are the only sensible solutions:


Slicing the body from the top...


...starts with an almost round hexagon-ish shape.


It will reach its maximum lateral and longitudinal expansion around a height slightly above the midpoint between top- and bottom-most tips.


The lower half has a lot less volume and turns into a star-ish shape...


...that ends in a triangular tip.


There are combinations of parameters that lead to somewhat strange shapes. As far as I could tell those are not within the limits of what a normal actuator would be able to achieve range-wise. So, no need to worry about getting stuck on an "island" with the rig.


Noteworthy: Sometimes two valid positions can't be connected with a line. In actual use it is highly unlikely that this aspect will ever become a factor.

Dirty

I like your borderline ideas. It stimulates the imagination.



I do intuitively limit the heave of my rig by limiting its travel. Although my capabilities are over 350 mm for the heave only, I use 200 because the heave is what eats the most of other resources.

The washout and travel limiter on heave is the step number one on the practical side.

I guess it crops the workspace in similar way like in the picture above.

This workspace representation:

is when you use full possible travel for each dof which in reality is not a good solution.

As test, could you please limit your degrees of freedom in a way that every combination is possible? (No out of reach state)

How would it appear on the graph?