Awesome Illuminated Arcade Spinner

January 23, 2017 by Steven Dufresne 2 Comments

[Tinker_on_Steroids] made some awesome looking spinners that not only light up when spun but are a really professional looking build on their own. Before we’d watched his assembly video we were sure he’d just added on to something he’d bought, but it turned out it’s all custom designed and made.

In case you’ve never played the old arcade games, a spinner is an input device for games such as Tempest or Breakout where you rotate a knob in either direction to tell the game which way and how fast to move something. In Tempest you rotate something around the middle of the screen whereas in Breakout you move a paddle back and forth across the bottom of the playing field.

He even detects rotation with a home-made quadrature encoder. For each spinner, he uses two ITR9608 (PDF) optical switches, or opto-interrupters. Each one is U-shaped with an LED in one leg of the U facing a phototransistor in the other leg. When something passes between the two legs, the light is temporarily blocked and the phototransistor detects it i.e. the switch turns off. When the thing moves away, the light is unblocked and it turns on again. The direction of movement is done by having the thing pass between two ITR9608’s, one after the other. The “things” that pass between are the teeth of a 3D printed encoder wheel. Continue reading “Awesome Illuminated Arcade Spinner” →

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” →