Proving a robotaxi can see a red light

Argo AI was one of the leading robotaxi companies in the world, funded by Ford and Volkswagen — two of the largest vehicle manufacturers there are. I was there for seven months. It is the shortest role on this timeline and one of the most formative.

The first thing that struck me was the scale of the systems organisation. Hundreds of systems engineers, distributed evenly around the V, with separate departments for the individual spaces. Somebody owned the problem space. Somebody else owned verification. Nobody was doing all of it at once, and after a startup where I had been the eleventh person in an office, that was a revelation about what a mature systems organisation actually looks like.

One sub-claim

I was part of a validation team working on perception functions, led by Brent Tweddle — a formidable mind and a generous mentor, and someone I count myself lucky to have worked for. My task was to develop the metrics for traffic light detection and classification.

Stated that way it sounds narrow. It is not, and the reason is the safety case.

Somewhere near the top of that argument sits a claim to the effect that the vehicle does not run red lights. That claim does not belong to any one team, because nothing in the system is solely responsible for it. It decomposes. Perception has to see the light and classify it correctly. Planning, which consumes perception’s output, has to do the right thing with what it is told. Each half becomes a sub-claim, and each sub-claim needs its own evidence.

My work was the perception half of it: the pipeline that automatically produces the objective evidence that the perception stack’s accuracy on traffic lights is sufficient for the driving task.

Evidence at fleet scale

The input was data from hundreds of robotaxis driving in multiple cities across two continents, and being the consumer of that much data changes how you think about the question.

A test tells you what happened in a case you chose. A metric over a fleet tells you what is true across a population you did not choose, including the cases nobody would have thought to construct. That distinction is the whole reason metrics exist, and it is why they answer the question a test cannot: not did it work here, but is it good enough, generally, now.

The deadline is what makes it real. These metrics evaluate a new software release before it goes onto the road. The pipeline is not a report you write afterwards; it is a gate that a release either clears or does not, and the thing on the other side of the gate is a vehicle at a junction with nobody in the driver’s seat.

Where a lot of my present tense started

This was my first contact with three things I now work with every day: Jama, a safety case, and metrics as objective evidence rather than as reporting.

It was also the first time I worked inside an established process rather than inventing one. Clear guidelines, defined interfaces between teams, a place where each artefact belonged. I did not appreciate at the time how much I was absorbing — that came later at Plus, where the technical compliance function, the release process for TRATON and eventually the V&V strategy all had to be built rather than joined. Learning the discipline somewhere it already existed is a very different thing from having to derive it, and I had the luck of doing them in that order.

The end

Argo was shut down not long after my work had begun to reach the product. Ford and Volkswagen ended their investment, and a company with hundreds of engineers and a fleet on two continents stopped existing.

That is a strange thing to have on a CV, and it taught me something no technical problem would have: a programme’s survival is not a function of its engineering. The work was good. The people were exceptional. It ended anyway, for reasons decided several floors above the systems organisation.

I took the learnings and went to build the same disciplines somewhere they did not exist yet.