Hacker News Reader

Comment by WalterBright | Hacker News Reader

I'd like to know what those autodrivers do for failsafety. What about software crashes? bugs? sensors giving bad readings? intermittent loose connections? chips failing?

They should at least talk to the engineers who design airplane autopilots, who know how to deal with that stuff.

View on HN

In that same vein but perhaps more subtle, what of the social failsafes? I keep imagining this scenario (one which I run into consistently in the Bay Area), where I am looking to merge into the lane to my left because my lane has ended, and nobody will fucking let me in. Does the automatic driver have a level of aggressiveness that it follows? What if two automated drivers have the same level of aggressiveness and one wants to merge and the other won't let it? Do they just stop, resigning themselves to an endless loop of near catastrophe because neither will yield? I'd love to know more about exactly by what driving conventions these automated drivers abide. I think it'd go a long way to help people understand how such a process could be automated at all.

Can Google cars even change lanes at all?

This was a basic requirement of the Urban Grand Challenge... in 2007.

What about policeman directing traffic with hand signals ?

I'd guess that if both cars are automated, there will likely be some type of vehicle to vehicle negotiation process between them to determine who has the right of way.

What do people do when their cars fail or there are drinks behind the wheel? I agree with what you're saying sort of but there are very serious people working this technology (it's not just Google) but there will be accidents but much less than with human drivers. It may seem fantastic but if you actually look at the current state of the technology and even conservative projections by people like the Economist ... It's quite impressive.

> They should at least talk to the engineers who design airplane autopilots, who know how to deal with that stuff.

What leads you to think they don't?

Exactly. This sort of thing is what embedded programming is all about. "Real Time Computing" is the relevant keyword.

Just like a frontend dev learns HTML/CSS/JSframeworks and a backend dev learns JSframeworks/Node/(no)SQL, embedded developers learn about creating real-time, fault tolerant, highly recoverable systems.

Tell an embedded engineer that he should consult with Boeing and he'll give you the same strained smile that you would give a family member who suggested consulting with Amazon/Ebay/YouTube because "they are good at making websites."

> What leads you to think they don't?

From what I read about the Deepwater Horizon design, and the Fukushima design, neither followed basic failsafe design principles.

From what I read about the Toyota "surging" issue, the throttle/braking system did not follow basic failsafe design principles.

Failsafe design principles are not taught in any engineering degree program I'm familiar with.

When I talk to other engineers about failsafe design principles, they are not aware of them.

I used to write embedded firmware for factory machinery, and I can tell you that there are a few obvious nuisance bugs in my car's firmware. The kind of things that probably wouldn't be present if they had even owned or driven the car.

Cars already failsafe or just stop in the middle of the road due to chips failing http://www.recalls.gov.au/content/index.phtml/itemId/1051195

Just stopping in the middle of the road is often a terrible mistake.

Reply on news.ycombinator.com