FTC Robotics — Intellibots Academy

From 2023 to 2025, I was part of Intellibots Academy’s FTC Team 27076, and eventually became Team Captain. On paper it was a competition robot. In practice, it was a full engineering project — design, software, controls, testing, and strategy all living in the same machine.

We built on the FIRST Tech Challenge Android stack and the FTC Robot Controller 10.2 SDK (the 2024–2025 INTO THE DEEP release). The SDK handled the base control layer; our team wrote the robot-specific code and OpModes on top of it.

I worked across both sides of the robot: programming, mechanical design, CAD, autonomous behavior, debugging, and a lot of iteration. In competition robotics, those pieces don’t stay separate for long. A mechanical change can break control assumptions, and a software goal can force a redesign.

Building the mechanical side

On the mechanical side, I helped take mechanisms from a rough idea through CAD, fabrication, assembly, testing, and redesign. CAD wasn’t just for pretty pictures — we used it to work out clearances, mounting, and how parts would interact before we trusted them in a match.

The chassis was compact, so everything had to earn its space. We spent time on linkage geometry, motor placement, gear ratios, rigidity, cable routing, sensor mounts, and making sure moving parts didn’t collide.

The real work was iteration. We’d build something, run it, find what failed, then fix the CAD and try again. A mechanism that worked once on the practice field wasn’t good enough if it couldn’t survive a full match day.

Mechanical choices also shaped the software. Sensor placement, encoder alignment, drivetrain geometry, and hard stops all affected how accurately we could control the robot — so hardware and code had to stay in sync.

Writing the software

A big chunk of my work was on the software side.

We didn’t want every match to depend on perfect human driving. The code was written in Java inside the FTC environment, structured around OpModes, hardware abstractions, sensor feedback, motor control, and autonomous routines that could behave the same way run after run.

The hard part wasn’t flipping a motor on and off. It was coordinating actuators, sensors, drivetrain state, and autonomous steps as one system.

That meant dealing with initialization, encoder feedback, power and position targets, timing, state changes, telemetry, calibration, and the weird edge cases that only show up on a real robot — battery sag, backlash, wheel slip, and localization drift.

Everything lived in one shared repository, so the team always had a single place for the robot controller code as the season moved forward.

Making autonomous reliable

Autonomous was where we put a lot of engineering time.

We didn’t want a brittle sequence of “drive for X seconds.” We wanted the robot to know where it was on the field and use that to hit the same paths and actions repeatedly.

Odometry was the backbone. Encoder data helped estimate pose, so autonomous routines could think in field coordinates instead of pure timing.

That let us aim at points and goals on the field — move toward a known location — rather than hoping a timed push landed in the right spot.

We spent a lot of time tuning how encoder readings mapped to real motion so trajectories stayed consistent instead of drifting halfway through a routine.

We also tried some machine-learning experiments around point selection and autonomous behavior. The idea was to help the robot choose targets more intelligently on top of the localization and path system, not replace them.

By the end of the season, autonomous was one of the strongest parts of the robot. Positional targets made match performance feel a lot more predictable.

Odometry and knowing where we were

Odometry turned into one of the most important systems on the robot.

In simple terms: encoders measured movement, and that became an estimate of X, Y, and heading on the field.

Once we had that, higher-level autonomous logic got much easier. We could ask where the robot was, where it needed to go, and how to correct along the way — instead of stacking raw motor powers into a fragile path.

Calibration mattered. Wheel size, tracking-wheel placement, mounting tolerances, and heading estimates all add error over time. We treated localization as something to measure and tune, not a checkbox feature.

The payoff was autonomous code that could work in field coordinates while the localization system absorbed some of the messiness of real robot motion.

Navigating with points

A pattern we kept coming back to: work with points and coordinates, not just a long list of motor commands.

A target was a place on the field. The software figured out how to get there.

That made the code easier to grow. If a scoring location moved a few inches, we could update the target without rewriting the whole routine from scratch.

Tuning got simpler too. Change the coordinate, retest, keep the rest of the sequence intact.

In practice, the field became a coordinate space and the robot became a mobile system moving through it.

Closed-loop control

We also leaned on closed-loop control instead of blindly commanding motors.

Encoder feedback told us whether an actuator actually reached its target. On a real robot, sending a command and getting the physical result are not the same thing.

Control logic had to balance target vs. current position, error, motor response, and how the mechanism actually behaved under load.

That mattered most in autonomous, where small errors stack up quickly if you ignore them.

Tuning always happened on the real hardware. We watched how the robot responded and adjusted from there, instead of assuming an ideal math model.

When software and hardware collide

One of the best (and hardest) parts of FTC is that software bugs are often mechanical, and mechanical issues often look like software.

Bad localization might be calibration, wheel slip, drivetrain geometry, a loose mount, or a wrong assumption in code. An actuator that never lands in the same place might be control, backlash, torque, or something physically in the way.

Debugging meant thinking about the whole chain:

• Sensor reading
• Data and filtering
• Control algorithm
• Motor command
• Mechanical response
• Feedback back into the sensors

That systems view was one of the biggest technical lessons I took from the project.

Test, break, fix, repeat

Development was a loop more than a straight line:

• Design
• CAD
• Build
• Program
• Test
• Measure
• Diagnose
• Redesign

We tested individual mechanisms and the full robot. Telemetry and controlled runs helped validate software; autonomous got judged by how consistently it hit the same spots over and over.

When something failed, we tried to find the real cause instead of papering over it in code.

That meant a lot of back-and-forth across mechanical and software. Reliability beat a perfect-on-paper design every time — something that works once and flakes in a match isn’t useful.

Working in a real codebase

Robot software lived in a GitHub repo based on FTC Robot Controller 10.2. That kept our team code organized and separate from the underlying SDK.

It felt different from one-off school assignments. The codebase had to stay usable while we kept adding routines, mechanisms, hardware configs, and control changes.

Organization, maintainability, and careful iteration mattered as much as any single feature.

Leading the team

As Team Captain, I wasn’t only writing code or designing parts.

I helped keep mechanical and software work moving together across a long season with a six-person team. Everyone had their lane, but it still had to become one robot — so subsystem choices always had ripple effects.

I helped steer design, prototyping, testing, and priorities: what to fix now, what would actually help in competition, and where extra polish wouldn’t pay off.

We qualified for regionals and kept pushing toward the World Championship path, and earned Judges Award and Motivation Award recognition along the way.

What stuck with me

The biggest takeaway: on a real robot, disciplines don’t stay in neat boxes.

Code depends on mechanical design. Localization depends on wheel geometry. Autonomous depends on calibration. Reliability depends on how the robot is actually built.

I learned how to take a rough idea and turn it into something that has to perform under time pressure and physical limits.

I also learned that the first version is rarely the right one. The useful skill is noticing what’s wrong, figuring out why, changing the right thing, and testing again.

FTC gave me hands-on experience with software architecture, autonomous robotics, odometry, feedback control, sensors, CAD, prototyping, Git, debugging, and system integration — all forced to work together on one machine.