Game-object mass feeds five places in your design: grip force, arm and lift torque, drivetrain budget, center of gravity, and structural deflection. This guide shows the math for each, with worked Override 2026-27 examples.
Every V5RC robot that picks something up runs into the same five questions. The same payload mass m shows up in all of them.
| Design output | What weight tells you | Where on this site |
|---|---|---|
| Claw grip force | Minimum normal force per gripping surface to hold the object against gravity and dynamic loads. | This page § Grip Force, plus mechanism-claw |
| Arm / lift motor torque | Continuous torque the motor sees at the worst moment-arm position; sets reduction ratio and motor count. | This page § Arm Torque, plus mechanism-lifts |
| Drivetrain wattage budget | Whether payload meaningfully changes acceleration or top speed within the 88W cap (Override R10a). | This page § Drivetrain, plus super-clawbot-v2-override |
| Center of gravity shift | How much picking up the payload moves the robot's CG horizontally and vertically — tipping risk. | This page § Center of Gravity, plus center-of-gravity |
| Structural deflection | Whether the arm or lift sags under load enough to miss scoring positions; aluminum vs. steel choice. | This page § Deflection, plus wheel-and-config-analysis |
For a 5 kg robot lifting an 80 g object, the payload is roughly 1.5% of the total mass. That sounds small enough to ignore — and for some calculations (drivetrain wattage, simple structural deflection) it really is. But for two of the five outputs the payload completely dominates: the grip force is set only by the payload mass (the robot mass is irrelevant), and the worst-case arm torque comes from mgL at the end of the moment arm.
So the right mental model isn't "payload is small compared to robot" — it's "different design questions are sensitive to different masses." Section 7 has a full sensitivity table.
Every official game manual eventually publishes element masses in the appendix or game-element specifications. This is the only source judges, refs, and other teams will all cite consistently. When you have it, use it; when you don't, document what you used.
Once you have actual elements in hand — from a kit, a competition, or a 3D-print — weigh them. A kitchen-grade digital food scale reads to 1 g resolution with ±1–2 g accuracy at this mass range, which is more than precise enough for V5RC design math. Notebook discipline:
Before any element exists in the wild, estimates are the only option. Sources, in decreasing order of trust:
Estimates should always be flagged as such in the notebook, and revisited as soon as a real element is available.
If you're another V5RC team and you have your own measurements, they're more authoritative than ours for your robot. The 73 / 78 g numbers are the best-available reference until VEX publishes official values.
For two gripping surfaces (wheels, fingers, jaws) compressing the object from opposite sides, each providing normal force N, friction coefficient μ with the object surface:
m = payload mass (kg), g = 9.81 m/s², μ = friction coefficient, N = normal force per side (N).
This is the minimum hold — you'd add a safety factor (typically 5–10×) on top.
| Wheel material | μ (typical) | Notes |
|---|---|---|
| Black flex (65A) — hard | ~0.3 | Most durable, lowest grip; needs more compression to compensate. |
| Dark gray flex (45A) — medium ← common pick | ~0.5 | Goldilocks zone; good grip + acceptable wear. |
| Light gray flex (35A) — soft | ~0.8 | Highest grip; wears faster, may grab too aggressively. |
| Standard wheel rubber on cup plastic | ~0.6 | For reference if not using flex wheels. |
| 3D-printed PLA/PETG — smooth | ~0.2–0.3 | Add a TPU pad or rubber strip for grip. |
If the arm holding the payload accelerates — swinging up, slamming to a stop, riding bumps — the effective gravity goes up. The grip has to handle m · (g + a) where a is the linear acceleration of the payload at that moment.
For a payload at the end of a rotating arm:
ω = angular velocity (rad/s), L = moment arm length (m). For a 90° sweep in 0.5 s: average ω ≈ (π/2)/0.5 = π rad/s ≈ 3.14 rad/s.
For static-only conditions (object held still), this drops to ~7.6 N per side at 10× SF. The mechanism-claw Architecture E delivers ~10 N per side at the recommended 0.125″ compression — covers static fully (13× SF), and dynamic with 9× SF.
For an arm pivoting at one end, holding payload m at distance L from the pivot, the worst-case torque (arm fully horizontal) is:
τarm = marm · g · Lcg (where Lcg is the distance from pivot to the arm's center of gravity, typically L/2 for a uniform arm).
A motor at 100 RPM with stall torque τstall can drive an arm output through a gear reduction R:
R = reduction ratio (5:1 means R = 5), η ≈ 0.85–0.92 efficiency for clean spur gears. Output speed = motor speed / R.
Don't size to stall torque — that's the absolute ceiling, not the sustainable rating. A 11W V5 motor stalled draws ~2.5A and overheats in seconds. The conventional rule is:
Note that the payload contributes only 25% of the total static torque — the arm's own weight dominates. This is true at V5RC scale for almost every sub-100 g payload: the design driver is the arm itself, not what it carries. See super-clawbot-v2-override for the full V2 power-budget calculation.
τarm at the most common operating angle leaves the motor responsible only for accelerating the system and lifting the payload. This is how teams run a 4-DOF arm on small motors.F is the net pushing force from your wheels (after friction losses). Adding payload mass reduces the achievable a for the same F.
For a typical V5RC robot at ~5 kg pushing 1 cup (78 g):
If the game allows stacking or multi-element possession, mass scales linearly. For an Override robot carrying a hypothetical 4-cup stack:
For most V5RC designs, you can skip drivetrain re-sizing for payload. The robot dominates the mass. The exceptions:
For a robot of mass M with CG at (xR, yR) holding payload m at (xP, yP), the combined CG is the mass-weighted average:
y). Compute both. Both matter for tipping — horizontal moves the projection, vertical raises the moment arm.
The robot tips when the combined CG, projected straight down, falls outside the polygon defined by the wheel contact points (the "support polygon"). For a square holonomic drive, that's the square of the wheelbase. For a long, narrow chassis, the short side is the failure direction.
The 18″ square chassis is forgiving. Narrower chassis (12″ wide rear-mounted lifts) or larger payloads (multi-piece carries, heavier objects) can change this materially. See center-of-gravity for an interactive calculator with multiple wheelbase options.
For an arm of length L, modulus E, second moment of area I, with a tip load F = m · g:
I ≈ 0.0066 in⁴ (steel) or same for aluminum (geometry, not material). Esteel = 29×10⁶ psi. Ealuminum = 10×10⁶ psi. Self-weight contribution: δself = w · L⁴ / (8EI) where w is weight per unit length.
For payload masses below ~500 g, structural deflection is dominated by the arm itself. Material choice matters — see wheel-and-config-analysis for the steel-vs-aluminum tradeoff — but for payload-driven deflection at V5RC scale, the answer is "no, you don't have to worry."
"Sensitivity" here means: if your payload mass estimate is off by 10%, by how much does the design output change? The closer to 1:1, the more important accurate measurement is.
| Design output | Sensitivity to payload mass | Robustness |
|---|---|---|
| Claw grip force (required N) | 1:1 (linear) | Low — measure carefully |
| Arm payload torque alone | 1:1 (linear) | Low |
| Arm total torque (with self-weight) | ~0.25:1 (payload is ~25% of total) | Medium — estimates often fine |
| Drivetrain acceleration | ~0.015:1 (payload is ~1.5% of mass) | High — ignore differences below ~50 g |
| CG horizontal shift | ~0.015:1 (linear in m/M ratio) | High |
| Payload-only deflection | 1:1 (linear) | High — absolute value tiny |
| Arm total deflection | ~0.01:1 (self-weight dominates) | Very high |
If you only measure one thing: measure for grip force. A 10% error in payload mass directly causes 10% error in required grip. That can be the difference between "secure" and "drops the cup at the worst moment."
If your payload is < 200 g (most V5RC game elements), drivetrain and CG calculations are robust to even rough estimates. Use a placeholder; refine when you have time.
The arm-torque case is the interesting middle: payload contributes only ~25% of the total joint torque, but that 25% can be the difference between staying under the 50%-of-stall design rule and not. Measure when you can; estimate ±20% if you can't.
The RECF Engineering Notebook rubric (EN1–EN5) rewards entries where the engineering process is visible. For a payload-driven decision, that means showing:
Payload mass. Override cup mass measured 78 g (mean of n=3 cups, range 76–79 g) on a kitchen-grade digital food scale, May 2026. Pin mass measured 73 g (mean of n=3, range 72–74 g). Awaiting confirmation against game manual v1.1 (August 2026).
Constraint. Arm must reach the 8.77″ tall center goal from the back-loader position. Reach calculation in [previous entry] sets arm length at 17″. Per V5RC R10a/R11a (Override), our 88 W budget allocates 11 W to the shoulder.
Math. Worst-case static torque at horizontal extension: payload contributes 0.078 × 9.81 × 0.432 = 0.330 N·m. Arm self-weight (0.45 kg, CG at 0.22 m): 0.971 N·m. Total: 1.30 N·m. Red 100 RPM stall = 2.10 N·m at the motor. Required output torque to stay under 50% of stall (the design rule from payload-design): need at least 2 × 1.30 = 2.60 N·m at the output.
Decision. 5:1 reduction gives 2.10 × 5 × 0.88 = 9.24 N·m at the output (3.6× the requirement). 7:1 would give 12.93 N·m but slows the arm from 20 RPM to 14.3 RPM, lengthening cycle time. We chose 5:1 to preserve cycle time at acceptable safety margin.
Verification. Built and tested: arm holds 78 g cup at full extension without motor stall warnings on a 12.8 V battery. Cycled 50 lifts on a depleted (10.8 V) battery — no thermal protection triggered. Test data in [later entry].
The example above is a purple-slide entry in the standard notebook color scheme — it's a "select best solution" decision backed by analysis. Place it after your gold-slide brainstorm (where you considered 3:1, 5:1, and 7:1 as candidates) and before the orange-slide build log. See notebook-template for the full slide-color scheme and how this fits into a complete EDP cycle.