Spartan Hero Bot Design Build Log

Starting point. Nothing on paper yet. Override game manual just released; team needs a Hero Bot reference design for V1 prototype build at Mtg 8.

From nothing to first sketch. Architecture: tower at the back of the chassis, single 11W motor inside the chassis, chain reduction up the tower to a driven shaft at the top, single 4″ flex wheel concentric with a driven sprocket on that shaft, single-pivot lift arm extending forward to a claw at the front of the chassis. Toggle assumed mounted "approximately mid-wall" on the perimeter (height to be verified on field).

The "shared shaft" was the elegant simplification. One motor input doing both jobs simultaneously: the chain spins the driven shaft, which both rotates the arm (lift) and spins the wheel (toggle flip). Saves one 11W motor on the R10a 88W power budget — that motor can go to a claw or extra drivetrain.

• Coupled motion (arm and wheel rotate together — can't lift arm without spinning wheel)
• Single side of approach (toggle on one specific perimeter side)
• Toggle position assumed; not yet verified against the manual

Flip direction (rest-to-up vs up-to-rest); which works reliably depends on contact geometry and friction. Test both at Mtg 8.

• Toggle position: moved from mid-wall to ON TOP of the perimeter wall. Apex now at ~13.3″ from floor (11.5″ wall + 1.78″ equilateral triangle apex)
• Tower: restructured from a small square at the back to a full-width goalpost spanning the chassis width with X-bracing
• Wheels: doubled to two flex wheels, one at each outboard end of the driven shaft, so the robot can flip toggles on either left- or right-side perimeter without rotating
• Arm and claw: centered on the chassis (instead of offset to one side)
• Motors: doubled to two 11W motors on parallel chains, both driving the same shared shaft
• New back view SVG added to communicate the linkage detail

The new architecture has more rotational mass on the shared shaft (two wheels instead of one) and the centered arm doubled in effective length compared to V1's offset arm. A single 11W motor with chain reduction would still work but would run near torque limit. The fix is not to split into two independent systems (one motor for wheels, one for arm) — that throws away the elegance of the shared-shaft concept. The fix is to put two motors on the same shared shaft via parallel chains. Doubles the torque, adds redundancy if one stalls, preserves the "one input, both jobs simultaneously" elegance.

• Rejected: separate motors for arm vs wheels (loses shared-shaft elegance for marginal benefit; deferred as a post-V1 optimization)
• Rejected: stay with one motor (math says yes but margin is uncomfortable)
• Accepted: 4 drivetrain motors at 11W (44W) + 2 lift motors at 11W (22W) = 66W of the 88W R10a cap. 22W remaining for claw or other manipulator. Still inside the rule.

• Flex wheels moved inside the 18″ chassis envelope — outer wheel edges now sit at the chassis edges. R4-compliant: robot fits the 18×18×18 sizing box at start of match. Tower verticals moved inboard so they don't overlap with the wheels.
• Sprockets redrawn as thin rectangles — orthographic edge-on view of a disc (more accurate than circles)
• Sprocket ratio recommendation specified: 1:5, 6T driving / 30T driven, HS-25 chain
• Explicit "no gear train needed" reasoning added

Worked four candidate ratios. With ~12 in-lb arm load and 2 motors at 200 RPM cartridges (21 in-lb stall each):

• 1:3 (6T:18T) — shaft 67 RPM, 19% of stall, 0.22s lift time
• 1:4 (6T:24T) — shaft 50 RPM, 14% of stall, 0.30s lift time
• 1:5 (6T:30T) — shaft 40 RPM, 12% of stall, 0.38s lift time ← recommended
• 1:6 (6T:36T) — shaft 33 RPM, 10% of stall, 0.45s lift time

1:5 is the sweet spot. Motors run cool with massive headroom for unexpected loads (a stiff toggle, a wheel that catches). 0.38s for 90° is fast enough for game tempo, slow enough that the driver has actual feel. Wheel rolling speed at 40 RPM is 8.4 in/sec — flips a 2.05″ toggle face in 0.24s. Both 6T and 30T HS-25 sprockets are stock VEX parts in the standard kit.

At 12% of stall, we already have 8× safety margin on torque. Adding a gear stage to get more torque is solving a problem we don't have. What it would add: weight on the back of the robot, backlash that compounds with chain slop, 5–10% efficiency loss per stage, more failure modes (one more meshing surface to lubricate and check). The right tuning variable is the chain ratio itself: swap to 1:4 (10 minutes of work) for more speed, or swap one motor to a 100 RPM cartridge for 2× torque without changing any sprockets.

• Driven shaft now cantilevers outboard of the tower verticals to support the wheels (~2.4″ cantilever) — standard V5RC pattern, well within shaft stiffness
• Tower span narrowed to ~11″ (from chassis-edge to chassis-edge in V2) to make space for the wheels at the chassis edges

• Single-pivot arm replaced with parallelogram four-bar: input link (driven by chain at the shared shaft, pivot A), output link (free pivot C, on a separate tower shaft 3″ below A), coupler at far end carries the claw
• Coupler stays vertical throughout the motion — claw stays oriented forward at any arm angle, no wrist motor needed
• Rubber band lift assist: stub on the input link perpendicular to its centerline (above the link) forms the third vertex of a triangle with pivot A and a fixed anchor at the top-front of the tower; rubber bands stretched between stub and anchor pull the arm UP at all positions
• New side view SVG added showing the four-bar geometry, three arm positions (down/horizontal/up), and the rubber band triangle at three stretch lengths

The first instinct is "rubber bands cancel gravity at all angles" — arm holds passively at any angle, motor only fights friction. But the geometry to achieve that is fragile: rubber band force is roughly linear with stretch, gravity torque is roughly sinusoidal with arm angle, so the curves don't match exactly. The pragmatic alternative is to bias the rubber bands so they always pull UP, with maximum tension when the arm is DOWN. The arm passively wants to lift; the motor only does work when actively driving the arm DOWN to grip a pin. On release, the bands lift the pin for free.

This is the same trick used by every desk lamp with a spring counterbalance: the spring isn't perfectly cancelling gravity at every angle, it's biasing the lamp arm toward "up" so the user can position it without it falling.

With anchor E at top-front of tower (above pivot A), stub on input link perpendicular UP at distance 2.5″ from A with stub length 2.5″, and 4 #64 rubber bands total (k≈2.4 lb/in combined):

• Arm at -45° (DOWN): stretch 6.6″, tension 16 lb, RB torque 43 in-lb UP, gravity 8.5 in-lb DOWN, net +34 in-lb UP
• Arm at 0° (horizontal): stretch 4.1″, tension 10 lb, RB torque 35 in-lb UP, gravity 12 in-lb DOWN, net +23 in-lb UP
• Arm at +45° (UP): stretch 1.5″, tension 4 lb, RB torque 7 in-lb UP, gravity 8.5 in-lb DOWN, net −1.6 (~neutral)

Natural rest equilibrium near +54° (where the line from anchor through pivot A intersects the stub-end's circular path). Motor's worst case is at DOWN, holding against ~34 in-lb of net upward torque — about 16% of two-motor stall. Comfortable.

With rubber bands carrying the arm UP at all positions, the original case for two motors (rotational mass + torque margin) is largely solved. Recommendation: build V1 prototype with one 11W motor on the lift; freeing the second motor (and its 11W) for a claw motor or extra drivetrain power is more game-relevant than a marginally faster lift. Add the second lift motor only if Mtg 8 testing shows torque or redundancy is the limit.

This is V4 partially undoing V2's "double the motors" decision — not because V2 was wrong, but because V4's rubber bands changed the load profile. Each version is correct in light of what was known at the time.

• Trade-off vs. pure gravity comp: motor must actively fight rubber bands when holding arm DOWN to grip a pin (~34 in-lb hold). Brief duration during the actual grip; not continuous. The lift on release is fast and free.
• Rubber band fatigue: latex bands lose ~20% tension over a season. Plan to swap between tournaments. Pre-stretch new bands for a few hours before a match.
• Anchor geometry: anchor at top-front of tower (slightly above pivot A in y, slightly back in x). This puts the closest point of the stub-end's circle to the anchor at +54° arm angle — the natural rest position.
• Starting point: 4 #64 rubber bands total (2 per side) for a ~14″ arm carrying ≤1lb. Adjust based on rest behavior — release the motor at horizontal; if arm rises to +60°-ish and holds, you're tuned.

• Anchor relocated from below pivot A to top-front of tower. Old position gave max stretch at arm-UP and min at arm-DOWN — opposite of what an actively-lifting design needs.
• Stub direction reversed: was perpendicular DOWN (below the input link), now perpendicular UP (above the link). Required for the new anchor position to give max stretch at arm-DOWN.
• Three rubber band positions visualized in the SVG (DOWN max, horizontal mid, UP min) instead of just one. The contraction/expansion is now visible at a glance.
• Right-side annotation block decluttered: three vertically-spaced blocks (PARALLELOGRAM · TRIANGLE · INTENT) instead of two crammed-together blocks.
• Design philosophy clarified: from "gravity comp at all angles" (idealized but fragile) to "lift assist with max tension at DOWN" (pragmatic, robust, easy to tune).

The original V4 SVG had a real geometric flaw: the stretch curve increased as the arm rotated UP, so the bands fought the motor on the way up and helped gravity on the way down — the wrong direction. Coach review caught it immediately ("the bands should have max tension when arm is down so it wants to go up"). The fix is small in geometry — relocate one anchor point, flip stub direction — but the math has to be redone from scratch to verify torque values at each arm angle.

This is exactly the kind of iteration that judges look for in an engineering notebook. Not "we got it right the first time" — but "we drew it, we noticed something was off, we worked the math again, we corrected it." The presence of a V4.1 entry is itself evidence of careful iteration.

Tuning the spring constant — how many bands, what type? — is empirical and depends on actual arm mass and claw load. The math says 4 #64 bands total is a good starting point for a 14″ arm carrying ≤1lb. But the only honest answer is "build V1, hang the actual arm, and adjust band count until the rest position feels right." That's an Mtg 8 task.