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

Hi @pmvcda thanks for the info regarding Classes being used and the shared functions actually make for easier updating , for me that was very helpful , so just my way of saying thanks for the explanation . we learn something everyday here Cheers .

Thank you @wannabeaflyer2, this weekend I won't be at home, but next week will be the time to make a movement video using with amazing FlyPT interface of cource

Now it works fine me too, next step I will test it real with my rig next week. Its getting better ...


Edit: Now I realized the "range" means the half of full range. Sorry I missed some of your infos. Now its crystalclear.

I assume when the intarface goes wrong, maybe it sends a wrong data to the rig, the arduino SMC3-SPS code does not let the motors go through the limit. Do I think it right? @BlazinH ?

For the SMC3, I think there's no problem if you have the limits well defined.
Do you use limit switches?
I'm more in linear actuators, so I'm not sure how it works in your case.
If SMC3 receives a 16bit value to spread over 360º or less, I don't know.
Just keep the emergency stop at hand
From what I see in your fotos, even if it goes beyond limits there wont be a problem, unless you are using pot's or something with a limited angle of work. In that case, going beyond limits might damage that part. Be careful! Don't want you to hate me

I don't have any feedback yet, if the serial output is working on the new version.
I'm going to post anew version today, but only with new images for the rotating measures and a correction, I hope, for the error when we have axis pointing to the outside.

I

I don't use limit switches, I believe SMC3 can save my rig if I set motors in SMC utils correctly. They work quite reliable.
I think if I don't see any issues on FlyPT 3D show, than could not happen any bad. Moreover I believe if the FlyPT send data beyond the limit, the arduino wouldn't send it to sabertooth.
Of course emergency knob will be wired on it

Ne version 1.6.2 Beta



-Solved the error with the axis of rotation pointing to the outside in rotating actuators (don't ask it was a really stupid error...)
-New images for rotating actuators dimensions
-Minor corrections

NOT WORKING --> <255> is not replace by a byte with 255 value. To be corrected

Waiting for testing feedback, specially with serial communication.

DOWNLOAD in the first post of this topic!

Im on my way to go out this weekend, but I had a half an hour to try out FlyPT interface on my rig. I have to say everythings worked fine with serial communication. Well done @pmvcda very good job!!!!
Im happy to hear about 1.6.2 beta, but I tried it with 1.6.1 beta.
I have to tweak a lot with SMC3 utils to get smooth and get motors in sync, but it works!!!

Nice work @Gabor Pittner great to see you in a happy place, and making great progress with you sim Project , and Once again Thanks to @pmvcda for the rapid response and quick updates to this ever evolving Interface the whole project is all heading in the right direction nicely

Version 1.6.3

Download in the first post of this topic: https://www.xsimulator.net/communit...face-for-linear-and-rotating-actuators.12859/

-Corrected serial output, now we can send <#> values. It was not working correctly. AMC should now work.
-We can now output speed on the serial by using <Speed1> to <Speed6>. It's a one byte value (0 to 255).
-Send back position to the interface.

New features will be explained on a guide update with sample code.
Those new features can allow full control and adjustment of PID, only with the interface, but require code changes on the boards.

Thanks for the update 1.6.3
It worked great in my case using the serial output.
It was great for about a minute until a retract move pulled apart an end connection and the whole rig fell sideways and bent a ballscrew. I'll show you with pics in my build thread.
Despite the setback, Im really happy with your interface and it completes a major milestone in the build.
Thanks again.

I just realised I sent my initial help request to you on your rig build thread and it should have been here on this thread. It was late and I had too many tabs open.

Sorry for your rig @JAD . I just want to know, is the break of your rig was caused by the Hexapod Interface?

Hello @pmvcda .
I downloaded the version 1.6 of your Hexapod Interface. I have not yet tested it. I am still using 1.5 on my other computer.
I wanted to give you my first impression of it right away.
- Still had problem to start the program with configuration file. It's noted in your update. Know issue.
- There is "gain", this is great!
- No more top and bottom crop?
- The version comes with a filter applied on all the actuators. That filter is not obvious and made me loose a lot of time trying to calibrate my rig. You should set it to none in the initial configuration.
- When I saved a file over an other existing file, it asked me if I wanted to overwrite the file twice? This is strange. Like it save it twice.
- The "Lock in lowest position" use maximum speed and Heave position. If we want a lower heave range for a specific game, it change the lowest position. It would be nice to have a specific heave for it and also a speed so it could be set at a lower speed (and save our actuators).
- To set up the Dimension, I had to go to the top menu and select the "linear actuator" that was already check. Not a big deal, since it's done once, but still a bit confusing. The dimension button was nice.
- The "Top radius" parameter is acting quite strange when entering value. It's the only one like that. Again, not a big deal, just an observation.

I will test it as soon as I can next weekend. Thanks a lot for this great program.

No, the interface was operating just fine.
It was just a poor fitting of the end connector inside the Aluminium tube. I relied on friction fit and hammer tapped these end connectors into the tube.
I didnt expect much of a pulling force to ever occur when doing retract moves. But without a rider weight on board and a quick retract, it was a sufficient pull force to separate them.

"require code changes on the boards" what does that mean exactly? Do you mean the arduino code? for example SMC3 sketch?

Yes.
In my rig, I make speed calculations on the FlyPT Interface, and then send them to the rig board.
Then the rig board sends as feedback the current position.

SMC3 board code, has PID calculation on the board.
I'm giving the possibility to use the calculation on the program, by allowing input/output on standard serial.
It's already working, but I want to make a sample code to show how to use it.

Why I made it this way?
Because I wanted to have feedback from all actuators to calculate the position error from all.
I can have only 3 actuators per board, so I could not gather info from all.
Then I calculate speed for the maximum error an interpolate speed for the other actuators.
That way I can move the rig in such way, that all actuators reach the pretended position at the same time, making the movement a "soft" transition.
While in the other solution, the actuator near destination might arrive sooner and stop, while others are still moving.

Ouch!
Those rigs, if you loose one support, they fall right away.
Hope you can repair it easily!
Keep positive

It sounds very very good.
I want it

- I will remove the config file! Made some changes and it keeps happening?

- Yes, gain is a easy way to increase/reduce intensity.

- Removed top and bottom crop, because you can make it just by simply reducing the range.

- Just updated the code to hard code a default config without filters. Next version with this update.

- I have no problem with repeated messages for overwriting files. If anyone else has this problem, please report, but that's a strange one.

- The lock in lowest position is really a problem, because I have no way of telling directly to your rig to go slow.
Only way is to repeat many slow moves.
Right now, I'm using the range heave you set on the interface to determine the lowest position. I will change it to use the actuator range.

- Yes, Radius is giving a strange behaviour. You can change the value in a specific range depending on other values. I recommend the use of L1 to L4 instead of radius and angle.
I have to take a better look there, I would like to keep both methods.

Thank's for the feedback!

I'm realy near but missing something ….
the com/port are ok ! everything move with( simtool to Fly Pt) but not the Rig …!!!
With SMC3 each arms work well !!

You should not use FlyPT output.
Use custom binary.
See here: https://www.xsimulator.net/community/threads/6-dof-from-scratch.9409/page-22#post-170785 (last pic)

That's the configuration used by @SilentChill