Vladimir Arustamov
A pedestrian in dark clothing steps into a poorly lit road. An autonomous car has to spot the person, work out where they might move and decide how to respond. There is no time to ask for a better view.
Vladimir Arustamov sat down with NVIDIA system software engineer Anwesha Kar. She works on DRIVE OS and spoke about how self-driving cars handle uncertainty. The conversation went from a noisy hardware lab to the question of what it takes to put robotaxis on ordinary streets.
What's in the conversation
Kar talks about the work on both sides of a driving decision. That starts with keeping the vehicle computer running and extends to testing how it reacts when the road surprises it.
- What a vehicle computer looks like on an engineer's desk
- Why a pedestrian in dark clothing is a harder test than a clear road
- What NVIDIA's 34-billion-parameter Alpamayo 2 Super does during development
- How simulation lets engineers test what happens after the car makes a decision
- Why a robotaxi pilot tells you only so much about deploying a fleet
A chatbot can give you a bad answer and you can ask it again. On the road, the first answer might already have moved the car. Kar uses that difference to explain why a good average can tell you very little about the moment a driving system gets wrong.
Inside the hardware lab
Kar describes a desk with an electronic control unit on it and fans loud enough to make the office sound like a hardware lab. Before a driving model can make a decision, the computer that runs the vehicle software has to start up and behave predictably.
Coding agents now sit alongside that hardware. Kar describes leaving an agent running to investigate a problem while she sleeps. The next morning, there is still a physical system on the desk and an engineer who has to check whether the proposed fix works on it.
The pedestrian the car has to see
Kar asks what happens when a pedestrian is wearing a black dress in low light. That changes a familiar scene in a way that matters. The person may be harder to distinguish from the background, but the car still has to decide how to move.
The question also changes when there is no steering wheel. In a driverless ride, the passenger has no wheel to grab if the vehicle encounters something it cannot handle. The response to uncertainty has to be part of the system the passenger gets into.
Anwesha Kar on detecting a pedestrian in low light. Source: thehype talks.
What Alpamayo adds to the decision
Kar describes Alpamayo as a turning point for the way her field talks about reasoning. Her example is a driving model that can use what it sees to infer a risk and plan a trajectory around it. Those are two separate jobs. A system can recognize an object and still choose a poor path around it.
NVIDIA describes Alpamayo 2 Super as an open, 34-billion-parameter model that reasons over surround camera views and can produce future trajectories. NVIDIA positions it as a teacher model for developing smaller models that can run in the vehicle. That distinction matters when reading a demo. The full development model and the software a passenger rides with are different parts of the pipeline.
Testing the decision after the car makes it
A recording can show how a car arrived at an intersection. A simulation can ask what happens next if it brakes sooner, moves forward or takes a different path. In a closed-loop test, the system's action changes the scene it gets back. Engineers can then see what that choice does over the following seconds.
NVIDIA's AlpaSim provides the simulated driving environment. AlpaGym runs driving policies in that environment and uses the resulting drives to train them. Kar brings up these tools while explaining how a model moves from seeing a situation to learning what to do in it.
The city that comes after the pilot
In the longer conversation, Kar also imagined how vehicles could share observations that help cities plan their roads. In the interview above, she contrasts two approaches to deployment. In her telling, the Gulf starts with building smart infrastructure. India starts by making autonomous systems work on the streets that already exist.
Those are perspectives she draws from the conversation around deployment, rather than fixed rules for either region. They expose a choice that matters to builders. How much should the vehicle be able to handle on its own, and which problems are easier to solve when the city can help?
Why mostly correct won't be good enough
A robotaxi may run well in one pilot city. Moving from that pilot to millions of cars means encountering more combinations of roads, lighting and human behavior. The night-time pedestrian is one of those combinations. The next city will have others.
“Mostly correct won't be good enough,” Kar says. Her point for founders is to start thinking about what a failure does when it leaves the demo. A result that looks strong on average can still hide the situation the team most needs to test.
What we took away
The hard part of autonomy is what happens between seeing something and moving the car. A trajectory makes the decision concrete, and a closed-loop simulation gives engineers a way to follow its consequences.
The first city is also a test of what might transfer to the second. A team needs to understand which decisions its system handles well, what conditions it relied on and what changes once the car goes somewhere new.
Chapters
- 00:00 Highlights
- 00:22 Meet Anwesha Kar
- 01:25 Inside the hardware lab
- 02:46 How engineers assess safety risks
- 04:54 What happens when a feature fails
- 06:24 Driverless taxis and edge cases
- 07:31 What Alpamayo adds
- 09:14 Testing in simulation
- 10:24 Two approaches to deployment: Dubai and India
- 12:30 From one pilot city to millions of cars
- 13:57 Would you take a driverless taxi?
