How Autonomous Cars' Safety Features Clash With Normal Driving

An anonymous reader writes: Google's autonomous cars have a very good safety record so far — the accidents they've been involved in weren't the software's fault. But that doesn't mean the cars are blending seamlessly into traffic. A NY Times article explains how doing the safest thing sometimes means doing something entirely unexpected to real, human drivers — which itself can lead to dangerous situations. "One Google car, in a test in 2009, couldn't get through a four-way stop because its sensors kept waiting for other (human) drivers to stop completely and let it go. The human drivers kept inching forward, looking for the advantage — paralyzing Google's robot." There are also situations in which the software's behavior may be so incomprehensible to human passengers that they end up turning it off. "In one maneuver, it swerved sharply in a residential neighborhood to avoid a car that was poorly parked, so much so that the Google sensors couldn't tell if it might pull into traffic."

Comments

Programmed behaviour is programmed behaviour.

[ledow]

If the programming makes it jerk the steering away from a stationary hazard rather than, say, detect it earlier and slow down as it approaches, then it's not suitably programmed for coexistence with unexpected stationary hazards (Not even anything to do with human presence! What if that was a cardboard box and it swerved heavily in case that box "pulled out"?).

If it can't make it's way through a junction where the drivers are following the rules, that's bad programming. If it can't make it's way through a junction where other drivers don't come to a complete halt for it, it's not fit to be on the road with other drivers.

If you want a car to co-exist on the road, it has to be treated as a learner driver. If a learner driver swerved at a non-hazard, they would fail. If a learner driver refused to make progress at a junction because the masses didn't open up before it, they would fail. So should an automated car.

Unless - and this is important - you are saying that automated cars should only operate on automated roads where such hazards should never be possible and they are deliberately NOT programmed to take account of such things. Which, in itself, is expensive (separate roads with separate rules with no human drivers), stupid (that's otherwise known as a "train line", and because they can't do anything about it it will hurt more when it does happen), and dangerous (because what happens if a cardboard box blows over the automated road? etc.).

Program to take account of these things, or don't plan on driving on the road. The safety record is exemplary but equally there are only a handful of them and the eyes of the world are on them, and there are still humans behind the wheel, and even by miles travelled each one is probably dwarved by a single long-distance driver over the course of a year - and it's not hard to find a long-distance driver who's not had an accident for years.

If you're going to be on the roads, then you need to be able to take account of all these things, the same as any learner driver. Sure, you didn't hurt anyone by swerving or not pulling out, but equally - in the wording of my first driving test failure - you have "failed to make adequate progress" while driving.

A car sitting on a driveway would have an even better safety record but, in real life, it's still bog-useless compared to a human. Similarly for any automated vehicle that just stops at a junction because it can't pull out, or swerves out of the way of a non-hazard (and potentially weighs up collision with non-hazard vs collision with small child and gets it wrong).

Re:Programmed behaviour is programmed behaviour.

[Cassini2]

If it can't make it's way through a junction where the drivers are following the rules, that's bad programming. If it can't make it's way through a junction where other drivers don't come to a complete halt for it, it's not fit to be on the road with other drivers.

The problem is that people don't follow rules. We follow approximations of the rules. For instance, my driver's handbook described the correct way to deal with yielding at a four-way stop as "yield to the person on the right." For a computer, that's an obvious deadlock situation, or worse - an obvious mistake. If four cars are parked at a four way stop, and each car yields to the car on the right, then (a) a situation could occur where no one goes anywhere, and (b) if the individual cars only pay attention to the person on the right, then they could hit an on-coming car turning left, or the car on the left turning left. People process the "yield to the person on the right" rule into something much more complex.

People use a number of complex behaviours at four-way stops. Firstly, the wave of the hand, or the nod of the head to indicate that you yield to the other driver is an important signal. Secondly, in my jurisdiction, 90% of the four way stops are done on a first-come first-served basis. Lastly, and this is the bit I don't understand, often people yield to the person on the left. The actual system of navigating a four-way stop is much more complex than what an initial computer implementation might be.

Re:Poor example

[Braedley]

As it turns out, we do. A Google Self Driving Car and a cyclist on a fixed gear bike met at a 4-way stop. The cyclist was doing a track stand (staying upright on the peddles, sometimes peddling backwards and forwards a small ammount) instead of balancing on a foot. This caused the Google car to think the cyclist was going to enter the intersection after the car had started moving, causing it to stop and "wait" for the cyclist, which by this point had "stopped", which the car took to mean that he (the cyclist) was waiting for the car to go (which was actually the case), and so the car would start moving again until the cyclist started his next forward motion to balance himself.