FlyPT Mover

It does accelerate at 9.81 m/s²

Unless you take into account the air resistance acting on the object that has been dropped, the object will eventually reach a terminal velocity without accelerating anymore.

@

I was already starting to wonder why no-one picked up on this But @hexpod is still correct.

Like I mentioned before, many problems can be solved by...

1. understanding the accelerations present on board the vehicle and then...
2. understanding how they are filtered to drive the rig.

In this case the misconception arises from 1.

Do an experiment with your phone:
- Download the app Phyphox
- Take a look at "Accelerations including G"
- Wiggle the phone around a little (just to get the scale adapted to higher values)
- Throw the phone up into the air and catch it



You will see that the phone does not measure ANY accelerations while falling freely.

The opposite is the case: It will START to measure an acceleration as it approaches terminal velocity

I know this is counter-intuitive, but rest assured you are in very good company if you have a hard time fitting this in with the rest of what you know about the world. When asked what his greatest achievement was, Einstein answered "the equivalence principle". It was his realization that an acceleration is not necessarily a change of velocity, but can also stem from the curvature of space. More precisely: The curvature of spacetime under the influence of a large mass. Curved space and acceleration are the same thing --> equivalent.

Here's the core of the misconception:
You, almost everyone else and certainly your computer think in "Euclidian space" while the real vehicle moves through "curved 4D spacetime". The guy coding the physics model of the sim knew this and outputs the accelerations as if they WERE measured in curved space though. At least in DCS and X-Plane. FSX, P3D do not! But luckily @pmvcda has done exactly that conversion for us in those games and provides accelerations with gravity for us.

I'm not saying everyone desperately has to understand all of this to build a motion sim, but if you want to understand the accelerations present on board the vehicle, then you will at some point have to face this Euclidian space <--> spacetime thing.

PM me if you want to know more, you will never see the world the same again once you accepted this concept.

Watch this!
And maybe even this.

Dirty

You have to take it from the other side.
Sitting on earth, you get permanently accelerated. You are so use to it that you don’t notice it.

Once you want to accelerate an object, it is supposed to get weight. In free fall, the weight is 0.

Edit:
This little vid can be helpful :

I'd like to mention (to everyone reading this) that if you've ever heard that when astronauts and orbiting objects are weightless in space they are actually in "perpetual freefall" and that didn't make any sense to you, this conversation should be starting to enlighten you on that as well. =)

My lessons in orbital physics came from these guys! Crazy but true!

I'll look at the videos you linked as I'm curious, thanks

• the explanation for the phone app result is the following:

the phone sensor measures a force applied to its cantiliver piezzo
it doesn't measure an acceleration along an axis (ddx/dt²)

while free falling, gravity and acceleration substract,
hence phone sensor says = 0

it's the feeling of weightlessness

• In Newtonian physics, free fall is any motion of a body where gravity is the only force acting upon it.
  According to this definition, the sentence "a free falling object doesn’t accelerate." is false. But apparently you're using "free fall" not in a strict sense. So we disagree

https://en.wikipedia.org/wiki/Free_fall

I Think we don’t need here to get to deep in the 4d geometry which’s pretty complex to imagine but we could simply abandon the acceleration concept as being relative to gaining speed but take it rather in terms of forces acting on the object.

Again, in free fall the force is 0, resting on ground, you accelerate 9,8m/ss

@RacingMat @Dirty @hexpod I'm going to try to get us all on the same page.

The problem here I think is a common one. We oversimplified things a bit to make things easier to understand for our purposes, and that oversimplification has caused confusion.

We are way off track in terms of this having practical application in the context of the conversation here, but it seems we need to resolve this debate. =)

Gravity isn't really an ACTUAL acceleration. Acceleration is just the only practical way to measure it and account for it in your maths. The measurement of Gravity as an acceleration refers to the acceleration the force would cause if there were no other forces present, and the fact that gravity feels exactly the same as an actual 9.81 m/ss upward acceleration. It is not because all objects subject to Gravity are actually accelerating by the proper scientific definition of "acceleration". The reason we describe it this way, is that unlike any other "Force" Gravity exerts a quantity of force directly relative to the mass of the object being acted upon. That's where the science gets wacky. Read here if you want to understand using acceleration as a measurement of force (which is what we are doing) more clearly: https://en.wikipedia.org/wiki/G-force

I find that usually when intelligent people disagree, it's a matter of them each using a different definition of a term being used in the discussion. In this case "acceleration". This is why scientific definitions exist. =)

Those who are saying that an object at rest on Earth's surface is accelerating at 9.8 m/ss and that an object in freefall has no acceleration are referring to measured acceleration which is actually "G-Force", but just like actual acceleration is measured in m/ss.

Those who are saying that an object at rest on Earth's surface is not accelerating, and that an object in freefall is accelerating are referring to the actual proper scientific definition of acceleration, and as such I have to say are technically correct. Technically correct, but not really correct in the context of the original discussion because we were discussing measured G-Force, not acceleration. More importantly, looking at it this way will confuse the issue of understanding motion sim telemetry because for this purpose specifically gravity MUST be looked at as an acceleration, and be included in our telemetry. G-Force is what the numbers coming out of our sim telemetry are expressing. This is the measurement of acceleration forces acting on the vehicle and it's occupant.

What really is important here is that a 1G (9.81m/ss) in the opposite direction of gravity always results in no measurable acceleration. That justifies the oversimplification of stating that "Gravity is an acceleration" for practical purposes. There is simply no other good way to describe the force applied to an object by gravity.

We can't use an actual measurement of "Force", because a measurement of Force will be different for every object discussed due to the variations in "Mass". Remember, F=MA! If you want to use a measurement that is the same regardless of the mass of the objects being discussed, you have to measure it as acceleration.

Edit: Fixed a dumb and embarrassing mistake hopefully before anyone saw it.

@hexpod @pmvcda I just started reading at the beginning of this thread to help a friend troubleshoot why his sim isn't moving and found the answer.

I had forgotten that adding the "cropping" feature was my idea/request in the first place. My need for using both in and out filters was how I was getting by before input signal cropping was added.

So, since cropping was added you are probably correct that the input gain feature may be redundant and unneeded.

Hey guys. I'm trying to help a friend get FlyPT mover working on his 6DOF.

His motion sim uses Ethernet UDP. Do we have a way to send the output of Mover via Ethernet UDP yet? If not, is this something we could reasonably add?

In the UDP output of FlyPT Mover there is no place for the IP address of the sim or an option for "network" such as in SimTools so my best guess is we just haven't had a request for this to be added yet.

Also @pmvcda Because I have not had a working motion sim for many months I just loaded it up for the first time in a long while. The new features look fantastic! It will be interesting to see how I have to set it up for the G-seat.

I do have one small suggestion @pmvcda just to help brand new users. When a new person loads up Mover for the first time they see a window with all of the options dim and grey so there is no obvious way to start. I'm certain this causes some people to just give up. I would recommend you add text to give them a hint to right click. I made an image to show my suggestion.

The udp output, broadcasts data to all ip's, so you just need to set the port.
It also broadcasts to all the network cards attached to the pc.
The idea is to make it simpler to use.
I will add the text on the empty window.
Curous to see your rig working.

I must assume that I am the person with network connectivity problems that Trip mentioned. Since he is currently busy I wave hands and say "hello".

To beginn with I tried to migrate my (working) SimTool settings to Mover's Output module: The port #, the Output String, I set Interval Loops to 10 to match the 20ms "output rate" (?) and set type to "Binary".
I didn't find an equivalent to the "Output Bit Range" in SimTools (which I have to set to 16). And, of course, the IP address of my rig (which is displayed in its attached dash).
But if I understand you correctly that isn't necessary because Mover spreads output signal to ALL connections, anyway?
Now I see that Mover indeed reports 3 "Network interfaces". What intrigues me slightly is the fact, that this number remains the same all the time, no matter whether my rig is powered on or off.
The dash of my rig (a GforceFactory EDGE6D) reports active connections by the frequency number that must be > zero. It now remains zero all the time. Of course, moving the "actuation position test" sliders in the Rig module has no effect.
I appreciate any ideas how to move on.

First, bit output is specific to the actuators. You set it on the rig. Usually all actuators on the rig use the same bit output.
When you specify the actuator(axis) in the string, Mover outputs the value in the bits specified on the rig.

The 3 you see in Mover is the number of network boards on your PC.
One for WiFi, another for wired LAN, and the last probably for Bluetooth.
This is just an indication.
To see if Mover is sending data out, you can use an app on your phone to see if you receive data.
Something like UDP monitor:



On the top left, set the port you use in your rig, and press the button to receive.
See if you get data from Mover.

It was you indeed. =) I'm sure we'll get it working for you!

@pmvcda does the actuator numbering in Mover now match the numbering in SimTools? IIRC it was different.

As for seeing my rig, it will be a while. =( Now that I no longer have my father's garage available to work in, I have to make a usable shop to work in on my own property first before I can resume work on the sim. I might be able to squeeze just enough space to work in my current garage so maybe I don't have to wait until after I actually build a new add-on shop space but even this will be a month or more.

Those orders are a mess...
I kept my order, but in the Thanos output, if you select the rig, the output is generated with Thanos order.
And you are not alone in the rig, I'm reorganizing my cables and electronics for almost 2 months... When I get to the garage, there's always something extra to do.

The monitor app DOES receive packets as soon as I "connect" in Output::UDP and stops when I disconnect.

My output string is copied from SimTools and reads: <Axis1a><Axis2a><Axis3a><Axis4a><Axis5a><Axis6a>
I don't need a start or stop string in SimTools.

So it should be working with the rig. Where you able to connect to the rig?
You have to set the correct bit output in the rig module.

FS2020


(This is the source in the future version of Mover, you are not getting this in the files I'm sharing)

So, I'm working on a new Mover, but time is not much and I'm having some problems with new features.
Since the connection to FS2020 is compatible with the P3D source, we can use a small program to connect Mover with FS2020.

So download the attachment and put those two files anywhere.
-Start a flight in FS2020
-Run the program FlyPT_FS2020.exe
-In Mover use the p3D source and try to connect

Seems it's working well although there's some problems with simconnect and frame drops.
Asobo/Microsoft are aware of that and a solution is coming soon.
The program uses a basic workaround to reduce load and avoid the fps drop (forces updates at 60 fps).
FPS drop can still happen if you are using another program that requests data with simconnect.

This is still WIP. Any problem, please report.

I want to share my settings for DCS World, or rather for helicopters in it. I am completely satisfied with them at the moment.

Very happy to hear this! When I get a chance I'll have to look at your profile.

That aside though, the profile doesn't tell us much without knowing the details of the rig you are running it on! Might you share photos and maybe a description of the type of rig, motors and electronics, etc. you are using to go along with the profile upload?

Great stuff, DCS helicopters are the best, hands down!

which helicopter do you fly @Trip Rodriguez