Wrist Mechanism Gearing

We are planning to use a wrist mechanism on our robot this year. Last year, we also used a wrist, but we had the issue where the gearbox and motor would not be able to hold up the arm due to the force of gravity. It kept falling down and we had to bring it back up after reaching the switch in order to score our cube.

We don’t want to have to do that this year; we want our arm to stay at a raised height even when the robot is powered off. How do we determine which gear ratio we need in order to do this? I’m aware of the JVN Design Calculator’s rotary mechanism sheet, but that only talks about the force that the motor applies when powered. How do we determine what ratio we need to keep it up either way?

you should counterbalance any mechanism with weight, springs or surgical tubing so there is very little force required to move it up or down.

Because to move a wrist up, you have to have power to move and to overcome gravity. To move down, you have gravity assist.

Counterbalance is your best bet. no calculator needed.

This would depend on the resistance of back driving whatever gearbox or gear train you have powering the arm, not directly the gear ratio but rather the efficiency. Things like a ball screw or worm gear won’t typically back drive as they are very inefficient. In my opinion, the way to ensure this is to use springs or some other kind of assistance to the motors, similar to a constant force spring in an elevator. You can use torsion springs, or pull springs. Looking at 1619 in 2018, they used a lever arm when the arm went down the spring assisted the motor. You can see this action in their reveal video.


Here’s something I worked up for a few teams last year. It’s not the most comprehensive guide, but it’s a good starting point to estimate the torque you’d need for your motor.Motor Selection Basics.pdf (82.6 KB)

1 Like

You won’t get there just by putting a large enough gear reduction in place. That’ll either introduce a lot of friction in the system (which means it’s less efficient and takes more power to run) or it’ll make things incredibly slow. Both of those things are bad.

Instead, look at counterbalancing the arm to reduce the force needed to hold it up. That’ll both help hold it in place and mean you need less power from the motor to lift it - a win-win! You can also add in a physical brake to hold things in place. My team has successfully used this disc brake in the past. The disc has the same bolt pattern as the AndyMark hubs, which make it easy and convenient to attach to a hex shaft. You just need a relatively small force (we used a small pneumatic piston) to engage it. On our elevator last year, you couldn’t lower it by hand if the brake was engaged. If I wasn’t afraid of breaking something, I would even say you could hang off it without it moving.

I have to disagree with this. Sure you might not have the best robot out there if you do this, but it will definitely work (within reason). We’ve used this idea for our wrist mechanism last year and it worked fine. Sure, it wasn’t the fastest or most efficient method, but it worked for the competition.

Sagging due to gravity was solved with a PID loop on the wrist position, but could also be determined empirically with small holding torques. Furthermore, a good design would ensure that the resting position of the arm was in a position that didn’t need holding torque (i.e. vertical)

While counterbalancing is a good idea, it cannot eliminate movement entirely. Any acceleration (robot moving, elevator/arm moving the wrist up and down) will impart force on the wrist that is not cancelled out by the static counterbalance force. For teams that aren’t using closed loop control, using large gear ratios or disk breaks (as previously mentioned) are great options. For teams that are using closed loop control, large ratios make controls easier and more stable.

It’s extremely hard to determine exactly how much resistance force the inefficiency in a gearbox causes. And, if you can’t make it perfectly, you should make it adjustable. For this reason, I recommend choosing a reasonably slow movement speed (I’d go for 1 second for a 90 degree rotation) and then use a Versaplanetary as the first gearbox stage so that you can easily adjust the gearbox ratio.

Please remember to consult the VP load ratings chart, to make sure you don’t gear it to the point of failure. So long as the torque you need is there, I recommend gearing twice as fast as you really want it to move. That way your only running the motor at 50%, which puts you on a better part of the motor curve. It also gives you options down the road if you want to speed it up, or overhead for your PID loop to have available if needed.

I would HIGHLY reccomend a counterweight on the other side of the wrist, for sure. It is the most simple and most elegant solution in most cases. But, with that being said, sometimes you just don’t have room for counterweights, like in our bot last year. In this case, some crazy gearing is my personal favorite way to go. Using a Versaplanetary and a 775Pro, we were able to actuate our polycarb Spectrum intake clone pretty easily. All it took was a 200:1 ratio and an SRX encoder slice. A few words of warning though, this configuration means you have to use 4 stages. when using 4 stages with a VP (something Vex strongly reccomends against) you have to be very careful to prevent the bolts that hold the slices together from shearing. We actually had that happen to us during a match last year and had to make a Home Depot run for threaded rod and nuts to fabricobble our own replacements. What we ended up doing was putting a plate on the side of the VP, where the side mounting holes are, to hold it together and prevent total annihilation.

I don’t know why it would be necessary to have the wrist stay at its position even when the robot is off, but that’s just a personal opinion. My team did a wrist last year and we just implemented PID to the wrist so that during the match, it would stay at desired position. We had potentiometer attached to the shaft so that we can read the angle it was at.

1 Like

Quick question on the disk brake: how did you set that up programmatically? If your driver’s where moving it manually did they disengage and then engage it? How about if you have programmed height levels, were the disengage and engage steps added to the position seek routine?

As far as the drivers were concerned, they didn’t even need to know about the disc brake. I wasn’t working with the programming team, but I believe they set up the elevator as a subsystem that contained both the motor and the solenoid. That let them control the two together - release the brake when we want to move and drive the motor up or down, or engage the brake and stop the motor when we want to stop. Then it didn’t matter if we were controlling it manually (go up/down while this button is pressed) or using set way points (go up/down until hitting a limit switch/reaching a specific spot on a potentiometer, then stopping).

One key point - there wasn’t really PID control going on with the elevator. It only had one speed in each direction. That made it relatively simple to control, and we set it up so we didn’t really care if it hit the exact spot or not, other than all the way up for the scale, which involved both a hard stop and a limit switch.

1 Like

Good stuff, thanks for the info!

Thanks to everyone for your help.

Is it possible for you to clarify how the mounting for this would end up working? Would the pneumatic tubes go straight to a solenoid?

Also, a question for everyone who suggested PID: I was under the impression that PID only works for when you’re actively trying to move the mechanism, not hold it in place. I assume that I’m wrong about that? (Disclaimer: not part of the programming team)

As long as the PID output variable is position, then yes, PID will work for this.

PID works however you set it up to work. Essentially you give it a target value, and based on how you set it up, it will try to get to (and maintain) that target value. So if you are feeding a desired encoder count into the PID controller and you are reading the current encoder count as feedback, PID will work for holding a constant position (that’s really where the “I” term shines)

A disc brake is made up of several components:

  1. A hub
  2. A disc
  3. Calipers
  4. Cabling

Attaching the disc to the hub is trivial, if you buy a disc with the same bolt pattern as the hub you want to use.

The calipers are the part that clamp down on the disc. The need to be mounted such that the disc runs through them. You then attach the cabling to the calipers. This cabling has a braided steel wire running through it, with stiff plastic on the outside. The other side of the cable is going to be attached to a pneumatic piston.

With the piston, you have two options. If you mount it near the calipers and oriented correctly, you can just pull the cable and you’re done. However, the beauty of these brakes is that you can run the cable anywhere you want. So your piston could be on the other side of the robot in any orientation! You just need to run the cable through a small hole, such that the plastic sheathing doesn’t fit. This lets the sheathing provide a fixed path for the cable, so when you pull it instead of altering the path, it exerts force on the calipers.

If that’s not enough of a description, head to the garage and take apart the brakes on your bike. Even if your brakes grip the rim instead of a disc, the principle is the same! All you’re doing with the piston is emulating the forces created by the brake lever on your handlebars.

1 Like