Somewhere at every Techfest, Robocon, or college LFR meet, a robot that worked perfectly for three weeks straight fails in front of the judges, not because the code was wrong, but because of something nobody checked the night before. This happens to more teams than the podium results suggest, and it's rarely one dramatic failure. It's one of seven small, avoidable mistakes that repeat year after year across robotics clubs. Here's what they are, why they cost teams the run, and exactly how to build a routine that catches them before they reach the table.

Mistake #1: Soldering the Night Before (Or Morning Of)

The most common failure at any competition table isn't a bug. It's a joint that got re-soldered under hostel lighting at 1 a.m., tested for thirty seconds, and never touched again. A rushed connection, a motor wire re-terminated after a last-minute chassis swap, a sensor cable spliced because the old one frayed, looks completely fine on the bench. Then it flexes during transport or heats up under load, and the joint that tested "good enough" becomes an intermittent short exactly when it matters most.

Intermittent electrical faults are the hardest bugs to diagnose, because they don't behave like bugs. The robot runs fine on attempt three and dies on attempt four, with nothing pointing at a cold joint two millimeters wide. Teams burn their entire prep window "debugging code" that was never actually broken.

Treat any hardware change made less than 48 hours before your run as a risk, not a fix. If you must make one, re-test it under the same load and duration as a real run, not a quick bench check. If rushed soldering is a recurring problem for your team, building on a proper controller board instead of loose breadboard wiring removes most of the failure points before they can happen. The Blueprint 01 controller PCB has on-board voltage regulation and clean, isolated power traces, so the connections that usually go wrong on a breadboard aren't there to fail. And if your team is short on build time altogether, a pre-assembled and PID-tuned Mark 1 skips the soldering step completely. You calibrate on the track and race.

Mistake #2: Trusting a Battery That's Already Tired

A LiPo battery that reads a healthy resting voltage can still sag hard the moment the motors draw real current: accelerating out of a turn, correcting a hard swerve, climbing a slight seam in the track. A pack that's been charged and discharged dozens of times sags more, and sags faster, than a fresh one.

Your PID gains were tuned against a specific amount of motor torque. When pack voltage drops mid-run, the motors respond slower to the same correction signal, and a robot that was gliding through turns an hour ago starts drifting wide. Not because anything broke, but because the physics under your tuning quietly changed. Layer a motor driver running close to its current limit on top of that, and heat becomes a second failure stacked on the first. Driver current and heat is its own quiet failure mode that only shows up after a robot has been running a while, which is exactly when your competition run happens.

Charge your competition batteries the night before, not that morning, and bring at least one fully-charged spare per bot, not per team. Check pack voltage under load, with motors spinning, not just resting on a meter. If a driver board runs warm during practice, treat that as a signal to act on early, not something to ignore because "it still works."

Mistake #3: Skipping Recalibration on the Actual Track

Sensors like the ARC8 and ARC16 read line position by measuring reflected infrared light, and that reading shifts with ambient lighting and surface finish. A calibration run done on your home practice mat under warm room lighting produces different min/max sensor values than the same robot sees on a glossy competition track under a hall full of overhead lights.

Calibration sets the threshold your code uses to decide "this is line" versus "this is floor." Get that threshold wrong for the surface and lighting actually in front of you, and a robot that tracked perfectly all season loses the line on turn one. That's not a code problem. It's a stale-data problem.

Recalibrate on the actual competition track, under the actual venue lighting, as close to your run time as the schedule allows, every single time. If your event leans toward mazes or multi-junction tracks rather than a straight speed run, it's worth understanding how a junction-detecting sensor array changes what your firmware needs to do before race day, not during it.

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

Two versions of this mistake show up constantly. One is copying a Kp/Ki/Kd set from a tutorial or another team's robot without re-tuning it for your own hardware. The other is tuning carefully at a slow, comfortable test speed and never retuning once speed goes up.

PID gains aren't universal constants. They're a fit between your specific robot's weight, motor torque, sensor spacing, and speed. Numbers that work beautifully on someone else's lighter, faster-geared robot can make yours wobble or overshoot. And gains tuned at a crawl often can't keep up at full speed, because the correction has less time to respond to the same physical drift.

Tune your own P value in isolation before adding anything else, and retune incrementally as you raise speed toward race pace, the week you start full-speed practice laps, not the week before the event. We've written a full walkthrough of the tuning process if your team is still racing on copied numbers.

Mistake #5: Ignoring the Chassis Until Something Rattles Loose

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

A tuning session spent chasing a mechanical problem with PID changes never actually fixes it. You're adjusting code to compensate for a frame that's drifting under you, and the compensation stops working the moment conditions change again.

Before every competition, physically check sensor height, motor mount tightness, and wheel wear, not just battery and code. If your build is genuinely outgrowing a basic 3D-printed chassis at higher speeds, that's a real upgrade point, but only after you've ruled out a loose screw as the actual problem.

Mistake #6: Showing Up With No Backup Plan

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 kit bag. Nobody wrote down which Kp value worked, so "going back to what worked" turns into a guess made under pressure.

Competition tables reward routine, not improvisation. Every decision you're forced to make on the spot (which cable, which battery, which firmware version) is attention taken away from the one thing that actually matters: the run itself.

Keep a saved, known-safe firmware profile separate from whatever you were experimenting with that week, and label your tuning values as you go instead of trusting memory. Pack spare wheels, a spare battery, and a spare cable as standard kit, not an afterthought. Our race-day firmware checklist is built around exactly this: removing decisions at the table so there's nothing left to improvise.

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 specific event. The track's line width or turn radius is different from what the team practiced on, and nobody found out until the walkthrough.

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

Read the official rulebook the week you register, not the week before the event, and check it again once travel is confirmed. Specs change between event years. Confirm dimensions, weight limits, and track parameters against your actual build, not your assumptions about what "should" be standard. If anything is ambiguous, ask the organizers directly instead of guessing at the venue.

Quick Pre-Competition Checklist

• No hardware changes in the final 48 hours without a full re-test.

• Two charged batteries per bot, checked under load, not just at rest.

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

• PID retuned at race speed, not just practice speed, and tuned by you, not copied.

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

• A known-safe firmware profile saved, spares packed, values written down.

• Rulebook re-read after travel is confirmed, not the week before.

Conclusion

None of these seven mistakes are really about skill. They're about routine. It's the difference between a team that treats race day as a continuation of practice and a team that treats it as a separate, higher-stakes event where old habits quietly stop applying. The robots that place well aren't always the most advanced builds in the room. They're usually the ones that eliminated the most avoidable failure points before the run even started.

Go through this list once 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? Compare notes with other teams and drop by the community before your next event.