How to Design a Linear Actuator - Project: DeepBlue Juggling #4.2
ฝัง
- เผยแพร่เมื่อ 24 พ.ค. 2024
- This video covers how I designed the linear actuators that make up the legs of Jugglebot's stewart platform. It begins by looking at the most important decisions you need to make when designing your own linear actuators (speccing the motor and ball/lead screw) and then explores some more qualitative design considerations that should be made when building a linear actuator.
Apologies for weird audio in some parts; there is construction going on in the building I'm in and I haven't been able to fully remove the audio artefacts caused by this.
Links to resources mentioned throughout the video:
Helpful threads on the XSimulator forum:
1 - www.xsimulator.net/community/...
2 - www.xsimulator.net/community/...
3 - www.xsimulator.net/community/...
Ball screws vs. lead screws:
www.helixlinear.com/blog/lead...
00:00 - Introduction
01:09 - Video Summary
01:38 - Motor and Ball Screw Analysis
02:14 - Speed Analysis
06:59 - Power Analysis
12:33 - How to Actually Make Use of This Analysis
15:19 - Qualitative Design Considerations
15:28 - Force Transmission
16:47 - Bearing Choice
17:57 - Choosing Number of Guide Rods
19:39 - Position of Limit Switch(es)
22:31 - Supporting Free End of the Ball Screw
23:50 - Attaching Ball Joint to Push Tube
24:47 - Choosing Joint Types for Stewart Platform
27:10 - Final Remarks - วิทยาศาสตร์และเทคโนโลยี
Excellent and welldone
You have a third option for mitigating limit switch failure (instead of moving or having more limit switches): observing the motor/servo. I presume it has some sort of encoder output? You could use an interrupt on the microcontroller that triggers if the pulse rate falls below the expected rate. Microcontrollers are very good at - have hardware support for - comparing two pulse streams (frequencies). You may be able to find motor drivers that have such a function built-in? Depending on encoder rate, etc this may or may not work to prevent things physically exploding on impact, but should definitely work to prevent the magic smoke from escaping. You can also monitor current draw and watch for a stall, but that's much more likely to overlap with normal operating ranges.
Unfortunately the motor doesn't have an encoder; it's just a standard stepper motor. Monitoring the motor current is a good idea and I know that's possible, since AFAIK this approach is used in some 3D printers (eg. Prusa printers), however I'm pretty sure my drivers can't do this and I don't know anything about what's required to do that. I'm going to do my best to never skip steps and just keep my fingers crossed that nothing goes too crazy.
On another note, I really need to get around to buying an emergency stop button...
You can add one - if it'll fit? e.g. www.usdigital.com/products/encoders/
Mind you, might be best to leave solve that problem until after you know whether or not it'll _be_ a problem, and finger's crossed works in the meantime🤞
It would be pretty nice to have some sort of closed-loop feedback as an absolute fail-safe, though I think the good ol' "fingers crossed" approach _should_ be alright, given how overspecced these motors are for what I'm doing. We'll see!
Thanks, very good
Good work
Cheers!
great video - quick question about the supporting rails. how do you insert them into your 3D printed housing? do you simply use a press fit? doesn't seem like the shafts are threaded on either end when looking.
Good question! Yep, those smooth rods are held in place with an interference fit. It took a bit of trial-and-error to get the printing tolerances correct, but they're super solid joints.
I've actually changed this design quite a lot for Jugglebot, but IIRC the rod was inserted ~25 mm. That gave a really solid connection (almost too solid - they're not easy to remove!)
you should teach for a living
Haha thank you! This is actually one possible direction that I'd like to take my channel in 😊