Fatalities vs False Positives: The Lessons from the Tesla and Uber Crashes

In one bad week in March, two people were indirectly killed by automated driving systems. A Tesla vehicle drove into a barrier, killing its driver, and an Uber vehicle hit and killed a pedestrian crossing the street. The National Transportation Safety Board’s preliminary reports on both accidents came out recently, and these bring us as close as we’re going to get to a definitive view of what actually happened. What can we learn from these two crashes?

There is one outstanding factor that makes these two crashes look different on the surface: Tesla’s algorithm misidentified a lane split and actively accelerated into the barrier, while the Uber system eventually correctly identified the cyclist crossing the street and probably had time to stop, but it was disabled. You might say that if the Tesla driver died from trusting the system too much, the Uber fatality arose from trusting the system too little.

But you’d be wrong. The forward-facing radar in the Tesla should have prevented the accident by seeing the barrier and slamming on the brakes, but the Tesla algorithm places more weight on the cameras than the radar. Why? For exactly the same reason that the Uber emergency-braking system was turned off: there are “too many” false positives and the result is that far too often the cars brake needlessly under normal driving circumstances.

The crux of the self-driving at the moment is precisely figuring out when to slam on the brakes and when not. Brake too often, and the passengers are annoyed or the car gets rear-ended. Brake too infrequently, and the consequences can be worse. Indeed, this is the central problem of autonomous vehicle safety, and neither Tesla nor Uber have it figured out yet.

Continue reading “Fatalities vs False Positives: The Lessons from the Tesla and Uber Crashes”

Hackaday Links: May 13, 2018

The dumbest thing this week is Uber’s flying car concept of the future. The braintrust at Uber envisions a world of skyports, on rooftops or on the ground that will handle 200 takeoffs and landings per hour. That is 4800 per day at a maximum. The record for the number of total takeoffs and landings for any airport was set last year at Mumbai’s Chhatrapati Shivaji airport with 969 takeoffs and landings in a twenty-four hour period. Yes, Uber wants to put the world’s busiest airport in a parking lot or something. Just wait, it gets dumber. Uber’s ‘flying car’ looks like a standard quadcopter, but with stacked, non-contrarotating props, for safety. These aircraft will be powered electrically, although it’s not quite clear if this is a hybrid setup (which could actually be practical now, but without regulatory precedent) or something built around an enormous battery (impractical for anything bigger than a 152 in this decade).

This aircraft is just a render, and Uber expects it to be certified for commercial flight in two to five years. This is nearly impossible. Uber plans to fly these aircraft autonomously. This will never happen. Additionally, Uber will not manufacture or design the aircraft. Instead, they will partner with a company that has experience in aerospace — Bell or Embraer, for instance — making the render a moot point, because ultimately Uber is just going to go with whatever Bell or Embraer have on the drawing board. Uber’s entire business plan is “move fast and break laws”, which will not serve them well with the FAA. The mere mention of Uber’s self-flying car has lowered the level of public discourse and has made us all dumber.

Here’s a great example of how cheap TVs are getting. [tmv22] built a 55 inch, 4k digital photo frame for $400. The TV was one Walmart was blowing out for two hundred and sixty dollars. Add in an Odroid C2 and some various cables and hardware, and you have an absurd digital photo frame for a few benjamins.

Espressif is getting investment from Intel’s venture capital division. Espressif, is, of course, the company behind the incredibly popular ESP8266 and ESP32 chipsets designed for the Internet of Things. Before the ESP8266 module popped up for sale on SeeedStudios, no one had heard of Espressif. Intel, on the other hand, is the largest semiconductor company on the planet and recently exited the maker IoT space because of the complete and utter failure of the Curie, Joule, Edison, and Galileo product lines. I would bet a significant portion of Intel’s failure was due to their inability to release datasheets.

Awesome news for synth heads. Behringer is cloning just about every classic synth and drum machine. At Superbooth 2018, Behringer, manufacturers of the worst mixers on the planet, revealed their clone of the Roland SH-101 synthesizer. It’s called the MS-101, and yes, it has the keytar grip. Also announced is a clone of the TR-808, Odyssey One, the OB-Xa, Arp 2600, and M100 modules. Here’s some context for you: a good Detroit techno show consists of an SH-101, TB-303, TR-808 and TR-909, all made by Roland in the 80s. These vintage synths and drum machines, at current prices, would cost about $10,000, used. The prices for these clone synths haven’t been announced, but we’re looking at a Detroit techno show for $1000. That’s nuts. Here’s a video of the 808.

Self-Driven: Uber and Tesla

Self-driving cars have been in the news a lot in the past two weeks. Uber’s self-driving taxi hit and killed a pedestrian on March 18, and just a few days later a Tesla running in “autopilot” mode slammed into a road barrier at full speed, killing the driver. In both cases, there was a human driver who was supposed to be watching over the shoulder of the machine, but in the Uber case the driver appears to have been distracted and in the Tesla case, the driver had hands off the steering wheel for six seconds prior to the crash. How safe are self-driving cars?

Trick question! Neither of these cars were “self-driving” in at least one sense: both had a person behind the wheel who was ultimately responsible for piloting the vehicle. The Uber and Tesla driving systems aren’t even comparable. The Uber taxi does routing and planning, knows the speed limit, and should be able to see red traffic lights and stop at them (more on this below!). The Tesla “Autopilot” system is really just the combination of adaptive cruise control and lane-holding subsystems, which isn’t even enough to get it classified as autonomous in the state of California. Indeed, it’s a failure of the people behind the wheels, and the failure to properly train those people, that make the pilot-and-self-driving-car combination more dangerous than a human driver alone would be.

A self-driving Uber Volvo XC90, San Francisco.

You could still imagine wanting to dig into the numbers for self-driving cars’ safety records, even though they’re heterogeneous and have people playing the mechanical turk. If you did, you’d be sorely disappointed. None of the manufacturers publish any of their data publicly when they don’t have to. Indeed, our glimpses into data on autonomous vehicles from these companies come from two sources: internal documents that get leaked to the press and carefully selected statistics from the firms’ PR departments. The state of California, which requires the most rigorous documentation of autonomous vehicles anywhere, is another source, but because Tesla’s car isn’t autonomous, and because Uber refused to admit that its car is autonomous to the California DMV, we have no extra insight into these two vehicle platforms.

Nonetheless, Tesla’s Autopilot has three fatalities now, and all have one thing in common — all three drivers trusted the lane-holding feature well enough to not take control of the wheel in the last few seconds of their lives. With Uber, there’s very little autonomous vehicle performance history, but there are leaked documents and a pattern that makes Uber look like a risk-taking scofflaw with sub-par technology that has a vested interest to make it look better than it is. That these vehicles are being let loose on public roads, without extra oversight and with other traffic participants as safety guinea pigs, is giving the self-driving car industry and ideal a black eye.

If Tesla’s and Uber’s car technologies are very dissimilar, the companies have something in common. They are both “disruptive” companies with mavericks at the helm that see their fates hinging on getting to a widespread deployment of self-driving technology. But what differentiates Uber and Tesla from Google and GM most is, ironically, their use of essentially untrained test pilots in their vehicles: Tesla’s in the form of consumers, and Uber’s in the form of taxi drivers with very little specific autonomous-vehicle training. What caused the Tesla and Uber accidents may have a lot more to do with human factors than self-driving technology per se.

You can see we’ve got a lot of ground to cover. Read on!

Continue reading “Self-Driven: Uber and Tesla”

Uber Has An Autonomous Fatality

You have doubtlessly heard the news. A robotic Uber car in Arizona struck and killed [Elaine Herzberg] as she crossed the street. Details are sketchy, but preliminary reports indicate that the accident was unavoidable as the woman crossed the street suddenly from the shadows at night.

If and when more technical details emerge, we’ll cover them. But you can bet this is going to spark a lot of conversation about autonomous vehicles. Given that Hackaday readers are at the top of the technical ladder, it is likely that your thoughts on the matter will influence your friends, coworkers, and even your politicians. So what do you think?

Continue reading “Uber Has An Autonomous Fatality”

Click Your Heels Thrice, Hail a Cab Home

If Dorothy from The Wizard of Oz were to wake up in 2017, with her magic Ruby Slippers on her feet, she’d probably believe she had woken up in a magical world. But modern folks will need a little more magic to impress them. Like Clicking your heels thrice to get home with these Uber ruby slippers. [Hannah Joshua] was tasked by her employer to build a quirky maker project. She got an idea when a friend complained about having trouble hailing a cab at the end of a hard day at work.

[Hannah] started with ruby colored slippers with a platform toe and high heels to allow space to stuff in all the magic dust, err, electronic bits. The initial plan was to use an Arduino with a GSM/GPS shield but that would have needed a separate SIM card and data plan for the shoes. Instead, she opted for the 1Sheeld which connects to a smart phone over Bluetooth. The 1Sheeld gets access to all of the smart phone’s sensors including the GPS as well as the data connection. The Arduino and 1Sheeld are put in a cavity carved out in the toe section. The 9 V battery goes inside another cavity in the heel, where an activation switch is also installed. Three LED’s indicate when the shoe is active, the cab request is accepted, and when the cab is on its way.

The code is basic since this one of her first Arduino projects, but it gets the job done. It sends an http request to Uber’s API to request a cab. The destination is hard-coded, so the slippers only allow you to get from your current location to whatever destination is programmed. The GitHub repository provides code, as well as some additional information on construction. [Hannah] has also added notes explaining some of the design choices and things to take care about if you plan to build one of these magic slippers.

We covered the 1Sheeld when it was introduced several years back, and if you get your hands on one, try building this Hand Waving Door Unlocker.

Continue reading “Click Your Heels Thrice, Hail a Cab Home”

Hacking iBeacons For Automating Routines

Every self-respecting hacker has an automation hack somewhere in his/her bag of tricks. There are a lot of modern-day technologies that facilitate the functionality like GPS, scripting apps, and even IFTTT. In an interesting hack, [Nick Lee] has combined iBeacons and a reverse engineered Starbucks API to create an automated morning routine.

By creating a mobile app that scans for iBeacons, [Nick Lee] was able to reduce the effort made every morning while heading to his office. When the app encounters a relevant beacon, a NodeJS app sitting in the cloud is triggered. This consequently leads to desired actions like ordering an Uber ride and placing an order for an iced latte.

[Nick Lee] shares the code for the Starbucks application on GitHub for anyone who wants to order their favorite cup of joe automatically. This project can be easily expanded to work with GPS or even RFID tags and if you feel like adding IoT to a coffee machine, you could automate all of your beverage requirements in one go.

Automate the Freight: Robotic Deliveries Are on the Way

Seems like all the buzz about autonomous vehicles these days centers around self-driving cars. Hands-free transportation certainly has its appeal – being able to whistle up a ride with a smartphone app and converting commute time to Netflix binge time is an alluring idea. But is autonomous personal transportation really the killer app that everyone seems to think it is? Wouldn’t we get more bang for the buck by automating something a little more mundane and a lot more important? What about automating the shipping of freight?

Look around the next time you’re not being driven to work by a robot and you’re sure to notice a heck of a lot of trucks on the road. From small panel trucks making local deliveries to long-haul tractor trailers working cross-country routes, the roads are lousy with trucks. And behind the wheel of each truck is a human driver (or two, in the case of team-driven long-haul rigs). The drivers are the weak point in this system, and the big reason I think self-driving trucks will be commonplace long before we see massive market penetration of self-driving cars.

Continue reading “Automate the Freight: Robotic Deliveries Are on the Way”