Writing a motion cueing software from scratch.

Those acc x,y,z are the same as the g loads. You can superpose the curves if you don’t trust me ;-)

I think I got it!!! 90% sure. Please check!!

1. Do you use a free spinning nose wheel? If so, the forward kinematics of it might interfere. Make sure you have "Nosewheel steering" assigned to an axis.
2. Try exporting the data that Austin provided under "Motion platform stats". That's what you need. Yes XYZ are identical, but QPR are not identical to MLN.
3. Try displaying the graph data at 99.9 fps (that's max). It will smooth things out.

If it still persists, try the taildragger aircraft...


If that is symptom free, it's not the friction modelling, it's the nose wheel.

Right!

I never said XYZ were different but QPR are different from MLN

...I corrected my previous post.

You're a programmer aren't you? If you can't get what you need then why don't you make your own plugin(s) for your software to work with instead of using Simtools? If you're mostly interested in x-plane it shouldn't be that difficult to make only one. I'm a dummy compared to you guys yet I was still able to write my own motion software and make some plugins for it. I just need Simtools to get access to games I don't yet have the ability to gain telemetry from myself if I want to have motion with them.

Even better would be if you guys would develop an open source open license plugin structure that everyone with the ability to find telemetry in games could use to contribute their efforts. Then you and anyone else that has the ability to write motion software would have plugins we could use directly instead of being shut out. If that were to ever happen then we could really get some diversity on this open to all diy website. Since you're already writing you own filters etc. why do you need Simtools except for its plugins?

I would say, it’s like a sandbox. It’s cool to go there for two reasons. You can share toys and talk with a mate. That’s why we can’t get rid of simtools. )

Good try but...

1.)
For rudder assignments, unfortunately I see no other options than “yaw” and eventually “Nosewheel Tiller” which is not a solution.
2.)
“Graph data is for the “Data Output Graph” resolution. It doesn’t affect motion I think but I might be wrong.
3.)
Just tried the “Stinson L5 Sentinel” - the same spikes on the graph.

Fair enough its your choice. It just appears as more improvements are announced for Simtools the less satisfied you become.

I mean... maybe the side spikes are less present with the Sentimel but the longitudinal are there if you brake just a bit to hard. You have to apply like a little little tiny bit of brake to avoid them

Oh not at all! You’ve got me wrong. I am applauding with hands and feets all announced improvements.

I just try to contribute and advise what could be done from my point of view. That’s all.

Maybe we should move this over to the X-Plane section, because I 'd love to continue this. Open a new thread there. I think I can contribute. My Cessna behaves pretty plausible now as far as I can tell.

Not sure if I understood correctly still trying to answer.

Some good points in there! I'd love to see that happening if I weren't a total noob when it comes to programming. I actually bought a C# book in Dezember, read only 100 pages and that's about all I know of programming. I'm struggling to get even a clickable button to work reliably. I'd love to see this develop into an open source, community driven, free motion simulation software, but I simply lack the skills to do that.

Basically my dilemma is this: I know exactly WHAT I wanna do. I also know exactly HOW I wanna do it, but I have pretty much no tools available to implement it in code. Every step I take is something I learned from scratch just a few days earlier.

As I guess you have noticed, I have no problem arguing my points passionately (but rationally!) when it comes to vehicle motion dynamics, but I strongly doubt that anyone will ever hear me making a claim about programming. Absolutely not my area of expertise.

And because a picture says more than a thousand words:

...this is the area my software (Nutkicker) is targeting in the near future. Very few sims (DCS, X-Plane, P3D and all others that allow export of data via Network) but a very deep integration between Sim and motion platform. I prefer depth over width anytime.

Oh no. Quite to the contrary! Like @hexpod, I applaud with hands and feet if Simtools develops. Better Simtools --> more People --> more revenue for Simtools --> better Simtools.

I'm in this only to satiate my appetite for knowledge. This is porn for my intellect!

---EDIT---
Deleted the post because of an error in my arguments!

---EDIT---
The assertions were correct (afaict) but the conclusions were premature. I will re-post further down.

After @Dirty has shared his 20yo flying experience and knowledge, I got totally convinced that using the "Euler angles" for our platforms is not only useless but also unrealistic.

I mean if you don’t have the choice because of telemetry lack and it is your only option for pitch roll an yaw to use Euler, than it’s fine.

It is absolutely great that @pmvcda has the "transform swap" kinematic option (When enabled I call it "local kinematics") which makes the translations dependent on rotations. (No need of @Dirty ‘s ghost platform approach I think)

@value1 could got mislead by myself (apologies) concerning the x-plane telemetry.
After checking it again and again, I am pretty sure the forces are local and not world!

Concerning the telemetry mapping I prepared another experimental plugin where I use the rotational velocities on the Pitch Roll and Yaw instead of positions (Euler angles). @yobuddy no any need of any "roll over" in this case!

Additionally, on the Extra1 I am doing the tests with "landing gear forces" trying to mix them inside Simtools matrix with the "g-load norml"

I believe this is the right way to go if you want a good separation between "ground model" and "flight model" (more on this maybe later if somebody is interested)

From what I can see in my tests, the result is simply mind-blowing. Simply this is it!

I use Simtools LPF for only "G-load norml" and FLYpt HPF for the landing gear forces.



Thanks

@value1 , if you have an idea how to properly scale to the center the gear forces please share because « /2134 » is not a solution

Thank you

A quick little update on my progress:
I have (quite sloppily) implemented a little recording tool to write the motion data stream coming from the simulator into a file so that I can play this stream back when I'm on my laptop and don't have a sim available.

It also comes in pretty handy when tweaking and tuning the gains, because it allows you to define "exemplary" motion snippets, like Takeoff, S-turns, Acceleration-deceleration. Then you can play them back in a loop and you have a repeatable situation to judge the effects of changes of settings on the motion.



...and a little vision for the future of Nutkicker: It would be cool to be able to define an "edge case track" that would contain all the manoeuvres that you want to be "in scope". Then the "tuning assistant" could pump this track through the motion cueing algorithm in a 1/100th of a second or so and you'd get an IMMEDIATE display of which axis are over- or under-utilised. Which DOFs are most likely to hit an end stop etc... No need for trial and error anymore You could see changes take effect in real time. It could show you immediately if you would've hit an endstop in that exemplary track.

You could even set a tick mark "[ ] Background analysis" and the software would permanently analyse ALL of your flying/driving and tell you which DOFs are under utilised based on dozens of hours of data of your kind of operation in your vehicle.

...but that is a. l o o o o o o o o o n g way from here

Dirty

Glad to hear that!



The forces and moments from the landing gear should already be considered in the sum of all forces/moments that x-plane exports. The problem I guess is only you don't get to see them because you filter them out. (For good reasons)

BUT.....

...you could use the amount of "weight on wheels" to blend over between two completely different sets of gains. Without WOW you have one set of gains, with WOW you could have another set of gains. And then you could interpolate between the two as more and more weight goes from the wings to the wheels on landing.

That's an example of "conditional processing" that I mentioned in my first post. It could also be seen as the first step in the direction of "adaptive cueing".

Dirty

Man! Your take-of motion is commented like a legendary final’s champions league soccer match. Love it!

Can you explain in more detail what you would like scaled?
And what does /2134 stand for? Just curious.

This is just a desperate way to overcome the lack of HPF.

I thought that doing a simple arithmetic could give me a half solution waiting for a properly working HPF.

Like subtracting 1 from G-load to bring the platform to the center of the heave, we could maybe subtract the landing gear force in the similar way.

The small issue is that it is dependent of the aircraft type weight and its CoG.

Subtracting 2134(lb) from the landing gear variable, brings more or less my heave close to the middle position but it works only for Cessna.

I was thinking we could find a solution (other than HPF) which could work for all types of planes

Ahh, got it

Well there are two ways:
1. High pass filter
2. Differentiator

I'd prefer a HPF, but what comes out is very similar anyways.

I said I wanted to correct the datastream for offsets in the pilots/drivers positions. Turns out this was easier than I thought: About 1 hour and then another for the 3D illustrations

If someone wants to correct for those offsets, you will just have to add 3 accelerations (Ax, Ay, Az) to the exported accelerations. These are dependent on the angular rates (w) and the angular accelerations (w°) of the vehicle.

May be interesting to know for @pmvcda:
Correcting in this way will not eat away your translational operating space








...isn't this beautiful:


oh,... and I haven't tested those yet!!! Use with caution.
oh,... and they're created in a right hand coordinate system,... but I think it shouldn't make a difference.

Dirty