Autopilots Don’t Kill Drivers, Humans Do

January 23, 2017 by Elliot Williams 120 Comments

The US National Highway Traffic Safety Administration (NHTSA) report on the May 2016 fatal accident in Florida involving a Tesla Model S in Autopilot mode just came out (PDF). The verdict? “the Automatic Emergency Braking (AEB) system did not provide any warning or automated braking for the collision event, and the driver took no braking, steering, or other actions to avoid the collision.” The accident was a result of the driver’s misuse of the technology.

This places no blame on Tesla because the system was simply not designed to handle obstacles travelling at 90 degrees to the car. Because the truck that the Tesla plowed into was sideways to the car, “the target image (side of a tractor trailer) … would not be a “true” target in the EyeQ3 vision system dataset.” Other situations that are outside of the scope of the current state of technology include cut-ins, cut-outs, and crossing path collisions. In short, the Tesla helps prevent rear-end collisions with the car in front of it, but has limited side vision. The driver should have known this.

The NHTSA report concludes that “Advanced Driver Assistance Systems … require the continual and full attention of the driver to monitor the traffic environment and be prepared to take action to avoid crashes.” The report also mentions the recent (post-Florida) additions to Tesla’s Autopilot that help make sure that the driver is in the loop.

The takeaway is that humans are still responsible for their own safety, and that “Autopilot” is more like anti-lock brakes than it is like Skynet. Our favorite footnote, in carefully couched legalese: “NHTSA recognizes that other jurisdictions have raised concerns about Tesla’s use of the name “Autopilot”. This issue is outside the scope of this investigation.” (The banner image is from this German YouTube video where a Tesla rep in the back seat tells the reporter that he can take his hands off the wheel. There may be mixed signals here.)

There are other details that make the report worth reading if, like us, you would like to see some more data about how self-driving cars actually perform on the road. On one hand, Tesla’s Autosteer function seems to have reduced the rate at which their cars got into crashes. On the other, increasing use of the driving assistance functions comes with an increase driver inattention for durations of three seconds or longer.

People simply think that the Autopilot should do more than it actually does. Per the report, this problem of “driver misuse in the context of semi-autonomous vehicles is an emerging issue.” Whether technology will improve fast enough to protect us from ourselves is an open question.

[via Popular Science].

Raspberry Pi Home Automation For The Holidays

January 13, 2017 by Elliot Williams 2 Comments

When you want to play around with a new technology, do you jump straight to production machinery? Nope. Nothing beats a simplified model as proof of concept. And the only thing better than a good proof of concept is an amusing proof of concept. In that spirit [Eric Tsai], alias [electronichamsters], built the world’s most complicated electronic gingerbread house this Christmas, because a home-automated gingerbread house is still simpler than a home-automated home.

Yeah, there are blinky lights and it’s all controlled by his smartphone. That’s just the basics. The crux of the demo, however, is the Bluetooth-to-MQTT gateway that he built along the way. A Raspberry Pi with a BTLE radio receives local data from BTLE sensors and pushes them off to an MQTT server, where they can in principle be read from anywhere in the world. If you’ve tried to network battery-powered ESP8266 nodes, you know that battery life is the Achilles heel. Swapping over to BTLE for the radio layer makes a lot of sense.

Continue reading “Raspberry Pi Home Automation For The Holidays” →

David Krum: The Revolution In Virtual Reality

January 9, 2017 by Elliot Williams 18 Comments

[David Krum] is associate lab director at the Mixed Reality Lab at the Institute for Creative Technologies at USC. That puts him at the intersection of science and engineering: building cool virtual reality (VR) devices, and using science to figure out what works and what doesn’t. He’s been doing VR since 1998, so he’s seen many cool ideas come and go. His lab was at the center of the modern virtual reality explosion. Come watch his talk and see why!

Continue reading “David Krum: The Revolution In Virtual Reality” →

USB Arduino Into AVR TPI Programmer

January 6, 2017 by Elliot Williams 4 Comments

Turning an Arduino of virtually any sort into a simple AVR 6-pin ISP programmer is old hat. But when Atmel came out with a series of really tiny AVR chips, the ATtiny10 and friends with only six pins total, they needed a new programming standard. Enter TPI (tiny programming interface), and exit all of your previously useful DIY AVR programmers.

[Kimio Kosaka] wrote a dual-purpose TPI and ISP firmware for the ATmegaxxUn chips that are used as a USB-serial bridge on the Unos, and constitute the only chip on board a Leonardo or Micro. The catch? You’re going to have to do a little bit of fine-pitch soldering. Specifically, [Kosaka-san] wants you to get access to an otherwise obscured signal by drilling out a via. We’d do it just for that alone.

Continue reading “USB Arduino Into AVR TPI Programmer” →

Toshiro Kodera: Electromagnetic Gyrotropes

January 4, 2017 by Elliot Williams 12 Comments

We’ve learned a lot by watching the talks from the Hackaday Superconferences. Still, it’s a rare occurrence to learn something totally new. Microwave engineer, professor, and mad hacker [Toshiro Kodera] gave a talk on some current research that he’s doing: replacing natural magnetic gyrotropic material with engineered metamaterials in order to make two-way beam steering antennas and more.

If you already fully understood that last sentence, you may not learn as much from [Toshiro]’s talk as we did. If you’re at all interested in strange radio-frequency phenomena, neat material properties, or are just curious, don your physics wizard’s hat and watch his presentation. Just below the video, we’ll attempt to give you the Cliff’s Notes.

Continue reading “Toshiro Kodera: Electromagnetic Gyrotropes” →

Rust Running On The Realtek RTL8710: ESP8266 Alternative?

January 4, 2017 by Elliot Williams 26 Comments

For simply getting your project connected to WiFi, a least among hacker circles, nothing beats the ESP8266. But it’s not the only player out there, and we love to see diversity in the parts and languages that we use. One of the big shortcomings of the ESP8266 is the slightly-oddball Xtensa CPU. It’s just not as widely supported by various toolchains as its ARM-based brethren.

And so, when [Zach] wanted to do some embedded work in Rust, the ESP8266 was out of the picture. He turned to the RTL8710, a very similar WiFi module made by Realtek. Documentation for the RTL8710 is, at the moment, crappy, much as the ESP8266 documentation was before the hacker community had at it. But in trade for this shortcoming, [Zach] got to use the LLVM compiler, which supports the ARM architecture, and that means he can code in Rust.

In the end, the setup that [Zach] describes is a mix of FreeRTOS and some of the mbed libraries, which should be more than enough to get you up and running fairly painlessly on the chip. We’ve actually ordered a couple of these modules ourselves, and were looking to get started in straight C, but having Rust examples working doesn’t hurt, and doesn’t look all that different.

Is anyone else using the RTL8710? An ARM-based, cheap WiFi chip should be interesting.

Derek Schulte: Path Planning For 3D Printers

January 3, 2017 by Elliot Williams 54 Comments

[Derek Schulte] designed and sells a consumer 3D printer, and that gives him a lot of insight into what makes them tick. His printer, the New Matter MOD-t, is different from the 3D printer that you’re using now in a few different ways. Most interestingly, it uses closed-loop feedback and DC motors instead of steppers, and it uses a fairly beefy 32-bit ARM processor instead of the glorified Arduino Uno that’s running many printers out there.

The first of these choices meant that [Derek] had to write his own motor control and path planning software, and the second means that he has the processing to back it up. In his talk, he goes into real detail about how they ended up with the path planning system they did, and exactly how it works. If you’ve ever thought hard about how a physical printhead, with momentum, makes the infinitely sharp corners that it’s being told to in the G-code, this talk is for you. (Spoiler: it doesn’t break the laws of physics, and navigating through the curve involves math.)