FlyPT 6DOF/Stewart/Hexapod Interface for linear and rotating actuators

I am able to test this in the afternoon tomorrow, will you be available?

It's now 18:09 here so in 19 hours

Cheers

Yes I think I can. I will be in the office with the laptop.

Great, I will let you know how it's going.

Cheers

I finally found the one labeled "correct string"! Now to try it.

<255><255><Axis3a><Axis4a><Axis5a><Axis6a><Axis1a><Axis2a><0><0><0><0><10><13> <<<< CORRECT STRING!

I don't know why I couldn't find it. Walked away for a while and sat back down and boom, found it. Still haven't found it on the first page though, where I kept seeing posts direct me to find it!

I'm so excited, the graphical sim has me very very optimistic that this may solve the last of my smoothness issues. Amazing work FlyPT. Just positively outstanding. What is looking to me like it should work is the triple LP filter.

I need to really, really ease it into motion, but then let it accelerate up as fast as possible before slowing down to stop. Short of the triple LP the start of the motion still looks far too sudden for my rig. I'm bouncing up and down in my chair with excitement LOL.

OK @pmvcda , feedback time! I know you are working on FlyPT Mover so my feedback is mostly meant for you to consider when working on that version. Since I don't know much about mover yet I'll post it here since it's all based on testing with this version.

First off... WOW. Just wow, this software is amazing. It's on a whole different level. I love it.

One really really big problem though. I need the servo "range" to be respected at all times, even when I'm allowing poses beyond limits. The way it is now if I let it do poses beyond limits my servo arms are hitting the end stop limit switches which is bad.

So it can not go past the 58 degrees range of servo arm rotation, but if one actuator is at that limit it will still play the poses as best it can using the actuators that have not hit the limit. Does that make sense? I'm finding this difficult to explain, sorry.

Trip

PS- Side note: I'm not getting translation output from DCS world (Direct) except in a crash. Seems like there's a bug somewhere. We need to fix the LUA anyway so we can deal with gravity properly as per @Dirty 's explanation. No Euler angles, no need for anti-rollover.

Answered you by PM, but I will repost here for others:
=================================================
I, sorry for late reply.

I will be out all day, so what I'm posting was tested and thought in a speedy way.
So please don't take everything for granted.

I was testing your values.

Those ranges, with the measures you have above don't allow the rig to even reach the middle, just using heave.
You can see on the 3D that the arm is not reaching the middle.
It should work, but imposes huge limits on your rig.
Ideally, center should be more than 0º. Something like 10/15º.
Range should go up to 80º at least. That's the values I have from others that use the program.

The problem with limit switches might be from various sources:

One could be from "Output swap swapped".
This option, makes all actuators increase value up (positive) and decrease by rotating down.
Without this checked, they all increase rotating right and decrease rotating left.
This depends on how your hardware works. From other users tests with the AMC, I think you need this checked.

Another one could be the scale:
The output sent to the boards in the bit range value, is supposed to be from 0 to let's say 1023 for 10 bits.

The program makes 0 the lowest allowed angle
1023/2 the middle
1023 the maximum angle

But there's a catch here. Depending on your hardware, the resolution is different.
You can have 1024 values for 180º or 1024 values for 10º.
The program doesn't know this.
So you need to use scale (top left corner, first field).
Try to adjust it until the angle you have on the rig matches the angle on the program.
A good way of making it is to measure the heave travelled by the rig and compare to the slider value.
I think for your rig, 1.2 might be near what you need (not 5% sure )

If nothing works, please tell me.
I will take a better look tomorrow (sorry).
=================================================

For DCS, are you using my script?

No need to apologize @pmvcda ! I know you have other things to do and you have been doing very well with the communication IMO.

I figured out the problem! When "stay in last possible pose" is unchecked the simulator should be sent the "cropped" values. It is instead receiving the "filtered" values. BOOM! I finally got it right LOL.

Thanks again @pmvcda !


PS- As for DCS, I am using the .lua you provided with the most recent version of FlyPT. When I crash heave/sway/surge move, but the rest of the time they do not. I think maybe the scale is wrong and only super high accelerations are big enough to register?

I'm posting my sim dimensions and settings, just in case someone wants to see them now that it is all set up.

Well, DCS needs work... sorry.

For the rest, let me show this:


(Ignore gain in actuator please, forgot it from another test)
This is your rig at upper limit, you can have almost 100 mm heave up, around 65º
In red are the calculated values, at their right what is sent to the actuators. It's cropped to the limits defined.


This is the same position, but showing the bit values sent to the board (bytes over the 3D view)
In red the bit range (I made it for 10bits)

The value is cropped. When you move outside of range, the actuator as always the same value. Not the ones inside their range.
There's some differences due to rounding and maths simplifications.

Here, the rig at it's lower position:

That light green line in the circles is the middle.
You can't even reach the middle without going through an impossible position.
At around 13º (-4mm heave) you have an impossible position for your geometry.

You need to change this.
I would remove the springs that limit your travel, and make 10 to 15º your middle and something like 80º range.

Try to use a bungee jump rope to attach the top center of the rig, to the floor, That's an artificial weight for testing.

@Trip Rodriguez
Repost from PM:


They should have stopped there.
On the right column (of the red ones), you have the value sent to the boards.

Now the problem is the scaling to generate the bit value.
I might have explained it bad. Let me try better:

You have a pot attached to the rotation of the motor.
Imagine that pot allows 180º rotation.
At 0º it sends a value of 0
At 180º it sends a value of 1023 (for 10 bits).

The problem here is that the program doesn't know what is your pot range. And there's always small variations.
The program calculates everything so 0 is the smallest angle you defined and 1023 the maximum.

This is without changing scale:

At top limit you have a value of 1023 while it sould be less, because 1023 would be for 180º

If you reduce scale (not increase, I was wrong before)

Now you have a lower bit value for the same angle.

@Trip Rodriguez

Was testing some measures, and for your geometry, I thing a range of 75º with middle at 23º, is what gives you the best compromise. (heave between -150 to 150 mm)

We can discuss the rest later, but right now the problem is that what you said here is not happening. When I move the actuator outside the range the value continues to change. Unless I misunderstand, this image should show it.

I moved it to out of range with heave, that is first screenshot. Then I moved the slider farther over and isn't it showing that the bit value changed? And I can tell you, actuator keeps moving!

I can not remove the gas struts at this time. The simulator works well for me! I just need to not have actuators go out of range and I'm happy. =)

The way you suggest it is the way it was for over two years! It shakes and vibrates like crazy without the struts. Now it is nice and smooth and I find the range adequate. In the future when I have more time I will try again without the struts and with correct angles using your software and the filters, but I think it's going to shake no matter what I do with software.

If the image I posted just above does not show the problem, then I am very confused. =)

OK I see the problem!

I will solve it.

Version 1.8.8

Corrected problem that allowed bit range to exceeded maximum value when using scale (@Trip Rodriguez).
When using scale under 1, we are stretching the bit range values, but it was not cropping at the scaled bit range.
It was also affecting linear rigs. That might be the reason for some limits problems for @Pierre Lalancette .

Download in first post.

Thank you @pmvcda , I'm glad this helped others as well.

Does it mean that while using 360 sensors on the shaft, if you use a 0,5 scale, you lever motion is restrained to 180 deg?

If yes it’s bad.
A scaler should not be the limiter in my opinion.
Two different functions should have two different controls.

There are indeed two different controls.

When you define the platform in FlyPT you tell it the range of actuator travel on your rig. That is the "limiter".

Then separately, you adjust the "scale" until a given value in the software measures the same on the real physical sim. For me I moved the slider so in FlyPT software it indicated +60 mm heave, and then adjusted scale until it was exactly +60 mm of heave in the real world.

Problem was apparently that the "limiter" was not properly allowing for scaled sensor values, so if your scale was not 1:1 the limit setting did not work correctly.

Aha, got it, it’s about the “Range” function.
I’ve pushed the “Range” limiter beyond 90 deg, letting the “Stay in last possible pose” limiter do the job. That’s should be way to get the whole kinematic range.

Well, there's still a problem...

Solved it for scale under 1, but not over 1...
So there might be a new build here.
I might add a filter with the logistic function to the list.