Writing a motion cueing software from scratch.

These three are advancing the world of home motion sim software at a prodigious rate for sure! Even more exciting due the fact that it had been in a rather stagnant state IMO for as long as I've been into the hobby (for flight at least). It's a fantastic thing to witness and has me very excited all around.

@Dirty spot on with the mention. That sounds like it could be an excellent solution for that particular issue. Something else to maybe keep in the back of your minds is trying to allow for high frequency effects when "on ground" in particular. With BFF I was able to essentially achieve this by telling the software to increase all heave, surge, and sway effects when "on ground". My setting for this varied between about 1.3 to 1.8 times the in-flight value. I'm sure you guys likely will provide a more elegant solution but it generally worked. The thing is some things (like runway bumps) you really just want higher frequency, but others (surge and sway) I definitely want much bigger cues on ground than in air for the same g-value acceleration.

The following is based on my experience with BFF so may or may not be valid for you guys: I think that being able to set a bias to surge cues should be possible , so you can reduce negative surge accelerations without reducing positive. I have to experiment with the SimTools tuning center on this. Oh, and one more strange quirk I found that I'd love a fix for if anyone is interested. When you brake hard (like on landing) and then don't accelerate immediately afterward the surge into pitch coordination tilt always stuck around far too long. Brake to a complete stop and you are were still tilted forward... then you would slowly feel it wash out while you are sitting there stopped. Always annoyed the heck out of me. Again bear in mind that this was with BFF so it may have been a quirk of that program. You know in a real car when you stop kinda hard, at the moment you 100% stop you get that kind of rebound effect? That should be the cancellation of the tilt coordination on braking to a stop. Just random-ish thoughts, don't mind me.

I don’t know exactly how Ian deals with ground separation but for sure, getting a flag and increasing the dof response is not the best approach.

Indeed while touching or leaving the ground, the aerodynamic response (lift drag etc.) can be altered if you suddenly modify the ground/air coefficient.

In my opinion a much better approach is to deal with landing gear forces if the simulator outputs such data. I don’t know about DCS or P3D but we are lucky to have access to it in xplane.

I sent you my experimental plugin where the ground separation is outputted following this method, (weight on wheels) through the “extra1” effect.

Sure but than, the HPF should bring the surge cue allowing bigger bank angle.

Hard to achieve this behaviour with filters tuned for flight. My plan is to implement a logic that fades between two filter settings. One for flight and one for ground. My hope is that this will improve the experience quite a bit, but I will have to keep an eye on how and when exactly this "crossfade" takes place.

Something else that becomes apparent when thinking about this issue: The better the motion tuning becomes for one vehicle (plane), the worse it becomes for another (car).

...DCS allows for that too You can read the gear strut compression and scale that to a value between 0 and 1. You can take a look at it in my DCS export server simple project. Use the gear strut example.

Cheers

What I'm doing to solve the flight vs track feel:



What you see there, is motion generated from one source, but from different data.
From motion (accelerations/rolls, whatever we have been discussing) and another one from suspension.

You see 4 wheels there, but two in front are the same.
Problem now is that some air planes have one wheel at front, others at rear... There's always something.

And it works. When you lift off, there's no more wheel feedback.

The two motions are added in the rig (look at right):

Not a bad Idea to use two different "pathways" to motion cues. Still some brainwork needed to determine when to use which cues, but it has the potential to be of good use for motion cueing. Smart!

Took some time to wrap my head around this formula but I think I got it. Might not be of high importance to casual users, but for @pmvcda or @yobuddy it might be interesting to understand where the differences lie:

Hard limit:

self explanatory, I guess.


Soft limit using an ArcTan function:



My choice, mainly because it allows you to use coefficients to blend this behaviour in and out. Small coefficients will fade the curve over to a simple Output = Input shape (unscaled linear, blue line).


Soft limit using an exponential function:


Gives nice curves, for sure. And it has the advantage that in this function the limit is truly a limit: The function will never exceed this value, just get closer and closer to it. There is one downside to it: If you want to have a pretty much linear behaviour and only add a "grain of curviness" to it, this function is a bit problematic because small coefficients will blend the curve over to a flat line. I have an idea of how to tweak this into the right shape, but then it would loose it's truly limiting property.

Bottom line:
Both work when done right

...would anyone know if an ArcTan or an e-function is computationally more efficient to calculate?

There's a good approximation to a sigmoid (logistic) that is faster to calculate (red):

Output = range*Value*alpha/(1+Math.Abs(Value*alpha))

But the one that is close to the linear values and curves near the extremities is the pure logistic (yellow):



I don't like them much. I think we can get something better and faster... some more thinking needed

For takeoff I want the largest smoothest heave cue possible when I finally pull back and leave the ground as that is one of the great moments in flight IMO. If I yank the stick back hard I'd say the motion could be shaper, but it should be as large as possible regardless.

For landing I always want a pretty sharp bump on touchdown, but if it's a decent touchdown it shouldn't be a very big heave movement, just abrupt.

Much more complex is the time on the runway while speed (and by extension lift) is changing dramatically I feel like the forces felt during that time have varied pretty drastically across different aircraft I've flown in. The one stuck in my memory is the takeoff run in a B-25 Mitchell bomber.

I look forward to playing with that "extra 1" value. But we also need a no "Euler angles" plugin! I've been talking a bit with Dirty about that.

It’s the case. No Euler there

=O
Now I really can't wait to try it! =)

Oh wait, that was only for X-Plane wasn't it? DCS is what I'm working with. I will still look forward to trying it just for testing.

The AMC is currently not installed on my sim. My brother was in town for the weekend so I had him solder the pins onto the AMC to switch it over to 12bit. Not sure I'll have time tomorrow to put it back together but I definitely should be able to get it running by Tuesday night. =D

I am not sure how to call this decreasing curve. Maybe « logistic growth » is the right therminology.

I am looking forward to try out this math on the dofs.
It might help us to stay inside the workspace. It definitely worth to be tested.

Concerning this kind of limiter on the actuator level, maybe I was wrong assuming that it could work.

As the “out or reach” doesn’t seems to be related to the position of the lever, it might be impossible to predict it you don’t use the lever’s “range” limiter.

I already though of adding this formula as a filter for testing (on each pose component, see the FlyPT interface thread).
But you have to take into account that for example the range of sway is not constant, just changing heave changes the sway range and I'm probably (or maybe not) going to use range as a parameter for the logistic function.

In the actuators, the formula needs to be straight or we are going to have to much variations on the cues.
Curvature to the limit needs to be close to the limit to reduce the error.

Honestly, I don't know if it's worth. But we can try.

Same opinion here!
It has the potential to mitigate some nasty problems, and also has the potential to create some nasty problems

Pity we can not combine the logistic function before or after other filters. That would interesting. Using it alone seems to be to rough.

Best

Well, I'm working on a new filtering system for FlyPT Mover.
It will allow you to create filtering sequences however you want.

First release is near, and wont include it, but I want it.

Huge adventage indeed !

I really like these exponential curves.

How it would look like in c++ ?

You might find it interesting to watch.

Hey guys. I just got done with my first few hours of testing with a new LUA and FlyPT and man, it feels great! What I felt tonight I would say for the first time my sim performance feels good enough in flight to make me happy! FlyPT hasn't got that bug fix out yet, so I wasn't able to really get a completely valid test just yet.

As I said, flight feels great. Still the issue with "on ground" stuff though. I know you guys have talked about "heave" cues on the runway via the landing gear but after my tests tonight I wanted to reiterate: We need to be able to create high frequency surge and sway (and maybe yaw) cues when we are taxiing, landing, and taking off. Adjusting for good cues in flight means taxiing feels completely wrong.

Any of you have ideas for how to address that?

I've got to take a closer look at FlyPT mover now, tonight I tested with the old FlyPT software because I wanted to get right to the testing of filters but tomorrow I plan to test with "Mover".

Trip