# Botball Coach Guide ## Your Job Isn't to Write the Code The goal is for the students to understand what their robot is doing and why. When they're stuck, your instinct will be to fix it for them — resist that. Ask questions instead. "What do you think is happening?" is more valuable than pointing at the bug. That said, don't let them spin indefinitely. A good rule: if students have tried **three different ideas** and nothing has changed, step in and suggest a new direction. Three attempts is enough to learn from; more than that without progress is just frustrating. --- ## How to Coach a Troubleshooting Session When something goes wrong, walk them through the same process every time. They'll internalize it. **1. Observe before touching anything.** Watch the robot fail. Ask: "What did you expect to happen? What actually happened?" If they can't articulate the difference, they're not ready to fix it. **2. Isolate the problem.** Is it mechanical (motor, servo, wiring), sensor-related, or code logic? Have them run the self-test program first if they're unsure. "Let's rule things out one at a time." **3. Form a hypothesis.** "What do you think is causing it?" Make them guess. Wrong guesses are fine — they're learning. Then test the guess. **4. Change one thing at a time.** Students will often change three things at once and then not know what worked. Slow them down. One change, one test, record what happened. **5. Use `printf`.** If they can't see what the robot is thinking, have them print sensor values and motor states. "What does the sensor actually read when the robot is in that position?" --- ## When They're Stuck on Code **They don't know where to start:** Help them break it down. "What's the very first thing the robot needs to do in this section?" Get them writing one function at a time. **The code doesn't compile:** Read the error with them, out loud. Compiler errors are intimidating but usually specific. Most common issues: missing semicolons, mismatched braces, calling a function before it's defined. **The robot does something unexpected:** Ask them to walk you through the code line by line, out loud, and describe what each line should do. They'll often find the bug themselves mid-explanation. (This is called rubber duck debugging — it works.) **Timing is off (robot stops too early or too late):** Remind them that `msleep` timings depend on battery level and surface conditions. If they're relying heavily on time-based movement, encourage them to add encoder or sensor checks. **The sensor threshold seems wrong:** Have them print the sensor value in a loop while moving the robot to the exact position where the behavior should change. Then set the threshold to that value, with a small buffer. --- ## Coaching Mecanum Bots Specifically Mecanum robots are powerful but have a higher coordination cost. A few things to watch for: - **Motor directions matter more.** Each wheel needs to spin the right way for strafing and diagonal moves to work. If the bot is spinning instead of strafing, at least one motor direction is flipped. Run the self-test to check each motor in isolation. - **"Squaring up" is tricky.** Mecanum bots can strafe into walls to align, but students often just use time-based strafing. Encourage them to think about whether a sensor could give them a more reliable stop condition. - **Inconsistent strafing.** Friction and floor surface variation affect mecanum movement more than regular drive. If a strafe distance is inconsistent, use encoder ticks (`cmpc`/`gmpc`) instead of `msleep`. --- ## Pre-Practice Habits Worth Building - **Always run the self-test first.** Before writing new code or debugging a route, verify the hardware is working. A loose motor wire will look like a code bug. - **Charge batteries before practice, not during.** Nothing kills debugging momentum like stopping to swap batteries mid-session. - **Back up code before making changes.** Encourage them to copy working code to a commented-out block or a separate file before experimenting. They'll thank you when they break something. - **Write port assignments as `#define` constants at the top of the file.** If a wire gets moved to a different port, changing one line is far better than hunting through code. --- ## Pre-Competition Checklist Run through this with the team the day before and the morning of competition. - [ ] Self-test passes on competition robot (all motors and servos respond correctly) - [ ] Sensor thresholds verified on the actual competition surface and lighting - [ ] `wait_for_light()` is the first call in `main()`, not buried in a section function - [ ] `shut_down_in(119)` is called early in `main()` as a safety net - [ ] All `#define` port constants match the physical wiring - [ ] Robot starts from the correct position and orientation - [ ] Team knows what to do if the robot fails mid-run (stay calm, note what happened for next run) - [ ] Battery is fully charged --- ## Managing the Team Dynamic Middle schoolers will disagree about the code. That's good — let them argue it out to a point, then have them *test* the disagreement rather than just debate it. "Both ideas sound reasonable. Let's try yours first and see what happens." If one student is dominating the keyboard, rotate. Even if they're the strongest coder, the others need hands-on time. Celebrate working things. A section that runs correctly in practice is worth noting, even if the full route isn't done yet.