Hey so I am currently doing a telescoping climber and am designing a gearbox for it. I am struggling with a gear ratio for it. It would be a dual telescoping climber design. I just don’t know how to do the gear ratio and account for back drive.
I forgot to mention each gearbox is limited to two stages by preference and weight/size.
You might just want to do the gearing based on speed and weight, and use another mechanism to keep it from falling down after power goes off.
This implies you are using separate motors for raising the mechanism and for lifting the robot. Is that a correct assumption? If so, they will likely be quite different. Our raise motor+gearbox was designed around time — getting our hook up quickly. On the other hand, the lift motor+gearbox was designed around weight — the gearbox needs to multiply the motor’s torque enough to lift the robot. If you are not using a split design like this then you will likely have to make some compromises—especially since your requirements seem to preclude a 2-speed gearbox. In our case a simple versaplanetary is used for hook raise and a 4-stage gearbox for lift (we have unique space constraints that limit the diameter of gears we can use — with bigger gears we could likely do it in 2 stages). We use a simple ratchet wrench on a hex shaft to prevent back-drive, but there are also other techniques.
Theoretically, any motor can lift any robot.
Practically, for the winch up, it’s about power. Power is best thought of as “effort” times “flow”–this idea works across disciplines, from mechanics to fluids to electricity and beyond.
In the case of linear motion, the effort is force, and the flow is speed, so P = Fv. In rotational motion, the effort is torque and the flow is angular speed (in radians/sec). You want to translate the output power of the motor (torque x circumference of your winch drum x angular speed in rev/sec) to linear output power in your telescoping arm (force is mg, speed is h/t, so P = mgh/t, which is also the rate of change of PEg).
To find out what you need for your motor, I’d start with the desired output to figure out the needed input. How fast do you want to climb and how heavy is your robot? Plug those into P = mgh/t. This gives you the ballpark minimum power you need to lift your robot in the time you want. [You’ll probably want to divide that by, say, .80 to account for system losses as a starting point, but that number is just a fudge at this point, so let’s ignore that for the moment and work with “perfect”.]
The required output torque will be the weight of your robot times the “length of the moment arm” (which is most likely the diameter of your winch drum), so consult published torque-power curves and find a motor or set of motors that have (at least) the power output you want.
In the very likely case that the torque-power curve tells you that a motor or set of motors at your current limit (likely 40A per motor but possibly less) has enough power at the current limit but insufficient torque to actually lift the robot, find the gear ratio you need to lift the robot by dividing the desired torque by the motor torque at that current.
And again, this produces a theoretical minimum gear ratio with a theoretical minimum motor power, and shifting from there to actual robot design requires a mixture of testing and overkill. Friction and gearbox efficiency will be the two biggest factors, and in my experience with FRC, calculating the theoretical situation and then going with around 50% more motor power and torque results in light-enough, small-enough mechanisms that can do the job well.
All of that said, you might want to explore drive train PTOs this year in the what-looks-like-a-year-long off-season–you have some beastly-strong motors on your robot already, and with a little modification can use all that power to pick up your robot while adding not a lot of weight or packaging. We don’t always use a PTO, but haven’t at all regretted it when we have!
Be aware that if your drum winds up several layers of rope/cable that the moment arm can grow significantly (esp. if you start with a small diameter drum).
It’s designed around it being quick but i don’t want to have to have something to block it from coming down if I can use a gear ratio instead. I am also using the jvn calc for it.
Yeah there are some good motors, I have the box designed for falcons.
You’re literally just designing for inefficiency that way, though. Don’t get me wrong–we used to do that, too. But not only is it not the best way, it’s not even a good way…
But even with that not good way, you have at least two options.
#1. Make the system so that it’s got so much friction on the back-drive that the robot either doesn’t move, or drops slowly enough that you’ll get the points before time expires.
#2. Make the system so that when you’re at your highest point, you can stall the motors at a “holding voltage” << 12V to assist the friction/back-drive in keeping the robot in the air.
The former (#1) is a real problem when your “enough friction” becomes either “too much friction” or “not enough friction” due to wear and tear, warping, and other factors. (And relatively thin telescoping arms supporting entire robot weights do tend to warp over time, and what starts off as “enough friction” can quickly become “terribly bound mechanism”.) The latter (#2) is a real problem when your motors get really, really, really hot, especially in near back-to-back games. The more you rely on either method, the more that method’s problems come into play–without actually eliminating the other method’s problems.
My suggestion would be to eliminate both of those problems with a mechanism that prevents back-drive. You have a wide variety of options, from a pneumatic pad brake to a cam-lock to a ratcheting wrench to a ratchet and pawl. (There are other options as well, so this is a non-inclusive list). This will allow a smooth, efficient, reliable climb with minimal wear-and-tear rather than a rough, clunky, unreliable climb with lots of wear-and-tear.
You have plenty of time to transition from clunky-but-works to awesome.
I completely agree. One you didn’t list that we considered was using a worm-drive for the first gear stage.
For a breaking force we have used four different options.
- Ratcheting wrench - great for climbers, harder to disengage at times than ratchet and pawl depending on how you hold it in place. Small form factor.
- Ratchet and Pawl - great for climbers or other mechanisms that you don’t want/need to reverse. More complete for design if you make your own. Probably largest form factor.
- Mountain Bike disk brake - My personal favorite, can be engaged and disengaged easily with a small pneumatic cylinder. Lots of breaking force.
- Drum Brake - least favorite, least amount of braking force and wore through pads quick. Smallest form factor.
We used a Neo on a 10:1 reduction for our climber winch, and set it to brake mode. With this setup it takes the robot 30-40 seconds to fall to the ground. We took out our disc brakes for the simple reason that we didn’t need it for this setup.
I’m not really sure if this would help you much since we only used a single motor, but i do agree with what most people are saying on this thread.
Yes! Thank you for the addition.
Of course, contrary to popular opinion, worm drives do back-drive…and when put in situations where they do so, they like to break, too (especially the nylon ones).
Reliability is a valid reason to introduce inefficiency. Not having to rely on a separate braking system to ensure that you don’t drop after the match ends does 2 things:
- it ensures that you won’t have a failure of that system that costs you the match and
- it ensures that you don’t run out of time to engage that seperate system before the clock strikes 0.
That second item may mean that using the braking mode in the motor controller as your brake and gearing for a slightly slower climb mechanism may, in fact shorten your total cycle time.
Assuming that you have a separate brake, and you wanted to make sure that you engaged it, you would probably make sure that you had completed your climb with about 5 seconds on the clock (gives you some margin to relax your climber and ensure that the brake is holding and possibly try again if it does not hold). If your “quick” climber takes 3 seconds to climb, then you need to start your climb with 8 seconds on the clock.
Now, suppose you double the gear ratio to get a gear ratio that will hold with brake mode alone. Your brake mode is automatic when the match ends. Now, you need to start your climb with 6 seconds on the clock. So, you have actually improved your performance by optimizing around simplicity and reliability instead of pure speed.
We used brake mode successfully on our 2018 climber as well as our 2020 climber. Our climbs in both cases were very quick. We had several instances in Turing Elims in 2018 where our partner was just getting onto our ramp with only 5 seconds remaining in the match and we were able to complete the double lift and not have to worry about setting the brake to ensure that we got the endgame points. I’m not sure we would have been able to pull off some of those endgame lifts if we had a separate braking system.
In 2020, we actually geared for a buddy lift climb (which we never used) which did incorporate a pneumatic piston brake. So, when we climbed alone, we had plenty of holding power without the separate brake using motor braking alone allowing us to wait fairly late to start our climb. In Pembroke F2, we were still shooting power cells with 15 seconds on the clock and still managed to complete our climb with 5 seconds to spare. So, the slow gearing needed to use brake mode is not really all that slow.
Well, I mean, there’s more than one way to skin a cat… You can always set a braking system to engage at the moment the robot is disabled, too–which costs you no time.
True. While some worm-drives are designed so that theoretically they can’t be back-driven, theory and practice are not always the same!
The load on a worm gear can’t back drive the worm if the coefficient of friction between worm gear and worm is larger than the tangent of the worm screw’s lead angle. But worm drives are typically designed using the static coefficient of friction, so if there is vibration or something else (say a stray lubricant) that reduces the coefficient of friction, it CAN happen. So, in a life safety situation a worm drive is insufficient protection. But it will very likely work to hold your robot for 5 seconds. (Just not over your head!)
As for non-metal gears. It would be a very rare situation where the weight savings would be more important than strength. So, to a first approximation: No. Just no.
Just to be clear, non-backdriving worm gears are highly inefficient (often <50%). That’s distinctly different than a mechanism that has different locked/unlocked states with high efficiency in one and 0 efficiency in the other (e.g. friction brake, ratchet and pawl). I imagine you know this but I want to clarify for anyone else who may be looking here for a solution.
This is an excellent point. It is however one less active mechanism (and thus one less failure point) than many possibilities. But, in the end we just tossed on a ratcheting wrench. Cheap. Easy. Simple. Unlikely to fail. Disadvantages: can be a PITA to unlock, you only get 1 chance.
 This concludes this episode of “More than you care to know about worm drives”
Several of the FRC kit (or FIRST Choice) worm gearboxes use metal worms interfaced with nylon gears–and those nylon gears like to break teeth.
Ratchets are instant (ok, to be fair you might have to engage the ratchet which should be in the 10s of ms and can also be done during the accent).
We’ve used the VEX ratchet for 3 years now. There are things about it that we aren’t crazy about (won’t unlatch with pressure on it) but we’ve learned how to deal with that and we don’t have to design a brake (even though there are some cool brake designs out there). Climb gearing can then be optimized to climb fast.