Writing a motion cueing software from scratch.

Indeed, simtools 2.4 will be released soon.

The “Release Candidate 14” and its smoothing changement from “first order EMA to “third order EMA” for the axis assignments was a good step forward.

However, analyzing how the amount of filtering of a second set of EMA filter is smoothing the entry corner, I just realized, that actually we don’t need the “triple order EMA” in axis assignments.




Simtools has a “intensity slider” in the “game manager”. When applied, this is where the data from the games are filtered „before anything else“.
This feature allows the user to apply an overall smoothing “on the fly” for all axis at the same time.
This is a very useful feature especially for more simple simulators (like 2 or 3-dof) and its simplicity is a clear advantage.

Concerning this slider, I was advising @yobuddy to revert the “3rd order EMA” math to “1st order EMA”, arguing that the “1st order” solution have a big adventage over the “3rd order” staying always “real time”, and when applying the “1st order”, the “intensity” of incoming cues, can be much better damped with a very important weighting factor.

Now that’s being said, I think that this slider, could also be used to create a “2nd order” curve by combining the “1st order” set from the intensity slider with the “1st order” in the “axis assignments”

It’s seems obvious, that a “3rd order” EMA can be created in kinematics plugins like heXpod or FlyPT by simply applying a third set of “1st order“ EMA at the end of the filtering chain.

So @pmvcda , it seems that building the „third order“ in Flypt would be redundant.

I couldn’t predict it before I did my tests. Sorry

It makes me nervous when you start talking about reducing the filters in any way, but I'm pretty sure @Dirty will keep you in line for me! =P

Hopefully I will be able to start doing practical tests in just a few days. I need to refresh my memory on what smoothness problems I had with BFF despite the smoothing filters he has. I don't think he has the smoothing filters on all 6DOF though, only on the translational axes. I know one thing I was wishing for was smoothing filters on rotations.

I have more to say, but I don't want to complicate the issue by remembering something incorrectly.

Don’t be afraid.
The discussion here is about C-curve smoothing and S-curve smoothing.

While you apply a C on C you get an S (although it is counter intuitive it‘s how the math works) BUT the opposite doesn’t work !!

The main question for the moment is:

Do we want to completely get rid of „C-curve“ in simtools matrix or do we want to be able to use both (C alone and S by combining two or thre C) ?

BTW. Whatever the method you will be able to damp everything to almost NO-MOTION.

Yes, that's an overlap of filters.
But instead of using two separated filters, it's faster to calculate just one.
So if using the 6dof plugin, I would use just the filter on the plugin and disable the one in game manager.
Not that one is better than the other, it's just for speed reasons.
The fact of having the filter in the plugin doesn't affect performance, so I think we should keep it.
Might be loosing something here, but that's how I see it right now.
The Washout filters can be removed, they are now obsolete.

Might post a new version with the washout removed and with the Butterworth order 2 ones.
They give different results compared to the EMA ones. Would be good to have more people looking at them.
The previous pictures I posted, are for a situation that doesn't happen while gaming. That sudden change gives those overshoots, but in practice it should not happen that way.
The Butterworth filter seems to give a "rounder result". But I need time to test.
I need to make a good class witch allows the use of all those filters in an efficient way.

Sure you should keep it!

„Calculate just one“ ?

You mean „one“ 1st order EMA or „one“ 3rd order EMA ?

As you know for sure, game manager, game engine and kinematic plugins are 3 different things but by „overlapping“ the 1st order“ EMA between them, you create a „second“ or „third order“ math which rounds the entry corner.

In some specific situations, like for ex. the coordination tilt, we could take a huge adventage of a „second“ or „third order“ approach, even if it adds a certain degree of delay.

If you do it on one interface or if you create your second or third order between the interfaces I don’t think there will be a noticeable „performance loos“

In this vid example, the corner curve is rounded on purpose by using 1st order Simtools EMA and 1st order flypt EMA



EDIT:

We have to check how the 1st order from Game Manager is combining with the 1st order in the Game Engine. The Version to test this is the RC12

For sure, the 1st order from Game Engine combines pretty well with flypt 1st order from what I can see and feel.

Best

Guys when you say "using the 6DOF plugin" are you referring to HeXpod, FlyPT, both/either, or something else?


I am deeply invested in your project here as I've been battling with being unsatisfied with my motion for somewhere around three years, so I'm trying to help where I can but I know I'm more likely to get in the way and slow you down than anything else!

I'm super excited to get testing, and almost ready. Soon I will be your guinea pig!

I think that is technically correct (with my limited knowledge). At least it reflects what I learned about sequences of EMA filters.

There is one aspect of it that I would like to point out, and it is that something that I noticed here and there: Lets try to keep things tidy and organised
As of right now, I see some processing done in the plugins, some processing done in Simtools, some in the Hex/FlyPT interfaces....

I would argue that we should let one module do the exporting, one module do the processing, and one module do the inverse kinematics,... etc ...instead of having the filters scattered all over the place.

I'd second those statements.

Just yesterday I have redone my filters and instead of having three EMAs handing-off values from one to the other, I have an array of filters in one class. I haven't measured performance, but the code went from 3 x 50 lines down to 10.

One point I'd like to add: It's not like a 3rd is "better" than a 2nd or 1st. We need a 1st, a 2nd and a 3rd in different places of the processing-process

@Dirty ,@pmvcda , before going into the concepts of what could be an ideal solution, let’s talk about Simtools guys and ask two fundamental questions:

Do we need two different EMA filtering (first, second third order of it) ??

Do we need a separation of filtered and unfiltered content inside a single dof (ground/air separation, rumble, stall etc.) ??

The response in my opinion to both questions is: yes we do !

For the moment with simtools, the only way to achieve a filtered/unfiltered content is to use the internal simttols matrix and an external kinematics plugin. That’s good ! We have it !

The issue is that for the moment, in RC14, Simttols gives us the possibility to apply only “third order” EMA which is NOT present in kinematics plugin.

Unless @yobuddy adds several sliders for different smoothing arts, we are forced to use a combination of filtering, some inside sumtools some inside kinematics plugins.

I believe filtering everything inside simtools, would be the best solution and the only one which makes sense. For that @yobuddy has to allow different smoothing arts. He has the now-how now, it’s only a matter of will.


I hope it’s clear. - Thanks

What we are speaking right now is about which filters are the best to use with motion cueing.
We are applying this to multiple software's:

- Nutkicker by @Dirty on this thread.
- New Sim Tools version that will come with 6dof plugins based on the FlyPT interface and new filters.
- Hexpod from @hexpod
- And the FlyPT Hexapod Interface from me and it's successor FlyPT Mover Interface that I have almost ready.

You can already test/use Hexpod and the FlyPT Hexapod Interface. They have those filters implemented and are available right now.

That separation was what made me build the new software.
Like @Dirty says, it's multiple modules, you use what you want, the amount of times you want. Each module with it's own function.
Give me some more days and the first build will be out for testing.

By the way, the latest version of the plugin, already has the LP(LP(LP)) and LP(LP(HP))

Exactly !

Let’s make out of this list of 5 possibilities 3 categories :

- Solution which use SimTools plugin telemetry:

1.) Internal simtools 6dof plugin
2..) simtools with external heXpod software

- Hybrid solution:

1.) flypt hexapod external plugin (simtools telemetry or native game telemetry support for restrained number of games)

- upcoming solutions with dedicated telemetry:

1.) Nutkicker
2.) flypt mover. (Not sure if it will be designed to interact with simtools telemetry)

Now, in order to constructively point what’s still missing with simtools based solutions regardless of what the third party developers will add is:

1.) the additional smoothing slider (sliders) of first and second order of EMA to properly construct a tilt coordination algorithm
2.) link from standard simtools assignements to simtools 6-dof interface in order to be able to use filtered/unfiltered separation of telemetry content.

@yobuddy , can you follow us on those two last points ?

Thanks for your comprehension.

FlyPT Mover connects to SimTools also.
There's already some description/guides on how it works, on it's own topic: https://www.xsimulator.net/community/threads/flypt-mover-interface.13464/

Great, that’s cool !!

I guess you are implementing the tilt channel with different filtering arts (entry curves) than, I guess, we will be also able to separate the telemetry in simtools matrix.

Good idea.

Finally found the time to populate the UI a little more



It gradually starts looking like a software that is actually meant to be used

I wouldn't call it particularly difficult, but it's certainly a challenge to keep track of which signal goes where. With 22 parameters driving 16 objects, there are 352 ways to screw things up:


All in all, just one huge book-keeping task.


Up until now, I have the software throttled to 100FPS which saves CPU resources and is still way fast enough (I think/hope). If I shed all the computational load not directly necessary, I can get up to 600FPS, maybe more.... there is however one big question on my mind:

Does the behaviour of the filters change with increasing/decreasing frame rate?

It is only logical that the filters will manipulate the datastream on a "per frame" basis. So, when there are more frames in a given time, it means that the lowpass filters will not filter the frequencies as "low" as you would want them to.

Three possible solutions on my mind:
1. Lock the frame rate at a sensible value (~100FPS_ish?) Practicable, but not what I'd call an elegant solution.
2. Don't process the values themselves, but instead the integration of the values over time (Value * DeltaTime). This way every value is being weighted with the duration it persisted over. Still a very vague idea in my head.
3. Change the filter variable depending on frame duration. An even vaguererererer idea....

Does anyone have a clue on what to do about this? @harwoodr , @pmvcda , @Tim McGuire? I can hardly imagine that I am the first human to stumble across the problem of wanting to process a discrete time signal with a varying frame rate.

hmmm,....

*scratching head*

Right now, I'm making just loops.
1-Get info from game (and I think the fastest ones send data at 60hz)
2-Make calculations
3-Send data to boards (in a separate thread to achieve the selected transmission speed)

So filtering is made on the discrete domain, not frequency. And that's where EMA filters should be used.
I know, depending on processor, different users might get different results for the same values, but that's not a big difference.
If one loop takes 20ms for one user, other might take 50ms. Second user might loose one update from the game.

What will happen is that you will achieve a speed that will keep stable, so we get a "stable behaviour" of the filters for the same user.
All other options is to loose processing time in my opinion. But I might be wrong.

I have thought of using a stable frequency update, but honestly, I'm thinking more on the other problems.
So right now it's more power=more updates.

Thanks

Makes sense. As long as one user will get consistent results it does not really matter. Maybe the filters have to be adjusted if a user upgrades to a much faster CPU, but in general it should work.

My thoughts behind this were: If I keep the frames at 100FPS (10ms), then I will always work with data that is on average 5ms old. Cranking the frames up to 500 FPS was supposed to minimise this latency.

Fighting latency is cumbersome. For most other problems I kinda know where to look for the usual suspects, but latency comes a little bit from everywhere and no single fix makes much difference. Still worth keeping an eye on, I think.

Thanks,...

I've got something for you guys, more or less on topic I believe.

I was speaking to Thanos earlier tonight and I asked him why 8 bit output (for speed setting signal sent to VFD's) is the default when 12 bit is available on his board. His answer was "8 bit is four times as fast!".

I had been running the 12 bit before, maybe that was part of the reason I had some latency complaints about my cues in high performance aircraft.

Anyway, that got me thinking, is 8 bit resolution in regards to speed going to negate the gains in terms of smoothing out the accelerations that you guys are working on? In order to try both 8 bit and 12 bit I will have to take my simulator down for over a week to get pins soldered to my board by someone who won't destroy it in the process (in other words not me). I also will have to hook up the wires again when I get it back, which is another opportunity for me to break it. For now at least I've only got 8 bit available.

Trip

PS- Tonight I finally got my sim moving again! Now it's time (tomorrow I hope) to install SimTools and HeXpod and start tuning and experimenting. I'm planning to try the FlyPT mover also, but I'm a bit intimidated by that one. I have no idea what most of the instructions mean!

Yes, 8 bit is faster. Specially for the serial communication.
But is it for speed or position?

I'm afraid, that in the end and after all filters, we are going to feel an even worst latency.
Not only because of the amount of calculations, but also because filters add that latency.

For cars and high performance planes, we might remove most of the filtering. But that is something we are going to test in the end. I already feel it in some situations...

For the FlyPT Mover, I wanted it done last week, but some personal problems in the way didn't gave me enough free time.
Probably, I will be alone this weekend, and that's a good chance to end the first version.

Try the FlyPT interface. Not as complicated as it seems. At least you can start without filters and it moves.