A primary-source FRC guide to designing elevators and arms: cascade vs continuous rigging, staging, motor and gear-ratio sizing, gravity math, and safe holding.
to read
words
sections
Almost every modern FRC robot has to lift something. Game pieces have to travel from floor height to a scoring location well above the frame, and the two mechanisms that do that job over and over are the elevator (linear extension) and the arm (rotating extension). Get one of these right and your robot scores fast, holds position without draining your battery, and survives a six-week season of abuse. Get it wrong and you spend your competition weekend fighting a mechanism that sags under gravity, racks under load, or cooks a motor against a hard stop.
This guide is a mechanism-design reference: how to choose between an elevator and an arm, how staging and rigging actually work, how to size motors and gear ratios against gravity, and — most importantly — how to hold a loaded mechanism safely when the robot is disabled. Every numeric claim here is pulled from a manufacturer spec sheet or the WPILib documentation, and the design math is standard statics, so it stays true no matter which game you are building for.
Before you draw anything, decide what shape of motion you actually need.
An arm rotates a payload through an arc around a single pivot. It is mechanically simple — one pivot, one gearbox, few moving parts — and it is light. Its weakness is gravity: the torque a motor must fight changes continuously as the arm swings, peaking when the arm is horizontal (more on the cosine relationship below). A long arm also sweeps a large arc, so you need clearance for the tip and you have to reason about where the end effector is throughout the swing, not just at the endpoints.
An elevator moves a payload in a straight line, usually vertically. The gravity load is constant through the whole travel, which makes control predictable and tuning easy. The cost is weight and complexity: you are building precision linear rails, a rigging system, and multiple nested stages. Elevators also tend to be tall even when collapsed, which eats into your starting-configuration budget.
Many strong robots combine the two: an elevator with a rotating wrist at the top, an arm carrying a short telescoping stage, or a pivoting arm mounted on an elevator carriage. The decision comes down to the game's geometry. If you need to reach several precise heights straight up, an elevator wins. If you need to sweep a game piece from the floor to a fixed delivery angle, an arm is lighter and simpler. Sketch the required reach envelope first, then choose.
An elevator's stages are nested tubes (commonly 2"×1" or 1"×1" aluminum box extrusion) that slide within each other to telescope. The number of stages is a packaging tradeoff:
The tubes ride on each other using bearing blocks — typically at least two per side at each sliding interface — or on bearings that roll on the tube edges. West Coast Products' inline bearing blocks are a common example: they let stages sit with roughly a ¼" gap between tube faces instead of the traditional ½", which WCP notes saves about 1.5" of total width on a three-stage elevator. However you do it, keep enough overlap between adjacent stages when fully extended so the joint resists racking; a common rule of thumb is on the order of 20% of the stage's travel remaining engaged at full extension. Too little overlap and the elevator wobbles at the top of its reach, exactly where precision matters most.
Mount your motors and gearbox on the fixed base, not on a moving stage. Every gram you put on a moving stage is mass the mechanism has to accelerate and hold against gravity, and it raises the robot's center of gravity as the elevator extends.
Rigging is how one powered drum or sprocket makes several nested stages move together. FRC elevators are almost always rigged in one of two styles.
In a cascade elevator, the motor directly drives only the first moving stage. Passive pull-up and pull-down cable (or chain) segments run over pulleys so that when the first stage rises, it drags the next stage up faster, and so on. The defining property is that each stage moves the same distance relative to its parent stage, so the top carriage travels at a fixed multiple of the first stage's speed for the entire stroke.
That fixed ratio is the key tradeoff. Cascade rigging trades force for speed: because the carriage moves faster than the driven stage, the driving cable tension is higher than the carriage's weight. The YETI Robotics design guide describes a two-stage cascade as putting roughly 2× the force on the first stage while the final stage moves faster — the classic speed-vs-force reciprocal. Each additional moving stage stacks another multiple of speed and another multiple of driving-cable tension, which is why you gear cascade elevators down harder than you might expect. The upside: the ratio is constant and the stages always move in lockstep, so the motion is clean and easy to control.
Cascade elevators commonly use chain (#25 or #35) on the first stage — rigid, easy to tension with inline tensioners, but heavy — and lightweight Dyneema/UHMWPE rope running on pulleys for the upper stages.
In a continuous elevator, a single "up" cable winds around the powered drum, passes over passive pulleys at the top and bottom of each stage, and attaches to the carriage; a separate "down" cable winds the opposite way and pulls the carriage back. Because it is one continuous run rather than a fixed cascade of loops, the stages do not inherently move in a fixed proportion — they tend to extend sequentially (the lowest-friction stage moves first) unless you add hard stops at each stage to force an order.
Continuous rigging generally produces a lower center of gravity and lighter package, and it is popular with timing belt (which does not stretch and is very precise) or rope. The costs are a more involved design, fewer off-the-shelf options, more idler pulleys, and — with belt — real expense.
Whatever you rig with, get the tension right and keep it right — a ratchet or inline tensioner that holds tension over a full event is worth more than a clever routing scheme that goes slack after twenty cycles.
An arm looks simpler than an elevator, and mechanically it is, but its load case is trickier because the torque gravity applies changes with angle.
The gravitational torque an arm's pivot must resist is:
τ = m · g · L · cos(θ)
where m is the mass of everything past the pivot, g is 9.81 m/s², L is the distance from the pivot to the combined center of mass, and θ is the arm angle measured from horizontal. The cosine term is the whole story: torque is maximum when the arm is horizontal (cos 0° = 1) and zero when it is straight up or straight down (cos 90° = 0). The West Coast Products gear documentation makes the same point plainly — the most torque is needed in the horizontal position.
This is exactly why WPILib's ArmFeedforward controller multiplies its gravity gain by the cosine of the position: the model is kS·sign(v) + kG·cos(θ) + kV·v + kA·a, and the WPILib API explicitly states the angle must be measured from the horizontal — an angle of 0 means the arm is parallel with the floor. By contrast, ElevatorFeedforward uses a constant gravity term kG, because a vertical elevator fights the same weight at every height. That single difference — cosine for an arm, constant for an elevator — captures why arm control is fussier than elevator control.
When you size an arm, size it for the worst case (horizontal) plus acceleration. Static holding torque alone is not enough; the real requirement is τ_static + I·α, where I is the arm's moment of inertia about the pivot and α is your commanded angular acceleration. Leave margin so the motors are not living at stall.
An arm cannot reliably "home" against gravity the way a mechanism can drive into a hard stop, so use an absolute encoder on the joint — a through-bore encoder or a CANcoder mounted on the pivot axis — so the arm knows its true angle the instant the robot powers on. Put the encoder on the output (joint) side, not the motor shaft, so gearbox backlash doesn't corrupt your reading.
Both mechanisms come down to the same question: how much torque (or force) do I need at the output, and what reduction gets me there while keeping speed and current reasonable?
FRC brushless motors are strong, but you never get to use their full rating. Here are current, manufacturer-published specs:
Those stall figures are theoretical extremes you must never actually run to. In competition each motor branch circuit is protected by a 40 A breaker, and — as WCP's own Kraken documentation notes — teams "will not be able to use all" of a motor's peak power because of that limit. In practice you set a software supply-current limit (often in the 40–60 A range) well below stall, both to respect the breaker and to keep from burning a motor that's parked against a hard stop. Design so the mechanism does its job within those limits, not at the datasheet's stall column.
Speed and torque trade off inversely through a gearbox: a 9:1 reduction cuts output speed to 1/9 and multiplies torque by 9 (minus efficiency losses). Modular planetary gearboxes make this easy to iterate:
Don't guess the ratio by hand. Use a purpose-built calculator — ReCalc (reca.lc) has dedicated linear-mechanism and arm tools, and JVN's Mechanical Design Calculator is a long-standing spreadsheet — to plug in your load, motor, count, and desired travel time, then read out the current draw and time-to-position. Iterate the ratio until the mechanism hits its target speed and stays within your current limit at the worst-case load. For a cascade elevator, remember to fold the rigging's speed/force multiple into that calculation.
This is the part teams underestimate, and it is the part that matters most for both safety and battery life.
Motor brake mode is not a mechanical brake. When a motor controller is in brake mode and powered, it resists motion. The instant power is removed — end of match, brownout, disable, a tripped breaker — that resistance disappears and a raised elevator or extended arm falls under gravity. Relying on brake mode alone to hold a heavy load is both a battery drain (the motors fight gravity continuously) and a safety hazard.
For anything heavy or highly loaded, add a mechanical holding device:
A well-designed mechanism holds its worst-case position without continuously commanding torque into a stalled motor.
Because an arm's gravity torque peaks at horizontal, a counterbalance dramatically reduces the continuous work the motors do. Options:
The goal isn't necessarily to fully cancel gravity; it's to move the motors' operating point away from continuous high-torque, high-current territory so they run cooler and hold more reliably.
A raised elevator, a cocked constant-force spring, a charged gas shock, and a tensioned rigging system are all stored energy — they can move suddenly even when the robot is off. FRC's robot rules treat stored mechanical energy as a safety item, and inspectors will look at how you manage it. Practical habits:
Tie it together in roughly this order:
Design it on paper and in your CAD calculator before you cut metal. An elevator or arm that was sized correctly on the first pass is the difference between a mechanism you tune in an afternoon and one you rebuild the week before your first event.
ArmFeedforward and ElevatorFeedforward (docs.wpilib.org)This article is AI-assisted: drafted from primary sources, then reviewed and edited by hand. Errors still get through. When one is reported we fix it and write down what changed — publicly, in the corrections log.
Keep going
You came here for one answer. These lessons teach the same subject properly, in the order a team actually learns it. All 47 are free and none of them need an account to read.
Go deeper
This article pairs with a full structured design course — swerve layout, assemblies, worked mini-projects. A free account saves your progress lesson by lesson.
Save my progressKeep reading
Structured lessons and quizzes across every department. Create a free account to save your progress, track your team, and earn a certificate.