FlyPT Mover 3.5.3

We have developed a motion controller with ethernet, and it's continuously improved. I'm already using it on two 6dof and works very well.

https://www.xsimulator.net/communit...utput-motion-platform-controller-board.16554/

Ok, the mover is working now. We get input from the XPlane source and the output values look good. I can see movements in the 3D viewer. Axis position values show changes and return back to the neutral position after some time (wash out). We still had some problems with the motion4sim controller not accepting the serial output but that seems to be a minor issue with the output string format. We've contacted Denis and I think it's easy to fix.

One problem with the Mover seems to persist: It does not load the last module configuration after startup automatically. It always comes up with a blank window. We have to go to the menu -> local file -> open each time we re-start the software. It behaves the same on 3 PCs now, so I think I've done something wrong installing PlyPT Mover. Where is the file for the default setup stored? Windows 10 is known for sometimes being a bit picky with access rights and file visibility.

And I think we found another small bug:
If we disconnect the sources in the POSE window (checkboxes on the right) we can move the In/Out value sliders and the rig in the 3D viewer follows the commands. If the sources are connected, of course, the sliders are disabled. It think this should behave the same in the RIG window. If the POSE is disconnected the "actor position test" sliders are enabled. If I move them I can see the "Bit output" fields changing but the viewer does not show any movement.

But those are only minor issues. Alltogether, great software! I've sent a donation.

Ah, that's interesting. I especially like that all the inputs and outputs are differential 5V (for step/dir) or 24V with opto isolators. That's better suited for industrial components and should provide better noise immunity and protection against shorts or overvoltage. I'm always a little bit scared when connecting something to the 3.3V inputs of the sim4motion controller which are routed directly to pins of the CPU.

However, I have to admit that I'm currently not in the mood to test something new that is not fully finished. I have trouble reading manuals that are not fool proof and I hate having to troubleshoot software configuration browsing through forum posts because there is no (up to date) info in the manuals or I'm too stupid or ignorant to interpret them right. But that's my problem, not yours. Keep going!

Rather than launching Mover directly, launch the saved config file instead by double clicking that (or a shortcut etc). ie; Think of it like opening an MS Word document; double click on the .docx document to open it, rather than launching MS Word and then having to File->Open to open your document.

Ah ok. I just thought it should save and load the last settings automatically. I read in post#2 on page #1:

But if that doesn't work I can double click on a saved file, no problem. It's only not as convenient as automatically load/save because I can forget to save.

My apologies if this was already mentioned somewhere in this thread, but is it possible to create new sources yourself similar to SimTools plugins? I'm looking at using Space Monkey to get some telemetry out of Mechwarrior 5 and while Space Monkey uses the CodeMasters output format (Dirt 4, etc.), I'm not sure how to trick FlyPT into thinking that Dirt 4 is running when it's another game. Maybe it's as easy as renaming Notepad to the same name as the Dirt 4 process, but I'm not sure how FlyPT knows a game is running or not to connect to it.

Glad you asked that. I've been wondering what we'd need to do to get a Source module for KayakVR Mirage and was about to ask @pmvcda about that. KayakVR is UE and uses a 3rd party plugin to provide telemetry data.

Found a bug/feature on the latest release 3.5.3:
Was trying to debug why games were running with poor fps and a lot of stutter, maybe some graphics flashing too through the game, even with fullscreen. Three times my PC completely shutdown mid-game. Event viewer pointed to windows kernel file and flypt.

I figured out that if i have multiple windows open inside flypt, it will ruin all performance in-game! Now i Hide all windows inside flypt and games run like they should! No sudden poweroffs too.

On another note about EA WRC:
Anyone have figured out the data types of each channel in their telemetry file? (Just afte writing this found out about the telemetry doc and maybe the description files are also in readme/channels.json)
By using previous discussion in this thread(page 186) i got it to work somewhat on x,y,z-accelerations, but i think i am off a bit on the offsets and data-types used.

In my testing I used float(4bytes) for the accelerations. Offsets were 144, 148, and 152. I think only my longitudal (x-direction) acceleration is working with these. I think i am mistaken.

I am mostly interested in the data types and correct offsets to use for these:
-lateral acceleration (vehicle_acceleration_x)
-longitudal acceleration (vehicle_acceleration_y)
-vertical acceleration (vehicle_acceleration_z)
-yaw speed
-roll position
-pitch position
-all suspension data

Not a bug. Flypt suggests to close windows down while in use because it will have a performance hit if open

That's correct. I'm sure I came across that very recommendation. While I still do so in MSFS, I stopped so in DCS. The reason was that I felt that I needed to reconnect the source module more often than with the windows open (at least reconnecting was easier). Disconnect always happens when I pause the game ─ less often with 'active pause'. For which there is probably a better solution. Anyone experiences the same? I use 127.0.0.1 with the multithread version of DCS...

Hello Pedro (@pmvcda),
I'm currently running some analysis to find out why we have so much noise in out motion signals (when using the motion4sim controller). The servos are silent while standing still or during homing but make a lot of noise when moving. The whole rig rumbles and rattles. Of course, I could simply add more filtering but I'm the sort of "scientist" person (say nerd) who prefers fighting the root cause instead of the symptoms if possible.

So here is what I've found out, so far:

Code:

010180002C18 id=930b deltaPos=-2166 deltaTime=1989 velocity=-1.089
010180002452 id=930c deltaPos=-1990 deltaTime=2028 velocity=-0.981
010180002273 id=930d deltaPos=-479 deltaTime=616 velocity=-0.778
010180001A2A id=930e deltaPos=-2121 deltaTime=2362 velocity=-0.898
010180001364 id=930f deltaPos=-1734 deltaTime=2298 velocity=-0.755
010180000F1B id=9310 deltaPos=-1097 deltaTime=1665 velocity=-0.659
010180000AAE id=9311 deltaPos=-1133 deltaTime=2006 velocity=-0.565
010180000706 id=9312 deltaPos=-936 deltaTime=1992 velocity=-0.470
01018000041F id=9313 deltaPos=-743 deltaTime=1997 velocity=-0.372
0101800001FC id=9314 deltaPos=-547 deltaTime=2002 velocity=-0.273
01018000009C id=9315 deltaPos=-352 deltaTime=2030 velocity=-0.173
010180000001 id=9316 deltaPos=-155 deltaTime=2197 velocity=-0.071
01017FFFFFFF id=9317 deltaPos=-2 deltaTime=4871 velocity=-0.000

Now, I'm using UDP output (prototype of my own controller). From left to right you can see the raw data, id is the identification counter in the IP header, deltaPos is the difference in position compared to the last packet, deltaTime is the difference of the time stamps when the packets arrived and velocity is dp/dt as floating point value. The Position comes from a LOOP source so there is no delay or jitter cause by the CPU load of a game software.

Most of the time the UDP packets arrive quite regular with only small variations of some microseconds around 2ms. No packets are lost otherwise I would see missing numbers at the id counter. From time to time a packet arrives early (for example deltaTime=616) or late (deltaTime=4871). Interestingly, PlyPT Mover seems to compensate this at least partially by also providing al lower or higher deltaPos so that the resulting velocity stays almost the same.

This rules out network transmission delays as root cause. The variations must come from somewhere inside the PC (windows task scheduler or something). That is not a problem at all if we are aware of it. I think the best solution would be to add a timestamp to the output. This way the motion controller could calculate the "real" velocity which is defined as moved distance divided by passed time. A timestamp from inside the simulation software would be much more accurate than the timestamp from the network MAC because additional routing delay would have no influence.

Would it be possible to add a timestamp to the output string, e.g. something like
<255><255><Axis1a><Axis2a><Axis3a><TimeStamp><10><13>
with resolution in microseconds?

Guys, sorry, I'm changing house those days, please give me 2 or 3 days more and will come back full on it

Certainly no need to excuse, take your time. I just have a question I must get off the leash.
Do you still recommend 2ms for calculation rate with a loop intervall of 1 like said in an earlier post?
And speaking of variables: May it be possible in future Mover versions to change (and merge projects with different) calculation rate without the necessity of going into individual filters and change their values?

Well, answered my own question a little bit today. Played around with it some and found you don't really need to trick anything since you can tell it to manually connect, so the only thing I'd be missing with my current setup is a way to auto-connect to Space Monkey. I have enough other stuff I have to do in the right order though that this probably isn't really an issue. Would still be a nice future feature to be able to add your own sources manually though.

Hi

did anyone tried this : https://github.com/PHARTGAMES/SpaceMonkey
and dial with flypt mover ?

thanks

Hey , you move from Portugal to Montreal Canada !!
Do you need help to switch ( transport ) your RIG here
My rig still goes very well ! Thanks

No, but thanks for the tipp! I have first read about Space Monkey in this post, but thought that 'Space Monkey' was a game title...

Presumably, the telemetry is being exposed via UDP? Can't that be captured and pushed to FlyPT Mover?

Yes it certainly can. My platform manufacturer (GforceFactory) actually already integrated KayakVR support in his firmware, so it's not that important to me. I just like to tweak a bit to my likings. And then there is the virtual tracker in FlyPT...

Hi, I'm new to this forum. Reading some previous posts, up until about 11 months ago, I saw that a new version of Flypt was supposed to be “imminent” released. Could you tell me if a new version is still planned? approssimative Release time?