FlyPT Mover 3.7.0.26

We have a Source Elite Dangerous HOOK. How it works? ED have API? Have a possible do same for StarCitizen?

@pmvcda What I'm doing wrong? Why plane profile not opened automatically?

Elite uses memory hooks, so any update in Elite can compromise getting the data.
@Wagnard is the one looking for the hooks and shares them online or here on the forum. Mover get's them to get the data automatically and depends on Wagnard work for that.
Star Citizen, from what I know has no telemetry and we have to use the same method, but it's not easy and it's frustrating to loose the data each time the game is updated. Don't count on it.
The alternative is to use the joystick source. There you can assign values to the joysticks motion and move the rig with them.
For example put lateral acceleration on the joystick tilt left to right and then use that source in the pose.



I'm right now working on a bug correction for that module (filters are not updating as they should)

Maybe a bug, need to test (maybe just in the displayed name, usually the name of a file).

Jus a note, what i usually do is to have just one source in the setup and store that as the default.
Having so many sources at the same time might be the reason for the problem and makes everything lag, specially opening a new setup.
The idea is to make a dedicated setup for a specific sim/vehicle and store it in the defaults.
The base Mover default would be the poses, rig, output and some viewers module. When you open Mover you have that base and then add the source and adjust settings, Then you store that setup to open automatically.

Having so many sources might look easy, but even disconnected they use resources, specially if you check them for autoconnect.

I really appreciate all the work done so far on the mover and thanks for adding the "Epic RollerCoaster" back in.

I have a Leaderdream 6DOF steward platform interfaced with UDP using 19 bits (3bytes) for the 6 linear actuators for a maximum of 524287 units (250mm stroke) and Binary Big Endian.
The send string looks like this (adding an extra leading <0> for every actuator as this platform expect 4bytes per actuator):
<85><170><0><0><20><1><0><1><255><255><255><255><0><0><0><0><0><0><0><100><0><R0.A4.B><0><R0.A3.B><0><R0.A2.B><0><R0.A1.B><0><R0.A6.B><0><R0.A5.B><18><52><86><120><171><205>
It works pretty well.

Whenever I finish playing around with my platform I just kill the mover and forget to disconnect and then shut down the whole platform leaving it in the [drivers-position] state instead of the [Park position].
Would it be possible to (maybe optionally) send the stop string whenever Mover shuts down?

I also noticed that on mover 3.7.0.26 the X-Plane11-12 source can't connect (stays yellow) anymore although the X-plane-12 outputs telemetry correctly (on UDP port 4123). It works fine with SimTools V3.
I then saw that earlier versions of Mover had an X-plane11-12 UDP port setting of 49005 and that still worked with that older Mover 3.7.0.17 although my X-plane12 is currently set to output on port 4123.
Could there be something wrong with the UDP port setting on the X-Plane11-12 source module?

I can add that to Mover. But it will wait for the output to really stop before closing Mover.
For XPlane, there was an update with a new plugin. You can install the plugin in the source:



With that plugin it should work better and I added some extra data. You have to apply the plugin to both XPlanes, 11 and 12. The plugin should also work on XPlane 10, but I dont have it, so never tested.

EDIT: If you want, you can get the plugin here also: https://github.com/FlyPTMover/Patches/tree/main

@pmvcda that patch worked! I did not know that that patch button was there!
Thanks for the quick reply.

I know I should just disconnect before closing Mover but I keep forgetting to do that.

Coming soon:

Love FlyPT Mover - wouldn't be able to enjoy motion without it!

I have built and coded a custom ESP32 controller for AASD motors that receives serial data from Mover. When I was developing and testing my code I used Mover 3.7.0.17 and that worked well and I got my code running well with that.

I recently upgraded Mover (initially to 3.7.0.21 and then to 3.7.0.26) and when I create a new profile from scratch the motion is horrible, very jerky, not at all smooth. If I open my old profile (that was created in .17) I click through the warning that it was created with an older version and when I send motion to the controller it's buttery smooth, just like it should be. This is true even if an add new sources or play around with the settings.

If I then save that profile in the newer version (.26) and reload it in my next session (after a reboot) it's back to being very jerky and unusable. If I then load my old profile in the same session (without a reboot) it's smooth again. I can flick back and forth between the profiles and the new one is always jerky and the old one is always smooth.

I've had a look at the mover files but can't see anything obviously different. The setups are the same (for testing it's loop -> Pose from motion -> Three/Four feets (3DOF) -> COM) and from what I can tell all the settings are the same.

The 'send' string in the COM output looks sensible and my code expects Big Endian values (which is the only change I can see in the UI between versions) so it should work.

Is there anything you can suggest I do to troubleshoot?

Thanks in advance!

Hi,

I think the problem is in the endianess. By default its selecting BE and it should be LE.
Are you sure your code is reading it as BE? Because usually ESP32 uses LE. How many bits? 16?
Can you check and give me some feedback please.
In LE for example value 400 in 16 bits is bytes 90 followed by 1 (least significant byte first)
In BE its 1 followed by 90 (most significant byte first)

Code:

uint16_t value;
uint8_t buffer[2];

if (Serial.readBytes(buffer, 2) == 2)
{
memcpy(&value, buffer, 2);
}

the above code in ESP32 (Arduino) is Ok if sender used little-endian (LE)

You can also do:

Code:

uint8_t buffer[2];

if (Serial.readBytes(buffer, 2) == 2)
{
    uint16_t value =
        (uint16_t)buffer[0] |
        ((uint16_t)buffer[1] << 8);
}

Please make sure this is Ok, not saying there's not another problem in Mover. Can be also, but since you say you are using BE, it seems strange to me.
Can you show me the send string you are using? If the problem is not what I said above, need to investigate it deeper.

Thank you for the quick reply! I'm not at my rig & computer so don't have all the answers but can give the following...

I'm not sure it is an endianness issue because:

• When initially loading the old profile it works fine, at which point Mover would have presumably already made the BE decision
• When I tried LE my rig shot up to full height and errored out against the stops (exactly the same way someone above posted)
• Here is the code that reads the serial position data. It uses Serial.Read and puts each byte into a buffer (after two start markers):

Code:

// Big Endian assembly: [High Byte] [Low Byte] -> Converted to mm
                    posX.position_raw[0] = (dataBuffer[0] << 8) | dataBuffer[1];
                    posX.position_raw[1] = (dataBuffer[2] << 8) | dataBuffer[3];
                    posX.position_raw[2] = (dataBuffer[4] << 8) | dataBuffer[5];
                    posX.position_raw[3] = (dataBuffer[6] << 8) | dataBuffer[7];

The output string is two markers (255 255) followed by 4 pairs of bytes (i.e. 16 bit), one for each of 4 actuators. Output string looks like this in park position (midpoint):

Code:

255 255 127 255 127 255 127 255 127 255

The 'code' for that is:

Code:

<255><255><R0.A1.B><R0.A2.B><R0.A3.B><R0.A4.B>

Let me know if that's helpful or if I can send anything else. If I get a chance I'll upload a video of the problem. It does seem to be moving roughly in the correct direction (eg loop back and forth on the pitch axis) but there is a lot of jitter or noise in the movement. Pretty sure it's not a serial/usb issue as it works normally on the old profile, unless the new profile is introducing some delays/jitter when calculating position that then causes issues with serial output timing?

If I'm the only one having the problem though then it would suggest it's something to do with my setup...

Ok, I need to make some checks.
this:

Can you post the original setup (.17) and then the one saved with the last version (from scratch or modified by the new version).
Zip them and put the file here in the forum please

>> If I'm the only one having the problem though then it would suggest it's something to do with my setup...

Now that you mention it...
Today I tested some filter settings and for that in my rig module I switched (the connection to) individual poses on and off and back again. I sometimes noticed some strange heavy amplitudes into red, which the same pose (or the same combination of 2 or 3 poses) at other occasions didn't perform (I used a 2-min recorded loop) for testing. Like you I assumed the cause of that was rather my setup than Mover and that I might be wrong altogether─ but who knows?

Check the motion alghorithm you are using in the rig please. Is it the default one (follow pretended pose)?
Might be one of the possible causes. I added it to the list of things to check again.

Ok, please see attached. The 'Original.Mover' profile is the .17 version that works fine. The 'New.Mover' is a profile that started from the Original, opened in a newer version of Mover and tweaked (I added AC EVO as a source and adjusted some filters and added a player and two graph viewers) and then saved. This 'new' version worked fine until a reboot cycle of my rig and machine, after which it exhibited the jerky behaviour but Original was still fine.

You'll see that the COM port number is different between the profiles but that's because I switch between my laptop and my gaming rig for dev and testing. Note that the issue occurs on both.

Thanks for taking a look and hope you're able to find something...

I think the problem is with a leak to the UI thread... Still looking for it

It is the default (in 'Just Pose'-Rig). But I just learned something new (you constantly add new options) and I will certainly try out the other two! Thanks!