You are here

Notes on Uber's "Please take us back" safety plan

Topic: 
Uber tech at work on car fleet

reported earlier, Uber released a series of documents detailing safety strategy. It's their effort to restore their image in the world and get back on the road.

Most of this document is effectively a "How to build a robocar 101" without special relevance to Uber. It's what other teams are doing too, and most of it is fairly obvious. In the important section on safety drivers, they do concede they made an error going to just one, and describe how they are fixing that and how they are now screening applicants. They don't want to say "mea culpa" too much, so in only a few cases do they identify a change in policy, including:

  • Sticking with two safety drivers
  • Upgrading the type of person hired to be a safety driver (mission specialist) and having a stricter hiring process
  • Putting in attention monitoring on the "pilot" driver behind the wheel, and warning them -- and alerting HQ -- if they don't pay attention.
  • Lower latency in the processing pipeline, and higher priority for more important obstacles detected
  • Internal and External safety audit, and new safety advisory board
  • Stronger internal safety culture and regular safety standups, briefings and training for all staff
  • Always on automatic emergency braking through an external system. This might be the built into Volvo citysafe -- normally teams disable any built in systems of this sort since they are replacing them.
  • Better model of uncertainty in future path predictions for moving obstacles
  • Better perception in general

How many safety drivers is the right number?

An interesting question that I've avoided asking is, "What is the right number of safety drivers?" Almost everybody settled on two, because there are two front seats in a car. The passenger seat occupant usually has a focus on the diagnostic displays of the software system, making sure nothing odd is going on there, but also sometimes looks out the window and keeps the main driver on task.

I am loath to suggest this in some ways, because I don't want to drive the cost of testing up beyond the reach of small teams, but technically there could be more than two. You could have two more in the back seat, or even 4 more in a minivan or SUV. The rear seat crew could get monitors or even VR headsets showing views from cameras on the roof -- in some ways a better view than the main driver behind the wheel has. You could have one dedicated to looking right and another dedicated to looking left. This is also a good place for people monitoring the software, leaving the front seat for somebody also watching the road.

This is overkill, however. Aside from being expensive, it also eliminates seats for giving important demonstrations and eventual pilot projects with actual passengers.

With good radio spectrum, you could even have remote workers watching the view in VR headsets. With dedicated spectrum and a suitable radio tower in the test area, very low latency could be attained. That could allow an arbitrary number of drivers. Even without radio towers, test vehicles could be followed by chase vehicles, with one real driver and 7 additional people watching live video streams sent over line-of-sight radio or optical links. With the low latency, an operator in a chase car could actually even remotely control takeovers, but you would not want two people to try to take over at once, of course. The use of a chase car might be a reasonable strategy for testing unmanned cargo vehicles that can't fit a human safety driver.

Other document notes

The document is long, but contains a few surprise omissions. This does not mean Uber doesn't do them but it elected not to enumerate them.

If the driving system fails so badly that the system reverts to manual control by the safety driver, it gives a visual and audible alert. But what happens when it detects a safety risk but is still in control? The most extreme example of this is the need to emergency brake during the fatality -- the car finally figure out it should do this, but did not since that function was not working well enough to be enabled. Yet it also did not take the effort to inform the safety driver of the problem with noise or even a short brake jab.

Pilot surveillance

Uber's new system has driver monitoring. This is good, and it sends an alert to the driver if they get distracted. It also sends an alert to a remote team. This seems smart but could backfire. Extreme monitoring of employees is known to sometimes lead to fear and attempts to bypass the system. They should watch for that. No human can keep constant attention. The system should plan for this. Pilot drivers should even be encouraged to take brief "eye breaks" with the co-pilot warned and on the lookout, during safe times, and this should not count against them, or cause alert back at HQ. HQ should be informed only when a driver is performing below some expected performance level, not when they are below perfect.

Reverting to manual

Like many other vehicles, the system switches into manual drive if the pilot driver touch anything, in particular the brake or throttle. It turns out that Waymo's experience suggests this is a mistake, that a switch to manual should require that hands are on the wheel. Waymo had a safety driver fall asleep -- this can happen -- and accidentally brush the pedals with his feet. This caused a full disengage, and now the car had nobody at the controls. If a car gets disengaged but nobody is grabbing the wheel, the car should retain control of the wheel to keep in the lane until some other signal arises. Of course the driver attention monitor can also help here.

Logs

It looks like they have included a system to upload logs after a crash. After the Tempe fatality, their vehicle was confiscated by police, and they were not able to get their logs until much later. NTSB prefers to keep the vehicle operator out of the investigation and so doesn't mind if they are in the dark.

Security

The car has communications between domains, which should be kept to an absolute minimum (and eliminated wherever not essential.) They claim attack surface minimization. That's good, and since there is as yet no V2V or V2I there is no need to say that they have eliminated them, but it would be good if they did.

Metrics and review

They do agree that bad metrics (such as pure disengagements) can incentivize the wrong things.

Uber did an internal and external safety review. The external review was via a law firm but may have included some technical consultants, or so I hope.

They have a new advisory board. They never called me! (I have advised Uber ATG before but the people there I knew are mostly gone.)

Latency

The recommendations included improving latency. This leads one to believe they possibly had a very poor latency before, which could explain some of the failures in the fatality. They have also improved their velocity estimation -- which was the key thing that failed from a technical standpoint in the fatality. The system did not discern the pedestrian was on a collision course with their path until very late.

Overall

Uber knows what to say here. Have they really changed their tune? Only somebody inside can tell. Sometimes, after a plane crash, the safest airline to fly is the one that had the crash, because they have received a wake-up call. Sometimes, it's a sign to stay away from that airline.

Comments

> one dedicated to looking right and another dedicated to looking right

Did you mean "and another dedicated to looking left" ?

Add new comment

Subscribe to Comments for "Notes on Uber's "Please take us back" safety plan"