Our claw needs to be super lightweight and hold in 78 kg of force (multiply by 9.8 m/s^2 and you get the Newton force). But we were thinking of using 3, 553 oz/in servos for three claw pieces made of welded bike chain pivoting on small ball bearing mounts. Does that sound reasonable? I’ll have CAD ready by tonight but for now, does that sound reasonable? The claw pieces will probably be the arc of the basketball, but only 4.5 or 5 inches in horizontal length.
I am having a very difficult time picturing what you are describing. If you put up some cad drawings it will be much easier to see.
Here is our arm in CAD. Too bad CAD is unsupported, but I took plenty of pictures and I have one more to attach as a drawing of the claw itself
I wouldn’t use servos for this application. If you really want to make a motorized pincher claw, using a Window motor and a potentiometer for angle feedback would be much more preferable. Or if there are only two states needed (such as retracted in the robot OR fully extended), a pneumatic cylinder would be even easier to use if you already committed to having pneumatics on your robot.
As for the claw, is there any compelling reason why you are looking to weld dozens of links of roller chain together? It would be much easier, faster, and significantly lighter just to cut a claw arm out of 1/4" polycarbonate (Lexan) sheet.
Same point Art pointed out - bike chain is probably made from steel. Three pieces of chain the length you describe would probably weigh more than the ball itself.
I would also suggest using polycarbonate (lexan) cut into the same shape as a lighter alternative.
For the servos to hold the ball as the arm whips around to throw, then release the ball, the centripetal force they would have to hold against just for the ball would be in the neighborhood of 35 N (weight of an object of about 4 kg - about 8.8 lb) to throw the ball at 20 foot per second. If you are - the force of the holding fingers being whipped around in the arc would add to that.
My gut feel is there isn’t enough holding force of the 3 servos to hold the fingers and the ball. At 5 inch length, they are pressing inwards at about 300 oz for all 3 - about 19 lb. but only a small component of that inwards squeeze is actually holding the ball up - the rest is just squeezing the ball and holding center of mass of the fingers from flying straight out from the bearings.
If you covered the fingers with a really grippy material such as urethane rubber, then the squeezing would provide a normal force such that friction would keep the ball from flying out.
Hard to tell much from an analysis because of the complex shapes and the curved fingers - it might work - my gut feel says it probably won’t. Suggest you prototype it.
We don’t have the funds to prototype and the pneumatic or window motor or regular motor is too heavy. If I use the polycarbonate it might only be slightly lighter, but I think it’ll work better than the chain. Anybody know how much urethane friction would help against flying out?
I just ran the numbers* and the 553 oz-in servo you want to use is likely illegal due to rule R48-L (depending on what its maximum rotational speed is, as it will likely have a peak power output over the 4W at 6V limit).
- Assuming max torque is 553 oz-in and the max rotational speed is .21 sec/60 degree (which seems to be the average speed I found when looking up high torque servos in the 400-600 oz-in range at 6V), this results in a peak power output of 4.86 Watts.
It is defiantly a very unique idea.
Well we’re solving it by using a 1/4 cup to go un the underneath of the ball then using the servos (new ones cuz we figured out we cant use a servo the is rated right at 6V and just use the 12V option ) and 1 cm urethane fingers to hold it in tightly and hopefully if we ever get our checks, we’ll have a prototype up next week? lol
What if you ran the motor remotely? Use a cable like a bike brake system and have the motor off the arm. That way you can transfer force to the claw system and have it spring loaded to open or close while the motor and cable provide the opposite action. We used this for 2011 to grip tubes and it was incredibly flexible and allowed us to pinch tubes as tight as we could have wanted. Plus parts are cheap, you can get cable and clamps at Lowes, Home Depot, or any local bike shop.
There is one thing I’d be worried about, if my interpretation of this setup is correct (which it may not be).
Am I right in assuming that the claw(s) in question will be mounted on an arm, the entirety of which will be spinning at some speed sufficient to launch a ball if the claw holding said ball is opened, at some point during a match?
If I’m not right in that assumption, then you can ignore what I’m about to say. If I’m right, then your servos are going to be in a lot of trouble, whether they’re servos or some other motor. You have them out at the end of a rapidly rotating arm, so they have to be mounted securely. However, I am confident that that is doable.
What concerns me, if the assumption is correct, is: I think you will need either a metric ton of extra wire, a slipring, or some other linkage to get the servo power out to the servo. You’ll be winding up wire and possibly pulling and damaging connections, or having to reverse, otherwise. I would strongly suggest looking into sliprings for PWM (or whatever wire you end up using) to avoid this problem. Sliprings of appropriate gauge are legal per [R44] (this for those who were around when they weren’t). Or an alternative linkage for claw release that doesn’t involve the servo going around and around.
Again, this is only if I’m right about the intent of this arm design. If I’m wrong about that, then mea culpa for assuming something that wasn’t clear.
The other thing I could say, but at this point I’m willing to bet that it could be done: I think the entire system is too complicated for any team, let alone a rookie team. However, that is for the team to decide, and they obviously have.
Well we were thinking of leaving a lot of slack in the wire and either having the robot pre -wind backwards or after autonomous (our team is heavy programming) we would let it reverse while it it moving which isn’t that big a problem. As for damaging wires, we were going to at least hook the servo cable extenders at the weak points just in case it somehow gets out of hand then the break happens where it is designed to break.
We looked through the rules and it says that the actuators can’t be changed under x, x and x, but we might pose a question to the GDC because it says in the blue box about it being a rule so teams can’t get more power, but ours is just for functionality.
I’ll bring this up next meeting! I like it, and eventually we’ll have some prototypes to share at the end of week three, or even a full robot depending if we get money in time
So it’s just a back and forth launch? If it isn’t, see slipring. It’s more durable than a lot of slack, and eliminates any need for slack beyond what’s need to plug in.
What I meant by linkage change was something like a helicopter uses for control–I believe it’s called a flybar or something like that. You can do whatever you need to to the output of any non-integral gearbox. (See [R49-A])
Your post so far suggest that the timing of the release would be computer controlled. That seems really hard, and difficult to debug unless you have a high speed camera around. I would suggest that you make your release mechanical based on rotation of the arm. And the use a motor to adjust that release point forward or back. It is mechanically complex, but that can be understood without a high speed camera.
We we’re sure if sliprings were in compliance with rules. Is there anything to back it up that they are? Because that was our number one choice but we needed a backup which was the slack in the wires. Also, could you explain the flybar? I found what it basically is, but why would we need it again?
Well we havbelieve with an encoder (might need a better one than the FIRST choice ones) we can track the exact RPM the arm is moving at then have it correct tself before launch. It all is set to happen <2.5 sec, but we have an amazing programming team. We think the only hard part is finding how the motor corrects itself because we don’t want an oscillating graph where RPM is oscillating on the y axis over the x axis of time because it’s over correcting. So that’s an experimental stage. We are actually hoping the cup design would be able to release the ball on a tangent to the rotation without touching the ball. If the cup is too deep, we have a shallow one and we mount the servo arms (1 cm long urethane fingertips) parallel to the x axis (perpendicular to the rotation) to also decrease chance of even bein involved in the ball’s release other than the release of force.
Is there anything to back it up? You betcha. [R44] includes the following:
The branch circuit may include intermediate elements such as COTS connectors, splices, COTS flexible/rolling/sliding contacts, and COTS slip rings, as long as the entire electrical pathway is via appropriately gauged conductors.
If you wanted to avoid a motor or servo on the rotating arm (and thereby the electrical hassle of extra wire or sliprings), you could run a setup similar to a helicopter’s flybar. The flybar allows the rotor on a chopper to maintain a commanded orientation, regardless of where in the rotation the rotor is. It also translates changes up to the rotors. Something like that provides a mechanical solution to the problem (expense of weight). A slipring is probably the best option.
Ah I see! So basically since We HAVE to mount the servos directly on, it would be easier to do a slipring? And we’re actually mounting the encoder to the outside of the shaft so that wiring is independent then taking the shaft and in the middle of the arm we’re creating a “keyed” (really just filed) section the then move with the arm. No extra anything needed it just let’s the encoder sit on the outside. So then we only have 3 servos on the claw. Sorry about the grammar, but I am on my iPhone getting posts in before sleep lol