I think one of the things that other posters are alluding to is that the phone can experience very significant forces if you are dancing, especially if it is being held in something like a purse or other bag that's flying around wildly as you dance (or if the phone is dropped). I'm pretty sure that if I threw my phone in a bag and caught it by the strap, it would experience far more G force than in any ordinary car crash, and if it is surrounded by screaming and general chaos, I think it's making a fairly understandable decision.
The sensor fusion algorithms get confused by this, and the phone decides to call 911. It displays a notification for 10 seconds, then it starts a further 10 second countdown where it buzzes at maximum power and plays a siren noise at maximum volume. Under normal circumstances a reasonable person would notice these very loud alerts, and cancel the call. In a festival scenario where the users are deafened by other noises and possibly drunk/high, you might not notice. The phone then makes a call to 911.
How would you alternatively design a system that calls emergency services in a crash? Where would you personally choose to calibrate the false positive/false negative rate? These are hard design choices, and there will always be incorrect detections with any automated system like this.
I'd filter cases where the phone wasn't previously traveling fast enough for the holder to have been in a vehicle, and cases where the phone wasn't near a road.
This would require AGPS rather than just the less power-hungry IMU, but maybe that's the price for not DDOSing 911 infrastructure.
Shouldn't a system like that be part of the car, not the phone? Trying to force a feature to exist outside of the context where it makes sense can only lead to issues in my opinion.
The solution is to move the system to the car. Cell phones are the wrong tool for the problem. Rollout will be much slower on the automotive side, but this can be addressed if we legistlate such systems up from luxury safety features to mandatory ones. Just like what we did in the past for airbags, automatic antilock braking, etc.
Light sensor. If the phone is in a handbag, there will hardly be any light. If it is in a car or flies away some amount of light would be perceptible by the sensors. Or just disable this feature. We got along ok before without it. First, do no harm.
> How would you alternatively design a system that calls emergency services in a crash?
If you want to prevent false positives—then, same as you’ve described, but only enable when either:
- phone is connected to Carplay via USB or bluetooth
- phone is connected to a bluetooth device known to be an auto (inferred by manufacturer ID, and configurable in bluetooth settings)
- GPS data for the last 5 minutes indicate you’re driving
And display an indicator on lockscreen that shows this feature is enabled.
Of course, consider that the downside of false positives don’t affect consumers or manufacturers—rather, they affect public utilities. Then, it’s easy to understand why this happens.
I think it’s possible that the noise levels at a festival resemble the very loud noise of a car crash on some level, and that is part of the equation in triggering the crash detection.
If it were g-forces alone that are confusing the phone there might be more stories about fall detection rather than just car crash detection. Even though the age cohort at festivals might be less likely to explicitly enable fall detection, I think it’s a default setting.
> How would you alternatively design a system that calls emergency services in a crash?
If significant motion does not stop shortly after a candidate crash is identified then reject the candidate as a false positive.
Maybe also listen for voices. If you can detect people talking and they seem to be reasonably coherent that suggests that even if there was a crash there are people on site already who can take care of summoning emergency services if needed.
Apple maps automatically pops up with directions to home when I connect to my 2008 car’s bluetooth. I’d just enable it when connected to a vehicle’s bluetooth.
Or if the phone continually collects sensor data already for this feature, I’d just make sure the second preceding the supposed crash was consistent with traveling in a vehicle, not being in the same place. It won’t work when you are hit by something though in that case.
They could build some better logic to determine how likely it is the phone is in a car at the moment and specifically for this kind of situation build longer baselines to determine if the user is likely to have heard the warning that the phone has determined it might have sensed a crash. The first option seems like it would solve a number of similar issues as well.
This feels like such an obvious failure-mode that I just assumed when they announced it that it would be smarter- incorporating different sensors, factoring in the exact way it tumbles, etc. If it really is just absolute acceleration, the false-positives are no surprise
I can only imagine that if I rushed a product to market that cost taxpayers thousands of dollars an interrupted emergency services, I'd be in serious trouble.
I think as Android and iOS release these new automated emergency reporting features, it should not tie up the existing voice-based 911 system. Maybe it goes to a call center where humans can interpret what they're seeing first. Or maybe we have a standardized API by which these devices can report directly to 911. But tying up a voice operator talking to a computer seems like a real waste of resources. I'm assuming that's what's happening, maybe I'm completely wrong.
At least the Android version requires manual input (pressing the power button five times in quick succession) but as reported some people seem to do that accidentally somehow (bad power button, I guess?).
It's crazy what large tech companies are allowed to do with public infrastructure. I bet you an app from a small developer would get cease and desisted within a month if it had false positives like these. At least put some of your own operators on the line first so you can verify that the emergency services are actually needed, and maybe don't even roll out the feature in areas that don't opt into receiving these automated alerts.
Burglar alarms often require alarm permits. Alarms first ring the alarm company's employees who ask if help is needed and your PIN. Also police just don't respond to automated burglar alarms, only manually reported ones.
How on Earth are you ever going to reliably prevent false positives for a feature like this while still reliably detecting crashes?
I mean realistically unless you have a clear visual of the crash it's going to be very hard to tell a car crash from a loud noise + movement alone.
Really they should be asking you if you want to enable "crash detection" before setting off and it should remain disabled at all other times. If you can already ensure the user is in a car and then the phone happens to sense something like a crash then chances are much greater that it's actually a crash.
The G-forces in a crash are much higher than dancing.
Other implementations are better.
I carry an iPhone when I go biking, and I have a Garmin GPS. The Garmin crash detection works far better. The Garmin is tuned well enough to go off on a real crash mountain biking but won't go off if you have an accident that's not a full fall.
I have had a very "real" crash and seen the Garmin correctly identify it and the iPhone does not.
An easy way would be to calculate your speed ahead of time. If I’m going 55 mph (90 km/h), there’s a loud noise, and the phone gets jolted a bit, then it can check the distance it’s traveled for the next 3-4 seconds. If it’s clear that it’s not moving anymore, then it can begin alerting me; no response, it calls 911.
Apple currently checks your location periodically, so it can fulfill location-based reminder requests, so I honestly figured a similar tech was used for the crash detection. I’m pretty surprised that that’s not the case.
Security alarms require obtaining an alarm permit. Automated alarms notify the alarm company who call the customer. They ask if help is needed and what their security code is. If the customer says an actual emergency happened they then call 911. In my jurisdiction more than three false alarms results in a fine for the resident/business.
The police generally don't respond to an alarm signal unless a person on site calls it in. Although once in the 1990s someone at work didn't know the burglar alarm keypad code and the police did eventually respond with guns drawn. That was a hair raising experience.
Unless the person has been going faster than 20mph at a turning radius of more than 30ft for more than a few seconds, it's unlikely to be a car accident. Whether the accuracy and sampling rate are always sufficient to distinguish these (or data could be cached with look back at high-g) I don't know.
That excludes most human only activities. Of course roller-coasters and various other rides could still trigger it.
Apple knows exactly where you are, how fast you've been traveling and how much distance you've traveled.
If you've been standing in a field for the last 40 minutes, and haven't traveled more than 10 meters at a slow pace, and are surrounded by hundreds of other iphones that also have barely moved, you probably aren't suddenly in the middle of a car crash.
I wonder what happens when people start taking these things into mosh pits.
I would also think it's pretty easy to dismiss on the 911 operator side. Hey reported car crash. Oh wait, the location is in the middle of a dance club. Guess it's just another false positive.
Been there, done that. Why would you think that has yet to start? Never had a problem with the phone auto-dialing 911 in this scenario personally.
Maybe a difference is that people in the pit are more likely to have phone in pocket, whereas dancers are more likely to be holding phone in hand (cuz generally more likely to want it at the ready for selfies, etc?). I imagine that a phone’s accelerometer, when at the end of a moment arm (or literal arm in this scenario), is going to have a wilder experience than when held closer to the center of mass.
To Apple's 100% credit they were willing to ship engineers out.
This happened day 1 (Thursday) of a 4-day festival. Even though they declined to have Apple come out you know they still sent a couple engineers out to gather data regardless.
On top of that, being proactive once it started happening and getting messaging out to attendees helped cut down the calls by ~50%, which definitely helped.
All you can do is continually refine it once you deploy it. A bit damned if you do, damned if you don't.
And yesterday there was a similar story about android.
Feels like these automated emergency things should go into a 2nd lower priority queue if they’re so low signal to noise ratio. Else it drowns out the higher quality sig/noise actual calls
This whole iOS dialing 911 thing reminds me of the technology connections video on LED street lights. A perfect case of good intentions all around but with some emergent caveats that could not have been foreseen until the final result was in place. In the case of LED street lighting, a mild compromise or patch-around makes sense. In the case of your phone automatically dialing emergency services, the game theory seems a bit more difficult to mediate.
At this point I feel like the best course of action is to back out the feature. Adding a "are you sure" button to prevent a false dialing might as well just be turning it off. Making it less sensitive - effectively the same (maybe worse if you expect to rely on it). There really isn't a fundamental way to save this without yet-more-complexity. The user's intention will be betrayed from the perspective of their device in some percent of cases. You will never be able to solve this 100%.
Now the real question is, are we comfortable with some % error rate? Probably yes. A crank call to 911 isn't like an airbag going off unprovoked or your car deciding a plastic bag floating on the freeway is good cause to engage full emergency braking.
This is a hard engineering problem to solve. Garmin bike computers and fitness trackers have a similar incident detection feature which uses the accelerometer. It doesn't automatically call 911 but it will automatically text designated emergency contacts via a Bluetooth link to your smartphone if it thinks you crashed your bike or something. I have had a few false positives when making hard stops on rough surfaces. Fortunately I was able to cancel the alert before it sent a message.
From what I've heard, 911 operators regularly get people calling them for non-emergencies. The 911 operator's job is to judge whether the caller is actually reporting a legitimate emergency, and if so, route the report to the correct emergency personnel (fire/police/ambulance/etc) OR disregard the report as a non-emergency.
The end of the article seems to confirm the false positives didn't actually have any real negative impact. So legitimate emergencies were not drowned out by the accidental dialing.
> Thankfully, that wasn’t enough false 911 calls to overwhelm the local system and prevent responders from dealing with real emergencies that weekend, and with the help of festival organizers, the local authorities were able to locate the source of every false 911 call to determine that no actual emergencies were being reported.
Obviously eliminating false positives would be ideal. But if the false positives aren't overloading 911 operators, seems like maybe a non-issue? Especially if these things can be predicted, e.g. local emergency personell should be aware of a local festival anyway (and can be on alert for these false positives, assuming it's not so bad as to drown out actual emergencies).
Many people have an irrational fear of dialing 911. If you do it right now, someone will pickup the phone, and if you simply say "Sorry, I didn't mean to dial!" you won't get in trouble and the 911 operator will gladly let you off the line.
Instead of Apple making a device and trying to convince all car makers to adopt it, they are putting it in phones. To sell phones. It shows that all our companies are in it for money and not for saving your life. There's no reason a feature like this needs to be in a phone. It should be in a car. Only
It must be from slam dancing, moshing, ect. Sometimes it can get down right violent but most people are respectful but I can see how it can be set off and ignored as bodies are being slammed around.
[+] [-] noodlesUK|2 years ago|reply
The sensor fusion algorithms get confused by this, and the phone decides to call 911. It displays a notification for 10 seconds, then it starts a further 10 second countdown where it buzzes at maximum power and plays a siren noise at maximum volume. Under normal circumstances a reasonable person would notice these very loud alerts, and cancel the call. In a festival scenario where the users are deafened by other noises and possibly drunk/high, you might not notice. The phone then makes a call to 911.
How would you alternatively design a system that calls emergency services in a crash? Where would you personally choose to calibrate the false positive/false negative rate? These are hard design choices, and there will always be incorrect detections with any automated system like this.
[+] [-] recursive|2 years ago|reply
I'd put it in the car. Make it use the same sensor as airbag deployment.
[+] [-] sowbug|2 years ago|reply
This would require AGPS rather than just the less power-hungry IMU, but maybe that's the price for not DDOSing 911 infrastructure.
[+] [-] samuellavoie90|2 years ago|reply
[+] [-] mattnewton|2 years ago|reply
I wouldn’t - it’s not clear to me this feature is saving lives. Why not incorporate it into the car?
[+] [-] megous|2 years ago|reply
It's already done and mandated. Why design something new?
https://europa.eu/youreurope/citizens/travel/security-and-em...
[+] [-] Calavar|2 years ago|reply
[+] [-] mejutoco|2 years ago|reply
[+] [-] croshan|2 years ago|reply
If you want to prevent false positives—then, same as you’ve described, but only enable when either:
- phone is connected to Carplay via USB or bluetooth
- phone is connected to a bluetooth device known to be an auto (inferred by manufacturer ID, and configurable in bluetooth settings)
- GPS data for the last 5 minutes indicate you’re driving
And display an indicator on lockscreen that shows this feature is enabled.
Of course, consider that the downside of false positives don’t affect consumers or manufacturers—rather, they affect public utilities. Then, it’s easy to understand why this happens.
[+] [-] rz2k|2 years ago|reply
If it were g-forces alone that are confusing the phone there might be more stories about fall detection rather than just car crash detection. Even though the age cohort at festivals might be less likely to explicitly enable fall detection, I think it’s a default setting.
[+] [-] tzs|2 years ago|reply
If significant motion does not stop shortly after a candidate crash is identified then reject the candidate as a false positive.
Maybe also listen for voices. If you can detect people talking and they seem to be reasonably coherent that suggests that even if there was a crash there are people on site already who can take care of summoning emergency services if needed.
[+] [-] activiation|2 years ago|reply
[+] [-] ecuaflo|2 years ago|reply
Or if the phone continually collects sensor data already for this feature, I’d just make sure the second preceding the supposed crash was consistent with traveling in a vehicle, not being in the same place. It won’t work when you are hit by something though in that case.
[+] [-] rtkwe|2 years ago|reply
[+] [-] adriancr|2 years ago|reply
Keep state for a longer period of time.
Activate when you start driving and deactivate when parking.
Start could be triggered by gps detecting movement over longer period of time over roads.
That would avoid festival where you're stationary in a place where cars arent allowed.
Problem here is solved.
[+] [-] brundolf|2 years ago|reply
[+] [-] RC_ITR|2 years ago|reply
Pretty easy to filter all the car crashes coming from a grassy lawn somewhere.
[+] [-] DropInIn|2 years ago|reply
Really, this is effectively criminal under the statute iiuc
[+] [-] hospitalJail|2 years ago|reply
But when you are famous, they just let you do it.
[+] [-] taeric|2 years ago|reply
That is, be careful not to strawman this such that they can't have any false positives. Do keep on them to make it ever better, of course.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] vkou|2 years ago|reply
We have a piss-poor track record of holding 'job creators' accountable for direct harm to our communities, let alone two-steps removed indirect harm.
[+] [-] thiht|2 years ago|reply
Where do you see that they rushed it?
[+] [-] rootusrootus|2 years ago|reply
[+] [-] jeroenhd|2 years ago|reply
It's crazy what large tech companies are allowed to do with public infrastructure. I bet you an app from a small developer would get cease and desisted within a month if it had false positives like these. At least put some of your own operators on the line first so you can verify that the emergency services are actually needed, and maybe don't even roll out the feature in areas that don't opt into receiving these automated alerts.
[+] [-] supertrope|2 years ago|reply
[+] [-] kypro|2 years ago|reply
I mean realistically unless you have a clear visual of the crash it's going to be very hard to tell a car crash from a loud noise + movement alone.
Really they should be asking you if you want to enable "crash detection" before setting off and it should remain disabled at all other times. If you can already ensure the user is in a car and then the phone happens to sense something like a crash then chances are much greater that it's actually a crash.
[+] [-] ben7799|2 years ago|reply
The G-forces in a crash are much higher than dancing.
Other implementations are better.
I carry an iPhone when I go biking, and I have a Garmin GPS. The Garmin crash detection works far better. The Garmin is tuned well enough to go off on a real crash mountain biking but won't go off if you have an accident that's not a full fall.
I have had a very "real" crash and seen the Garmin correctly identify it and the iPhone does not.
[+] [-] cowsup|2 years ago|reply
Apple currently checks your location periodically, so it can fulfill location-based reminder requests, so I honestly figured a similar tech was used for the crash detection. I’m pretty surprised that that’s not the case.
[+] [-] supertrope|2 years ago|reply
Security alarms require obtaining an alarm permit. Automated alarms notify the alarm company who call the customer. They ask if help is needed and what their security code is. If the customer says an actual emergency happened they then call 911. In my jurisdiction more than three false alarms results in a fine for the resident/business.
The police generally don't respond to an alarm signal unless a person on site calls it in. Although once in the 1990s someone at work didn't know the burglar alarm keypad code and the police did eventually respond with guns drawn. That was a hair raising experience.
[+] [-] kurthr|2 years ago|reply
That excludes most human only activities. Of course roller-coasters and various other rides could still trigger it.
[+] [-] autoexec|2 years ago|reply
If you've been standing in a field for the last 40 minutes, and haven't traveled more than 10 meters at a slow pace, and are surrounded by hundreds of other iphones that also have barely moved, you probably aren't suddenly in the middle of a car crash.
[+] [-] ufmace|2 years ago|reply
I would also think it's pretty easy to dismiss on the 911 operator side. Hey reported car crash. Oh wait, the location is in the middle of a dance club. Guess it's just another false positive.
[+] [-] aksss|2 years ago|reply
Maybe a difference is that people in the pit are more likely to have phone in pocket, whereas dancers are more likely to be holding phone in hand (cuz generally more likely to want it at the ready for selfies, etc?). I imagine that a phone’s accelerometer, when at the end of a moment arm (or literal arm in this scenario), is going to have a wilder experience than when held closer to the center of mass.
[+] [-] michaericalribo|2 years ago|reply
[+] [-] M4v3R|2 years ago|reply
[+] [-] kotaKat|2 years ago|reply
This happened day 1 (Thursday) of a 4-day festival. Even though they declined to have Apple come out you know they still sent a couple engineers out to gather data regardless.
On top of that, being proactive once it started happening and getting messaging out to attendees helped cut down the calls by ~50%, which definitely helped.
All you can do is continually refine it once you deploy it. A bit damned if you do, damned if you don't.
[+] [-] Havoc|2 years ago|reply
Feels like these automated emergency things should go into a 2nd lower priority queue if they’re so low signal to noise ratio. Else it drowns out the higher quality sig/noise actual calls
[+] [-] pengaru|2 years ago|reply
trash
[+] [-] bob1029|2 years ago|reply
At this point I feel like the best course of action is to back out the feature. Adding a "are you sure" button to prevent a false dialing might as well just be turning it off. Making it less sensitive - effectively the same (maybe worse if you expect to rely on it). There really isn't a fundamental way to save this without yet-more-complexity. The user's intention will be betrayed from the perspective of their device in some percent of cases. You will never be able to solve this 100%.
Now the real question is, are we comfortable with some % error rate? Probably yes. A crank call to 911 isn't like an airbag going off unprovoked or your car deciding a plastic bag floating on the freeway is good cause to engage full emergency braking.
[+] [-] nradov|2 years ago|reply
https://support.garmin.com/en-US/?faq=RfaXahBWkH8Q7pVFLsuUmA
[+] [-] nazgulsenpai|2 years ago|reply
[+] [-] cj|2 years ago|reply
From what I've heard, 911 operators regularly get people calling them for non-emergencies. The 911 operator's job is to judge whether the caller is actually reporting a legitimate emergency, and if so, route the report to the correct emergency personnel (fire/police/ambulance/etc) OR disregard the report as a non-emergency.
The end of the article seems to confirm the false positives didn't actually have any real negative impact. So legitimate emergencies were not drowned out by the accidental dialing.
> Thankfully, that wasn’t enough false 911 calls to overwhelm the local system and prevent responders from dealing with real emergencies that weekend, and with the help of festival organizers, the local authorities were able to locate the source of every false 911 call to determine that no actual emergencies were being reported.
Obviously eliminating false positives would be ideal. But if the false positives aren't overloading 911 operators, seems like maybe a non-issue? Especially if these things can be predicted, e.g. local emergency personell should be aware of a local festival anyway (and can be on alert for these false positives, assuming it's not so bad as to drown out actual emergencies).
Many people have an irrational fear of dialing 911. If you do it right now, someone will pickup the phone, and if you simply say "Sorry, I didn't mean to dial!" you won't get in trouble and the 911 operator will gladly let you off the line.
[+] [-] coding123|2 years ago|reply
[+] [-] nekoashide|2 years ago|reply
[+] [-] mydriasis|2 years ago|reply
"I was going so hard that my phone thought I was dying and called an ambulance"
[+] [-] blueflow|2 years ago|reply
[+] [-] nazgulsenpai|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] activiation|2 years ago|reply