FlyPT Mover 3.5.3

I wanted to include transition in this build, but I needed to change some more things in the sources code.
I want to clean it a bit. I think I have it confusing right now.

I'm making some more test's.
I'm trying to remove the spike without any interaction. I think it might be possible.

Great! Thanks for sorting this out.
Ive been doing some homework in the meantime trying to understand how CR and LF is sent in decimal in a serial terminal program but it isnt so plain to search for.
I'll eagerly await your next update.

Regarding the bit choice, 14bit worked out better and matches the machine units without any scaling
Once I understood how soft limits are managed within the Kangaroo and a machine zero is set relative to the hardstop, then the remaing working range nearly matched exactly the 14bit range.
It was a coincidence that 16560 machine units is the actual working range for the encoder/gear ratio/ball screw length I had.
Sending a p0 is 50mm off the bottom hard stop, and sending p16383 is nealy 50mm away from the top hardstop.

But the Kangaroo module can receive any other bit range value and scale it internally to the machine units it works with. I just didnt need to add this step in my setup.

FlyPT Mover 2.5

New build for download in the first post of the topic.

What changed:
-Solved bug in serial output, that did not allow to send CR and LF in the proper way (decimal output). @JAD please make a test.
-Removed old files from old filter system.

For XPlane11:
-Cleaned XPlane11 source.
-Just one click to open and close both sources (air and ground).
-Transition between both states with user defined speed for each direction.
-Filter for accelerations in ground source. Allows testing with filters, but predefined filter seems to work(at least on the graphics since I could not test in the rig)

I think the problem is now solved.
To send the CR and LF, we have to send the char. But you can't see it as a letter, so you can't specify that directly. We have to send a byte with the value of that "letter"/char.
CR is 13 and LF is 10.
When you put it in Mover like <10> <13> in decimal format, it sends a byte with that value.
If you where using binary, <10> and <13> are just that value.
The problem in Mover was that it was converting 10 and 13 in two chars: char '1' and char '0' or '3'.

I might change it to recognise <LF> and <CR> and keep numbers just as they where... Don't know.

That's why I entered the LF and CR as numbers in my last video, like this:

(4 axis output string)
<255><255><Axis1a><Axis2a><Axis3a><Axis4a><0><0><0><0><0><0><0><0><10><13>
(6 axis output string)
<255><255><Axis3a><Axis4a><Axis5a><Axis6a><Axis1a><Axis2a><0><0><0><0><10><13>

Yes, but in binary the conversion was correct. He's using decimal and it was converting <13> to "13" not the byte 13

Review about ground spikes :

I see it’s complex. Two small issues. Fine tweaking needed.

1.)
I have the feeling that you went for a bit to radical solution. At the very and stop there is simply nothing coming through.

2.)
It is adding some strange artifacts (small jump) while the response should be progressive. Please see this:

In the graph you see the amount of left and right brakes and the longitudinal accel.

Observe the slider response in Mover :

Ok, did you played with the filter?
You can put anything there.
Filter is applied if brakes are active and the plane is on the ground.

The default filter I used is the spike filter:

SPIKE(VALUE;1.0;0.05)

This filter is removing all values that have a variation above 1.0
0.05, means that we remove that spike, but use 0.05 of the amount of the variation.

Imagine we have a spike that goes from a value of 3 to 6.
That's a variation of 3, so the value is ignored. But we specified that even filtered, we want to use 0.05 of the value. So instead of staying at 3, the new value is 3+ (6-3)*0.05 = 3.15

Hahhh. It’s the same “spike remover” as for air => ground ??

I have diminished the value because landing was just ridiculously soft.

Best

I’ll test it more in details...

No, air to ground is the speed of transition.
If you put 1.0, transition is instantaneous, with zero, it's not changing
The number is a %.
That air to ground, should be really fast or disabled, while ground to air should be smoother.
So air to ground with a big value maybe even 1.0, while ground to air with a lower value like 0.1 (changes in steps of 10% up to 100%)

Can confirm output is all good with CR and LF for decimal.
Love your work
Cheers!

What i like about Mover is the wysiwyg style.
I had manual heave setup for + and - 100mm in the pose window and I put a tape measure on the sim body to the floor and it measures out sub millimeter accurate.
Its great to see whats going on and what is being sent on the output before you hit connect.
It takes out some of the nerves when setting up for the first time.

The wysiwyg, was one of the aims of mover and the old program.
Now needs forward kinematics for full fidelity.
I have made some progress there, but it's not ready.

Besides the 3d view the graphics where a needed tool to tune filtering.

Almost perfect!

I managed to tune the spikes perfectly but
I still have a trouble with side coordination channel.

Example :

The platform is banking left or right using “mix sway in roll” while doing circles on the ground.

If you want to accentuate the circle curve by applying the toe brake the coord channel is quickly centering the platform destroying the effect.

The issue is sometimes present sometimes not.

Are you able to reproduce it ?

Best

Can you share your setup file?
I will test it later.

You are using 3 poses from motion. They might cause interference.
But I can't open the file.... that's strange. There's a bug somewhere, that doesn't allow me to open the file

I see that you use in the rig those 3 poses from motion. One from air, one from ground and one with both and the loops.

@hexpod ,

I opened the file.
You are using an huge resolution for my laptop... All windows out of range.

But here:

You have loops generating values on the pose that is used in the rig.