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

In my software the 3D model is hard coded with the Inverse Kinematics so it’s fully independent from scaling.

You seems to deal quite differently with this but I am sure you can manage.

Hope I am not confusing.

Thanks

Hey, no sweat. It's not a life threatening situation. It's just you are removing all the fun in my life.
If the previous version was not working, I would say I'm doing something wrong (still could be me), but it's working fine.

Version 1.7.3
Look at first post for download...



-Roll back to old scale method (it was correct...).
What I made, worked for linear, but not for rotating. I was scaling on the pose, not on the output.
Implemented this thinking it could be faster. But didn't think at all... @hexpod , you are right.

-Solved drawing problem on rotating rig.
Front was not green when out of range.

-Added swap for pose transformation (was on background, now enabled on interface).
Unchecked, translations are in world coordinate system (by default and used until now).
Checked, translations are in top structure coordinate system.
After reading the "Writing a motion cueing software from scratch". It's a doubt I have asked before in my build thread, so here's the two versions for teting.

-Added serial output debug (was on background, now on interface).
If checked, shows bytes sent to boards.
In binary, shows the byte value,
in decimal shows the char.

-Solved mixing problem (was not reset on loading, default was different from what was shown in interface until we changed the value).

-Serial output. Can't find the error. It's working for me, on a board I have with me. Need more feedback.
Could not test on my rig. Only tomorrow.

And... some new bugs for sure!!!!

2 quick thing.
I entered all data by hand in the new version and the rig moves now.
Mix sway in roll and surge in pitch push the rig to its limit with only little forces. I remove them as they were actually dangerous.

edit:
3. Lock at lowest position does not work anymore for me.

I have to put a default gain of around 0,1 on the mixes.
Try with something like that and use the low pass filter.
See this post: https://www.xsimulator.net/communit...-rotating-actuators.12859/page-13#post-174325

It looks reasonable. congrats !

I did a quick comparison.
It seems you are dealing with scaling differently than me.
With the same pose (175mm) I see a discrepancy of 0.3 deg. in the crank position, which is a little, and 1.9 percent in the output, which is A LOT !

It could be there is a misconception or conversion mistake somewhere.

Fast thinking (not a good idea as we saw before):
I'm pretty sure it's the way I calculate %.
But I also have some simplifications to make the code run faster.
Can remove some of them and see if it get's closer.
I will also take a look at some conversions between doubles and int's, but I think it's not related.

Small change in rounding:

Interesting... how did you managed?

Hello,
I'm new in this community and trying to see if i could use this interface for my DIY hardware in which i try to use 2 arduino boards. I'm wondering if there is any possibility to read the output somehow. I need to see an example of output format.

Sorry if this is an irrelevant post.

Welcome!
Don't be afraid to ask.
It's the purpose of this community.

Yes, it's possible.
Just specify the serial string you want to use.
Check the Serial debug checkbox to see exactly what is sent to the boards.
Right now you need to have a board connected to see the serial output.
I want to change that in the next build.

You can send it in binary or decimal format.

There are some wildcards for the pretended position:
<Axis1a> = actuator 1 value in the specified bit range (if you choose 8 bits, it sends the value in 0 to 255 range)
<Axis2a> ....
<Axis6a> = actuator 6

Optionally, if you want speed and PID calculated on the interface, you can also use (I need more testing for this option, but I think it works in standard serial):
<Speed1> = calculated speed for actuator1
...
<Speed6> = for actuator 6

To use speed, the interface expects to receive the current position.
You can send it from the board in binary format with the following values:

0 127 127 127 x y

Where x is the high byte of a 16 bits value
and y is the low byte of the 16 bit value

Added more decimal places to the output display because of rounding.

And you have 180º field in your app, but in mine you have 170 (2*85º).
The % is relative to the range. So the result was different.

I've tried the Washout with the new version, and I still get severe correction.
It works nicely for the pitch. Without it, pitch was late or unsynchronize sometimes.
I have to test again and compare, but I think the roll was way better in version 1.6.8. When I run in curve that are rolled on the side, I don't get the nice roll effect I use to have in version 1.6.8. Like I said, I will compare them next weekend.

What settings do you have?
Can you take a screenshot?

I understand but what’s the concept behind using reduced 170 deg. range? (Security while using 180 sensors?)

As you know already, in some circumstances, the actuator path between two extreme poses can demand a range exceeding 180 deg.

Not right now, I am away from my rig. I used (at least tried) the same exact values for both version. If I remember well, it's a range of 12, no filter, gain of 1.1. Value for the main gain: 0.72.
I tried with and without the add sway in roll.
I don't see any other value that could influences that much the roll effect. But, like I say, I still have to test it back to see if it's not only my imagination. But, I noticed it right away in the first lean curve. We will have to wait for next weekend. Please, don't make an heart attack over this.

I never tested your program, so I don't know how you use those 180º. Might be completely wrong on my thoughts.

What I do right now:

-Limit actuator extension/rotation to -range to range value

- Calculate bit output considering:
0 to max bit range value <=> -range to range

-Multiply by scale the bit output

Seems an error in step #5, because 2*range doesn't match the bit range.
This "problem" comes from my rig, where I calibrate the rig from the start with absolute values and range is the number of steps, so I never get lost.
But in my test code for using the rig in the traditional way, the value received in the board is then remapped (on the board) to the minimum/maximum of the actuators.

It's working around this idea, and for linear it seems to work well.
For rotating, I think we can make the same. It's up to the user to decide where is the min and max rotation, and what angle do they have.
In a 0 to 1023 bit range, they can have min=100 with 10º and max=1000 with 30º, being the middle 20º, just as an example.

So my basic idea of range is hardware limitation. like limited pot rotation or pot fixation in front of rod...

But I can be wrong.

I need to test with my rig, most my last updates where not tested. Scale might still be wrong or inverted...
And for rotating I might build a scale model.


This is a fast post in the middle of work, so might contain nonsense

While using 0,5 scaling factor I see the bit range output reducing while the percent of travel remain same.
I guess you scaled it to the crank travel.
It would not be more comprehensive to scale the percentage on bit output?
Up to you

build this one plz. Ill try an acid test on it

Since my idea of scale is to match values (mm) in the program with the rig, I thought % would be more suited to range in mm instead of bit value.
The bit output is not really "visual", considering that 0 should be the middle value, it's not a good comparison in my mind.