Writing a motion cueing software from scratch.

350mm,... nice!

I don't think I will achieve that much.

yes, the "umbrella-body" represents all possible states before hitting an end stop. All translation - and only those - within the umbrella can be present simultaneously

I agree that it is indeed a good Idea to stay well clear of those surfaces, because in this example there are 3 other DOFs that are at their center. And when they kick in, they can drive your rig to the ends tops quickly.

In the end it is a trade-off: "How much travel are you willing to give up to achieve a reliable, end-stop-free operation?"

I think that "input filtering" of the signals has some unused potential there. And AFAIK it is something that has not yet been mentioned.

Dirty

Interesting question! My quick approach to that (between breakfast and work) would be to rephrase the question into:
How big is a box that you can stow inside the umbrella body?

Would that make sense?

Yes what’s the shape of the box with additional rotations.

Phew,.... that is a tiny bit beyond the outer edges of my "operational envelope" in math
In general I'd say it requires n-dimensional geometry. In this case a body that has six dimensions - all perpendicular to each other. Try to imagine that!

I don't have the tools available to work with those and acquiring them would simply take too much time. It's not like I wouldn't love to find out, but I think we can get great motion cueing even without a full-on analytical solution.

The umbrella-body I postet here, displays only the x/y/z translations and all rotations are considered to be zero. Therefore I only have three dimensions and those are much more accessible for human imagination.

With sufficient Hammock-time I might be able to stumble across an approach that displays rotations only (with all translations at zero) and I might eventually be able to integrate them, but that is not something urgently pressing on my agenda.

A brute force approach would still be possible where we let the software run over night trying out different combinations, but even if you are willing to accept a resolution of like 10mm in translation and 1° in rotation we are looking at ~1 Billion states to check. Imagine the table to hold that information...

All in all, I think it's interesting, but not crucial enough to invest huge resources into.

Cheers, Dirty

In my geometry I have to limit to 8deg on rotations and 50mm on translations in order to never go beyond the workspace.

Of course It’s a drastic limitation.

Now I use 100 on translations and 25 on rotations.

Depending on the intensity I am rarely hitting the “out of pose” limit

I thought about what I would want to do to the signal before it even enters the motion cueing algorithm. Simply guessing the Min/Max values to take into consideration didn't satisfy me. Even using Min/Max from a recorded exemplary lap or flight didn't yield the results I wanted.

In the end I looked at data recordings, displayed them in a histogram and it allowed me to make a somewhat informed decision about where I wanted my Min/Max values to be.

Here's the vertical acceleration data from a flight with a little bit of interpretation added:

As you can see, even though the aircraft experiences a wide range of accelerations, the lion share of the flying takes place in a very narrow band. I found this to be quite interesting, but since I'm using the Acc_vert only after a high pass filter, this particular data set isn't really all that relevant.


Since the longitudinal acceleration is being used for high and low frequency content, it is much more relevant for motion cueing: Here's the longitudinal acceleration of another flight (same aircraft type):

Decelerations below -0.3G are present, but occur so rarely that I would be willing to simply ignore them and have the rig tuned for the cues that actually show up frequently.

This is similar data from a transport aircraft:

It covers a very different range of possible inputs. Occasional spikes show up that I assume to be artefacts from measurement. Again, I wouldn't want to simply use the Min/Max values but instead make a decision based on the distribution.

Once I cropped the un-useful data from the signal, in a second step I am considering "skewing" the signal in a way to give the most frequent accelerations more "room" on the signal that then goes to the motion cueing algorithm:

I know that this will introduce non-linearities, but as long as this is done cautiously, I think it will benefit the quality of motion for most of the operation with marginal side effects in very few occasions.


I'm not 100% sure if "transfer function" is a term that is technically correct in this context, but I hope it brings the point across that you will have to find a function that transfers the inputs over to the outputs in a way to stretch the data in the right places.

...the resulting signal will then be processed by the motion cueing algorithm.

I expect, the results to make the motion felt on the rig less "general" and more "specific". It will benefit only a specific type of operation on a specific type of vehicle. Wether or not that is an overall benefit will only become evident after testing.

Cheers, Dirty

So what are the most demanded vectors in your scenarios and what are you planning to favorise?

This is something which could be really interesting to implement:

“The cutoff frequencies of the filters are adjusted according to the workspace margins and driving conditions.”

Source:

https://link.springer.com/article/10.1007/BF02984393

I'm not sure. I'd probably just look at the distribution and try to judge how much of the signal range I can leave out without missing parts that are typical for the operation of the vehicle.

Maybe a more systematic approach would make sense, where I don't even specify any min/max values at all, but instead only enter the top and bottom percentiles that I want cropped...

The bottom graph shows all measured values in ascending order with percentile lines. I think it becomes apparent that the top and bottom 3% can easily be left out.

Something else becomes apparent as well: The distribution is not symmetrical. Wether or not it makes sense to account for that by using an offset on the center position is something I am undecided on.

...that is the idea behind "adaptive cueing" as far as I understood. Instead of having fixed gains on the filters, you might as well use the motion data itself to let an algorithm change those values. In FlyPT's Hexpod interface this is implemented on actuator level with the autogain feature. It would sure be interesting if not the actuators but instead the DOFs themselves could be changed. But for that we'd need to know which DOF was most "involved" in driving the actuator to its limit. Then we could dial down the rampant DOF instead of limiting all actuators.

All in all a super interesting Idea! I'd love to take a look at the study, but 40€/50$ for a PDF...

Here's a quick and dirty explanation on how I stack the reference systems to create the motion of the rig. So far I have 4 reference systems stacked inside each other, each tasked with creating a very specific component of the final motion. I plan on using a couple more for turbulence, buffet, stall, ground roll, landing bump, engine vibrations, flight control deflections, etc.

Basically I would call it a platform with multiple degrees of freedom.

Having several sets of different rotational (objects) for use for specific effects makes out of your 6-dof a 8-dof or more.

Very creative and complex approach of a complex topic.

Small precision. Some games like xplane doesn’t need the center of rotation to be lifted because the internal approximation outputs the rotating point 1 meter above the cockpit floor. In this case I guess it’s better to leave it at 0 unless in your platform, the seat is sinked below the upper joints plane.

Well, with these four "levels" of objects I have effectively 6 x 4 = 24 degrees of freedom. Many of which are unused though

Still there are 10 DOFs in use so far and there are going to be a few more in the future. Key point here is to realise that a single transformation with 6DOFs (X-Y-Z-P-Q-R) will not be able to perform all transformations without "contaminating" other DOFs. If you use only a single transformation you will have either...

1.Rotations dependent on translations
...or...
2. Translations dependent on rotations

What I propose instead is:
Use high frequency content dependent on low frequency content!
...and let each transformation represent one, and only one task.

That way you minimise contamination of DOFs from "hierarchically higher" objects.

...not sure if that makes sense in the ears of someone not directly involved...

And two more videos on the behaviour of the algorithm:




@hexpod:
Here you can see, that the yellow ball (center of rotation) moves similarly to the video you sent me. It is only the true center of rotation for the high frequency motion, not the low frequency motion.

Yep, aircraft are strange beasts to simulate, its why there were so many crashes in the early days especially at night when there were not enough visual clues - 'Somatogravic Effect' .....

Thank you for bringing up the “ice tee” example.



With this, everybody should be now convinced that the angular positions - pitch roll yaw - being a “simtools standard” since the beginning for its pitch roll and yaw cues are useless for flight and car simulation games which outputs angular velocities.

Unfortunately, a pretty limited number of car games outputs the velocities and that’s probably the main reason why the positions are extracted and forwarded in simtools as main rotational dofs.

Yes, we know, all games provides angular positions and it’s kind of nice to have an unified standard for all of them but in my opinion it creates more confusion and misleading than help.

For now, for the games which doesn’t output velocities, the only reasonable overcome of lack of angular those is a washout filter on angular positions.

As the washout code got fixed in the upcoming sim tools v2.4, the user will finally have the possibility to improve his motion rig response.

That being said, before the plugin writers @yobuddy @value1 and others can start to think if there could be a better way to forward the telemetry to simtools, I would strongly advocate to put this crucial information in the simtools manual because it concerns not only 6-dof platforms but also a simpler setups like 3 or even 2dof.

That would really help the user (new and also the experimented one) to get a better comprehension of the not always intuitive force mapping technique and avoid a tons of irrelevant questions, debates and waisted hours on trying to avoid wrong cueing, motion sickens for VR users and other issues.

For the games where we are lucky to get the access to the velocities, one could think if it wouldn’t be better to forward those on the main pitch roll and yaw and make free the 3 extra slots for other additional valuable telemetry effects. (exageration effects)

My answer is yes, it would be much better to do so.

Maybe it’s time now to re-think the “simtools standard” and slowly draw the main lignes of its further development.

Thank you very much.

Just for shi#s 'n giggles I tried the software in VR and it was pretty impressive to see the platform alive and breathing in 3D, in full scale, right in front of my eyes. You get a pretty good idea of what the motion is like and where to make changes when you see it in 3D.



Something else I played around with while I was at it: I implemented some very generic motion compensation. But before you open the Champagne bottles,... I did this from the perspective of a (novice!) simulator developer. I mean, I asked myself the question: What would a sim developer have to do to be able to implement native motion compensation in his software? And the answer is: Surprisingly little! It took me all of 10 minutes to get the compensation for rotations done - and translations should be even simpler, I figure. But again: This was ME in MY OWN simulator! I have full access to the source code, and it is a tiny piece of software (basically just a horizon). Doing this for the VR runtime is a different story! Certainly beyond my abilities for now.

I have then talked to Austin Meyer of X-Plane (or as @hexpod would call him: "God himself" ;-) about my approach and it felt like kicking-in an open door! Austin was very (quote)"intrigued", talked to Ben Supnik, who got back to me within two hours saying (quote)"...we are definitely gonna do this, just not ASAP."
So, aside from developing a solution like the VR input emulator, there is still a good chance that a sim developer might support this feature when properly sold to him.

And up until that solution comes along, I even have another idea on how to do motion compensation in X-Plane by writing to the following datarefs:


Depends a lot on how X-Plane handles cameras in VR, but I am hopeful. Certainly an option too tempting to ignore!

Dirty

Hmmm... interesting.

I understand the argument of 360 deg.

Please someone correct me if I am wrong on what follows:

As we already pointed, your body doesn’t feel the yaw but only the changement of yaw. Therefore, in my opinion, 360 yaw rigs doesn’t bring any benefits in term of realism in comparison to the good performing Stewart platforms with let’s say 25deg. yaw ability.

In my statement I am expressing here, i don’t want to establish a scale of value “what is better” but only to put in relation two different approaches with a single goal: what is more relevant in terms of our human body senses to provide a better degree of realism.

If somebody comes with arguments, I am ready to change my opinion. Not owning a 360 deg rig, I can only base my assumptions on a theoretical level.

How many of 360 rigs do we have in the community?

If there is one, I would love to hear the owner experience.

Cheers.

Hey @yobuddy That is correct! But very few people actually do that. In fact just yesterday I had @apointner over for good old German "Kaffee & Kuchen" and I joked about how...: "You're the only friggin' guy on the forums who actually depends on the Euler Angles with your 360° tumble-dryer,... and you're not even using SimTools!!!"

I can totally understand, that you have to strike a balance between adopting new ideas and keeping legacy code running. And most of all: It's your project, so YOU call the shots! I can imagine that very often people approach you with all kinds of ideas of what THEY want, but only you are actually concerned for the "greater good" of SimTools. I can't tell you how much I back you up on this.

But,... may I make suggesions?

1. Should you ever put a point on the agenda that says: - Simtool's future motion data format, then off the top of my head I'd know a couple of people on these forums with interesting ideas.
2. Would it be possible to allow for moooooooooore data to be exported without breaking legacy plugins? I am exporting 17 data streams already and I haven't even started to get creative.
3. Would it be possible to modify existing plugins into different versions? I have done that already for DCS. X-Plane and P3D can't be all that complicated either. So people could try out "accelerations-and-rates" versus "Euler Angles" and see for themselves.

Point taken. It IS possible. But the proper way (if I understood correctly) would be either to convert into a matrix representation. Or better yet into quaternions.

Point taken too! If there is no other data available, then that's what people will have to go with. It's certainly better than nothing. But there are plenty of games where the data IS available, and I highly recommend people to use it.

see point 3. above


There is an understandable "incentive" for people to gravitate towards Euler Angles because they are more accessible in the mind than "accelerations and rates". I would recommend anyone who favours Euler angles over acc&rates to ask themselves if they have truly understood the concept of both. Don't get me wrong, there are indeed use cases for Euler angles. Especially the racing car guys among us can have a lot of fun with them.

-thinking-


-thinking-


-still thinking...-



OK, at least let me say it once before I duck for cover:
Euer Angles are great for navigational purposes! Everything that has to do with orientation of the vehicle in reference to "(true) north" and "gravity" depend on Euler Angles. But here's the secret: Neither (true) north nor gravity have all that much to do with what an occupant feels in a vehicle

I'm off then....