Your robot ran perfect all season. Then it failed on race day. Most teams blame the code and spend the whole prep window rewriting it. The real fault is rarely the code. It's a cold joint, a tired battery, or a calibration run done on the wrong surface, something nobody checked the night before. These seven mistakes repeat every season, and each one has a routine that prevents it.

If your team has already lived through one of these, the community is where teams compare notes on what failed.

Mistake 1: Soldering the Night Before

Most competition-day failures aren't bugs. They're a joint re-soldered under hostel lighting at 1 a.m., tested for thirty seconds, and never touched again.

Treat any hardware change made inside 48 hours of your run as a risk, not a fix. A cold joint two millimeters wide looks fine on the bench. It fails once it flexes in transport or heats up under load, and by then it reads like a code problem, not a wiring one. Teams burn their prep window debugging code that was never broken. Rest the iron in its stand between joints, not on the desk. Tired hands drop hot metal.

If you make a change late, retest it under full run load and duration, not a quick bench check. If rushed soldering keeps costing you, a board with on-board regulation and isolated traces removes most of these joints before they can fail.

Mistake 2: Trusting a Battery You Haven't Checked Under Load

A LiPo can read a healthy resting voltage and still sag hard the moment the motors pull real current out of a turn. A pack that's been through dozens of charge cycles sags faster than a fresh one.

Check pack voltage with the motors spinning, not resting on a meter. Your PID gains were tuned against a specific motor torque. Drop the voltage mid-run and the motors respond slower to the same correction, so a robot that cornered clean an hour ago starts drifting wide, not because anything broke, but because the torque under your tuning changed. A driver near its current limit adds heat on top of that, and heat becomes its own failure mode right when your run does.

Charge batteries the night before, not race morning, and carry one full spare per bot. Charge and store packs on a hard, fireproof surface, never in a backpack overnight.

Mistake 3: Skipping Recalibration on the Actual Track

The ARC16 and ARC8 sensors read line position off reflected infrared light, and that reading shifts with ambient light and surface finish. A calibration run on your home mat under warm room lighting produces different min and max values than a glossy competition track under hall lighting will.

Recalibrate on the actual track, under the actual lights, as close to your run time as the schedule allows. Calibration sets the threshold your code uses to decide line versus floor. Get that threshold wrong for the surface in front of you and a robot that tracked all season loses the line on turn one. That's a stale-data problem, not a code one.

Mistake 4: Racing on a PID Loop You Never Actually Tuned

Two versions of this mistake show up every season. One is copying a Kp, Ki, Kd set from a tutorial or another team's robot. The other is tuning carefully at a slow, comfortable test speed and never touching it again once race pace goes up.

PID gains are a fit for your robot's weight, motor torque, and sensor spacing, not a universal setting. Numbers tuned for someone else's lighter, faster-geared robot can make yours wobble or overshoot. Gains tuned at a crawl often can't keep up at full speed, because the correction has less time to catch the same drift.

Tune your own P value alone before adding I or D, and retune it again the week you start full-speed laps, not the week before the event. Our walkthrough of the tuning process covers the order to do it in.

Mistake 5: Chasing a Mechanical Problem With Code

A chassis that flexes under acceleration, a sensor arm that shifted half a millimeter in a backpack, motor mounts that worked loose after weeks of vibration. None of these look dramatic. They show up as a robot that corners differently on the left than the right, and get blamed on the firmware.

Check sensor height, motor mount tightness, and wheel wear before every competition, not only battery and code. A tuning session spent chasing a mechanical fault with PID changes never fixes it. You're adjusting code to compensate for a frame drifting under you, and the compensation breaks again the moment conditions change.

If you're outgrowing your chassis at higher speeds, that's a real upgrade, but only after you've ruled out a loose screw first.

Mistake 6: Having No Backup Plan at the Table

A firmware flash goes wrong five minutes before your slot and there's no known-good build saved anywhere. A wheel cracks and there's no spare in the bag. Nobody wrote down which Kp worked, so "going back to what worked" becomes a guess made under pressure.

Keep a saved, known-good firmware build separate from whatever you're experimenting with that week. Competition tables reward routine, not improvisation. Every decision made on the spot, which cable, which battery, which firmware version, pulls attention away from the run itself.

Label your tuning values as you go instead of trusting memory, and pack a spare wheel, battery, and cable as standard kit. Our race-day firmware checklist is built to remove these decisions before you're at the table.

Mistake 7: Not Checking the Rulebook Until It's Too Late

A robot exceeds a dimension or weight limit nobody double-checked. A component turns out to be restricted for that event. The track's line width or turn radius doesn't match what the team practiced on, and nobody finds out until the walkthrough.

This is the only mistake on this list that can end your competition before your robot reaches the start line. Every other failure here still gets you a run, even a bad one. A rules mismatch can disqualify the most solid robot in the building before it moves an inch.

Read the rulebook the week you register, then check it again once travel is confirmed. Specs change year to year, so confirm dimensions and track parameters against your actual build, not what you assume is standard.

Quick Pre-Competition Checklist

• No hardware changes in the final 48 hours without a full retest.

• Two charged batteries per bot, checked under load.

• Recalibrated on the actual track, under the actual lights, same day.

• PID retuned at race speed, tuned by your team, not copied.

• Sensor height, motor mounts, and wheels checked, not assumed.

• A known-good firmware build saved, spares packed, values written down.

• Rulebook re-read after travel is confirmed.

Conclusion

None of these seven mistakes are about skill. They're about routine, the difference between treating race day as a continuation of practice and treating it as a separate event where old habits stop working. The teams that place well aren't running the most advanced build in the room. They're the ones who removed the most avoidable failure points before the run started.

Go through this list against your own build this week. Which of these seven have you already lived through, and which one are you still one bad night away from?

If soldering under pressure is a recurring problem for your team, the Blueprint 01 controller board has on-board regulation and isolated power traces, so the joints that usually fail on a breadboard aren't there to fail. You can build every routine on this list with a breadboard and still win. The board removes one more variable.