Building an FTC Robot That Can Navigate Obstacles

Building a robot that can navigate obstacles is one of the most rewarding engineering challenges in FIRST Tech Challenge. A successful FTC robot must do more than drive from one point to another: it needs to detect barriers, select a route, recover from mistakes and complete game tasks within a limited match time.

The best solutions combine mechanical design, sensors, software and driver practice. A low robot with dependable wheels may outperform a technically impressive machine that catches on field elements. Teams should therefore treat obstacle navigation as a complete system rather than adding a distance sensor at the end of the build season.

Australian teams face practical conditions that shape their design choices. School halls in Melbourne, Sydney or Brisbane may have polished floors, changing light levels and limited setup time. Teams often transport equipment in cars or trailers, work around school terms and order specialised parts from overseas, where shipping delays, exchange rates and GST can affect the build schedule.

Safety and organisation matter as much as performance. Young people should work under suitable adult supervision, follow their school or venue risk procedures and use appropriate electrical practices. Where mentors work directly with children, Working with Children Check requirements can apply according to the state or territory. Safe, documented processes create a better environment for experimentation.

Start with the field and the route

Before selecting sensors, study the FTC field as a collection of spaces, surfaces and decision points. Mark the robot’s width, turning radius and maximum extension on a field diagram. A route that appears open to a student may be impossible once the robot’s intake, lift or alliance partner is included.

Divide obstacles into categories: fixed barriers, low lips, narrow gaps, movable game pieces and traffic created by other robots. Each category calls for a different response. The robot might drive around a wall, strafe through a gap, raise an attachment above a barrier or pause until a safe route becomes available.

A useful first prototype is a simple chassis with bumpers and a reliable drivetrain. Teams can test whether the robot keeps moving when a wheel meets a small obstruction, whether it can reverse without snagging cables and whether the frame remains square after repeated impacts. Robust geometry usually provides greater value than a complex autonomous routine built on an unstable platform.

Choose a drivetrain and sensor combination

Mecanum wheels are popular in FTC because they allow forward, sideways and diagonal movement. That flexibility can help a robot avoid an obstacle without making a large turn. However, mecanum wheels can lose traction on dusty or uneven surfaces, and sideways motion may be inconsistent if the frame is not rigid or the wheels are not aligned.

Tank or six-wheel drivetrains are often easier to control and can provide predictable pushing power. They may be preferable when the field includes narrow lanes or when the robot must climb over a small change in height. Teams should measure wheel slip and turning accuracy on the actual practice surface rather than relying solely on motor encoder readings.

Sensors add information, not judgement. A distance sensor can identify a nearby wall, touch sensors can confirm contact, and an IMU can help maintain a heading. An odometry system using encoder pods can estimate position, while a camera may recognise field markers or game elements. Sensor fusion is stronger than depending on one reading: combine encoder movement with heading correction and a physical check before committing to a tight manoeuvre.

Australian venues may have bright sunlight through windows or inconsistent artificial lighting, which can affect optical sensors and cameras. Place sensors where they are protected from game pieces, test them at different heights and backgrounds, and include a fallback behaviour if a reading is missing or unreasonable.

Build autonomous behaviours that recover

A basic obstacle-avoidance routine can follow a clear sequence: drive towards a target, monitor a sensor, slow down near the obstacle, choose a direction, move around it and confirm that the path is clear. The software should use timeouts and maximum travel limits so that a faulty sensor cannot leave the robot driving indefinitely.

State machines work well for FTC autonomous programs. States such as “approach,” “check,” “detour,” “reacquire target” and “finish” make the code easier to test than a long block of nested conditions. Each state should have an exit condition, a timeout and a safe fallback. For example, if the robot cannot confirm that it has cleared a barrier, it can reverse to a known position instead of continuing blindly.

A practical example is a mecanum robot approaching a wall before placing a game element. The robot can use encoders for the main drive, an IMU to hold its angle and a side-facing distance sensor to maintain clearance. If the sensor reports that the wall is closer than expected, the robot reduces speed, strafes a measured distance and checks its heading before continuing.

Teams can also learn from public communication as well as technical documentation. A clear team press release can explain how students solved a navigation problem, helping sponsors, families and new members understand the engineering behind a match result.

Test for repeatability and safety

Obstacle navigation should be tested as a repeatable experiment. Change one factor at a time: surface, battery charge, obstacle position, speed or starting angle. Record the result in a notebook or shared spreadsheet, including successful runs and failures. A routine that works once is a demonstration; a routine that works twenty times is a competition tool.

Test at three speeds. Slow testing reveals sensor logic and mechanical interference. Medium-speed testing shows whether the robot can correct its course. Full-speed testing exposes momentum, wheel slip, loose fasteners and collision risks. Add realistic distractions such as another robot, a misplaced game piece or a short delay before a command is processed.

Students should secure batteries, protect wiring and inspect moving parts before every session. Keep hands clear during powered testing, use a controlled test area and disconnect power before changing mechanical components. Australian teams should follow venue procedures and relevant state or territory workplace and child-safety expectations, particularly when sharing a workshop with a school or community organisation.

Community partnerships can broaden access to equipment and mentoring. An organisation such as the Avalokitesvara Trust may offer a useful example of how community-focused groups support learning, service and youth development. For a robotics team, the principle is practical: define responsibilities clearly, document supervision and make technical learning available to students with different levels of experience.

Compare strategies before committing

Every navigation method involves a compromise between accuracy, cost, programming effort and resilience. Teams should select the simplest approach that meets the field requirement. A sensor-rich robot can be powerful, but extra devices create more mounting points, wiring and software conditions to troubleshoot.

Strategy	Strengths	Limitations	Suitable FTC use
Fixed timed movement	Fast to program and easy to understand	Sensitive to battery level, wheel slip and starting position	Open paths with consistent starting marks
Encoder-based driving	Measures distance more reliably than timing alone	Errors accumulate during turns and collisions	Straight approaches and repeatable routes
IMU heading control	Helps maintain a straight line and accurate turns	Can drift or react poorly to sudden impacts	Long drives and controlled rotations
Distance or touch sensors	Detects real field conditions	Readings can be affected by angles, surfaces and wiring	Wall following, stopping and clearance checks
Camera or vision system	Can identify markers and targets	Requires careful lighting, processing and calibration	Visual alignment and field-specific navigation
Sensor fusion	Combines several sources for stronger decisions	More complex to debug and maintain	Critical autonomous routes and recovery logic

Recommended build habits for an obstacle-capable FTC robot include:

• Sketch the robot’s full clearance envelope before cutting or ordering parts.
• Test the drivetrain on the same type of floor used at training and events.
• Add a manual override so drivers can recover from an unexpected obstruction.
• Use named software states, sensor limits and timeouts instead of unbounded loops.
• Keep a failure log that records conditions, symptoms and the change that fixed them.
• Design sensor mounts that can be adjusted without rebuilding the entire chassis.
• Recheck autonomous performance after every major mechanical or software change.

FTC teams in Australia can also use off-season practice to build confidence before a regional event. A team in Perth may need to plan further for travel and shipping than a team near Sydney, while a rural group may rely more heavily on online mentoring and locally available materials. These differences make modular design, spare parts and clear documentation especially valuable.

Maryland FIRST provides broader information about starting teams, mentoring, volunteering and FIRST programmes through its robotics team resources. The same planning principles apply anywhere: give students ownership of the engineering decisions, use competition rules to define constraints and turn every test into evidence for the next design choice.

A well-designed obstacle navigator is built through many small improvements. Start with a stable chassis, measure what the robot actually does, and let students refine the route through structured testing. Teams, schools and community groups can use these methods to create a robot that is capable on the field while giving young engineers meaningful practice in design, coding, collaboration and problem-solving. Explore local FIRST opportunities, connect with mentors and begin a documented build that can carry your team from its first test run to competition day.