FlyPT Mover 3.5.3

Hello,

I think I have a problem using the interface (I'm trying to switch from the previous flyput interface to this one)

I'm using the lastest 1.7



The problem, is that I have 3 arduino for my 6 actuator, in the old version I used 3 = 2 actuators in each ports.

I'm trying to do the same, but as soon as I build a second serial interface, the formated output is the SAME for all the ouput

In the screen cap, you can see I added a bunch a fasle caracter in the upper interface and there are in the debut of the lower one ....

It seems that I canno't setup more that 1 formated output

Am I doing something wrong ?

Looks like a bug. Sorry.
When I come back, I will clean all the code, with more testing and attention.
All the last builds where made in a fast way trying to correct some speed problems. Instead of solving them, I added more problems...
That's a static variable because of the threads....

Enjoy your holidays, you already made so much for the community

This cue should come from the sway axis. Gravity is a constant 1G acceleration away from the ground. When you are flying knife edge etc. that 1G (in the telemetry) is pulling you to the left, which would be cued via sway into roll tilt coordination.

Of course, tuning is always an intricate balancing act, so trying to get a good cue for this without getting excessive cues during flight is something I haven't really had the time to battle with much yet.

Hey Trip,

I will have a go at doing DCS today. Are you able to send me a screen capture of your Pose screen for DCS that worked best for you?
Thanks

My poses are still a bit of a mess, so I wouldn't want to post an image and have people fail to read the caption. If you really want what I've got so far I can PM it.

So here is what I've got so far. PMVCDA you aren't allowed to read this stuff until your vacation is over! Go away!

Surge and Sway appear to be swapped still, so use "lateral speed" for surge and "longitudinal speed" for sway. I think Yaw might be swapped with something too. Possibly other things. I'm trying to systematically test each DOF to make sure it's behaving as expected. Next session (theoretically late tomorrow night) I'll be getting right back to that task.

I seem to have a really really odd thing going on with surge that has me very very confused. I don't see how it should be possible.
I set up surge so it reacts brilliantly to the throttle, but when I do...

...pull the stick back to start climbing, and I get a large forward acceleration response?
...push the nose down into a dive, and I get a deceleration.

So it seems like that is working backwards. But....

You know, I just realized something. I think it was @Dirty that said he thought something was not quite right with IAS. I wonder if this could be related? I mean, in theory I'm not using IAS, I'm using acceleration but maybe there is some kind of connection.

I'll have to try watching the airspeed on the instruments under the same circumstances and see if it contradicts that seemingly backward cue. I hadn't thought to do that yet.

Also a Feature Request: @hexpod has a brilliant feature in his software that allows you to specify a maximum angle of the actuator rods to the upper platform. That feature would give me a measure of peace of mind.

@Trip Rodriguez , I think we're at about the same point. I got mine working mostly fine today.
If you think that surge and sway are the wrong way around, then switch them in SimTools.
If you think your surge is working the wrong way, then put a minus in front of the value oil the "out gain/flip" to fix it.
I'll have another fly and screen cap my pose window if it starts to feel right...

That's the problem though, if I flip surge then it will respond in the correct direction when I climb or descend, but will respond backward to throttle changes! At least, in theory. I definitely have to do some more testing before this is worth discussing. As it stands now, I might be spreading misinformation. D=

I'll post a screen cap when I think I've got things feeling good too.

Oh, and I'm not using SimTools, I'm using the FlyPT direct DCS interface. I figure one less software layer is a bit less latency and processing power in the equation.

For tuning what I've mostly been doing is tuning the "in" gain until the slider moves most of the way across the bar in big movements, but doesn't ever go red. Then adjusting the "out" gain until the cues feel about the right size. Of course, every time you change the gain settings, you have to change the filter settings and then change the output gain settings again... it's a time consuming process tuning one of these things.

Also, until we get a way to crop the incoming values in FlyPT (like I used to do with the Tuning Center) I have some of the axes with some pretty wacky settings trying to avoid cues that are too big, without making small cues too small. I find cropping really important if you want to tune it for normal flight, but also don't want to get harsh, unrealistic feeling cues when you pull the stick hard or whatever. I'd rather have a 2G and 5G movement feel nearly the same than have the 5G movement feel like I drove over a speedbump at fifty miles an hour.

Awesome job. Looking forward to trying it out soon.
@pmvcda Any plan include X plane as an available interface as well ? I know it can be done using SimTool (that is the way I am using it currently) but as @Trip Rodriguez said: " I figure one less software layer is a bit less latency and processing power in the equation."
Thanks in advance and enjoy your holidays.

I know it seems counter-intuitive, but this is actually the desired behaviour. Technically speaking "System behaves as designed" ...for good reasons!

Keep in mind: "Acceleration" does not necessarily mean "changing airspeed" ;-)

I still think there is a bug in DCS concerning LoGetIndicatedAispeed() and LoGetTrueAirspeed in non-zero wind conditions. However, this is certainly not at play here.

OK, that is good to hear but now it's time for @Dirty to explain WHY this is the desired behaviour. Dirty, you should know by now that I always want to understand as much as I can. =) I can understand that when initiating the maneuver the way it's working makes sense but I'd expect it to change to what I describe above after a few moments.

My understanding was that in a steep climb the continual [loss of airspeed = an acceleration backward], which counters [gravity = an acceleration forward] and that this is why you don't feel like gravity is pulling you back into your seat. The two largely cancel one another out, to varying degrees of course depending on the rate of airspeed change.

Of course, there are aircraft that can climb without losing airspeed, but that is not within the scope of this conversation so far.

Wait! Never mind! I get it! Just had a sudden epiphany.

Let's say you were flying level, and pulled back the stick into a vertical climb. Airspeed might decrease but that's not what is relevant. What is relevant is the fact that you have gone from zero vertical speed (+1g) to a rather large amount of vertical speed. You accelerated upward. So, the deceleration from losing speed would not be felt until the vertical acceleration stops and deceleration begins... which would take a bit of time.

If you continue to climb vertically, lets say until you stall, then is when you subtract the deceleration of the aircraft losing airspeed from the 1g upward acceleration of gravity. If your change (negative acceleration) of airspeed gets to 1G you should feel weightless more or less, and if you are losing vertical speed at a rate greater than 1g you will feel whatever that acceleration is minus 1g which is back to what I described above.

So, the real question then is what the acceleration numbers look like during this vertical climb. What is the greatest vertical acceleration as you transition from horizontal flight into a climb, and what is the peak negative acceleration from losing airspeed to gravity in the vertical climb. I bet the positive at the beginning is well above 1g, and that typically the negative acceleration as you approach a stall is generally less than 1g so you would never get a backward surge cue. At least not until the stall occurs. I'd have to sit and think for a bit on what the forces would be like during a stall, but there is no need and I've got work to do. =)

The best part about all of this, the way we are doing things now, as long as the telemetry data is correct, the cues should be essentially correct. As demonstrated here with the cues I thought were wrong.

I do also realize that the deceleration on the horizontal axis when this happens will be high, which should be a rather substantial upward heave cue.

PS- I'm surprised nobody has gone on a rant about using the term deceleration, when in truth it's an acceleration in the opposite direction. =D I hesitate to use it myself, but it is much shorter to type!

Finally got movement !

The plugin for rFactor does not connect at all I've tried reinstalling the plugin but nothing happens at all it just will not connect. Old program still works great with it.

The plugin for assetto corsa is just savage as hell !! I dunno what to do with that apart from change every setting to try and smooth it out cause its bloody awful.

Sorry, it's completely messed up right now.
Wanted to make some changes before holidays and was able to break everything.
I will contact you next week, to try adjusting the settings you have right now to the new program. They are different, but for the better. Now it's using same units and scales for all games, so setup for one should work on another game if forces are in the same range (same physics and between same type of game).

I realy wanted your feedback. I know you where able to get some good sensations, and I want to reproduce them with Mover.

Your expectation is wrong ...but wanting to understand is still good!

When you pull back on the stick, this is what happens:
AoA increases --> Lift increases --> G-load increases -->Flightpath angle changes

1. Short term: The combination of high AoA and high G-load alone will lead to a perceived longitudinal acceleration while the aircraft is in the pull-up manoeuvre. Lift acts perpendicular to the free airstream (per definition), but since the aircraft has a high AoA, part of that lift ( sin(AoA) * G ) acts along the aircraft longitudinal axis. This acceleration can even exceed the acceleration from the engines at full afterburner. It costs a lot of energy to do that (maybe more than even the afterburners can supply) so the aircraft will lose energy (speed).

2. Long term: Even after the pull-up manoeuvre the perceived longitudinal acceleration will persist, because the aircraft now has a lower airspeed than the equilibrium-speed it had before the manoeuvre. Effective thrust is higher now (higher speed difference between incoming and outgoing airmass flow) and drag is less (due lower airspeed), so all-in-all the aircraft now has a thrust surplus which will sustain the continuous longitudinal acceleration.

Why will this not lead to an increase in airspeed? Because the aircraft is now flying "uphill" and has gravity holding it back.

I know it's not really a straight forward argument, but just "play simulator" in your head. I hope this helps.

Dirty

Thanks Dirty, I appreciate the explanation.

Being told how to fix it is good, being made to understand "why" is much better!

OK I thought I was losing my mind but now I'm pretty sure it's not my imagination. I'm working with the DCS World direct version of FlyPT still, currently on 1.7

The rotational axes seem to be changing places on me.

So right now I have to put "yaw speed" into the Roll field, and "roll speed" into the Yaw field.

But then an hour later (game restart, computer reboot etc. are frequent at this point while I'm tuning) I notice that my cues are doing very odd things and find that they are reversed again! Now I have to set roll speed in roll, and yaw speed in yaw... until the next time and then have to switch back the other way!

This is very very strange.

Also, I think that the DCS export.lua somehow gets broken at times and I have to replace it. I think this was happening if I used the "load file" feature in FlyPT while in the game with FlyPT connected.

Hi,

I'm back.
OK, just forget 1.7, and maybe 1.6.
The code threads are mixing everything. I'm just looking at it right now.
Needs a good look, there are to many interactions in the code.

Sorry.

Update:

-First, sorry for putting out such a bug fest build.
-Well, I used some static variables and they where causing an huge amount of errors, one of them, the mix between values.
-I'm running through all the code, making some cleanup and adding missing locks for variables shared across threads. Missed many locks...
-Detected also some more bugs , being corrected right now...
-Making also optimisations as I go through all the steps. From get game data to final output.
-Really, just wait for the new version there's so much S*** in the code right now

I think I needed this time out. Now I see everything better.
New build is going to take at least one if not two days.
And then, I really need people to test it. Let's put it working as smooth as silk!

Thank's for your patience.

No need for apologies @pmvcda , you are iterating at an incredible rate and we know that we are just your alpha/beta testers at this point so things being broken is expected!

A break does always help a whole lot to find and solve problems.

I will be continuing to test for you as much as I can. Hopefully @hexpod and others can continue to look for the more technical stuff that I'd miss but I'll do my best. I will be back to tuning tonight, around four or five hours after I'm making this post.

I'll probably try to use 1.5 or older, let me know which I should use if you have any suggestion.