Writing a motion cueing software from scratch.

I will never understand how something like this works, without ripping everything apart!

Maybe you just allow 3 shorter legs and the kinematic should follow.

I was considering this design back than but I am afraid the collision possibility due to hight of the gearboxes and shorter legs could gives you a pretty poor performance.

I would disagree.

My experience shows me that what gives you a good performance is the ratio base / upper platform and the length of the leg.

This „two stage“ System can’t perform well IMHO

Also I would not put the cranked systems as less performing in general. Quiet the opposite.

Do the test @Dirty with a base diameter of 120cm upper platform of 100cm and levers of 35cm (yes 35 yes it’s possible with AC servos from Teknic)

You could reach almost 1 Meter heave with such cracked geometry. Imagine the size of the room you would need if you would get such performance with linear stuff.

Best

I agree this sin cosine in cranked math is quite fascinating. Almost hypnotizing as a camp fire.

Thanks, hexpod! Might be the easiest reason yet. I guess nothing is free.

Cheers!

You're right! I Agree with literally everything you said. They both have their strengths and weaknesses. And the range of motion you can achieve with crank arms is certainly impressive. In my post I was focussing on only that one single aspect of crank arm systems: There is an additional joint and that builders should be aware of that.

I might as well phrase it the other way around: You need good (big) joints to avoid the rig from becoming shaky. Linear actuators can get away with small (cheap) balljoints , cause all forces on the actuator are always "in-line" anyways.

If I remember correctly, you have these huuuuge 40mm-ish balljoints,.... NICE!!!!!

He there,

made a little progress and put some new features in the software:
- Softstart/stop with "cosine" crossfade
- Crash detection and recovery working flawless (that was tricky!)
- Rig configurations can be saved/loaded
- Crank arm systems implemented (albeit no output to controller yet)
- Plenty of optimisation done. That was urgently necessary.
- View panning possible

The crash detection and recovery was a feature that surprised me, because it was very easy to do badly, but really difficult to do good.

Outputting the commands for crank arm systems is still on my list, but thus far what kept me from making progress is the fact that I still have absolutely no Idea what in that context a "full stroke" even is!?!
I think I am nearing a point where the software can actually be used My first actuator will be ready for testing late this month, I guess. The other 5 may follow early 2020 and then it's rig building time.

Cheers...

Ups,... forgot to link the video

Hi,

That crash detection is interesting. I'm trying to filter the spikes on crashes, I would like people to feel them, but limit the impact.

So my idea is to remove sudden changes in values, or a low pass filter.
So I made what I call:

LDYNLP a linear dynamic low pass filter and a EDYNLP an exponential dynamic low pass filter.
The logic here is to adapt the number of samples used in the low pass, to the variation of the value.
So if we get a crash with a high value variation, the values are filtered with an higher intensity low pass filter, keeping lower variations original.
We can define a multiplier for the number of samples. While in the linear it's just the difference between last filtered value and the new value, in the exponential that difference is ^2.
I need to make more tests, but it seems to work good. So we can crash and we are not killed by the rig, and we can keep using it without restarting it.

Curious to see the final rig! Those motors are powerful and fast!

Great to see your progress!

I've been thinking a lot about my rig, and the fact that we still didn't have Huey "on-ground" detection working is really bugging me since that's the main sim I'm building for. =(

Too many things to do, my head is spinning!

LDYNLP is a fantastic addition and works really great for “in air” heave in xplane.

I played a bit with two values of EDYNLP but I wasn’t able to get what’s going on in there.

What kind of application you imagine for the EDYNLP ?

That filter sounds like a great addition. I've generally kept the crash detection turned off on my sim because it's a lot of fun sometimes! I have trusted my sim to take the punishment with the settings I was using that capped all cues at a certain threshold but sometimes it was a bit much.

That's ambitious, but interesting!

So far, my crash-paradigm was to conservatively "detect and cop out". I have thought about "detect and mitigate", but eventually I imagined how the guy from the German Aviation Authority (LBA) would ask me how I would ensure occupant safety. I feel a lot more confident being able to say "I block all values above a certain threshold and keep the rig in the last good state" rather than "I will give the occupant the ride of his life, making him feel as good as possible what it would feel like to crash in an airplane" :-D

...if I were the examiner, I'd immediately ask how that mitigation would behave if it was used to simulate the impact of a space capsule on Mars at 23km/s.

I will certainly try out the different filters you made, and would love to learn more about them, but for the actual build I will have to stay on the conservative side.

Those motors are powerful indeed. I actually ditched the Clearpaths for them.

Cheers, Dirty

I think the experience in the Huey will be great regardless of wether the devs will add an "OnGround" variable for the Helos. After all, in the sim engine they interact the landing skids with the ground and thereby generate the accelerations and angular rates needed to feel the contact.

In my view, DCS' OnGround variable is great for "knowing" but not required for "feeling" the touchdown.

Dirty

Hello Dirty!

I know the Huey ground detection is there because SimShaker for Aviators has a working touchdown cue in the Huey. I just need to find out what it is.

I very definitely disagree with you on the usefulness of the on-ground detection but decided to forego the wall of text. I'll be happy to argue...erm.. debate it with you if you want! I've got plenty of examples that I'm absolutely confident in for you to debunk and prove me wrong. =D

Edit: I agree that it's much less important in the Huey and Gazelle than every other aircraft in DCS. Still I'd very much like to disable or drastically reduce low pass filters when "on-ground".

Here's my reasoning, let me know if you disagree.

1. Filters only matter in dynamic situations where values change.
2. After touchdown the Helo is in a static situation.
3. --> Therefore filters will not make a difference after touchdown.

I could understand if planes needed different filters after touchdown, because there is still so much "going on" while on the runway. I guess I will have to buy a DCS Helo to see for myself in Nutkicker

Cheers, Dirty

I accept your challenge!

For helicopters, one of the most significant things a motion simulator can do for you is let you feel exactly what the ship is doing as you "pick-up" off the ground.

As you increase collective you input corrective control on the cyclic to try to keep her level so that when you lose contact with the ground she doesn't try to take off in any given direction.

Being able to feel the helicopter tilt as it gets light on the skids is fantastic for maximum realism and can even help to improve your technique.

If you are landing on somewhat uneven ground you also want to feel the skid touch the ground at one corner and feel it tilt as you lower it onto the ground. If tuned for proper feel in flight this tilting will be much too subtle.

And lastly, there is the touchdown "bump" in general. If I touch down a little harder than I'd like I want to feel it. =) If I tune to feel that bump then turbulence or rapid collective input changes will be too 'sharp' in the air.

These three things are some of the best parts of having a motion sim for helicopters IMO!

Still, I agree that having the on ground/in air trigger is more important on any aircraft that taxi's with wheels on the ground (which includes the Ka-50 and upcoming Mi-24 helicopters in DCS). Due to all the above however, I won't be happy until I figure out the "on ground" trigger for the Huey!

@Dirty

Posting this from the DCS experimental plugin

One question, probably an obvious one to many...

Talking about Heave,
Which direction does the motion platform move when I apply positive G's? (pulling the stick)
I have mine set in this way.
I pull the stick, positive G's, my motion platform moves down, towards the floor.
I push the stick, negative G's, my motion platform moves up, towards the room ceiling.
Is this correct?

OK,.... brace yourself! This is gonna be a trip for an unprepared mind, but I have the impression your mind is not totally unprepared.

Take a look at these graphs:

I have inserted them as full image for you to have them open all the time. If you don't dream of those graphs tonight, come back here and stare at them until you do! The key is to know that the vertical axis has two distinct meanings:

• For the blue input signal it is an acceleration. This is the vertical acceleration we're getting from the plugin. It makes a step from 0 to 1.

...whereas for all other output signals...

• ...it represents the vertical displacement of our platform.

The response of the filter to this exemplary "step input" can be applied to any other step as well.

Here's the recipe:

1. We apply a low pass filter to the input signal to get the green line.
2. We subtract this signal from the original signal and we get the grey dotted line. This is what people call "washout". We could use that signal to drive the rig in heave, but the signal still represents an acceleration, but we need a position command for our rig.
3. We send that signal through a low pass, to convert an acceleration into a velocity.
4. We send that signal through a low pass again, to convert a velocity into a Position.

...then we use this signal to drive our platform in heave.

Now take a good look (again) at those graphs. If the vertical axis represents the displacement, then the...

• ...height of the graph represents the position of the platform.
• ...slope of the graph represents how fast it is moving. (1st derivative)
• ...curvature of the graph represents how strong it is accelerating. (2nd derivative). Yes, I know, technically it is not the curvature directly, but for shallow gradients "curvature" is good enough.

Now take a good look (yet again) at the yellow graph. As the input signal jumps up, the yellow graph jumps to a certain concave curvature. THIS curvature represents the acceleration the user feels on the rig.

But if you look even closer, you will see that the graph has two inflection points:


The curvature changes from concave to convex and back to concave. That means that from the first inflection point on, the user experiences an acceleration adverse to those on the vehicle and then from the second on the acceleration on the rig goes back to being provers!

But if you look closer still, you see that the adverse part is not curved as strong as the initial provers part!

And this is where the magic happens: If the filters are tuned right, those curvatures are just above and just below the human threshold of detection, so you can feel the first, but not the second part.

Now, it will probably also become clear why with grossly mis-tuend filters, potentially both directions can feel somewhat OK: Both cues are present at certain times and if you learned to ignore the quick (but still wrong) initial jolt, then you will be able to enjoy a loooong provers cue above the threshold of detection, when instead there should have been an even loooooooooonger adverse cue hidden below the threshold of detection.

Congratulations! If you made it this far without falling asleep or throwing up, you're now ready for the tragic end of the story:
Unless you have A LOT of heave travel, like 1000mm or so, you can almost ignore vertical acceleration completely . The vertical axis is the one that we're least sensitive for and the only one on which we cannot use gravity for help (as opposed to lateral and longitudinal acc. through the tilt coordination channel).

Long answer,... sorry

Cheers,... Dirty

@Dirty

Thank you so much for this.
I read it over and over today and I looked at these graphs.
I was doing it wrong apparently....

The way I understand it now is, when I pull the stick I will feel positive G's, my rig has to move up.
The curvature of the yellow line from 0 to the 1st inflection point shows me that if the rig moves up fast enough I will feel an increasing pressure of the seat on my butt, similar to being on a lift the moment it starts going up.
This is the initial Jolt you are talking about right?
Passing the 1st inflection point the rig is still going up but not accelerating anymore and will continue up till the axis limit.

I hope I got it right.
Thanks a lot for taking the time to explain this, I am sure many forum users will find it very useful