Project Update - PDJ #13
ฝัง
- เผยแพร่เมื่อ 13 มิ.ย. 2024
- This is just a quick update on Project: Deepblue Juggling, in which I cover some helpful suggestions from viewers, as well as two progress updates.
I hope you find it interesting, and please let me know in the comments if you have any thoughts/suggestions about the project!
##### Links to things mentioned in this video #####
Oak-D-Lite depth cameras:
docs.luxonis.com/projects/har...
##### Github folder for this video ######
github.com/Project-DeepBlue-J...
This folder contains the simulation python script, as well as the CAD for Jugglebot with the updated leg design.
00:00 - Intro
00:11 - Impact of Your Suggestions
03:37 - Other Applications of Jugglebot
04:03 - Update 1 - New Leg Actuation
07:32 - Update 2 - Tracking Simulation
10:08 - Where to Place the Camera(s)? - วิทยาศาสตร์และเทคโนโลยี
![[Full] อังคารคลุมโปง Close Up EP.49 | คนใกล้ผีคนที่ 49 : หมอฉุกเฉิน “หมอบอส” (Thai Sub)](http://i.ytimg.com/vi/dKPUaX7UxMQ/mqdefault.jpg)
I forgot to mention in the video that I've put the CAD and code for this video up on Github. Link is in the description 🙂
really cool stuff! interesting how humans can learn to juggle, but to make a robot do it is far more complex in comparison, now this shows the miracle of how our human bodies are designed 😯👍
Yeah it's nuts how good humans are at such a wide range of activities. That said, we do have our limitations (eg. the guy with the current world record of 14 balls thinks it might be impossible for humans to do 15+ because of how fast it is).
I honestly think Jugglebot will be able to "learn" 6+ balls faster than I have. It's taken me around 3 years to be able to get ~20-30 catches of 7 balls and I reckon Jugglebot will be able to do 7 balls within the next 18 months, so it would've gone from nothing (not even existing!) to 7 balls faster than I could. Fingers crossed!
This is a great project to watch develop. It's fun to see the ideas develop and get refined! Thanks for sharing!
Constant string tension: the classic way is to put an idler pulley on the string. It will reduce the throw of the actuator, but not necessarily a great deal.
Crazy camera location idea - on the top of the platform. Always a clear view of the ball. The math for ball position would be extra noisy, but since you know where the platform *should* be, you can translate coordinates to compensate. If you add an IMU on the platform, you could use that for closed loop position control too. Using the theoretical platform orientation, along with IMU data, an added benefit would be the ability to implement another Kalman filter (or some of that crazy quaternion math I have heard of, but have never learned) to estimate real platform position. Very cool project!
I've toyed around with this idea but I'm not sold on it yet. My worry is that there will be too much high-frequency vibration and the camera won't be able to get a steady view. That said, this version of Jugglebot has much tighter joints and transmission than the previous design(s), so I'm definitely going to give it a go once everything is up and running!
Another issue that will need a solution is how to route the power and data cables to the camera if it's on the platform 🤔
I've never used IMUs before but have worked with people who researched them pretty thoroughly and I'm a little turned off them due to their penchant for drifting. Have you used them before?
Cheers!
@@harrisonlow I was thinking that vibrating could cause some rolling shutter issues with the camera. And I agree, power routing is a bit tricky. Data could be via wireless (Wi-Fi probably) if you had a Pi Zero on the platform to connect a camera to. As for the IMU, I have not used one before, so I haven't experienced the drift issues myself. But my understanding is that drift is the sort of thing that a multi sensor kalman filter is good at dealing with, especially since your estimated position state should be pretty reliable with the actuator setup you have (even without linear encoders). I've been working (slowly) towards implementing a Kalman filter of my own, but haven't yet finished that project. Too many distractions :)
Hmm, I wireless data transmission would be tricky (for me, at least). Perhaps using ROS would make it easy, but ROS is scary
Interesting, maybe it's worth playing around with some IMUs! What are you implementing a kalman filter for?
Haha I fully appreciate the endless distractions that come up 😂
@@harrisonlow trying to do sensor blending to estimate chemical flow rate based on a slow tank level measurement that is accurate but not overly precise, and a metering pump speed that is precise but not accurate :) All of this in am industrial PLC, so it has no matrix math functions. That got me on a tangent of writing some matrix ops... Never ending tangents :)
Oh man. I can't imagine doing any of this without matrix math. At one point I was coding some of the basic Stewart Platform math into an arduino and even that (very straightforward linear algebra) was driving me mad. So many loops!
Sometimes i stand in my front garden and just whack away, until the neighbour complains.
Jugglers only look at the top of the curve. You can hide about 75% of the trajectory and they can still joggle. The balls in the top also move at the slowest rate. Maybe an idea for the camera as well as the software.
Good thinking! I actually haven't considered this myself and it might end up being the way I'll have to go. It'd be quite a bit easier if I could keep the balls in view the entire time-jugglebot doesn't have a sense of touch the same way we do, so it can't make adjustments based on that the same way we can-but I may have to compromise if the cameras' viewing angle isn't large enough
Are you a juggler yourself? This seems like something only a juggler would think of 😂
@@harrisonlow Only 3 balls. I saw a long time ago a tv-show about this. Juggles need very few information to catch the ball. But they need the top of the curve.
I saw you with 5 balls. Look were your eyes are all the time.
You could use the linear bearings on ground steel rod, but reverse it so the rod is on the lower fixed side, then have a larger diameter carbon fibre rod on the outside of the bearing so the actuator is only seeing the weight of the bearing and the CF rod.
That's an interesting idea!
@@harrisonlow obviously by CF rod I actually meant tube, whoops
You could 3D print a coupler for the CF tube to the linear bearing allowing a tube with an ID only slightly larger than the OD of the steel rod. But the 3D printed part might be heavier than just using a larger diameter CF tube 🤔 very interesting project!
@@ollied1981 That would be pretty cool! With steel tubes and the method you're describing you could make some super thin actuators! Very interesting take on the problem
I'm pretty surprised you're using the Oak-D. I did not find it friendly or intuitive, but I'm curious to hear how well that works out. If you end up putting the camera on the side you could use something like AprilTags as fiducials + OpenCV to get the position of the jugglebot automatically.
Interesting... I haven't used the Oak-D _too_ much at this point and for better or worse, I've found most of the software stuff I've been working with to be very non-intuitive (CAN, Linux, Jetson devices, ODrives etc.) and I don't know of a better replacement for the oak cameras so I'm sticking with them mostly out of convenience/necessity at this point. If you have any alternative suggestions, I'm all ears!
Yeah I think your idea with the April tags is what I'd do if the cameras were positioned off of jugglebot, though I'd prefer to avoid that because it's just _another_ source of error...
considerd using pneumatics instead of wires?