Showroom FlyPT - 6DOF Brushless DIY Actuators

@pmvcda Hey FlyPT, have you tested your simulator for smoothness yet? As you know, the reason I'm going to start over is smoothness for flight sim. For flying heave movement should feel like an elevator in a big building, one that isn't too slow of course.

Looks plenty fast, I wouldn't have thought those motors were powerful enough.

They are speaking of the red connections:

and use some plates like shown in green.

Honestly, I don't notice any stress for now, but with time and more weight/intensity, it's probably going to destroy the soldering or even crack the aluminium.
It's 40 mm square aluminium with 3 mm wall.
I could clean those soldering and make them pretty, but that would make everything weaker.
I'm going to take the risk some more time...
Maybe I could use something to measure the flex...

Until now I had a n old G25 with just a piece of wood and some clamps, so everything could flex and the stress was split by those T joints and the lower L joints.
Now with the new wheel and the aluminium dash, the lower L flex is reduced and the T's will get more stress. Might be a question of time... (It was working like an U now it's a square).

Some more work on the hardware side...

Well, more software for the ESP32.
I'm now going to use UDP to send data to the ESP32 boards. Been making some test's and looks good:



In the image, we can see FlyPT Mover, sending data over UDP to the ESP32.
I have it configured to write in serial what he receives.
The timestamps are a bit misleading, because they are the timestamps for when the data was received in the PC. Data is received way faster in the ESP32.
The column after the -> shows the milliseconds on the ESP32 We can get one reading at each millisecond easily.

So, I will update the code soon to reflect this new feature.

Well done FlyPT! That is a great explanation with the image. =)

I'm making some rig changes.
Will try to make a video when it's working.
I think it's smooth and works at low speeds, but not toooo slowwww. There's a minimum speed

May I ask what changes? No detail required just curious.

I need my actuators to move at a crawl. Thanos indicated to me that the AASD servo drives/motors can move super slow. I think I'll ask him if he might a video demo but I already ordered my drives and motors so kin of a moot point now I guess!

Adding new pedals and wheel.
Also going to use wireless UDP instead of serial.

Really? Why go to wireless?

Because I'm curious and since the Esp32 has that solution, why not try.
This leaves serial free for feedback.
Still not sure if it's going to work.

Ah ok, that makes sense then.

I guess if I use Thanos AMC I won't be able to get feedback to the PC eh? I should probably see if I can get the ESP32 to work for me with the new sim I'll be building. Thanos stuff is great though, and it sure looks awesome to be able to just plug on the AASD drives to his new board!

The new AMC-AASD15A does not need feedback from the motors to know their position, it always know where they are since it calibrates the internal buffer with the home position of each motor... see this video that it controls a simple stepper motor to demonstrate the real servomotor behavior:




Also @pmvcda is using brushless motors and reading the 3phase sensors for position feedback, something that is not needed at all with the AASD-15A servos as the drives use the servomotor encoders to control the PID...

When I speak of feedback, is for this reasons:

- Get info to make some tests with my system. I'm going to try something to increase resolution, just with code. And with serial free, I can get serial output strings to the Arduino IDE.
- Make some tests to remove limit switches, and test limits just with load.
- Make a module for my rig that allows PID control on the module, like I had in the first program.
- And feedback on current actuators position to do forward kinematics for VR. And I think it's not going to work... but I want to do it.

All this is going to take time as things are going now... Need to work to pay the new parts.

Edit:
With Thanos new board and those motors/controllers, you are safe.
I just like to make it and since I have it made, I want to see the limits.
I'm considering the chance to try the ODrive, but my last days thinking is more on the challenge to see what I can get with the cheapest solution I know right now.

I'm currently build a 6 DOF simulator based on your design. I've brought the BLDC-8015A with the 57BLF03 motors.
Currently soldering up the circuits from the esp32 to the motor drivers so looking forward to any developments you have with this solution.

Brought the parts just before you said that you'd go with the Odrive system now. ha.

Hopefully for me you don't change your system as I'd love to see what you end up doing with it. Will create a build log of mine once it really gets going so you can see those results. I presume the current flypt interface will give me a working simulator for VR and flying sims?

Another quick question though, would nylon work as well as PETG or worse for the 3d printed parts?

Thanks

Hi,

I'm going to keep current config.
And we might get more resolution, just from code. I have some ideas.

FlyPT Interface is now gone. Look for FlyPT Mover.
Last days have been dedicated to XPlane11 planes, and now helicopters also. All WIP yet, but already usable.

Nylon vs PETG, I don't know, from what I read, PETG seems better, but there's also PLA+ now.
If you can go for aluminium or something stronger, I advise you to go that way.
That's something I might change. I'm increasing weight on the platform, and I'm starting to worry... Might post some designs for that soon.
This for the bottom joints.

Good luck on your project! Any question/problem, just ask

Sounds good Thanos! As far as having feedback from the actuators to the PC I was thinking about FlyPT's forward kinematics for motion compensation. The more accurately the PC knows the position of the platform during motions the more likely it is to work. I agree with FlyPT that it's a long shot though. I'll be very happy if it does work! =D

The good thing with servomotors is that you instruct them to go to a position and they will make anything to the limits their power for it to happen! And they can move slow or instantly fast! They will plain follow the motion data. If the motion data is accurate, the servomotors will replicate the motion cues perfectly, with no need for feedback or forward kinematics recalculation.

Hmm, what you describe is what we all use no matter what motors etc. are used. By Wikipedia's definition also. Its really only differences in precision of control but that's not to say someone can't make their own servomotor as precise as off-the-self setups. But I'm not necessarily saying its easy to equal them either.

I know what you mean but also by definition if there is there isn't feedback then its not a closed-loop system and therefore its NOT a servomotor. And adding feedback after purchase to a suitable motor (a motor that can be controlled in some way) technically makes it no less a servomotor than buying a motor that comes with something already attached.

Just saying.

I think what Thanos means is that all of that is self contained within the AASD drive/motor assembly. No external sensor is needed, that's internal to these servos, and I think he means there's no need to send the position data all the way back to the motion software on the PC. It's a closed loop system but the PC isn't part of the closed loop.

The reason that came up is that FlyPT has been talking about feeding the actual position data back to the software on the PC for various experiments etc. which I had asked him about.

I'd say the advantage of using commercially produced servos rather than homebrew ones is just that it makes it a lot simpler to achieve really good results in terms of accuracy and response time. A really good homebrew setup could be as good (or better) but a great many of us would never achieve this level of accuracy and reliability.

As stated I knew what he meant but technically it was incorrect. Hall sensors internal to the motors is feedback. No feedback means its not a servomotor. It doesn't make a rip where the feedback is located to be a servomotor though. As long as there is feedback from the motor somehow and its controlled by a closed-loop system its called a servomotor. Considering his expertise on the subject I think he could be more accurate with his words since again we all use servomotors (or at least +99% of us do). Others have stated they use integrated servo systems which is a more accurate description to differentiate what he really means from the rest.

Spot on. When you consider the resources and expertise commercial entities usually have when developing their products it can be difficult for home brewed systems to equal them.

With your talk about big heave (like a lift), it got me thinking that it would require a re-think of the current interpretation of the aircraft data. Eg. In a real aircraft when it climbs there is a constant gravity pressure felt relating to how quickly it is climbing. In a sim, a rate of force matching the rate of climb is sent out from the plug-in as just a number which then drives the rig to a to a point (impulse) and then stops at that point even if the aircraft is still climbing. Having a bigger heave is really of little benefit, apart from a possibly producing a bigger initial impulse. What is really required is to actually track the height of the aircraft and somehow relate that to the point of heave height. Therefore as the aircraft moves up and down at different rates of climb the sim will track all those changes and it will feel very real. Obvious the problem is that it would require some fancy code and maybe? big heave to make it happen. Interesting to think about though . Its sort of why I have settled on using G systems for that.