Writing a motion cueing software from scratch.

ahhh,.... I got it!
Thanks for the explanation, now it's clear.

I never came across that problem, because I kinda solved it before I even saw it coming

I think you should use a highpass filter on that accel_vert signal. That will eliminate all "long lasting" components. The steady 1 G will simply disappear as it is very low frequency content.



In more detail: subtract the lowpass filtered signal from the original signal. It is quasi equivalent:


Is that what you're working on @yobuddy?

It also explains why subtracting 1 (kinda) worked That "1" is the lowest frequency content imaginable. At least in straight and level flight

I suspect however, you will run into problems in inverted flight when this subtraction will bite you in the butt by taking away 2 units of heave from your operating space! I think using a highpass filter will make sure that you always subtract only what's necessary.

Does that make sense?

I am not sure xplane takes any units in inverted flight. can you double check it?

In this example you see the platform with LPF only:



Ill try your approach as soon as the filters will be disponible.

Well from what I can tell you're doing a better job of this than half of my graduating class would have! Feel free to PM if you ever need any electronics specific help

Wow, thanks! That is an offer I can't refuse

However, I had a luxury your graduating class didn't: I can work on this project at my own pace No pressure that makes things a lot easier. ...oh, and I greatly enjoy this!

I checked and X-Plane indeed gives -1G vertical acceleration (G-Load_normal) in straight-level-inverted flight. Anything else would've been an atrocity. All other flight sims I ever came across do as well and I'm 99.99% sure modern driving sims do as well. Yes, Yes,... you will not be driving upside down, but having the physics right matters even if you will not encounter edge cases like this

I'm trying to make everyone understand why I think using a HighPass filter is more suitable for the task then subtracting 1:

Here's a quick test flight showing the vertical acceleration over the 8615 frames duration (97 seconds)


It might be tempting to subtract 1 from the data, because in the long run we will have values around 1 most of the time. The flight I did is not representative for most airliners ...or even military flight ops.



If we simply subtract 1 from the signal we manage to get the curve closer to zero for much of the flight. Other regions however suffer from this, as they get shifted farther away from zero :-(


If only there was a way for us to subtract exactly what we don't need from the signal,...

hmmmm...

well,... "exactly what we don't need" is the low frequency content of the signal! Every G-load that persists over a reasonably long time (few seconds max) is not useful for motion simulation. This statement applies only to vertical acceleration! I will give you a much closer look into this topic and a nice mental tool as well pretty soon.

So let's simply subtract "...every G-load that persists over a reasonably long time"! And that is what we get if we send the signal through a LowPass filter.


The result is this HighPass filtered Signal:

as you can see, it replicates the original signal whenever there are rapid changes, but smoothes out (HINT: You might as well say: it "washes out" ) if there is not much going on.



--> That's one of the reasons why I wanted more freedom to filter, add & scale signals. I have a few more (linear and non-linear) filters in mind that I will talk about at some point. Until then I will leave you with some food for thought:

What if you have 3 signals coming together on a single channel (lets say, roll) and each signal can have values between -1 and 1 (for simplicity). The roll channel itself can display only values between -1 and 1. So, if these signals add up to more than 1, we have a problem. Or a triggered endstop switch!

If I simply scale down the signals by a factor of 1/3, then we won't trigger an endstop anymore, but every motion information has just been depreciated by 66%! What a waste! What if two of the signals are mostly zero with only occasional spikes? Would you be willing to scale down on the fun for most of the time for that?

I have an Idea how to handle that, and I will publish it here. But has someone else out there ever thought about this?

Of course man! For this reason I am screaming since months now how important is to have a working HPF in SimTools.

"So, if these signals add up to more than 1, we have a problem. Or a triggered endstop switch!"

It's not a big issue as a well working IK plugin will prevent the actuator going to the endstop. It will just clip a particular dof. but the platform will still be able to move

It's always a matter of compromise. Although my rig limit for pitch is over 30 deg. I limit this axis in the plugin to 25 deg. so there is some room left for other dofs.
After, in SimTools, once you choose your angular limit for positions in percentage (which may NOT be washed out in my opinion) you can apply your angular accelerations and the infamous classical washout (surge on pitch and sway on roll)

You are absolutely right HPF will help us to waist less resources BUT you will need them mostly for translational motion and the yaw.

Once we have all the goodies we need (very soon I hope) I am looking forward exchanging profiles with you and see on the practical side what works the best.

you have to take in consideration that using the IK plugin, 100 percent in SimTools is not necessarily the end of your actuator. Its the end of your dof and you never use the 100 % intensity for each dof in your ik plugin

You know what I mean?

@yobuddy , for this reason, please don’t remove yet the 150 percent scaling feature. I would wish to experiment with this a bit more. It might be useful for constructing the “classical washout” (using translations on rotations)

Your heart's in the right place! The range of motion that a DOF-channel can utilise is definitely precious real estate. Clipping (by simtools) or voluntary limiting (by yourself) are measures that can be taken. And I am pretty sure that in my own software I will implement clipping to prevent hitting an endstop in some form. But only as a last resort!

I was thinking of a more elegant solution to make sure that you...
- utilise as much DOF-range as possible for motion cueing from a single signal.
- prevent multiple signals from adding up to more than the max value (without clipping!)
- NEVER(!) hit an endstop.
- NEVER(!) have a DOF unresponsive, no matter how high DOF-channel utilisation already is.

That sounds ambitious, I know. But I didn't come up with those points as requirements and then looked for a solution. Instead it went the other way around: I played with an ArcTan function to use in a non linear filter that was just meant to trim the signal more gently than clipping and when I saw the graph I realised, that those very points could be the effects of this filter.

OK, an example:
Two values affect roll: "Vehicle_Lateral_G" will gently tilt the platform sideways through a LowPass filter. And "Vehicle_Roll_Rate" will tilt the platform additionally through a HighPass filter. When both come together, you might hit maxValue of this DOF. What can you do about it?

a) Accept clipping. --> This DOF will no longer be responsive until you are below maxValue.
b) Limit your utilisation of this DOF preemptively. --> Means that you will under-utilise this DOF when only one signal is active.

I thought of another way:
Use a filter element that outputs the ArcTan of the value you put in. (Then scale that down to suit your needs).
A picture might illustrate better:

No matter how many signals you add up, the angle inside the unit circle will never exceed 90° (π/2)
Then you cut that output down to whatever maxValue you allow . Output = (2*ARCTAN(Input)/π) * maxValue

This picture illustrates that you'd need an infinite input to reach an output of maxValue. The orange line is the relationship between input and output.

The yellow line is the 1st derivative. Responsiveness = 2/(π*(1+Input^2))
- So you would still get to keep the signal 63% responsive around the center.
- And you'd literally never be able to reach an end stop
- And your DOF would always keep a little rest-responsiveness.

Two considerations:
1. This filter is NOT an LTI system! (It's neither additive nor homogenous) I don't know if that will bite me eventually. I will certainly try it out to see if it does what I hope it would. After all it's just one line of code.
2. Instead of applying this filter on DOF-range level, I could apply it at the very end on Actuator-travel level. I have however not thought this idea through yet...

...I need more time in the hammock!

I wouldn't worry about it too much
It's nonlinear but time invariant, so you should be good to go. The filter will be invisible to the actual control loop, so it won't cause any control/stability issues. The only thing it'd stop you doing is a frequency analysis of the filter, but even then, you can still model it using other means (state-space model).

a) Accept clipping. --> This DOF will no longer be responsive until you are below maxValue.
b) Limit your utilisation of this DOF preemptively. --> Means that you will under-utilise this DOF when only one signal is active.

That's indeed our options in simtools for the moment.
It would be so exiting If @yobuddy could implement your "option c" directly in SimTools.

These guys have...
http://publications.lib.chalmers.se/records/fulltext/98871.pdf

That's an interesting paper! I'm not through yet, but I already saw some interesting points:


It's nice to see someone else formulate these thoughts in clear and technically precise words. I wouldn't even have the vocabulary available!

btw, I'm not advocating that SimTools must be turned into a research tool for Ph.D. students! Basically, think of this thread as my way of saying: "This stuff is interesting! And it's not TOO hard to understand either! So let me see if I can implement some of this in my program."

Dirty

"- prevent multiple signals from adding up to more than the max value (without clipping!)"

It sounds like a limiter for audio recording where a filter is rounding the edge of the signal preventing 0db threshold.

That's something which could be a part of each degree of freedom but as the intensity of a degree of freedom changes dynamically in relation to 5 others, how to know where is his threshold ??

As like in audio the threshold limiter acts on the "master" regardless of how many channels are mixed one maybe could dynamically reduce the whole motion based on the single actuator travel.

I don't have time for a hammock for the moment ;-)

Adaptive, non-linear etc. highly interesting stuff!

That's a good way of looking at it! I have never spend much thought on audio stuff, but you're right: Motion Sim building is just one giant exercise in (digital) signal processing. I'm sure an understanding of audio engineering can be helpful here

OOOOHHHH!!!!!!! This is where it gets interesting!!!!
I didn't mean to throw everything out there at once, because I feared it would scare too may people away from this, but since YOU brought it up...

The Idea is this: If we knew how much operating room each DOF has left we could utilise this room a lot more effective.

This is the translatoric operating room of a Stewart platform:


I don't know if there is a catchy English name for it, but in German I'd call this a "Hüllkörper". Maybe "hull-body" or "bounding-body" would be an appropriate translation. In a nutshell, it answers the question: "How far can the platform move in x/y/z direction while yaw/pitch/roll are zero?" , because it is only the translatoric operating room. And since we are talking about 3 dimensions (x/y/z) the answer is a 3-dimensional shape.

The even more interesting question would be "Can we extend this to all 6 dimensions?" And the answer is: YES!
...well,... "Yes, if you know how to define n-dimensional shapes". Which in my case is pretty much "No!".

My two approaches to that problem:
1. Brute force I could simply let my program try out all possible values in 10mm and 5° intervals until one of the actuators reaches its limit. And then I could refine those 10mm/5° 6D-cubes further to 1mm/1°. If I can process 100 combinations a second, I might be done overnight. Not really what you'd call an analytic approach, but it might give usable results.
2. Applying a non linear filter on actuator-travel level like I talked about above. So, this would be kinda like saying: The motion cueing algorithm can do whatever it wants. We don't care for endstops. We just send the signal to the controllers which ensures through a non linear filter that the actuators cannot hit an endstop.

This is getting way over my head here, but it would sure be nice if I could know how much range any of the DOFs have left.

Instead separately limiting dofs, limit the “workspace”
First one should calculate the edges of your workspace according to the platform size and geometry, than monitor how far we are from “out of reach” state than apply a adaptive washout on it.

Man! you opened a pandora box that I was always trying to deny it exists.

I had those thoughts couple of years ago searching for someone able to write something like this in our C++ plugin.

If you manage, well, you will put me on my knees;-)

The worst is that it isn’t impossible.

One thing I hadn't considered, if you apply this filter to each actuator individually, would you run into problems driving the actuators into "forbidden states"? (ie. ones that would violate the geometry of the platform). I think it'd depend on how you implement your control scheme. Just a thought

Hi,

Before making the last updates for the motion cueing in my software, I have tested some auto calibration features in my program.

To start with something simple, I started with gain in the actuators (I use the same gain to all actuators although they are separated in the code).
Gain starts at maximum value (something like 10x, rig is not connected to the program).
Each time the rig was out of range, the gain was adjusted.
Since what I do is more car racing, after 1 or 2 laps, gain was adjusted to avoid clipping.
It's a linear adjustment, but it makes the effects feel the same in all the range.
The problem is that we can get huge spikes and the calibration was taking those into account.
Solution is to make a clean lap, and generate those spikes we want to feel and stop auto calibration when we feel it's good.
Might put it in a build, but needs more work and to be incorporated in latest versions.

I want to try an auto exponential gain for the actuators.
Gain depends on actuator position with manual adjustment for the intensity of decrease.

I also thought of incorporating that auto adjustment in the pose components, but since the combination of them might generate clipped results on the rig, it has to work in conjunction with an anti clip feature for the actuators.

It seems that ideally, the auto calibration would work directly in the filters, specially in the high pass filters to make it fit inside the available range.
But filters also decide how you feel a specific effect while gain is how much intensity it can get.
So in my opinion, gain is where we can make an auto adjustment (linear or exponential) and leave the filters for filtering frequencies.

All this is interesting, but speed calculation might be a problem and for simulation, to much lag is something we don't want.

I know what you mean For years I knew WHAT I wanted to do, but didn't have a clue HOW to do it. Only after I learned a little programming could I cautiously think about the implementation. And once you have passed a certain point, progress starts to accelerate I will put everything open source, and am certainly interested in helping if you would want to write something. C++ and C# is what I use. But I am still very much a novice programer. If it weren't for Unity I don't think I could come up with something graphical.