RAI Institute

The Role

What I did

The Robotics and AI Institute runs a floor of robot research stations, each one set up by and for the researchers working at it. My job was to keep those researchers moving: answering questions, helping people get their work running on the stations, and troubleshooting whatever came up day to day.

The support work kept surfacing the same underlying problem: every station had drifted into its own configuration, so what worked at one bench didn't work at the next. Alongside the support role I picked up side projects aimed at that: making the development environment consistent enough that researchers could move between stations without relearning them.

Project 01

Robot Station Monitoring

There was no shared view of station health. If a station went down, we found out when a researcher walked over to say so, which meant the clock on any given outage started well after the outage did.

I built an API tool that collects internal statistics from each station's computer and reports them to an internal website showing the status of every station at a glance, along with any errors it had thrown. What had been a walk down the hall became a page anyone could open.

20%increase in research station uptime

Catching failures as they happened rather than after the fact raised uptime at the research stations by roughly 20%, and researchers spent measurably less of their day waiting on a bench to come back.

Project 02

RaiLabs 3

Each station carried its own proprietary variables and setup. That made working across stations genuinely difficult: moving to a different bench meant rediscovering which values it expected, and a bad change had no obvious way back.

I contributed to RaiLabs 3, the internal variable and configuration tooling built to solve exactly this. It gave every station a common place to manage its settings, so the differences between benches became something you could read rather than something you had to learn.

The part that mattered most in practice was history. RaiLabs 3 tracks previous versions of the configuration files and internal API keys a station depends on, so a researcher who breaks their environment can roll back to a known-good state instead of rebuilding it. Consistency across the floor stopped being a convention people had to maintain by hand.

Project 03

Spot Documentation

Getting started with Spot was the other recurring question, and the answer lived mostly in people's heads. New researchers were relying on whoever happened to be free to walk them through it.

I rewrote the onboarding documentation for Spot so that path was written down: what to set up, what to run, and what to expect, in the order you actually need it. The goal was for someone new to get from arriving at a station to doing real research on Spot without needing to find me first.