I suspect that Uber was optimizing for the common case, which is normal traffic conditions, and didn't want their emergency braking accidentally firing during normal driving causing rear endings.

So the question becomes why couldn't they get emergency braking solved before driving on the road? Maybe that requires collecting good data first, for training the system?

You don't make things safe by optimizing for the common case, and "it can't be safe until after we have tested it on the road" is not a valid reason to allow testing of an unsafe vehicle on public roads.

Considering that 1) you are supposed to keep sufficient distance to break even if the vehicle/generic object in front of you suddenly freezes in space, e.g. a massive wall flush with the rear end of the vehicle in front of you suddenly appears, and 2) the only things that could conceivably rear end an emergency breaking Uber/Volvo would be bikes and other >=4 wheel vehicles (cars/trucks/etc.), which either drive carefully anyway ((non-)motorized bikes), or have a low probability of human damage (cars/trucks), false positives should be preferred to false negatives by somewhere between 5:1 and 1000:1. The latter only if the following vehicles are civilized enough to hold the distance. The car could figure this in, and computer probabilities for what damage an emergency maneuver would cause, which means that it'd break for a stray cat if it's otherwise alone on the road and the surface is dry. But it won't break for a wolf if it's tailgated by a truck, but potentially even accelerate, to make up for the loss of momentum (but light the rear break lights, to stop as soon as it registers the truck to slow down).

b r a k e

> I suspect that Uber was optimizing for the common case, which is normal traffic conditions

That's like creating HTML forms that only work with the common use case and crash spectacularly on unexpected input. Except that this time it's fatal. That's not the kind of software quality I want to see on roads.

Why not license the software system from Volvo, which obviously works (people drive Volvos with this turned on every day without erratic breaking), instead of disabling theirs because it was apparently broken?

This is beyond incompetence. There is a different level of software engineering when making a website vs making a pacemaker, rocket or flight avionics. You need the quality control of NASA, SpaceX or Boeing, not that of .. whoever they have running their self driving division.

I have a Subaru with EyeSight and it does strange things sometimes. For example, if I happen to be in the left (passing) lane going around a leftward curve and a car in the right lane is stopping or slowing to turn right, the Subaru will hit the brakes because due to the curve of the road, the right lane car is straight ahead. It's scared me a few times.

The other thing about the system that sucks is that it's all optical (AFAIK) so when visibility is poor, it shuts off. They need to add more sensors because those are the conditions I would most like an extra set of eyes.

Goddmn right : if the things brakes erratically then, come one, it's not ready to brake !!

s/not ready to brake/not ready to drive/

> I suspect that Uber was optimizing for the common case

Yeah that's not how you design safety critical software. This isn't some web service. Either you're wrong (let's hope) or Uber is completely negligent.

Source: I write safety critical code for a living.

> didn't want their emergency braking accidentally firing during normal driving causing rear endings.

In no case would sudden braking be the cause of a rear-end collision. It's always the fault of the driver behind.

True, and I'm with you, though I'd bet every dollar I have that, if people routinely randomly slammed on their brakes we'd have a whole lot more rear end collisions. We don't expect people to do that, and when it does happen it's rare.