The Unwritten Rules of Robotics Competitions: What Teams Wish They Knew Before Entering

TL;DR: Winning robotics competitions rarely comes down to the most advanced algorithm or the most expensive hardware. Teams that consistently place well share a different set of habits: they freeze their software stack days before travel, pack spare parts in duplicate, test under the actual lighting and terrain conditions of the arena, and treat logistics as a first-class engineering problem. This guide collects the practical robotics competition tips that experienced teams pass down informally, covering preparation, on-site debugging, ROS 2 stack hardening, and the human factors that decide who finishes a run and who watches their robot reboot.

Why most robotics competition tips miss the real problem

Walk through the pit area at any field robotics event - ERC, RoboCup, DARPA-style challenges, university rover competitions - and you will see the same pattern. The teams struggling are not necessarily the ones with weaker SLAM implementations. They are often the ones reflashing firmware at 2 a.m., hunting for an M3 screw, or discovering their Wi-Fi router conflicts with the venue's network.

Robotics competition tips published online tend to focus on the visible layer: which sensors to choose, which planner to use, which ROS 2 navigation stack performs best. Those choices matter, but they are decided months in advance. What decides the actual outcome on competition day is preparation discipline, redundancy, and the ability to debug under stress. This guide focuses on what you wish someone had told you before you registered.

How to prepare your robot for the stress of a competition arena

A laboratory is a controlled environment. A competition arena is not. Temperature swings, dust, vibration during transport, unpredictable lighting, GNSS multipath from metal structures, and Wi-Fi spectrum crowded with hundreds of devices will expose every shortcut in your build.

Before you ship the robot, run through this hardening checklist:

• Vibration test the wiring. Drive the robot over rough terrain for at least 30 minutes and check every connector. JST and Dupont connectors can loosen. Use hot glue, locking connectors, or strain relief on anything mission-critical.
• Thermal stress the compute. Run your full ROS 2 stack at maximum CPU load in an enclosed space for an hour. A Jetson or Raspberry Pi that is already near its thermal limit in the lab will throttle faster in a sealed pit tent at noon.
• Test under hostile lighting. Direct sunlight destroys many vision pipelines tuned indoors. Validate your perception stack outdoors at solar noon and at low sun angles. ArUco detection, color segmentation, and depth from stereo all degrade differently.
• Simulate GNSS denial. If your localization assumes RTK fix, test what happens when it drops to float or no fix. Many arenas have partial sky visibility.
• Freeze the software stack. Stop merging features at least seven days before travel. Use that week only for bug fixes and field testing. Tag the final release in git and flash it to every spare SD card.

Platforms designed for field research, such as the Leo Rover, already address some of these failure modes at the mechanical level - sealed enclosure, robust connectors, modular payload mounting - which reduces the surface area you need to harden yourself. Teams using off-the-shelf research platforms typically spend their preparation time on perception and autonomy rather than on rebuilding the chassis after every transport.

What logistics mistakes cost teams the most points

Logistics is the invisible category that ends more competition runs than software bugs. The following mistakes appear year after year across events:

1. Lithium battery shipping. IATA rules for passenger baggage generally require spare lithium-ion batteries to travel in carry-on baggage; batteries above 100 Wh and up to 160 Wh usually need airline approval, and batteries above 160 Wh are not allowed as passenger baggage and must be shipped under dangerous goods rules. Check your battery's Wh rating (V × Ah) months in advance. Many teams have arrived without power.
2. Customs paperwork. ATA Carnets, commercial invoices, and HS codes for robotic equipment crossing borders can take weeks. A robot stuck in customs is a forfeit.
3. Power adapters and voltage. Competitions held in different regions mean different mains voltages and plug types. Bring a step-up/step-down transformer if your chargers are region-locked.
4. Spare parts in duplicate. Pack two of every motor, two IMUs, two SBCs pre-flashed with the exact production image, and at least one spare of every cable. The cost of an extra compute module is often small compared to a failed run.
5. Network independence. Do not rely on the venue's Wi-Fi. If the rules allow it, bring your own router, a long Ethernet cable, and a 4G/5G hotspot as backup. Pre-configure static IPs.
6. Tooling. A pit kit should include a soldering iron, multimeter, oscilloscope (if you can transport one), heat gun, zip ties, electrical tape, threadlocker, and a full metric and imperial hex set.

How to debug a ROS 2 stack under competition pressure

When the run starts in 40 minutes and the robot will not localize, panic debugging is the dominant failure mode. Teams that handle this well have established protocols.

First, use ros2 bag aggressively. Record every run, including practice runs. Many arenas offer practice slots or controlled access before scored attempts. Bag every sensor topic. When something fails in a scored run, you can replay the exact data and debug offline while the next team competes.

Second, build a tiered logging system. Configure rclcpp and rclpy loggers so that during operation you see only WARN and above, but a single launch argument switches everything to DEBUG. Searching through gigabytes of INFO spam at 1 a.m. is not how you find a transform tree error.

Third, validate your TF tree before every run. A simple ros2 run tf2_tools view_frames takes only a moment and catches the most common integration error: a missing or duplicate transform after someone rebased a branch.

Fourth, separate autonomy from teleoperation. Even fully autonomous categories may allow manual recovery, restarts, or intervention between attempts. A reliable teleoperation fallback - tested, with its own controller and its own network path - has saved more runs than any planner improvement.

What experienced teams know about the human factors

Competitions are endurance events. A typical schedule involves setup days, technical inspections, multiple scored runs, and presentations, often spread over four to seven days with travel on either side. Sleep deprivation degrades debugging ability faster than it degrades driving ability.

Effective teams rotate roles. One person is the pit chief during a run, responsible only for the robot's readiness. Another handles communication with judges. A third manages the software branch and never touches hardware during a run. Diffusing these responsibilities prevents the single-point-of-failure problem where the one person who understands the navigation stack is also the one soldering a connector.

Document everything in a shared runbook. Boot sequence, calibration steps, network configuration, known issues with workarounds. When the team member who wrote the perception node catches food poisoning the night before finals, the runbook is what saves you.

How educational platforms shorten the learning curve

Teams entering their first competition often underestimate how much time goes into building a reliable mobile base before any autonomy work begins. Locomotion, power management, sensor mounting, and ROS 2 driver integration can consume an entire semester. Starting from a documented, supported platform shifts that time toward the parts judges actually score: perception, planning, and task execution.

Fictionlab's work in this area is documented under educational and research applications, where Leo Rover is used by university teams as a baseline UGV for ROS 2 development. For teams with payload requirements or mission profiles that exceed a standard platform, custom robotics development covers modified chassis, specialized sensor integration, and tailored compute configurations.

Frequently asked questions about robotics competitions

How early should you start preparing for a robotics competition?

For a serious entry in a field robotics event, six to nine months is realistic. The last two months should be spent almost entirely on integration testing and field trials, not on new features. Teams that are still writing core autonomy code one month before the event rarely finish their runs.

Is ROS 2 a requirement for most robotics competitions?

Not formally, and not universally. ROS 2 is common in many university-level and research-oriented events, especially with current LTS releases such as Humble or Jazzy, and many reference implementations, simulators, and sensor drivers support ROS APIs. Using a different middleware is possible but can increase your integration burden.

What is the single most common reason teams fail a scored run?

Network or power issues, not algorithm failures. Wi-Fi drops, batteries discharging faster than expected, or a loose power connector after transport account for a disproportionate share of did-not-finish results.

Should you build your own robot or use a commercial platform?

It depends on what the competition scores. If the rules reward mechanical innovation, build. If they reward autonomy, perception, or task execution, starting from a proven platform lets you spend your time where points are awarded. Many successful teams use commercial bases with custom payloads.

How do you handle a complete robot failure during the event?

Have a documented recovery procedure: which SD card to reflash, which calibration files to restore, which connectors to check first. Practice this procedure under time pressure before the event. A team that can recover from a brick in 20 minutes will outperform a team that cannot.

What sensors are most worth investing time in for outdoor competitions?

An IMU with good bias stability, a stereo camera that handles sunlight (global shutter is strongly preferred), and either RTK GNSS or a 2D/3D LiDAR depending on whether the arena is open or structured. RGB-D cameras can be useful, but many depth technologies degrade in direct sunlight and should be validated outdoors before the event. Spend calibration time generously - poorly calibrated good sensors lose to well-calibrated cheap ones.

How important are practice runs at the actual venue?

Critical. Lighting, surface friction, GNSS visibility, and radio interference cannot be replicated in your lab. Use every practice slot the organizers offer, record bags of everything, and treat the first scored run as if it might be your only one.

Where to go next

If you are building a team for an upcoming competition and want to start from a tested ROS 2 platform rather than from raw aluminum extrusion, explore how Leo Rover is used in academic and competition contexts on the education and research applications page. It includes references to university programs, supported ROS 2 distributions, and integration examples that map directly to the categories most competitions score.