Competition / Aug 2026 to Present
Intelligent Ground Vehicle Competition 2027
Leading ROS 2 software for perception, localization, planning, and control on an autonomous ground vehicle.
Gallery
Overview
I lead software for our Intelligent Ground Vehicle Competition entry, an autonomous ground vehicle that has to navigate a marked outdoor course without a driver. The software stack is built on ROS 2 and covers perception, localization, planning, and control.
This is current, active work. The vehicle and its software are still being developed toward the 2027 competition, so this page describes the role and the approach rather than a finished result.
The problem
An autonomous ground vehicle has to answer four questions continuously: what is around me, where am I, where should I go, and how do I get there. Each question has its own failure modes, and each one’s output becomes the next one’s input.
The competition course adds constraints that a lab environment does not. Lane markings have to be found in real outdoor lighting. Obstacles appear with no advance notice. The vehicle has to keep moving while all of this happens.
Approach
The stack is organized around the four questions, so that each can be developed and tested without waiting on the others.
Perception uses cameras and OpenCV to find lane markings, and 2D LiDAR to detect obstacles in the vehicle’s path. Localization fuses IMU data with the rest of the sensor set to maintain an estimate of where the vehicle is. Planning turns that picture into a route the vehicle can actually follow. Control converts the plan into commands the drivetrain executes.
Building on ROS 2 means these run as separate nodes with defined message interfaces between them, so a change in how lanes are detected does not require changing how the vehicle drives.
My role
As Software Lead I am responsible for how these pieces fit together and for the interfaces between them. That includes deciding what each subsystem is accountable for, keeping the boundaries between them stable enough that people can work in parallel, and making sure the integrated system is testable rather than only its parts.
Current state
Development is ongoing. Perception, localization, planning, and control are being built and tested against the competition requirements, and the team’s source is currently private.
What I am learning
Leading the software rather than writing one piece of it changes what matters. A subsystem that works alone but publishes at an unexpected rate, or assumes a frame nobody else uses, costs the team more than a subsystem that is merely unfinished. Most of the work is keeping the interfaces honest so that integration is not a separate phase at the end.