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].

Woodworking Basics For The Hardware Hacker

January 23, 2017 by Dan Maloney 79 Comments

Hackaday is primarily a place for electronics hackers, but that’s not to say that we don’t see a fair number of projects where woodworking plays a key role. Magic mirror builds come to mind, as do restorations of antique radios, arcade machines built into coffee tables, and small cases for all manner of electronic and mechanical gadgets. In some of these projects, the woodworking really shines and makes the finished project pop. In others — well, let’s just say that some woodwork looks good from far, but is far from good.

Continue reading “Woodworking Basics For The Hardware Hacker” →

Hackaday’s Sci-Fi Contest Hits Warp Speed

January 23, 2017 by Adam Fabio 31 Comments

Hackers’ perspiration may go into soldering, coding, and building. For many of us, the inspiration for these projects comes from science fiction. The books, movies, TV shows, short stories, and comics we all grew up on, and continue to devour to this day. We’re paying homage to all these great Sci-Fi stories with our latest contest.

The Sci-Fi Contest isn’t about the most efficient way of building a 555 circuit or the tightest code. This one is about celebrating science fiction in the best way we know how — building awesome projects. This is Hackaday, so you’re going to have to use some form of working electronics in your entry. Beyond that, it’s up to you. Bring us your Overwatch cosplays, your Trek Tricorders, your Star Wars pod racers.

This isn’t our first Sci-Fi contest. In fact, Sci-Fi was one of Hackaday.io’s first contests way back in 2014.
3 years and over 100,000 new hackers later, it’s time to take a fresh look at what you all have been up to. Projects that were entered in the first Sci-Fi contest are eligible, but you need to create a new project page and do some new work.

Check the rules for the full details. Once you’ve published a project use the drop-down menu on the left sidebar to enter it in the Hackaday Sci-Fi Contest.

Prizes

Great work reaps great rewards. Here’s what we’ve got for this contest:

Grand Prize is a Rigol DS1054Z 4 Channel 50 MHz scope.
First Prize is a Monoprice Maker Select Mini 3D printer
Second Prize is a complete Blu-Ray box of Star Trek: The Next Generation
Third Prize is Lego’s latest rendition of the Millennium Falcon.

The deadline is Monday, March 6, 2017, 09:00 pm PST (+8 UTC), so don’t waste time! Warm up your soldering irons, spin up your warp drives, and create something awesome!

Robo-Flute Whistles MIDI

January 23, 2017 by Al Williams 6 Comments

We aren’t sure this technically qualifies as music synthesis, but what else do you call a computer playing music? In this case, the computer is a Teensy, and the music comes from a common classroom instrument: a plastic recorder. The mistaken “flute” label comes from the original project. The contraption uses solenoids to operate 3D printed “fingers” and an air pump — this is much easier with a recorder since (unlike a flute) it just needs reasonable air pressure to generate sound.

A Teensy 3.2 programmed using the Teensyduino IDE drives the solenoids. The board reads MIDI command sent over USB from a PC and translates them into the commands for this excellent driver board. It connects TIP31C transistors, along with flyback diodes, to the solenoids via a terminal strip.

On the PC, a program called Ableton sends the MIDI messages to the Teensy. MIDI message have three parts: one sets the message type and channel, another sets the velocity, and one sets the pitch. The code here only looks at the pitch.

This is one of those projects that would be a lot harder without a 3D printer. There are other ways to actuate the finger holes, but being able to make an exact-fitting bracket is very useful. Alas, we couldn’t find a video demo. If you know of one, please drop the link in the comments below.

We have seen bagpipe robots (in fact, we’ve seen several). We’ve also seen hammering shotguns into flutes, which is certainly more melodious than plowshares.

Owning Hacker As A Word

January 23, 2017 by Jenny List 53 Comments

To a casual observer it might seem as though our community is in the news rather a lot at the moment. It’s all about hacks on our TV screens in the soap opera of Washington politics, who hacked this, whether those people over there helped that lot hack the other lot, or even whether that person’s emails could have been hacked on that server. Keeping up with it as an outsider can become a full-time job.

Of course, as we all know even if the mainstream journalists (or should I refer to them colloquially as “hacks”?) don’t, it’s not us they’re talking about. Their hackers are computer criminals, while we are people with some of the hardware and software skills to bend technology to our will, even beyond what its designers might have intended. And that divergence between the way we use the word in a sense of reappropriation and they use it in disapprobation sometimes puts us in an odd position. Explaining to a sober-suited businessman as the director of a hackspace, that no, we’re not *those*hackers can sometimes feel like skating on thin ice.

Continue reading “Owning Hacker As A Word” →

Ice, Ice, Radio Uses FPGA

January 23, 2017 by Al Williams 24 Comments

Building a software defined radio (SDR) involves many trades offs. But one of the most fundamental is should you use an FPGA or a CPU to do the processing. Of course, if you are piping data to a PC, the answer is probably a CPU. But if you are doing the whole system, it is a vexing choice. The FPGA can handle lots of data all at one time but is somewhat more difficult to develop and modify. CPUs using software are flexible–especially for coding user interfaces, networking connections, and the like) but don’t always have enough horsepower to cope with signal processing tasks (and, yes, it depends on the CPU).

[Eric Brombaugh] sidestepped that trade off. He used a board with both an ARM processor and an ICE FPGA at the heart of his SDR design. He uses three custom boards: one is the CPU/FPGA board, another is a 10-bit converter that can sample at 40 MSPS (sufficient to decode to 20 MHz), and an I2S DAC to produce audio. Each board has its own page linked from the main project.

Continue reading “Ice, Ice, Radio Uses FPGA” →

4-way Or 8-way Joystick Restrictor Mod

January 23, 2017 by Steven Dufresne 41 Comments

Having a restricted 4-way or 8-way digital joystick for an arcade game is fine if the joystick is built into a game cabinet that plays only one game — 4-way for Pacman and 8-way for Super Cobra. But [Tinker_On_Steroids] wanted a joystick that could be restricted as either 4-way or 8-way for a cabinet that could play a multitude of games, and it had to switch from one type of restriction to the other automatically based on the selected game.

His digital joystick already came with a plate that can be mounted for either 4-way or 8-way restriction, but it has to be manually screwed in place for one or the other. He removed it and designed two 3D-printable parts, one that is to be mounted firmly to the bottom of the joystick and the other that rotates within the first one. Rotated in one orientation gives 4-way restriction and in the other orientation gives 8-way. That left only attaching a servo to do the rotation. The first video below shows mounting this all to the joystick and demoing the servo using a Teensy. The STL files for the parts are on his Thingiverse project page.

He also shows a simple circuit board he made that has two buttons and two LEDs on it for connecting to the Teensy and controlling the servo. And as an added option he shows how to talk to the Teensy from his desktop computer through USB and control the servo that way. In the second video below he details all that and also does a walk-through of the code he wrote for the Teensy. On the Thingiverse page he provides only the hex file but it’s likely you’d write your own software for interfacing with a game anyway.

Continue reading “4-way Or 8-way Joystick Restrictor Mod” →