Jugglebot is SO MUCH FASTER! - PDJ #12
ฝัง
- เผยแพร่เมื่อ 14 มิ.ย. 2024
- This video has been a while in the making! In it, I cover my new design for Jugglebot. It was quite a bit of work to redesign the legs, but it was absolutely worth it; Jugglebot is now so much faster than it was before and can throw a ball ~60 cm high, which should be enough to juggle 5 balls (once I get the software side done)!
The next few steps of the project involve finishing off the hardware, and then I'll be working on the software (the "eyes" and "brain of Jugglebot). Will be interesting!
Links to things mentioned in the video:
##### Github for this video ######
github.com/Project-DeepBlue-J...
##### RoTechnic's video of the cable actuation method for his robotic arm #####
• The LIGHTEST Robot Arm...
00:00 - Intro
01:53 - Overview of Rest of Video
02:27 - The Hand - How it works
03:12 - The Hand - Improvements
06:25 - The Platform - Overview
06:58 - The Platform - Improvements
07:59 - The Legs
12:20 - Why Bother with Rotary Encoders?
14:11 - Next Steps to Improve the Design
18:41 - (Easy) Problems with the Current System
21:36 - (Hard) Problems with the Current System
24:05 - Closing Remarks - วิทยาศาสตร์และเทคโนโลยี
“Brushless dc motors shouldn’t be too tricky and shouldn’t take too long” were my very famous last words for my degree project hahahha.
I see you know a lot about them but the biggest issue with them is moving them at slow speeds, you are probably going to use low kv motors with an odrive but it will still be a lot faster than the stepper motors. You might need to add a belt reduction (as they don’t have any backlash), but I imagine you’ve done the maths and know what you are doing.
Good luck with this project, really looking forward to the result!
Yup, the plan is to use 150 kV (IIRC) motors with ODrives. If only UPS hadn't lost my package, I'd already have them by now!!
Yeah I'm expecting to possibly need some sort of reduction, but I'll have to wait and see how my testing goes. I'm hesitant to plan too much just based on the theoretical numbers, as that bit me in the butt a bit with these stepper motors (couldn't get close to the theoretical limit and I'm not too sure why)
Cheers for the support!
This is awesome! Looking forward to more.
I love this so much! Cool robot!!!
The two options for transmitting force would be fine stranded stainless steel cable or fine pitch tooth belts. Semiconductor robots for wafer handling use the toothed belt. Obviously there are tradeoffs, but the belt approach might simplify things quite a bit without adding much inertia.
That's really impressive!
Looking forward to when robots beat the human juggling record of 14 balls
There were quite a few things that I had to gloss over in this video, so if you're interested in any more details, just ask here and I'll either answer in a reply or (if there's enough interest) I'll make a video about it 🙂
Very nice project.
Just an observation regarding the 2nd "hard" problem where you get translation when attempting to rotate about the platform centre...
In the simulation it appears that the legs attached to close platform nodes always have similar lengths but in the clip of the actual platform the length of legs attached to two sets of close platform nodes are quite different. Almost as if two legs have been swapped.
@@hooks2998 Yes! This was the problem!! I had indexed the points where the legs attach to the base differently in my code vs. in the actual robot. Just corrected the indexing and now rotation works perfectly! I'm impressed by your noticing that, and I'm very thankful for you pointing it out to me. When I'm able to I'll post a quick video showing this off. Pure rotation is very satisfying 😍
Thanks again!
@@harrisonlow very happy to hear that this observation helped you to track down the cause of hard problem #2.
Is it possible that this was also the cause of hard problem #1 ?🤔
@@hooks2998 Just tried some pure translation movements and the extra rotation is gone (woo!) but the slight pitching up and down is still there. I'm pretty sure this is coming about because I'm only giving Jugglebot a start and end point, so I think this will be resolved when I implement more robust control. At least that's one less problem to worry about later!
@@harrisonlow That's great news.
Agree with your suspicions that the pitching up and down is probably due to only specifying start and end points. Getting it to follow a straight line path would take a bit more coding. The important thing is that it's getting to were you told it to go. 👍
This might be addressing a non-problem, but have you looked at using dyneema cord for "strings"? Dyneema is stronger than steel, stretches less than steel, and is very slippery; the latter actually being a challenge re. appropriate knots.
Very nice and ambitious project. About the slight variation of the platform: are you sure that all the hinge points are reary one point they are pivoting around? Aspecialy the home made hinges at the bottum?
Thanks! That's a good idea, though I'm pretty confident that the issue wasn't coming from the joints; all of the joints are one-sided universal joints, where all axes of rotation pass through the same point. This means that they act identically to ball joints, but they have a larger range of motion and are easier to make. Took a while for me to design them that way!
I like the thinking though - please let me know if you think of anything similar in the future!
I am a fan of James Bruton. He ran in something like this. Strange behaviour because the pivot point was slidely off.
@@jwkooi interesting! I'm also a fan of James, though I don't think I've watched the video you're referring to. As it happens, I think the problem I mentioned in this video was an issue in the code which has since been fixed. I *think* the joints aren't causing any issues (yet), though I'll soon be doing much more precise things with Jugglebot so any small discrepancies that exist will come up then. We'll see!
I'll keep the joints in mind as a possible culprit for future issues. Thanks for the heads up!
So cool! Love the design, you should check out James Bruton's video from about a year ago, constant-torque spring-balance actuator, it's a different problem he's solving, but it feels like some kind of logarithmic mechanical function could help here as well.
I love James' work! Such good content. It's funny that you mention that video. I actually tried something sort of similar a while ago to help with throwing the ball (I show it in my third video if you're interested). I had a cam-shaped pulley that amplified the distance travelled by a string as the pulley rotated. Ended up moving away from that design, but it was fun to try.
As for a constant-force/torque balance, I'm not sure how necessary that is for my application, as the platform is very light (especially compared to the power of the motors), so it should be fine to just have the motors actively holding the platform up at all times
@@harrisonlow Yeah very good point, the issue is, even if they're constant force, so they're not putting pressure on the "poor little motors" :D , they would probably have less, or no retraction speed, if only there was some way to vary the intensity of the force! Cam attached to the motor? I dunno lol.
For the leg two major design changes I would do are to use linear bearings instead of bearings as they do the same job but are way lighter and cheaper. And also change the strings for timing belts (as those used in delta type 3d printers) as they offer no backlash and can push and pull at the same time without issues. If you want to use a string to push and pull you will need a lot tighter tolerances in your tube to not have any backlash and you would still experience some.
I originally considered using linear bearings but I'm unsure of how the tolerances will go with the carbon fiber tubes; my (limited) experience with linear bearings is that they should have very precisely machined rods/tubes passing through them, and while these tubes are good, they're not designed for super fine tolerances. Maybe I should get some linear bearings and test... Would simplify that part of the leg quite a lot!
As for the timing belts, I toyed with that idea a little in one of my earlier designs (can see it at around 8:38 in the video), but a big problem with them that I couldn't see a workaround for is that they can only be routed along the plane perpendicular to the belt itself. This would mean that the motor would need to be mounted on the leg itself, as having the motor off the leg requires that the transmission mechanism can be routed at any angle. So far, strings are the only thing that I've found that can do that.
Today I'll be designing the next version of the string routing and I think I should be able to get it to have very little (if any) backlash in the push/pull (really pull-in-one-direction/pull-in-the-other-direction) mechanism. Finger's crossed!
Yes! This is exactly what I meant with the constant force springs to retract the legs! Much better :-)
Pretty interesting project. If I were to build a juggling bot I would have probably made tire drives to shoot the balls and a funnel / tube to catch it and pull it back through the spinning tires. But your looks more fun and interesting
Haha I think people have done similar things before (definitely with the funnel/cup to aid in catching) but it'd be tricky to get that to be robust/dynamic enough to perform different tricks/throw heights. Not to mention juggling balls are relatively soft and I don't know how they'd handle the friction of being launched with tyre drives. (I'm planning on using actual juggling balls because they're very good for this purpose - most importantly they have very little bounce to them)
I think that another possible approach for the position sensor could be to use the enconders you will need for the bldc motors to know the position and home the linear actuator at start up.
Also, to avoid the rounding error you mentioned from the steppers you could use integers for the position of the stepper and only convert it to float when you need it. (I don’t really think that that’s your problem but still a good tip)
Do you mean to put the encoder on the motor itself? I'm wary about doing that because then the robot won't "know" about any discrepancies between the motor and the leg movements vis-a-vis backlash/slop in the transmission.
Yeah I think there are a couple ways I could fix the rounding issue, but I'm really not that bothered by it since these motors will be gone soon anyway.
@@harrisonlow you need an encoder in the motor shaft to use the brushless motor with an odrive. The odrive lets you control the motor via position, speed or torque. Unlike steppermotors where you can only control the open loop positioning.
Your current plan of using a closed loop using an encoder to know the linear position and then give speed commands to the motor to reach the desired linear position could work, but you would be adding another dynamic system, which complicates things immensely.
Considering the whole control system, what you want is to control the end effector position by controlling lots of motors. The odrives have the ability to go to a position (with pid parameters you set, so you can decide how much overshoot and damping you want) and hold it with very high precision (and unlike stepper motors the position doesn’t drift because of slipping or anything). The inverse kinematics currently give you the linear position, which can easily be transformed to position commands for the odrives.
@@maeldorne5522 I thought the encoder isn't mandatory for ODrives if you're not using position control? I'll have to see how tight my new push/pull design is, but if I can get it to the level that I've seen other TH-camr's, I think it should be tight enough to allow PID control of the motors despite that mechanical separation of input/output. Maybe I'm being a little too optimistic, though...
If I understand what you're saying in the second paragraph correctly (to do closed-loop control of the leg motors using the position of the hand as the input of the feedback), that's more or less what I'm doing, except I'm not directly measuring the position of the hand since that'd be tricky to do with 6 DOF. I figure the leg length feedback should be fine since the platform frame is pretty rigid.
I need to do some more reading about control algorithms (I've long forgotten most of what I learned in my control course at Uni...) so it's pretty likely I'll have to deviate from my current plan when it turns out to be wrong. We'll see!
@@harrisonlow the encoder is mandatory, and even if it weren’t it would be a lot more precise and repeatable than using the encoder for the linear position by a lot.
Controlling the linear position given by the angular position is a lot simpler than controlling the linear position using the linear position to set a speed/torque to the motors via a pid to set the linear position back. The odrive has position control and you only need to tell it where to go and it will go and hold the position. You might really not get what you expected if you go through your route.
@@maeldorne5522 Hmm, I see what you're saying and I think I'll have to wait and test it with the motors and new transmission system.
I guess if all else fails, I could always have two encoders per leg: one directly on the motor and one measuring the linear position.
Perhaps it's just my inexperience/naivety, but I think the string push/pull mechanism will be quite tight and should give a pretty direct relationship between motor movement and leg extension with very little/no backlash. Though I can see how even a small amount would lead to instability with my proposed control approach. I'm keen to test this out!
What about using a limit switch for the homing sequence?
Good question! I've been considering doing that but the switches take up a lot of pins on the microcontroller (1 each) and I'm not sure that I'll have that many spare once the motors and encoders are wired up. One related option is to have all six switches wired up together so that they only need one pin, which should be fine for the purposes of homing as long as only on motor is moving at a time.
I want to try to avoid limit switches though because they're just more parts to deal with, and I'm pretty sure that homing without them is possible with the ODrives that I've bought (by monitoring current draw of the motors and flagging a spike in current as being the end of the leg travel). If only UPS didn't lose my package, I'd already be able to test them!
you should work with wintergarten. seem like similar design/engineering journeys.
I love Wintergatan's work! Been following his project for a few years now. Would be awesome to do a collab one day: the Juggling Marble Machine 😉
Speaking of synch, why is your speech always out ?
I think your servo is skipping some steps
What makes you say that? They're super beefy steppers and I don't think I was pushing them too hard in this video