Skip to content
Saim Hashmi

Leading software at Autonomous Robotics Carleton

2026-01-31

What I did as software development lead on Autonomous Robotics Carleton's car, July 2025 to January 2026: ROS2 latency work measured in Grafana, Docker-based CI, and onboarding 20+ contributors.

Leading software at Autonomous Robotics Carleton cover

From July 2025 to January 2026 I was software development lead at Autonomous Robotics Carleton (ARC), a student team that builds an autonomous car. My area was systems and tooling: the ROS2 perception and navigation stack, and the infrastructure the rest of the team built on.

The latency work

The car's perception and navigation stack runs as separate ROS2 processes that pass messages to each other. Every hop adds delay, and in a moving vehicle delay is a safety problem, not just a performance one.

I worked on cutting inter-process latency using concurrent programming in C++ and Python. The result was a 15% reduction, measured in Grafana.

The measuring part matters as much as the result. "Faster" is only a claim until latency is plotted over time. A graph lets you change one thing, check it, and keep or revert the change, and it gives the team a number to trust.

Docker CI and review

A student team's codebase grows through pull requests from people with very different experience. Without checks, the main branch breaks and nobody knows whose change did it.

I introduced Docker-based CI, enforced code review, and pushed test coverage up across contributor PRs as the codebase grew. Running CI in a container means the build is the same on a laptop and on the server, and a new member does not have to install the exact ROS2 setup by hand to find out if their change works.

Contribution standards and docs

The part I would do again first is the documentation. I defined contribution standards and maintained centralized docs. Together with the CI, they onboarded 20+ new contributors.

Those two things work together. Docs tell a new person how to contribute. CI tells them quickly whether they did it right. Take either away and the lead becomes the bottleneck, answering the same questions and checking the same mistakes by hand.

Two presenters at a lectern in front of a chalkboardThe Git workshop ARC ran with SCEsoc.

What I learned about leading

I was the lead, but most of the useful work was making myself less necessary. Standards, checks and docs scale. My attention does not.

The lead role covered both kinds of work: performance in the stack, and the process around it. Telling which one the team needs most at a given time is the skill.

Where this fits

This work is a big part of why I'm aiming at systems, DevOps and developer tooling roles. The ROS2 and C++ experience carried straight into my later robotics project, BOOPBOT, which runs ROS2 on QNX.

My time as lead ended in January 2026.

That's the whole story.

Liked it?

Say hi, I'm open to new-grad roles from summer 2027.

Something off?

Tell me and it gets fixed tonight.

← All writing