01
Quick facts students need.
- Field: 8 ft × 4 ft = 244 cm × 122 cm
- One "block" = 27 cm.
CutebotPro.runBlockCnt(n)drives exactlyn × 27 cm, then stops. → distance in cm ÷ 27 = block count (round to the nearest whole number). - The golden rule: the kick goes the way the bot is FACING. Finish your launch behind the ball, aimed straight down the field.
- Measure first. Before coding, use a tape measure: how far forward is the ball (
a)? how far to the side (b)? Those two numbers drive the math.
We're defining our own robot-local coordinate system. Treat the bot's starting position as the origin
(0, 0), with the x-axis running forward toward the goal (distance a) and the y-axis running sideways (distance b). The ball's location is the point (a, b). Every strategy below is a different path from (0, 0) to (a, b).
Heads-up: in algebra class, x usually runs horizontally and y vertically. On a real field, "forward" looks vertical — so in this lesson, x = forward. Different convention, same math.
Command cheat-sheet
cheatsheet.ts
JavaScript / MakeCode
CutebotPro.runBlockCnt(n) // drive n × 27 cm, then stop (best for geometry) CutebotPro.trolleySteering(CutebotProTurn.LeftInPlace, 45) // spin left 45° in place CutebotPro.trolleySteering(CutebotProTurn.RightInPlace, 90) // spin right 90° in place CutebotPro.pwmCruiseControl(left, right) // drive wheels (use currentPower) CutebotPro.stopImmediately(CutebotProMotors.ALL) // stop basic.pause(500) // wait 0.5 s
02
Choose your strategy.
Students often struggle more with picking a strategy than with executing one. Use this tree as a 60-second warm-up: read the ball position, follow the matching row. Strategy 3 always works as the general solution — the rows below are just the easier match for common geometries.
Ball is directly ahead. Bot, ball, and goal are collinear.
Strategy 1 · Straight Shot →
Ball is roughly ahead, exact spot unknown. A short nudge unblocks the sensors.
Strategy 8 · Sniper Hold →
Ball is forward and left, with
Strategy 2 · 45° Diagonal →
a ≈ b.Ball is forward and right, with
Strategy 7 · Mirror Diagonal →
a ≈ b.Ball is forward and offset, with
Strategy 3 · Measured Diagonal →
a ≠ b. The general case.Ball is well off to the side — you need to loop around it to hit it goal-ward.
Strategy 6 · Swing Wide →
You want to compare two paths to see why diagonals beat perpendicular legs.
Strategy 4 · L-Path →
Ball position is unknown (kickoff). Take a strong central post first.
Strategy 5 · Midpoint Hold →
You don't have
Strategy 9 · Time-Based Diagonal →
runBlockCnt available (older bot, blocks editor).You want one smooth curve into the ball — no turn-drive-turn.
Strategy 10 · Arc Launch →
03
The big idea — what the lesson is really about.
Ten launch strategies, but only one model. The lesson is fundamentally about modeling a point in space — measure the ball's location, represent it as a coordinate, compute the path, convert the path to robot commands. Everything else is a special case, a comparison, or an application.
The modeling cycle
STEP 01
Measure
Use a tape measure on the field. Forward distance
→
a, sideways distance b.STEP 02
Represent
Bot at origin
→
(0, 0). Ball at the point (a, b). The field is now a coordinate plane.STEP 03
Compute
Path length
→
c = √(a² + b²). Launch angle θ = tan⁻¹(b ÷ a). The general solution.STEP 04
Convert
Drive
c ÷ 27 blocks. Turn θ° in place. Run the code. Compare prediction to reality.How the ten strategies relate
Once you see the modeling cycle, the ten cards stop looking like ten unrelated recipes:
03
Strategy 3 · The Measured Diagonal
The core model.
c = √(a² + b²), θ = tan⁻¹(b ÷ a). Works for any ball position (a, b). Every other strategy in this guide is either a simplification of this one or a comparison against it.Special cases
The geometry collapses — Strategy 3's math still works, but a simpler path is available.
- Strategy 1 · Straight Shot — when
b = 0(ball dead ahead). No turn needed;θ = 0°. - Strategy 2 · 45° Diagonal — when
a = bon the left.θ = 45°;c = a√2. - Strategy 7 · Mirror Diagonal — when
a = bon the right. Strategy 2 reflected across the x-axis.
Comparisons, applications & variants
Same point in space, different goal — or a different way to drive there.
- Strategy 4 · L-Path — comparison. Two legs vs one diagonal. Triangle inequality lives here.
- Strategy 5 · Midpoint Hold — application. Coordinate midpoint when the ball's position is unknown.
- Strategy 6 · Swing Wide — application. Arc geometry (
L = rθ) to get behind the ball. - Strategy 8 · Sniper Hold — baseline. Tiny nudge; let the sensors run the model.
- Strategy 9 · Time-Based Diagonal — implementation variant of Strategy 2, using time instead of distance.
- Strategy 10 · Arc Launch — implementation variant. Curve in one motion instead of turn-drive-turn.
04
Ten launch sequences.
Color stripe = difficulty (green easy · amber medium · red challenge). Strategy 3 is highlighted as the core — every other strategy is a simplification, comparison, or implementation variant. Code is a starting point; students tune the numbers to their own field.
01
Straight Shot
⭐ Easy
GeometryThe shortest path between two points is a straight line.
SetupPlace the bot so the ball is directly between it and the goal.
// Ball is dead ahead. Drive straight at it; // the locked code finishes the kick. // 81 cm to the ball -> 81 / 27 = 3 blocks. CutebotPro.runBlockCnt(3) basic.pause(150)
TeachMeasuring + the cm → block conversion. The cleanest possible launch.
02
The 45° Diagonal
⭐⭐ Medium
GeometryA right triangle with equal legs (
a = b) has a 45° angle; its hypotenuse is a × 1.41.SetupBall is forward AND to the left by about the same amount.
// Turn 45° toward the ball, drive the diagonal, // then turn back 45° to face the goal. CutebotPro.trolleySteering(CutebotProTurn.LeftInPlace, 45) basic.pause(300) CutebotPro.stopImmediately(CutebotProMotors.ALL); basic.pause(150) // Hypotenuse: each leg ≈ 81 cm -> diagonal ≈ 115 cm ≈ 4 blocks. CutebotPro.runBlockCnt(4) basic.pause(150) CutebotPro.trolleySteering(CutebotProTurn.RightInPlace, 45) basic.pause(150)
TeachEqual-and-opposite turns cancel; the diagonal beats two straight legs.
03
The Measured Diagonal ★ Core model · Strategy 3
⭐⭐⭐ Challenge · The general solution for any (a, b)
GeometryGeneral right triangle from
(0, 0) to (a, b). The hypotenuse and the launch angle are both given by the coordinates.SetupBall is forward
a and to the side b, NOT equal.The math · general solution
c = √(a² + b²)
θ = tan⁻¹(b ÷ a)
Strategy 3 is the general solution. Strategies 2 and 7 are the special case where
a = b (giving θ = 45°). Strategy 1 is the special case where b = 0 (giving θ = 0°). Once students see this, the earlier strategies become shortcuts — not separate moves to memorize.// Example: a = 120 cm forward, b = 60 cm left. // angle = atan(60 / 120) ≈ 27° // c = √(120² + 60²) ≈ 134 cm -> 134 / 27 ≈ 5 blocks CutebotPro.trolleySteering(CutebotProTurn.LeftInPlace, 27) basic.pause(300) CutebotPro.stopImmediately(CutebotProMotors.ALL); basic.pause(150) CutebotPro.runBlockCnt(5) basic.pause(150) CutebotPro.trolleySteering(CutebotProTurn.RightInPlace, 27) basic.pause(150)
TeachPythagorean theorem + intro trig (or measure the angle with a protractor on a scale drawing of the field).
04
The L-Path
⭐⭐ Medium
GeometryTwo perpendicular legs. Great for comparing with the diagonal —
a + b is always longer than √(a² + b²) (the triangle inequality).SetupBall forward
a, to the side b.// Leg 1: forward toward the ball's depth. CutebotPro.runBlockCnt(3) // ~81 cm forward (a) basic.pause(150) // Turn to face the ball's side. CutebotPro.trolleySteering(CutebotProTurn.LeftInPlace, 90) basic.pause(300) CutebotPro.stopImmediately(CutebotProMotors.ALL); basic.pause(150) // Leg 2: across to the ball. CutebotPro.runBlockCnt(2) // ~54 cm sideways (b) basic.pause(150) // Re-face the goal. CutebotPro.trolleySteering(CutebotProTurn.RightInPlace, 90) basic.pause(150)
TeachRight angles, and why the diagonal (Strategy 2/3) is more efficient.
05
Midpoint Hold
⭐ Easy
GeometryThe midpoint of the field along the forward axis — coordinates
(122, 0) in cm. Posting up here minimizes the worst-case distance to wherever the ball ends up. Coverage-area optimization.SetupUse this when the ball's position is unknown or contested — kickoff, after a goal, or when the opponent's launch could send the ball anywhere.
// Drive to the midpoint of the field (forward axis). // Field is 244 cm long; midpoint = 122 cm = 4–5 blocks // from your goal line. CutebotPro.runBlockCnt(4) basic.pause(150) // Why post here? From (122, 0), the worst-case ball position // is the far corner: √(122² + 122²) = 122√2 ≈ 173 cm. // Compare to (0, 0), where the far corner is √(244² + 122²) // ≈ 273 cm. The midpoint cuts the worst case by ~37%.
TeachThe midpoint formula:
((x₁+x₂)/2, (y₁+y₂)/2) applied to a real field. Optimization framing: a fixed position that minimizes maximum distance to a moving target. Compare with a forward rush — when does each one win?06
Swing Wide — Get Behind the Ball
⭐⭐⭐ Challenge
GeometryCollinearity + circular arc. The bot must end up on the line bot → ball → goal, so it traces an arc around the ball. The arc has a turning radius
r and a sweep angle θ (in radians); the arc length is L = r × θ.SetupBall is well off to the side. Choose a swing radius
r (~30–50 cm is typical) — bigger r is more forgiving, smaller r is quicker but more error-prone.The math · arc geometry
L = r × θ
Example: r = 40 cm, θ = π/3 rad (60°) → L ≈ 42 cm ≈ 2 blocks
A bigger turn radius means a wider, gentler arc — easier to follow, longer to drive. Students who pick
r first and then derive L are doing real engineering.// Curve out and past the ball, then come back in // lined up with the goal. CutebotPro.trolleySteering(CutebotProTurn.RightInPlace, 30) basic.pause(300) CutebotPro.stopImmediately(CutebotProMotors.ALL); basic.pause(150) CutebotPro.runBlockCnt(3) // drive out and past the ball basic.pause(150) CutebotPro.trolleySteering(CutebotProTurn.LeftInPlace, 30) basic.pause(150)
TeachYou control the ball's direction by choosing which side you hit it from. Plus: turning radius, arc length (
L = rθ), and the relationship between sweep angle and distance traveled — the same math that connects to circles, tangent lines, and inverse kinematics later on.07
The Mirror Diagonal
⭐⭐ Medium
GeometrySymmetry. Same as Strategy 2, mirrored for a ball on the right.
SetupBall forward and to the right.
CutebotPro.trolleySteering(CutebotProTurn.RightInPlace, 45) basic.pause(300) CutebotPro.stopImmediately(CutebotProMotors.ALL); basic.pause(150) CutebotPro.runBlockCnt(4) basic.pause(150) CutebotPro.trolleySteering(CutebotProTurn.LeftInPlace, 45) basic.pause(150)
TeachLeft/right symmetry — swap every "Left" for "Right" to mirror a plan.
08
Sniper Hold — Minimal Launch
⭐ Easy
GeometryAlmost none — a tiny nudge, then trust the bot's built-in find / aim / kick.
SetupBall roughly ahead, exact spot unknown.
// Short nudge forward; let the sensors find, // aim, and kick on their own. CutebotPro.runBlockCnt(1) // ~27 cm basic.pause(150)
TeachA baseline to compare against — does a clever launch actually beat "let the robot do it"? Good first run for every team.
09
Time-Based Diagonal
⭐⭐ Medium
GeometrySame diagonal as Strategy 2, but driven by time instead of distance.
powerScale makes the distance come out the same on fast and slow bots.SetupBall forward and to the left (and no
runBlockCnt available).CutebotPro.trolleySteering(CutebotProTurn.LeftInPlace, 45) basic.pause(300) CutebotPro.stopImmediately(CutebotProMotors.ALL); basic.pause(150) CutebotPro.pwmCruiseControl(currentPower, currentPower) basic.pause(Math.round(1500 * powerScale)) // tune the 1500 until it reaches the ball CutebotPro.stopImmediately(CutebotProMotors.ALL); basic.pause(150) CutebotPro.trolleySteering(CutebotProTurn.RightInPlace, 45) basic.pause(150)
TeachWhy time-based driving is less reliable than distance — and what
powerScale is for. Have them race a fast build vs a slow build and watch the difference shrink with powerScale.10
The Arc Launch
⭐⭐⭐ Challenge
GeometryCurvature. Instead of turn, drive, turn, curve onto the ball → goal line in one smooth motion by running the wheels at different speeds.
SetupBall forward and to the left.
// Left wheel slower than right -> the bot arcs LEFT // toward the center line. CutebotPro.pwmCruiseControl(Math.round(currentPower * 0.6), currentPower) basic.pause(Math.round(1400 * powerScale)) // tune time for your field CutebotPro.stopImmediately(CutebotProMotors.ALL) basic.pause(150)
TeachA curved path vs straight segments; experiment with the
0.6 (sharper vs gentler arc). Swap the wheel values to arc right.
05
Optimization challenge — which path is shortest?
Once students can run the strategies, switch the question from "did it work?" to "how efficient was it?" The L-Path (Strategy 4) and the Measured Diagonal (Strategy 3) reach the same point. They don't travel the same distance.
L-Path · Strategy 4
distance = a + b
Example: a = 120 cm, b = 60 cm → 180 cm (≈ 7 blocks)
Measured Diagonal · Strategy 3
distance = √(a² + b²)
Example: a = 120 cm, b = 60 cm → ≈ 134 cm (≈ 5 blocks)
Savings: 46 cm. The diagonal saves about 25% of the driving distance for this ball position. Have students compute the savings for their own
(a, b) — and decide whether the savings are worth the extra turning math.
Extensions you can run with this:
- For which
(a, b)values does the diagonal save the most? Hint: the percentage advantage shrinks as one leg becomes much larger than the other — but the absolute savings in cm don't always shrink. Have students check both. - If turning takes time too, when does the L-Path actually win on total seconds — even though it loses on distance?
- Plot path-length vs. ball position on graph paper. The triangle-inequality result is suddenly a visible curve.
06
How to run a lesson with these.
- Everyone starts with #8 (Sniper Hold) — get a baseline, see the bot play.
- Measure the ball: record
(a, b)in your data table before anything else. Have students point at the origin (0, 0) and the ball (a, b) before they touch the code. - Pick a strategy using the decision tree in Section 02.
- Predict, then test. Before running, write the predicted distance, angle, and time-to-ball in the data table. After running, record what the bot actually did. The gap between prediction and actual is the lesson — much more than the result itself.
- Iterate: the numbers in every example (
runBlockCnt(3),45°,1500) are starting points — students tune them to their own field and bot. Each tune is a new row in the data table. - Compare strategies: which scores fastest from the same ball position? Which had the smallest prediction error? They're different questions, and the data table makes both answerable.
"Geometry predicts what should happen. Testing reveals what actually happens."
Real bots don't deliver perfect 45° turns or perfect distance calibration — wheels slip, batteries drain, surfaces vary. This is the engineering message of the lesson, not a failure mode. Frame mismatches between predicted and actual as data, not as mistakes. The students who tune fastest are the ones who write down the gap.
Match log · data collection
Hand teams this table at the start of the lesson. One row per run. Three rows minimum before they're allowed to claim "this strategy works."
| Strategy | (a, b) | Predicted distance | Predicted time | Actual time | Error = Actual − Predicted | Goal? | Tune for next run |
|---|---|---|---|---|---|---|---|
| 1 · Straight | _____ | _____ cm | _____ s | _____ s | _____ s | Y / N | _____________ |
| __ | _____ | _____ cm | _____ s | _____ s | _____ s | Y / N | _____________ |
| __ | _____ | _____ cm | _____ s | _____ s | _____ s | Y / N | _____________ |
| __ | _____ | _____ cm | _____ s | _____ s | _____ s | Y / N | _____________ |
A positive error means the bot took longer than predicted (most common — friction, wheel slip, battery drain). A negative error means it beat your prediction. After a few rows, students can spot whether their errors are systematic (always positive, always negative) or noisy. Systematic error → tune the formula. Noisy error → tune the bot.
07
Capstone — which strategy minimizes total match time?
After the optimization comparison (Section 04) and a few rows of real data, change the question one more time. Not "did it score?" Not "which distance was shortest?" Not "which turn count was lowest?" — but: which strategy reliably gets the ball into the goal in the fewest total seconds, averaged over multiple runs?
Insight 01
Shortest distance ≠ fastest.
Every turn has a cost:
~300 ms per pivot, plus settling time. A 45° diagonal that takes two turns may lose to a longer L-Path that takes zero turns at speed if the field is short.Insight 02
Fastest ≠ most reliable.
A best-case 1.2 s strategy that fails 3 of 10 runs has an effective time worse than a steady 1.8 s strategy that succeeds 10 of 10. Variance kills.
Insight 03
Reliability has value.
In a 3-minute match, the strategy with the lowest average time-to-goal wins more matches than the one with the lowest best time. Engineers optimize the expected value, not the highlight reel.
The capstone prompt: Run each candidate strategy three times from the same ball position. Record actual time + goal-or-no for each run. Then compute two separate metrics — they answer different questions:
- Average successful time =
(sum of successful run times) ÷ (number of successful runs). Speed when the strategy works. - Reliability =
(number of successful runs) ÷ 3. Probability the strategy works at all.
The winner is whichever strategy has the lowest average successful time AND reliability ≥ 2/3. A 1.2 s strategy that succeeds 1 of 3 times loses to a 1.6 s strategy that succeeds 3 of 3. Defend your pick with the data table — not the highlight reel.
This is the question engineers actually answer in the real world: not "what's possible in the best case?", but "what wins on average, accounting for failure?" Bring the data table forward — every row a team filled in becomes evidence for or against their final pick.
Reminder: turns use the compass-free
trolleySteering (dead-reckoned by degrees), and drives can be distance-based (runBlockCnt) or time-based (pwmCruiseControl + pause). Distance-based is more repeatable — push students toward it for anything that depends on geometry.