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...
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.
In motorway driving you could probably shut your eyes for 10 seconds every 20 seconds and be perfectly fine almost all of the time. Especially at night time, or other quiet times of day.
So that final reliability rates includes any and all things humans do while driving. (Not what they could do, what they actually do.)
In the scenario I mentioned you'd have at best a 50% duty cycle of good driving, but the accident rate would be substantially lower than 50% every 10 seconds.
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).
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?)
From other comments in this thread, the correct number is actually 10 9's, not 7. So using the accident rate instead of fatality takes you to 8 9's.
I've been hammering this concept for a while :) Unimpaired, non distracted humans are actually really good at driving. We're optimized for processing visual inputs and making fuzzy decisions, have high dexterity and coordination, and fear death. All of that is alien to software.
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.
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.
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.
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.
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).
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.
> 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.
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...
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.
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.
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
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.
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.
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.