Awesome! All I could think while watching is that you need motion capture! An optitrack / vicon rig would directly tell you the position of all joint and the ball with sub millimeter accuracy @ 100s of Hz. This would make debugging a lot easier since you can play back all the actual motions and zero in on what’s contributing to errors. It would also let you generate a calibration to null out the Stewart platform errors. Also if you wanted to be fancy, you could close the loop on the ball position fairly trivially. Univerities often have rigs in the robotics / sports / bio labs. Your project is interesting enough that I bet you could get access if you found the right interested researcher…
Cheers Shane! Yeah I've been looking into getting a mocap system but they're so darn expensive! Asking around at a university is a good idea 🤔 I'm very jealous of your setup 😅 Definitely agree on how useful mocap would be. There are so many problems that suddenly become tractable when using such a system...
Correct I just made a refillable lighter out of boredom and having to buy new ones and it worked but failed fast and I learnt that butane reacts with hot glue by melting it and it makes sense since it was a hydrocarbon and that I would never have learnt if I didn't do it and now I'll get some proper adhesive and the next prototype may work ❤❤❤❤❤❤❤
Thanks a lot! Becoming a juggler was my back up plan for when the robots take over all the jobs, and now you've taken that away from me as well. 😜😂 Seriously though. That was impressive!
Fantastic project! In addition to the great result, for me this is also a great example of how much physical stress is placed on the joints and connections even on such small machines with fast movements. I am really looking forward for the further development with ‘two hands’ and ‘eyes’ - thanks for sharing and good luck with the further development.
I think it is really satisfying to see the robot do this without any cameras tracking. If one uses tracking, in any project, i always think it is constraining the environment it will work in so much. Wouldnt it be cool, to just take it somewhere and have to care just about the robot and its brain only, not the + / - 10 cameras and and and
I always appreciate creators who try to open source their projects and the extent that you’re doing that is awesome! Loving this project and best of luck ❤❤
If Jugglebot ever gets eyes and computer vision, you couldn't just make it throw balls at you or see the balls it threw itself, you could also make it catch balls you throw at it.
The amount of progress you've made in the past couple months is incredible, I havent kept up with the livestreams, but WOW! And I concur that a state machine would be a good plan - implemented one for one of my recent projects and it the feeling of switching everything over from nested if statements was wild.I could feel the code becoming easier to reason about and also more flexible as I wrote the new version
In terms of connector you could use a Molex SL 4 pin connector, look at the DJI Can-Hub that was used with their drones . You could even use their hubs to connect everything. The connectors have a clip that secures them.
Interesting! These look similar to the connectors used for the CAN bus on the ODrives. Very solid option and I'll add them to my list! Cheers for the suggestion ☺️
I feel that the best whay to aproach the configuration of a jugglebot is with cableRobot so you can have 6dof for full control of the motion and launching. For this type of robot its really important to design something where the moving parts are as light as possible so you can have high speeds. Also its really important to solve the problem you talked about the motor coordination so all of them arrive to the correct position at the same time, if not you would not have proper control of the endfactor of the robot. Nice work!
Agreed! Though the question is whether we really need 6dof for the hand. I think 3 dof would be the bare minimum, but 5 dof would be ideal (imo) and I reckon this can ~potentially~ be done better in a non-cable robot design 🤔
I was surprised at how far I had to scroll to find this comment to agree with it. I knew that there would be SOMEONE who would agree that the cable design would be "the bee's knees". I feel like it would be the option most likely lead to the most nimble AND the easiest to re-configure, but I would also bet that in terms of BoM costs and the cost to replicate enough to meet the end goal of throwing & catching 14 balls reliably, it HAS to be far FAR cheaper. I think you may even be able to make it more compact too. but it could get awfully difficult to constrain the ball paths such that you DIDN'T end up needing the entire cable robot on a Stuart platform in a corexy on a delta platform.....and designing an optimum way of routing the cables....makes my brain hurt thinking about it
Ideas from 3d printing. Certain stepper drivers allow you to monitor if it has reached the end. Could you use this sort of thing to know that it has caught a ball? Like the voltage has changed so there is a ball in the hand? Also from 3d printing, could you use input shaper to help with any resonances or wobble? Super impressed it can juggle just based on physics and no vision! Infrared for vision maybe?
What you're describing is absolutely possible right now! The (stationary) hand motor can detect a ball placed in it, so it should be possible to detect caught balls, though I'm not sure how the signal processing would work to have it be reliable when the system is in motion. Definitely an interesting possible avenue to look into! Re infrared: one of the options I'm considering is a motion capture system and these use IR! Good thinking 😊
The keyword you need on McMaster is "continuous flex". No extant connector has the necessary strain relief built in, so you either need a conduit that'll bear most of the strain and set a minimum bend radius or you need to fix the cable to the structure in a way that will prevent strain from accumulating in the first place.
It's not so much the strain relief that I'm worried about, but rather the connector itself unplugging due to being shaken. I suppose the cable is pulled by the strain, but I've come to realize that the current connector really doesn't 'snap' together at all and comes out far too easily. Fwiw I also may add an extra strain relief as a backup. Cheers for the suggestion! ☺️
About connectors: I am taking part in the Bauman Racing Team car electronics department. We have been used Molex MX150, MX150L, DTM, Superseal, Microfit connectors, but I have never been totally happy with them. I consider aviation connectors definitely worth trying, but MX150 (with no L) and DTM connectors are definitely good enough if you have a proper crimping tool.
If you can unify the hand movement with the arm movement, you can likely utilize the arm to assist in movement for catching or throwing. Essentially speeding up the hand.
Yep, 'piggybacking' the hand movement on top of the arm movement would be great. Should be able to get super high throws and much gentler catches this way!
Awesome work Harrison! It's amazing how complex this problem is to solve. And even more amazing that our brains and body's can juggle (with a fair bit of practice :)
Absolutely! It's so impressive that humans can juggle at all. It's going to be a very long time before we have anthropomorphic robots that can juggle as well as the best humans
What an exciting project. Have you considered mounting an IMU to the top of your juggler for the option to run active vibration control/compensation to reduce the ringing? Basically use the IMU data to calibrate and counteract vibrations.. Maybe people with more experience in this field can give constructive suggestions on how to implement this code. Love the project!
Interesting idea! Some others have suggested input shaping and (I think) this would go a long way to helping implement that. I'll keep this in mind for if the ringing is still present after fixing the platform joints and the arm trajectory control. Cheers for the suggestion ☺️
others might have suggested this already, personally i would use an optical/ light/dark detector in the hand looking up. and programming it as a state machine is much better.
That's definitely a solid option, though it wouldn't tell us anything about the balls after they've left the hand, so those first few measurements would have to be really good to inform a physics model to predict collisions etc. Or, we could use an external set of eyes to watch the whole shebang. Lots to consider! Cheers for the affirmation of the benefits of a state machine ☺️
Keep in mind that the bigger you make the hand, the longer the ball will take to potentially settle for accurate throws and fast patterns might lose accuracy if the ball doesn’t land perfectly and bounces or rolls a bit in the hand. Making the hand as small as possible is more challenging but probably better in the long run because you want to eventually toss and catch faster and faster. I’d stick with the small hand for now and just experiment with shape and do some high speed footage to see if/how it bounces or moves during a catch. Good luck!
Yeah this is a very real concern of mine and is something I'll need to experiment with. I think the "correct" solution here is to use a larger hand with so-called "Russian" style juggling balls, which are basically firm plastic balls partially filled with sand. The sand (should) do a great job of dissipating excess energy and stopping the balls from dilly-dallying around the hand. No doubt, there's a lot of testing to be done! Cheers for the input ☺️🤹♀️
@@harrisonlow Oh cool! So Russian style balls are basically deadblow juggling balls? Haha I forgot to mention that you can get a used GoPro for pretty cheap that’s capable of 120fps at 1080 and if you can afford it there are a few Sony and canon cameras that can do 120fps at higher res and 240fps at 1080. It’s not suuuper slow motion but should be enough to get a decent understanding of what’s happening with your robot. A friend of mine had the same issue and had decent luck, he found a Sony that films 120fps at 4K used for about $700usd. But you can probably find a used GoPro for less than half that… If you need anything higher speed, I’d recommend rental if that’s an option in your area… anything over 120fps starts to get pretty expensive, starting around $2k or so. Just don’t make the mistake my friend did by being unprepared… high speed cameras need way more light than you think and if you’re renting, remember to have everything set up and prepared ahead of time so you can make the most out of it. Also, high speed footage chews through storage so that’s a huge factor is affordability and logistics. I’m not sure how fast jugglebot actually is, so hopefully one of the cheaper options will be enough for you to gather the data you need and you can avoid the cost and hassle of slowmo video setups. Either way, I know you can handle it. Good luck! I look forward to seeing some robo-human juggle action in the future! Haha
The hand shape you've got now is pretty good. Probably best to leave that shape exactly as is for the bottom then extend it with a slightly conical section going up to guide the ball back in place if it's a bit off. CoreXY is a good idea, but it seems completely unnecessary to make the hand able to pivot. With that largely spherical hand throwing mostly up it matches all the directions of throw you need already, just have to coordinate the XY and the hand to get exactly the trajectory you want. Aside from giving it eyes and getting the subtle details of the control systems working properly it looks like that approach should be able to get you there but you should test whether the hand mechanism you have now can throw high and fast enough to do 7 in one hand without breaking.
Check out industrial M8 / M12 connectors. There are various configurations (pin counts, key position, ...) and they are designed to by used on industrial robots - preferably with robotic cables. You can start by looking at SICK or Phoenix contact. Also, those green phoenix connectors you use are also made with locks, so they doesn't fall out so easily. We are using them without problems, lock-less versions always had to be glued in place to be secure.
Wow those look super solid! Cheers for the recommendation! Also big thanks for referring to my current connectors by their actual name. I had no idea what they're called so it's very handy to know that they're Phoenix connectors (and that they come in a locking variety!). Cheers ☺️🤹♀️
Hey Harrison I was extremely impressed with this project BEDORE you casually mentioned that you’re not using CV and the whole juggling operation is basically open loop…. then I nearly fell out of my chair. It’s a testament to the incredible mechanical precision that you’ve engineered from cheap 3D printed parts. Unbelievable work. I’m working on a project that could really benefit from that kind of precision. I would really greatly appreciate an opportunity to talk through it with you and any guidance you could offer me. Please drop me a reply if we can make a short call or email happen!
Cheers! For sure 😊 Depending how open you want to be about it, you can either post to this project's Zulip site (Link in the description. The "project showcase" Stream would be great for this) or you can email me using the email found on my RUclips channel (look at the "about" section). I'm keen to read about what you're working on! PS I probably won't reply for a few weeks as I'm still on holiday ☺️
What are your goals for the next movement platform design? Minimizing end effector mass? In that case, if you can somehow move the "hand" motor off of the actuator, that may greatly reduce the mass. I'm not sure how you would do that, maybe a bowden cable would be good enough? Maybe clever corexy style belts with multiple drive motors? Maybe even make the "hand" pneumatic with an extremely lightweight cylinder that acts as both the actuator as well as the linear guide?
I need to do some analysis for precisely what speeds I need, but at a guess, I'd want the hand to move at up to 14 m/s (for a 10m high throw) and the arm to move around 4 m/s. The whole system needs to be fully symmetric, or at least agnostic as to the direction that balls are coming in/out
I feel that vision based closed loop control will get you closer to your goal faster by compensating for imperfections in the motion system. Juggling seems like a task where suppleness, speed, and perception matter more than rigidity.
Fantastic work! I have been watching for quite a while. You have inspired me to DIY my own high speed actuators. The actuators you devised are amazing and I am considering "borrowing" your design idea to replace some pneumatic hardware I use on active aerodynamics.
Cheers! Haha go for it 😉 while they're not perfect, these actuators have served me pretty well and could at least serve as a starting point for you to build on top of ☺️
Awesome work. Very impressive. Have you looked at Molex micro-fit3 connectors? Thats what we use in 3D printers on a print head that has lots of accel..so that might work good here.
Cheers! I've added them to my list to check out. If they can survive the torture that you put them through, I reckon they could work pretty well! Thanks for the recommendation ☺️
Great project and progress. If you developed dual linear rail arms with catchers on the end, the form factor could be more humanoid. If you decide the catcher should be hand shape, look into team unlimited “phoenix”prosthetic hand that’s open source. I’ve printed several. They use a drawstring effect for grasping. Then once you have the “routine” down, you can sell to Tesla to incorporate into all bots. :) Can’t wait to see you shatter some records!
Very cool project! I would suggest a microfit 3 or similar molex connector for the CANBUS connection. I use those for my CANBUS system on my 3D printers and they hold up to extreme speeds and shaking very well.
Cheers! Those connectors look bomber and it's good to know you've field-tested them 😁 I'll add them to my list of options to check out when I'm back from holidays. Cheers for the suggestion!
Anderson Powerpole gives you tons of amps and lets you make any number of pin connectors. Haven't used deutsch but they look nice. XLR 5 pin are nice and easy to find connectors. There are also the "M16" series of threaded connectors, often used in lighting, not exactly a standard so you have to hunt around for a bit. Then there are amphenol connectors, widely used in aerospace and military, which come in every shape and size, rugged as heck, and $$$
With Peopoly now selling hobbyist linear motors, you might consider that as a possible motor for the hand. It's an EXTREMELY precise, closed loop motor that handle a lot of weight and won't need to be tensioned...kind of a perfect solution.
Absolutely agree with this. I think you have come impressively far by just making the hardware close to perfection. But if you want to juggle 14 balls, I think you will have a really bad and long time if you just try to perfect the hardware. I think you need to spend some serious time getting camera feedback or getting a proper tracking system. You will also need to develop control algorithms which can compensate for imperfect throws and balls bouncing against each other. Even things like air pressure, humidly and temperature will affect robot and ball performance from day to day. And in order to compensate for this you need a proper control system.
Absolutely agree! I'm very curious to see how far we can get with open-loop control, though I highly doubt it'd be all the way to 14 balls. Motion capture systems are just so darn expensive 😨
@@harrisonlow they don't need to be that expensive. 2 pi's and picams should suffice(one even but more complicated lens/positioning to get z from ball size). The tricky part is taking into account the lag. No lag systems would get increasingly expensive. Like the computer vision part to detect balls at realtime can run even on a cellphone just on cpu. Pi and cellphone based sbc's have better/faster camera interfaces than you'd get hooked up on a desktop cheaply(this is why laptop cameras are usually crap..). The picams hook up straight to the interface on a pi
Please explain how you use the jacobian to determine the ideal configuration. I've built more than a few stewart platforms and always wondered how to select the best form factor.
Deutsch DTM Plugs can be an option. We use them at work, but they sometimes need to be plugged in and unplugged a couple of times for them to work. Another option would be to just use a XRL Plug and Cable that is normally used for microfones. The cables are usually really soft and shielded and the connector hat a solid connection.
Ooh that's interesting! I've never heard that issue with Deutsch plugs so I'm glad you told me about it! I'll have a look into XLR plugs. Cheers for the suggestion ☺️
i have a brilliant idea for the "eyes" of it.. first, make the hand weigh the balls in real time. then make a program that calculates physics, calculate the balls trajectory in real time. that way the robot "knows" where the balls are. only downside is if someone interrupts the balls or there a wind heavy enough to move the balls enough to mess up the calculations(the wind one can be "fixed" with a simple wind sensor and feeding it to the calculations)
If you are going to switch to corexy, it may be a good idea to use an existing 3d printer platform to prototype on. That would also make creating many jugglebots easier.
Very good point! It's be great to have a solid foundation to develop on top of. Cheers for the suggestion!
2 месяца назад
I've built a laser engraver by building a Voron 2.4 Gantry and putting it on some self designed legs that hold the honeycomb plate. The gantry is a good standalone coreXY assembly
it may be easier for the bot to use paddle and ping pong balls., as most of the time is used for the throw and you would only need for the ball to touch the paddle to bounce up. Just a suggestion. I know it will mess up your future plans for the robot.
Good intuition! Paddle juggling is a lot easier than proper toss juggling for exactly this reason. Unfortunately paddle juggling also can't do the same patterns that toss juggling can (eg. three ball cascade)
your issue with the center rods on the linear actuators having wobble that you mentioned in your video a year ago could be fixed with 3 bearings, each one going to a rod. just like your top bearings keeping the actuating rod in place
Have you considered a machanism to settle the ball for a faster catch? I was thinking rubber grippers or maby vacuum. I would recomend SLA prints for a rebuild.
your CAN bus can include periodic watchdog messages and your teensy on the other end can reply to them and from your controlling side, if you don't get the reply it means communication is not working and you just cut the power to the motors or something like that. awesome job btw.
Oh yes, very good point! The watchdog is something I've been meaning to set up but it's been very easy to postpone 😅 Cheers for the reminder! I'll get this set up before running everything again ☺️
@@harrisonlow good deal. another thing you could do is monitor the current because i bet if one of the motors ends up getting blocked the current would jump up by a lot and stay at that level but i'm not sure if that is true.
Claude Shannon would be so proud! Was any compensation needed for the nonliar angular output of the universal joint vs the spherical magnetic joints? Or is it actually a double universal joint when you take in to account the attachment on the base of the platform? The Newport high precision hexapod looks like it uses a captured spherical bearing to remove the backlash in the joint! Incredible problem solving throughout🎉
Haha cheers! I'm not 100% on my universal joint terminology, so a "double universal joint" could be more correct, but all three axes of rotation meet at a fixed point, which I've used as the reference for where that 'node' is
I think an important aspect of human juggling that the bot is missing is in reflecting the ball’s trajectory with less energy loss. The human juggler makes a small circle with their hand, like a pendulum, to rebound the ball. I think a simple way to achieve a more efficient rebound would be adding springs for the ball to bounce off of. This should make it much easier to speed up each toss.
I absolutely agree regarding needing smoother redirection of the ball's momentum, though I'm not sure I agree about springs. These would be rather difficult to set up to allow variable throw heights and variable hold times. Perhaps with some sort of latch system with a slider that can lengthen or shorten the spring? But then it's becoming very complicated... 🤔
@@harrisonlowThat’s a very fair point. If the motor can still overdrive the spring, you could still probably vary the throwing speed. At minimum, it could help to just counteract gravity like floating monitor stands do
I think a limited jerk could help to reduce the vibrations and long settling time. If I understood correctly you are using trapezoidal velocity trajectories so you are only limiting the acceleration. There are also trapezoidal acceleration trajectories which limit the jerk and therefore reduce vibrations when reaching a target position. Furthermore, input shaping could help but is a bit more complex to implement.
Yeah I think the next version of trajectory control will be jerk limited for exactly this reason. I'm inclined towards the 'ruckig' generator, though I'll need to do some more experimenting with it to get familiar with how to use it. Cheers for the suggestions! ☺️
That would be interesting to see! Steppers are just so darn heavy 😧 not sure I like the idea of adding so much weight to the arm. Though I suppose I could work around that in the next version 🤔
The brushless motor for the hand has several magnets in it. Couldn't it be used for positioning? I wonder if any ESC exists which supports stepper motor like positioning.
Re: Resin printers, I really liked mine, but as I got more and more (important) safety equipment, using it got more and more annoying. Eventually I got an FDM printer, and I haven't touched my resin printer since. I'm still holding onto it in case I want to print some tabletop miniatures again, but it's mostly collecting dust.
Since you are already using ROS, there is ros2_control, which should allow to control all the joints and ensure they operate in sync. That would be the Joint trajectory controller, but not sure. I've used that also with more traditional robot arms, which have the same need for synchronisation
Very cool! I think I read of this a while ago when I first heard of ROS but never looked into it properly. I'll check it out! Cheers for the suggestion ☺️
a camera in the hand looking up (against a plain ceiling) should make tracking software pretty straightforward. This is the first video i watch in this series, so there might be a reason you already discarded that idea...
I'm not sure that would be as straightforward as you suggest. Adding a camera to the hand would mean routing wires and adding weight to the fastest-moving part of the robot, and a camera in that spot wouldn't be able to detect the ball once the arm tilts sufficiently far away from the trajectory of the ball
Haha believe me: I hate having to pick up balls that I've dropped, but what's worse is having to pick up balls that Jugglebot dropped! Very keen to make what I've been calling the "ball butler" to return dropped balls to the hand(s) 😁
Very interesting! It'll be cool to see how you approach vision in the future. 6 years ago some friends and i built a ping pong juggling robot based on a 6 axis stewart platform over the course of a few months (you can see a video of it going on my page). We used two webcams at a 90 degree offset and did raycasting to locate the ball. Vision is extremely sensitive to distortion in the field of the cameras and we had to do a lot of calibration in order to get something that worked consistently. However, given that you don't have the $200 budget we did you might be able to get a better solution that isn't as finicky.
@@harrisonlow We only tracked the ball, but technically we also corrected for the robot as well. We had two coordinate systems, the first being the one with the ball in it. We calibrated for distortion and carefully measured placement of the cameras, but at the end of the day it couldn't be perfect. The second was where the robot thought it was based on the forward kinematics of the stewart platform. As you know all too well, this only gets you a certain degree of precision as well. We then went through a painstaking process of moving the robot to a position and then dangling the ball directly above it at a known height. We repeated this hundreds of times and used that data to construct a function which mapped between our two coordinate systems. This allowed us to easily translate where we thought the ball was to where the robot should go.
Wow, that sounds like a lot of work! I can imagine the stress of being near the cameras after all the tuning is done and really trying to not bump them! 😂 Very interesting process, thanks for sharing it! ☺️
I would have stuck with Kevlar! While Kevlar has a lower strength to weight ratio, it has zero creep, and the length of the cable will not change over time. UHMWPE has roughly 5% creep, so if kept under tension for a bit it will start to stretch out.
I've actually got a video in the works on "which string is king". I've already run a heap of tests on a bunch of types of strings and (spoiler) UHMWPE has come out on top. Hopefully it won't be too long before I can get that video out!
Would it be beyond the scope of the project to have some sort of feedback from the hand (load cells, IMUs etc) to detect subtle catching and launching errors to incorporate in the ball trajectory prediction to avoid small inaccuracies adding up over time, adjusting the throws and catches accordingly to bring it back to a more stable state and keep things on track for longer?
Definitely not! This is something I've thought a lot about and hope to explore in the future. I think it won't be easy to filter out all of the "good"/expected vibrations/signals from those indicating that something is awry, though if such a system worked, it'd be extremely helpful for Jugglebot. Very similar to how human jugglers use their proprioception and tactile feedback to compensate for errors!
If you use fixed programmed trajectories. I think you need to make sure that the ball lays at a well defined rest position before the launch. An the the launch is very smooth. I think i would try a Tennisball. Maybe a not fuzzy one. and also kind of an physical damper mechanism. Just a 3 mm foam layer inside the hand. I recon trying different balls and hands could do big improvements. But really great engineering. Seriously impressed:) I always love to see if someone does fine stuff like that :)
Cheers! I agree that a pre-programmed trajectory needs the ball(s) to come to rest in the hand before each throw, though I'm not sure that a tennis ball is the right way to go here; these balls are designed to be bouncy and are notoriously one of the worst types of balls to use for human juggling. A foam/fabric liner on the hand is a great idea and I plan to experiment with this! Cheers for the suggestions ☺️
@@harrisonlow I dont think that they are too bouncy if not enough force is applied, what here would be the case. Apart from that, the reason for suggesting this was the well defined behaviour and surface of the ball. I guess a heck a seck 😅 ( no idea how to write that) is on the other side of the spectrum. I blieve due to strage form it can take, repeatability is way less
Perhaps reprint the hand with room for air to flow? I know its a small surface area but as the hand approaches the ball, it could be pulling some turbulence with it.
This is a very interesting idea! Definitely worth looking into this to see how big of an effect drag is having. No need to make the hand's job any harder than it needs to be! Cheers for the suggestion ☺️
Awesome! All I could think while watching is that you need motion capture! An optitrack / vicon rig would directly tell you the position of all joint and the ball with sub millimeter accuracy @ 100s of Hz.
This would make debugging a lot easier since you can play back all the actual motions and zero in on what’s contributing to errors. It would also let you generate a calibration to null out the Stewart platform errors. Also if you wanted to be fancy, you could close the loop on the ball position fairly trivially.
Univerities often have rigs in the robotics / sports / bio labs. Your project is interesting enough that I bet you could get access if you found the right interested researcher…
Cheers Shane!
Yeah I've been looking into getting a mocap system but they're so darn expensive! Asking around at a university is a good idea 🤔 I'm very jealous of your setup 😅
Definitely agree on how useful mocap would be. There are so many problems that suddenly become tractable when using such a system...
@@harrisonlow Would a Lighthouse based VR tracking system provide sufficient precision and refreshrate for this?
Yeah, it seems like it needs a camera in there somewhere.
Doesn't matter if it's perfect! It's the journey and learning along the way!!!
Absolutely! Cheers 😊
Correct I just made a refillable lighter out of boredom and having to buy new ones and it worked but failed fast and I learnt that butane reacts with hot glue by melting it and it makes sense since it was a hydrocarbon and that I would never have learnt if I didn't do it and now I'll get some proper adhesive and the next prototype may work ❤❤❤❤❤❤❤
Love this series Thank you for the great update!! 💪
Love the 3D ball RUclips icon. Never seen anyone use the circular icon like that!
Haha cheers!
I still remember one of your first videos when the actuator design was completely different. It's great to follow you on your journey to perfection.
Cheers for the continued support! ☺️
Thanks a lot! Becoming a juggler was my back up plan for when the robots take over all the jobs, and now you've taken that away from me as well. 😜😂
Seriously though. That was impressive!
Haha well you can still go for being a club juggler! That should buy you at least a few extra years 😉
Cheers ☺️
Fantastic project! In addition to the great result, for me this is also a great example of how much physical stress is placed on the joints and connections even on such small machines with fast movements. I am really looking forward for the further development with ‘two hands’ and ‘eyes’ - thanks for sharing and good luck with the further development.
Cheers! ☺️
this is actually so cool!
THOSE HAND MOVEMENTS ARE SO SATISFYING
If you planing to enlarge hand, don't forget to make air holes. Resistance at such speeds is significant
Very good point! This would be really fascinating to measure to understand better. Cheers for the suggestion ☺️
I think it is really satisfying to see the robot do this without any cameras tracking. If one uses tracking, in any project, i always think it is constraining the environment it will work in so much. Wouldnt it be cool, to just take it somewhere and have to care just about the robot and its brain only, not the + / - 10 cameras and and and
Jugglebot’s hips don’t lie. Great work!
💃
The engineering corner of RUclips is definitely my favorite corner.
Agreed! So much happening here. What a time to be alive! 😁
I always appreciate creators who try to open source their projects and the extent that you’re doing that is awesome! Loving this project and best of luck ❤❤
If Jugglebot ever gets eyes and computer vision, you couldn't just make it throw balls at you or see the balls it threw itself, you could also make it catch balls you throw at it.
Exactly! I'm very keen for when Jugglebot and I can juggle together 😁
The amount of progress you've made in the past couple months is incredible, I havent kept up with the livestreams, but WOW!
And I concur that a state machine would be a good plan - implemented one for one of my recent projects and it the feeling of switching everything over from nested if statements was wild.I could feel the code becoming easier to reason about and also more flexible as I wrote the new version
It's awesome to see it juggle!
Congrats on that accomplishment!
Cheers! 🤹♀
In terms of connector you could use a Molex SL 4 pin connector, look at the DJI Can-Hub that was used with their drones . You could even use their hubs to connect everything. The connectors have a clip that secures them.
Interesting! These look similar to the connectors used for the CAN bus on the ODrives. Very solid option and I'll add them to my list! Cheers for the suggestion ☺️
I feel that the best whay to aproach the configuration of a jugglebot is with cableRobot so you can have 6dof for full control of the motion and launching.
For this type of robot its really important to design something where the moving parts are as light as possible so you can have high speeds. Also its really important to solve the problem you talked about the motor coordination so all of them arrive to the correct position at the same time, if not you would not have proper control of the endfactor of the robot.
Nice work!
Agreed! Though the question is whether we really need 6dof for the hand. I think 3 dof would be the bare minimum, but 5 dof would be ideal (imo) and I reckon this can ~potentially~ be done better in a non-cable robot design 🤔
I was surprised at how far I had to scroll to find this comment to agree with it. I knew that there would be SOMEONE who would agree that the cable design would be "the bee's knees". I feel like it would be the option most likely lead to the most nimble AND the easiest to re-configure, but I would also bet that in terms of BoM costs and the cost to replicate enough to meet the end goal of throwing & catching 14 balls reliably, it HAS to be far FAR cheaper.
I think you may even be able to make it more compact too.
but it could get awfully difficult to constrain the ball paths such that you DIDN'T end up needing the entire cable robot on a Stuart platform in a corexy on a delta platform.....and designing an optimum way of routing the cables....makes my brain hurt thinking about it
Ideas from 3d printing. Certain stepper drivers allow you to monitor if it has reached the end. Could you use this sort of thing to know that it has caught a ball? Like the voltage has changed so there is a ball in the hand? Also from 3d printing, could you use input shaper to help with any resonances or wobble?
Super impressed it can juggle just based on physics and no vision! Infrared for vision maybe?
What you're describing is absolutely possible right now! The (stationary) hand motor can detect a ball placed in it, so it should be possible to detect caught balls, though I'm not sure how the signal processing would work to have it be reliable when the system is in motion. Definitely an interesting possible avenue to look into!
Re infrared: one of the options I'm considering is a motion capture system and these use IR! Good thinking 😊
The keyword you need on McMaster is "continuous flex". No extant connector has the necessary strain relief built in, so you either need a conduit that'll bear most of the strain and set a minimum bend radius or you need to fix the cable to the structure in a way that will prevent strain from accumulating in the first place.
It's not so much the strain relief that I'm worried about, but rather the connector itself unplugging due to being shaken. I suppose the cable is pulled by the strain, but I've come to realize that the current connector really doesn't 'snap' together at all and comes out far too easily. Fwiw I also may add an extra strain relief as a backup.
Cheers for the suggestion! ☺️
About connectors:
I am taking part in the Bauman Racing Team car electronics department. We have been used Molex MX150, MX150L, DTM, Superseal, Microfit connectors, but I have never been totally happy with them. I consider aviation connectors definitely worth trying, but MX150 (with no L) and DTM connectors are definitely good enough if you have a proper crimping tool.
Cheers! These appear very worth looking into
Great video and explanation. Congratulations on your fantastic effort.
Cheers Neil! 😊
Bloody fantastic, and a very smooth video! Nice one Harrison
I love his experimental/collaborative build style. very entertaining and informative
If you can unify the hand movement with the arm movement, you can likely utilize the arm to assist in movement for catching or throwing. Essentially speeding up the hand.
Yep, 'piggybacking' the hand movement on top of the arm movement would be great. Should be able to get super high throws and much gentler catches this way!
This is really impressive and love the community input. New sub!
Regarding the missing 3mm in height: Check whether your measuring tape actually is accurate, just to be sure...
That's a very good point! I'll check this when I get my new linear scale set up 😁
Cheers for the suggestion!
Awesome work Harrison! It's amazing how complex this problem is to solve. And even more amazing that our brains and body's can juggle (with a fair bit of practice :)
Absolutely! It's so impressive that humans can juggle at all. It's going to be a very long time before we have anthropomorphic robots that can juggle as well as the best humans
What an exciting project. Have you considered mounting an IMU to the top of your juggler for the option to run active vibration control/compensation to reduce the ringing? Basically use the IMU data to calibrate and counteract vibrations..
Maybe people with more experience in this field can give constructive suggestions on how to implement this code. Love the project!
Interesting idea! Some others have suggested input shaping and (I think) this would go a long way to helping implement that. I'll keep this in mind for if the ringing is still present after fixing the platform joints and the arm trajectory control. Cheers for the suggestion ☺️
What an interesting project. I immediately subscribed . keep up the great work !
Cheers! 😊🤹♀️
This is the second video that I have seen on your Channel. Great work and I look forward to viewing the rest of your content. Subscribed. 🔔
Cheers for the support! ☺️🤹♀️
others might have suggested this already, personally i would use an optical/ light/dark detector in the hand looking up. and programming it as a state machine is much better.
That's definitely a solid option, though it wouldn't tell us anything about the balls after they've left the hand, so those first few measurements would have to be really good to inform a physics model to predict collisions etc.
Or, we could use an external set of eyes to watch the whole shebang. Lots to consider!
Cheers for the affirmation of the benefits of a state machine ☺️
Keep in mind that the bigger you make the hand, the longer the ball will take to potentially settle for accurate throws and fast patterns might lose accuracy if the ball doesn’t land perfectly and bounces or rolls a bit in the hand.
Making the hand as small as possible is more challenging but probably better in the long run because you want to eventually toss and catch faster and faster. I’d stick with the small hand for now and just experiment with shape and do some high speed footage to see if/how it bounces or moves during a catch.
Good luck!
Yeah this is a very real concern of mine and is something I'll need to experiment with. I think the "correct" solution here is to use a larger hand with so-called "Russian" style juggling balls, which are basically firm plastic balls partially filled with sand. The sand (should) do a great job of dissipating excess energy and stopping the balls from dilly-dallying around the hand.
No doubt, there's a lot of testing to be done!
Cheers for the input ☺️🤹♀️
@@harrisonlow Oh cool! So Russian style balls are basically deadblow juggling balls? Haha
I forgot to mention that you can get a used GoPro for pretty cheap that’s capable of 120fps at 1080 and if you can afford it there are a few Sony and canon cameras that can do 120fps at higher res and 240fps at 1080. It’s not suuuper slow motion but should be enough to get a decent understanding of what’s happening with your robot.
A friend of mine had the same issue and had decent luck, he found a Sony that films 120fps at 4K used for about $700usd. But you can probably find a used GoPro for less than half that…
If you need anything higher speed, I’d recommend rental if that’s an option in your area… anything over 120fps starts to get pretty expensive, starting around $2k or so.
Just don’t make the mistake my friend did by being unprepared… high speed cameras need way more light than you think and if you’re renting, remember to have everything set up and prepared ahead of time so you can make the most out of it. Also, high speed footage chews through storage so that’s a huge factor is affordability and logistics.
I’m not sure how fast jugglebot actually is, so hopefully one of the cheaper options will be enough for you to gather the data you need and you can avoid the cost and hassle of slowmo video setups. Either way, I know you can handle it.
Good luck! I look forward to seeing some robo-human juggle action in the future! Haha
Cheers for the suggestions! ☺️
The hand shape you've got now is pretty good. Probably best to leave that shape exactly as is for the bottom then extend it with a slightly conical section going up to guide the ball back in place if it's a bit off. CoreXY is a good idea, but it seems completely unnecessary to make the hand able to pivot. With that largely spherical hand throwing mostly up it matches all the directions of throw you need already, just have to coordinate the XY and the hand to get exactly the trajectory you want. Aside from giving it eyes and getting the subtle details of the control systems working properly it looks like that approach should be able to get you there but you should test whether the hand mechanism you have now can throw high and fast enough to do 7 in one hand without breaking.
M12 connectors are quite affordable and should stay in place, same for M8 and M5 connectirs for that matter
I'm a big fan of the M8 and M12 style connectors. That's what I'd use for the CAN bus.
Interesting! I've never heard of these and they keep being suggested now and I can see why. They look very good!
Cheers for the suggestion ☺️
As a regular nerd, 3d printing nerd, juggler, and having done several circus tours I love this.
Cheers! 😁🤹♀️
Great video, happy I found this
I have always wanted to build one of these. Wonderful video.
Your gonna have so much stuff going on in that workshop once chat can easily interface and control all your robotics ❤❤❤❤❤❤❤
Haha that'd be so cool
looking forward to seeing bathrobe again
Haha it does have a cameo or two throughout the video 😂
Check out industrial M8 / M12 connectors. There are various configurations (pin counts, key position, ...) and they are designed to by used on industrial robots - preferably with robotic cables. You can start by looking at SICK or Phoenix contact.
Also, those green phoenix connectors you use are also made with locks, so they doesn't fall out so easily. We are using them without problems, lock-less versions always had to be glued in place to be secure.
Wow those look super solid! Cheers for the recommendation!
Also big thanks for referring to my current connectors by their actual name. I had no idea what they're called so it's very handy to know that they're Phoenix connectors (and that they come in a locking variety!). Cheers ☺️🤹♀️
More n more we move closer to the future of that terrifying ride from spykids where it juggles you becomes a reality
Hahaha "terrifying" is subjective 😂🤹♀️
Hey Harrison I was extremely impressed with this project BEDORE you casually mentioned that you’re not using CV and the whole juggling operation is basically open loop…. then I nearly fell out of my chair. It’s a testament to the incredible mechanical precision that you’ve engineered from cheap 3D printed parts. Unbelievable work.
I’m working on a project that could really benefit from that kind of precision. I would really greatly appreciate an opportunity to talk through it with you and any guidance you could offer me. Please drop me a reply if we can make a short call or email happen!
Cheers!
For sure 😊 Depending how open you want to be about it, you can either post to this project's Zulip site (Link in the description. The "project showcase" Stream would be great for this) or you can email me using the email found on my RUclips channel (look at the "about" section). I'm keen to read about what you're working on!
PS I probably won't reply for a few weeks as I'm still on holiday ☺️
What are your goals for the next movement platform design? Minimizing end effector mass? In that case, if you can somehow move the "hand" motor off of the actuator, that may greatly reduce the mass. I'm not sure how you would do that, maybe a bowden cable would be good enough? Maybe clever corexy style belts with multiple drive motors? Maybe even make the "hand" pneumatic with an extremely lightweight cylinder that acts as both the actuator as well as the linear guide?
I need to do some analysis for precisely what speeds I need, but at a guess, I'd want the hand to move at up to 14 m/s (for a 10m high throw) and the arm to move around 4 m/s.
The whole system needs to be fully symmetric, or at least agnostic as to the direction that balls are coming in/out
I dont know if you implemented it already but something like input shaping on 3d printers could help
I feel that vision based closed loop control will get you closer to your goal faster by compensating for imperfections in the motion system. Juggling seems like a task where suppleness, speed, and perception matter more than rigidity.
Yeah I'm inclined to agree. Just frustrating how darn expensive motion capture systems are 🤑
Absurdly cool! Very glad this popped up on my recommended; you've earnt yourself a new sub!
Very impressive project! 👍
Fantastic work! I have been watching for quite a while. You have inspired me to DIY my own high speed actuators. The actuators you devised are amazing and I am considering "borrowing" your design idea to replace some pneumatic hardware I use on active aerodynamics.
Cheers! Haha go for it 😉 while they're not perfect, these actuators have served me pretty well and could at least serve as a starting point for you to build on top of ☺️
Awesome work. Very impressive. Have you looked at Molex micro-fit3 connectors? Thats what we use in 3D printers on a print head that has lots of accel..so that might work good here.
Cheers! I've added them to my list to check out. If they can survive the torture that you put them through, I reckon they could work pretty well!
Thanks for the recommendation ☺️
Love what you are doing! Subscribed ! This is gonna look so amazing with led glow balls when you get it working 😜
Excellent work
Great project and progress. If you developed dual linear rail arms with catchers on the end, the form factor could be more humanoid. If you decide the catcher should be hand shape, look into team unlimited “phoenix”prosthetic hand that’s open source. I’ve printed several. They use a drawstring effect for grasping. Then once you have the “routine” down, you can sell to Tesla to incorporate into all bots. :)
Can’t wait to see you shatter some records!
Very cool project! I would suggest a microfit 3 or similar molex connector for the CANBUS connection. I use those for my CANBUS system on my 3D printers and they hold up to extreme speeds and shaking very well.
Cheers! Those connectors look bomber and it's good to know you've field-tested them 😁
I'll add them to my list of options to check out when I'm back from holidays. Cheers for the suggestion!
Anderson Powerpole gives you tons of amps and lets you make any number of pin connectors. Haven't used deutsch but they look nice. XLR 5 pin are nice and easy to find connectors. There are also the "M16" series of threaded connectors, often used in lighting, not exactly a standard so you have to hunt around for a bit. Then there are amphenol connectors, widely used in aerospace and military, which come in every shape and size, rugged as heck, and $$$
Whoo, those amphenol connectors *do* look awfully sexy though 🤔 I'll add these to my list of options! Cheers for the suggestions ☺️
With Peopoly now selling hobbyist linear motors, you might consider that as a possible motor for the hand. It's an EXTREMELY precise, closed loop motor that handle a lot of weight and won't need to be tensioned...kind of a perfect solution.
True! Definitely seems worth looking into. Cheers for the suggestion ☺️
It needs a camera feedback so it can catch a thrown ball and compensate for when its own throw is a little bit off
Absolutely agree with this. I think you have come impressively far by just making the hardware close to perfection. But if you want to juggle 14 balls, I think you will have a really bad and long time if you just try to perfect the hardware. I think you need to spend some serious time getting camera feedback or getting a proper tracking system. You will also need to develop control algorithms which can compensate for imperfect throws and balls bouncing against each other. Even things like air pressure, humidly and temperature will affect robot and ball performance from day to day. And in order to compensate for this you need a proper control system.
Absolutely agree! I'm very curious to see how far we can get with open-loop control, though I highly doubt it'd be all the way to 14 balls. Motion capture systems are just so darn expensive 😨
@@harrisonlow ruclips.net/video/0ql20JKrscQ/видео.htmlsi=wsBfqomIldgRd78K
@@harrisonlow they don't need to be that expensive. 2 pi's and picams should suffice(one even but more complicated lens/positioning to get z from ball size). The tricky part is taking into account the lag. No lag systems would get increasingly expensive.
Like the computer vision part to detect balls at realtime can run even on a cellphone just on cpu.
Pi and cellphone based sbc's have better/faster camera interfaces than you'd get hooked up on a desktop cheaply(this is why laptop cameras are usually crap..). The picams hook up straight to the interface on a pi
I was surprised that it's open loop
great progress!
Congratulations!
Cheers ☺️
Well done
I suggest M12 Connectors, there are even some intended for Can Bus with appropriate shielding
Oh neat! These look great. Cheers for the suggestion ☺️
Please explain how you use the jacobian to determine the ideal configuration. I've built more than a few stewart platforms and always wondered how to select the best form factor.
It's hard to describe this over text, so I recommend checking out Livestream Update 23 (Link in the description) where I went through some of this ☺️
Deutsch DTM Plugs can be an option. We use them at work, but they sometimes need to be plugged in and unplugged a couple of times for them to work.
Another option would be to just use a XRL Plug and Cable that is normally used for microfones. The cables are usually really soft and shielded and the connector hat a solid connection.
Ooh that's interesting! I've never heard that issue with Deutsch plugs so I'm glad you told me about it!
I'll have a look into XLR plugs. Cheers for the suggestion ☺️
@@harrisonlow No Problem. It is pretty much a joke at this point, we call them 1 2 3 Plugs, cause you need to plug them in 3 times for them to work xD
i have a brilliant idea for the "eyes" of it..
first, make the hand weigh the balls in real time. then make a program that calculates physics, calculate the balls trajectory in real time.
that way the robot "knows" where the balls are.
only downside is if someone interrupts the balls or there a wind heavy enough to move the balls enough to mess up the calculations(the wind one can be "fixed" with a simple wind sensor and feeding it to the calculations)
this is so beautiful
Your work is amazing. In my mind, the actuators are more analogous to muscles than legs.
Cheers ☺️
That's interesting! I'm not sure why but 'legs' has always just felt right to me 🤷♂️
You could use a pneumatic soft robot hand to grab the ball and let it go.
If you are going to switch to corexy, it may be a good idea to use an existing 3d printer platform to prototype on. That would also make creating many jugglebots easier.
Very good point! It's be great to have a solid foundation to develop on top of. Cheers for the suggestion!
I've built a laser engraver by building a Voron 2.4 Gantry and putting it on some self designed legs that hold the honeycomb plate. The gantry is a good standalone coreXY assembly
This is awesome!
it may be easier for the bot to use paddle and ping pong balls., as most of the time is used for the throw and you would only need for the ball to touch the paddle to bounce up. Just a suggestion. I know it will mess up your future plans for the robot.
Good intuition! Paddle juggling is a lot easier than proper toss juggling for exactly this reason. Unfortunately paddle juggling also can't do the same patterns that toss juggling can (eg. three ball cascade)
Congrats!
Cheers! 😁🤹♀️
For the CAN connections, you could try MOLEX
your issue with the center rods on the linear actuators having wobble that you mentioned in your video a year ago could be fixed with 3 bearings, each one going to a rod. just like your top bearings keeping the actuating rod in place
Have you considered a machanism to settle the ball for a faster catch? I was thinking rubber grippers or maby vacuum. I would recomend SLA prints for a rebuild.
your CAN bus can include periodic watchdog messages and your teensy on the other end can reply to them and from your controlling side, if you don't get the reply it means communication is not working and you just cut the power to the motors or something like that. awesome job btw.
Oh yes, very good point! The watchdog is something I've been meaning to set up but it's been very easy to postpone 😅
Cheers for the reminder! I'll get this set up before running everything again ☺️
@@harrisonlow good deal. another thing you could do is monitor the current because i bet if one of the motors ends up getting blocked the current would jump up by a lot and stay at that level but i'm not sure if that is true.
Claude Shannon would be so proud!
Was any compensation needed for the nonliar angular output of the universal joint vs the spherical magnetic joints? Or is it actually a double universal joint when you take in to account the attachment on the base of the platform?
The Newport high precision hexapod looks like it uses a captured spherical bearing to remove the backlash in the joint!
Incredible problem solving throughout🎉
Haha cheers!
I'm not 100% on my universal joint terminology, so a "double universal joint" could be more correct, but all three axes of rotation meet at a fixed point, which I've used as the reference for where that 'node' is
I think an important aspect of human juggling that the bot is missing is in reflecting the ball’s trajectory with less energy loss. The human juggler makes a small circle with their hand, like a pendulum, to rebound the ball. I think a simple way to achieve a more efficient rebound would be adding springs for the ball to bounce off of. This should make it much easier to speed up each toss.
I absolutely agree regarding needing smoother redirection of the ball's momentum, though I'm not sure I agree about springs. These would be rather difficult to set up to allow variable throw heights and variable hold times. Perhaps with some sort of latch system with a slider that can lengthen or shorten the spring? But then it's becoming very complicated... 🤔
@@harrisonlowThat’s a very fair point. If the motor can still overdrive the spring, you could still probably vary the throwing speed. At minimum, it could help to just counteract gravity like floating monitor stands do
Try using old serial/games plugs.
They screw on and should be quite cheap, plus these plugs can support many cables, ideal foe your usecase.
I think a limited jerk could help to reduce the vibrations and long settling time. If I understood correctly you are using trapezoidal velocity trajectories so you are only limiting the acceleration. There are also trapezoidal acceleration trajectories which limit the jerk and therefore reduce vibrations when reaching a target position. Furthermore, input shaping could help but is a bit more complex to implement.
Yeah I think the next version of trajectory control will be jerk limited for exactly this reason. I'm inclined towards the 'ruckig' generator, though I'll need to do some more experimenting with it to get familiar with how to use it. Cheers for the suggestions! ☺️
I’d be curious to see the height and trajectory consistency if you’d switch the servos for open loop steppers!
That would be interesting to see! Steppers are just so darn heavy 😧 not sure I like the idea of adding so much weight to the arm. Though I suppose I could work around that in the next version 🤔
Hello, I'm smashed :) what a nice work :)
The brushless motor for the hand has several magnets in it. Couldn't it be used for positioning? I wonder if any ESC exists which supports stepper motor like positioning.
spacex needs a big modded one of these to catch their spacetoobs
I believe LEGS (Linear Extension Gimbal Systems) is technically accurate. 😛
Re: Resin printers, I really liked mine, but as I got more and more (important) safety equipment, using it got more and more annoying. Eventually I got an FDM printer, and I haven't touched my resin printer since. I'm still holding onto it in case I want to print some tabletop miniatures again, but it's mostly collecting dust.
Yeah resin printing seems like a lot of effort/risk for the gain in print quality 🤔
awesome!
Cheers 😁
Since you are already using ROS, there is ros2_control, which should allow to control all the joints and ensure they operate in sync. That would be the Joint trajectory controller, but not sure. I've used that also with more traditional robot arms, which have the same need for synchronisation
Very cool! I think I read of this a while ago when I first heard of ROS but never looked into it properly. I'll check it out!
Cheers for the suggestion ☺️
@@harrisonlow though, like many things ROS: not for the faint of heart. But if you got to this point already...
Amazing video, Love your content from Sri Lanka. 😄
Cheers! 🤹♀️☺️
a camera in the hand looking up (against a plain ceiling) should make tracking software pretty straightforward. This is the first video i watch in this series, so there might be a reason you already discarded that idea...
I'm not sure that would be as straightforward as you suggest. Adding a camera to the hand would mean routing wires and adding weight to the fastest-moving part of the robot, and a camera in that spot wouldn't be able to detect the ball once the arm tilts sufficiently far away from the trajectory of the ball
well done sir!
Cheers ☺️🤹♀️
I see a fatal flaw: the juggle bot has no provision for bending over to pick up a dropped ball. 😉
Haha believe me: I hate having to pick up balls that I've dropped, but what's worse is having to pick up balls that Jugglebot dropped! Very keen to make what I've been calling the "ball butler" to return dropped balls to the hand(s) 😁
@@harrisonlow - check out marble lifts if you’re not already familiar with them.
Very interesting! It'll be cool to see how you approach vision in the future. 6 years ago some friends and i built a ping pong juggling robot based on a 6 axis stewart platform over the course of a few months (you can see a video of it going on my page). We used two webcams at a 90 degree offset and did raycasting to locate the ball. Vision is extremely sensitive to distortion in the field of the cameras and we had to do a lot of calibration in order to get something that worked consistently. However, given that you don't have the $200 budget we did you might be able to get a better solution that isn't as finicky.
Very cool!! Did you only track the ball, or the robot as well? Impressive that you got that working on such a low budget!
@@harrisonlow We only tracked the ball, but technically we also corrected for the robot as well.
We had two coordinate systems, the first being the one with the ball in it. We calibrated for distortion and carefully measured placement of the cameras, but at the end of the day it couldn't be perfect.
The second was where the robot thought it was based on the forward kinematics of the stewart platform. As you know all too well, this only gets you a certain degree of precision as well.
We then went through a painstaking process of moving the robot to a position and then dangling the ball directly above it at a known height. We repeated this hundreds of times and used that data to construct a function which mapped between our two coordinate systems. This allowed us to easily translate where we thought the ball was to where the robot should go.
Wow, that sounds like a lot of work! I can imagine the stress of being near the cameras after all the tuning is done and really trying to not bump them! 😂
Very interesting process, thanks for sharing it! ☺️
wow I did not expect it to be blind
I would have stuck with Kevlar! While Kevlar has a lower strength to weight ratio, it has zero creep, and the length of the cable will not change over time. UHMWPE has roughly 5% creep, so if kept under tension for a bit it will start to stretch out.
I've actually got a video in the works on "which string is king". I've already run a heap of tests on a bunch of types of strings and (spoiler) UHMWPE has come out on top. Hopefully it won't be too long before I can get that video out!
Would it be beyond the scope of the project to have some sort of feedback from the hand (load cells, IMUs etc) to detect subtle catching and launching errors to incorporate in the ball trajectory prediction to avoid small inaccuracies adding up over time, adjusting the throws and catches accordingly to bring it back to a more stable state and keep things on track for longer?
Definitely not! This is something I've thought a lot about and hope to explore in the future. I think it won't be easy to filter out all of the "good"/expected vibrations/signals from those indicating that something is awry, though if such a system worked, it'd be extremely helpful for Jugglebot. Very similar to how human jugglers use their proprioception and tactile feedback to compensate for errors!
If you use fixed programmed trajectories. I think you need to make sure that the ball lays at a well defined rest position before the launch. An the the launch is very smooth. I think i would try a Tennisball. Maybe a not fuzzy one. and also kind of an physical damper mechanism. Just a 3 mm foam layer inside the hand. I recon trying different balls and hands could do big improvements. But really great engineering. Seriously impressed:) I always love to see if someone does fine stuff like that :)
Cheers! I agree that a pre-programmed trajectory needs the ball(s) to come to rest in the hand before each throw, though I'm not sure that a tennis ball is the right way to go here; these balls are designed to be bouncy and are notoriously one of the worst types of balls to use for human juggling.
A foam/fabric liner on the hand is a great idea and I plan to experiment with this!
Cheers for the suggestions ☺️
@@harrisonlow I dont think that they are too bouncy if not enough force is applied, what here would be the case. Apart from that, the reason for suggesting this was the well defined behaviour and surface of the ball. I guess a heck a seck 😅 ( no idea how to write that) is on the other side of the spectrum. I blieve due to strage form it can take, repeatability is way less
Nice project. I wish I have so much time.
I feel very lucky to be able to do this! Definitely a huge time commitment
Perhaps reprint the hand with room for air to flow? I know its a small surface area but as the hand approaches the ball, it could be pulling some turbulence with it.
This is a very interesting idea! Definitely worth looking into this to see how big of an effect drag is having. No need to make the hand's job any harder than it needs to be!
Cheers for the suggestion ☺️
getting state machine pilled is probably similar to being ros2 or canbus pilled. you won't regret using them i reckon
🤞😁