7 ms·
The disturbing thing about this crash is that it's such a basic thing to test on a test track. A pedestrian walking in front at night, with nothing else unusual
by tlb 9y ago
The disturbing thing about this crash is that it's such a basic thing to test on a test track. A pedestrian walking in front at night, with nothing else unusual happening, should be on the list of scenarios to get 5 9s reliability on before taking it out in public.
The things you have to test in public are the complex real-world interactions, like these: https://medium.com/kylevogt/why-testing-self-driving-cars-in-sf-is-challenging-but-necessary-77dbe8345927 https://medium.com/kylevogt/why-testing-self-driving-cars-in...
- retSava 9y agoThat, and the inattentive safety driver. It's quite infuriating really, letting lose a ton and a half of fast-moving mass without even the decency of looking where it's going. There's really no excuse.
- CobrastanJorji 9y agoUnfortunately I think it's one of those things that is both inexcusable and guaranteed to happen. It absolutely makes sense to put a human in a car you're testing and don't have full confidence in yet but are sending into real traffic. Not doing so would be ludicrously negligent. However, humans simply don't maintain focus for a long period of time without some sort of extreme, years-long training. The ability of monks to concentrate on a single thought for hours is correctly seen as very, very difficult. There's no way any regular person could deal well with a scenario like "sometime in the next 8 hours, you may or may not need to smash this brake pedal with a second's notice, but other than that you have no task." That's one of the things that most worries me about "almost there" systems like Tesla's. That said, if you've decided to attempt this anyway, checking your phone is definitely not okay.
- deleted 9y ago[deleted]
- Rjevski 9y agoHowever, if the car saw the pedestrian, even as a false positive (presumably from far enough away to have enough time to brake/avoid it), I think it should’ve alerted the driver. The driver would’ve most likely started paying attention and avoided the crash.
- dllthomas 9y ago> I think it should’ve alerted the driver. I like the idea, and if these pruned false positives are rare enough I think it would be a great safety measure - you could even have the driver verbally label things, which might have both training (in the AI sense) and awareness (for the humans) benefits (https://en.wikipedia.org/wiki/Pointing_and_calling https://en.wikipedia.org/wiki/Pointing_and_calling). Note that "rare enough" needn't be all that rare, just that if it is multiple every second or something it clearly wouldn't be practical.
- mehrdadn 9y ago>> I think it should’ve alerted the driver. > I like the idea I'm not sure how well I would respond to a sudden alarm when everything has been deemed safe until a moment ago. I'd potentially need several seconds to figure out what is going on. I would hazard a guess that an approach that might be more fruitful be to have a meter that dynamically adjusts the "riskiness" of the situation between a yellow, orange, and red zone, so that the driver (a) has to pay attention constantly, (b) gets information constantly, and hence (c) has a better chance to react earlier. I know if I see a "danger meter" getting into the orange zone, I'm not going to wait until it goes into the red before I start paying attention.
- dllthomas 9y ago"I like the idea" doesn't mean I will like any given implementation of the idea - I certainly agree that there's plenty of room to get the interface wrong. I want the driver paying attention constantly, but I want them paying attention to the environment, not a meter. A periodic "things are unusually interesting, what's going on?" query seems like a way to motivate that. But any actual attempt at a solution should be validated in testing...
- SilasX 9y agoI think there's some room for improvement though. Instead of "just one human in there", they could put them out in teams of two, and have periodic "awareness checks" that you have to respond to by pressing a driving-irrelevant button.
- blattimwind 9y agoDead-man switches do not work.
- SilasX 9y agoDon't work for what purpose, according to whom? Are you sure that applies here? What I suggested there isn't really a deadman's switch ("stop if no one is around to do task x"), but something to periodically, randomly check the driver's attentiveness, and can raise a red flag if they take too long to respond. A deadman's switch is different and enforces "do X if person Y stops doing this thing at this predictable interval" -- not what I was proposing.
- blattimwind 9y agoVigilance control. But even these fail with more experienced users, similar to how alarm clocks fail some people (they wake up just enough to get up and turn the alarm off, then continue sleeping).
- SilasX 9y agoI was proposing it as a way to validate engagement by the testing teams, not the mass market.
- blattimwind 9y agoLike I said, these are especially hard to get right for frequent users, presumably your testing teams would log a lot of hours on these - just like train drivers, which have had this exact same problem.
- Lionsion 9y ago> However, humans simply don't maintain focus for a long period of time without some sort of extreme, years-long training. And anyone who's achieved this ability is unlikely to be willing to be hired as 1099 contractor for whatever low pay is being offered.
- Piskvorrr 9y agoImmaterial. "Let's keep killing bystanders, that's cheaper" is a good way to rouse a mob with torches and pitchforks; conversely, not very useful for getting the technology approved.
- taneq 9y agoGM SuperCruise uses a driver-facing camera to confirm that the driver does in fact have eyes on the road. Something like that would be trivial for Uber to add to its self-driving car fleet.
- JorgeGT 9y ago> but other than that you have no task. Then give them a task! Install a HUD drawing a box in real time with the classification of nearest detected object (bike, pedestrian, car, mailbox) and put buttons in the wheel for the driver to confirm/reject the classification. This way: a) you improve your machine learning b) driver has wheels on the road c) driver has hands on the wheel d) driver is focused on incoming objects
- gizmo686 9y agoHumans are terrible for supervising mostly functional machines. This was researched in the context of security guards, who had a 95% missrate after just 20 minutes on the job. It is entirely unreasonable to expect a human supervise to detect and correct this type of situation in time.
- trgn 9y agoyes for sure. I wish articles about this crash would continue to hammer on the basics, to keep front¢er this crash was completely avoidable. Even if there were no technical issues, (1) the driver was on her phone before and during the crash. The whole reason for the driver to be present is to intervene in a situation like this. (2) the car was driving too fast for conditions. Nobody should drive this fast in the middle of the city in the middle of night. It doesn't look like the car could have come to any kind emergency stop. Self-driving cars should drive more carefully than humans, not push against and over the speed limit regardless of outside conditions.
- Aspyre 9y agoIt was 38 mph in a 45.
- lewiseason 9y agoThe overriding principle is normally about driving to the conditions, not achieving a "target" speed.
- Piskvorrr 9y agoThis is one of the core problems of the car culture: ignoring the envelope except where mandated by law. A speed limit means, literally, "you are not allowed to go any faster than this" - but is interpreted as "you are supposed to go at this speed, or better 5 above". Nowhere else is this so prevalent: "there are 50 apples here, so you can't eat any more" is "you must eat all 50 of them" by the same logic.
- syncsynchalt 9y agoI both can and can't blame the safety driver. To expect full attention from a person that is not supposed to have anything to do for hours on end (different from driving, which requires constant inputs and adjustments) is not something that's compatible with humans. With that said they were looking at their phone instead of zoning out eyes front.
- deleted 9y ago[deleted]
- kbutler 9y ago5 9s sounds impressive, until you think that's 1 failure per 100,000 interactions. There are individual intersections in the US that have that many vehicles pass each day. I haven't seen estimates on number of specifically vehicle-pedestrian interactions, but 5 9s is nowhere nearly safe enough.
- hmschreck 9y agoHow many times does a car see this particular interaction, though?
- ars 9y ago> get 5 9s reliability That's it? Humans have greater than 7 9's reliability when driving. (As measured by fatalities per time of driving, and assuming a fatality takes 5 minutes, and average speed is 30mph.) If the cause of a fatality is 10 seconds of failure, not 5 minutes, humans have greater than 9 9s of reliability. Math: 10 seconds / (1.13 / (30 miles/hour / 100 million miles)) Fatality rate is 1.13 per 100 million miles. Good luck programming a computer to even stay on and not crash with that level of reliability. There's this belief that humans are horrible at driving, etc, etc. Until you run that math and realize, no, they're not. There's just a lot of driving going on.
- blattimwind 9y ago> If the cause of a fatality is 10 seconds of failure, not 5 minutes, humans have greater than 9 9s of reliability. If you're driving by the textbook, then you have two seconds to react to the car in front braking; the assumption being that you take one second to react normally, and get one extra second for safety. On the other hand, in something like a play street law grants you exactly zero seconds of response time. The question is now, of course, whether only those <<10 s intervals count as the failure, or your entire approach to driving (e.g. driving while texting).
- ars 9y ago> then you have two seconds Which takes us to 10 9s of reliability. Are there any computers with that level of reliability? > The question is now, of course, whether only those <<10 s intervals count as the failure, or your entire approach to driving (e.g. driving while texting). I thought about this all day. I feel that from the moment you can no longer avoid to accident (no matter what you do), until it occurs, is the correct timeframe to measure. Not sure what that number is though. Say you texted, got in a dangerous situation, then corrected. Is that really a failure? It's a risk of course, and enough people doing that will increase the final death tally. But for each individual driver it's not a failure, if it's not a failure then you can not count it. i.e. doing it any other way would be counting it twice: Once for those situations that actually caused an accident, and again for taking the risk. Or put another way, taking a risk and winning is not a failure. (Otherwise where do you draw the line on what a risk is?)
- digikata 9y agoI think the disturbing thing to me is that there wasn't any sort of layered reliability approach to the testing process itself. When you know you're going to be testing changes to a very complex, multi-sensor real-world system, it would be a standard approach to lay in a more foundational set of technology and practices to the system tests to serve as a conservative safety net. For example, an overriding set of heuristics to brake if needed could be one precaution, and in terms of practices, the human monitor, should have been swapped out at high intervals to alleviate attention fatigue. One can go back and forth on the details, but the need for a separate and independent treatment of safety reviews from the primary product development activity in this kind of endeavour should have been drawn from any of a number of existing practices in other industries. And this is something that a lot of the casual tech articles completely miss - criticizing the primary autonomy tech which of course will have faults, but if you know you will have faults, then where is the serious plan to operate safely knowing the dev system is anticipated to have faults of many types.
- mnm1 9y agoYou mean they shouldn't have disabled the car's own autonomous, non AI braking system and kept it as a backup for when theirs failed? Yeah, but that would take a responsible, caring player and we're talking about uber here, a company built on ignoring laws, best practices, and common sense. This can easily be a case of manslaughter, but their cozy relationship with the az government will probably prevent that from happening despite uber's egregious recklessness.
- digikata 9y ago> You mean they shouldn't have disabled the car's own autonomous, non AI braking system and kept it as a backup for when theirs failed? I admit that was a thought, but I'd hold back from to saying that simple specific thing was the missed item, or even if that was a realistic expectation to maintain that setup. Without a built up safety culture that looks at the issue from multiple directions in detail, and has the authority to halt testing if needed, then it could have easily been something else. And there are multiple industries from civil/military aviation, medical, architecture, as well as many industrial occupations from which one could have formed a safety framework upon.