Making Driverless Cars Safer 140
colinneagle writes "Several autonomous cars have been developed elsewhere, most famously by Google, and they are generally capable of identifying objects in the road directly ahead of or behind them. The challenge undertaken by MIT researchers is making these cars aware of dangers lurking around corners and behind buildings. MIT PhD student Swarun Kumar showed a video of a test run by the MIT researchers in which an autonomous golf cart running the technology, called CarSpeak (PDF), encountered a pedestrian walking from the entrance of a building to a crosswalk. The golf cart stopped roughly five yards ahead of the crosswalk and waited long enough for the pedestrian to walk to the other side of the road. The vehicle then continued driving automatically. The solution Kumar presented is based on a method of communications that is intended to expand the vehicle's field of view. This can be accomplished by compressing and sharing the data that autonomous vehicles generate while they're in motion, which Kumar says can amount to gigabits per second. In a comparison test, a car using CarSpeak's MAC-based communications was able to stop with a maximum average delay of 0.45 seconds, compared to the minimum average delay time of 2.14 seconds for a car running 802.11, the report noted."
Re:I wonder if it might help to record video... (Score:5, Informative)
Re:Does not 802.11 a (wireless) Ethernet... (Score:4, Informative)
From the OP: "a car using CarSpeak's MAC-based communications was able to stop with a maximum average delay of 0.45 seconds"
This acronym 'MAC' is not used or explained anywhere else in TFS, so it's unclear whether they mean Media Access Control from the IEEE 802 spec (which probably is employed in moving data wirelessly from car to car, but has little to do with the specific problem of detecting or responding to safety hazards) or something else entirely.
Re:Weather Conditions (Score:5, Informative)
How do these things perform in weather? ex. Blizzards
The same way cars driven by people do: They get stuck in snowdrifts several feet wide and thick. And that's before you back out of the driveway. Disclaimer: I'm from Minnesota. Autonomous vehicles can't unbury your car, and any visual sensor would be as blind as you are in a blizzard. For that matter, even radar operating at microwave frequencies would be... snow is made of water, and water attenuates it. That's why you're supposed to stay inside during a blizzard... It's suicidally stupid to try driving in conditions where, should your vehicle become disabled, not only are you at risk yourself, but others have to risk themselves to come rescue your sorry, impatient ass. And incase you're wondering, no -- your cell phone doesn't work very well in a blizzard and GPS is straight out too, so if you don't know exactly where you are, emergency workers may not find you even with E911 capability; It's only accurate to within 50 meters. In a blizzard... you have trouble even seeing a couple meters in front of you.
Take it from someone who lives and breathes the fluffy white death from above -- Never, ever, trust a vehicle with your life. Any vehicle, even ones connected to Skynet with an IQ of a billion and a hundred different types of sensors. If you can't walk 10 miles in the weather, don't go out in it.
Re:Does not 802.11 a (wireless) Ethernet... (Score:5, Informative)
From the OP: "a car using CarSpeak's MAC-based communications was able to stop with a maximum average delay of 0.45 seconds"
This acronym 'MAC' is not used or explained anywhere else in TFS, so it's unclear whether they mean Media Access Control from the IEEE 802 spec (which probably is employed in moving data wirelessly from car to car, but has little to do with the specific problem of detecting or responding to safety hazards) or something else entirely.
They explain MAC right in the paper ( which is linked in the article ). It's MAC just like you think MAC is (Media Access Control).
Really, the gist of the paper, is instead of each car being the source or identity of a packet, via normal MAC 'addressing' and trying to communicate some important information ( like soft squish target...er.. human at X,Y,Z moving Z-> Y-> Z-> at such and such a rate ) via the full OSI model ( like packaging that info in UDP or TCP), You instead break down the 3D space around the car ( and other cars do the same thing ) using an octree graph ( just like visibility systems in 3D game engines), and send out this info with the MAC layer altered to show which region of the octree your information is pertinent too.
So if you are Car A, and Car B,C,D,E,F,G,H,I are all in your broadcast range, and they are dumping out gigabytes of network aware info based on their laser scanners, you can quickly and at a very low level (hardware) pick out the packets that are important to you (from the air).
tl;dr:
It's a clustered index for wireless packets based on GPS location of events stuffed into the MAC (data link) layer. It's a complicated QOS scheme that has been crafted around a specific engineering latency problem.