Custom Media Player Helps Hacker’s Autistic Son

April 18, 2016 by Dan Maloney 39 Comments

Getting to play with technology is often the only justification a hacker needs to work on a build. But when your build helps someone, especially your own special-needs kid, hacking becomes a lot more that playing. That’s what’s behind this media player customized for the builder’s autistic son.

People generally know that the symptoms of autism cover a broad range of behaviors and characteristics that center around socialization and communication. But a big component of autism spectrum disorders is that kids often show very restricted interests. While [Alain Mauer] doesn’t go into his son [Scott]’s symptoms, our guess is that this media player is a way to engage his interests. The build came about when [Alain] was unable to find a commercially available media player that was simple enough for his son to operate and sturdy enough to put up with some abuse. A Raspberry Pi came to the rescue, along with the help of some custom piezo control buttons, a colorful case, and Shin Chan. The interface allows [Scott] to scroll through a menu of cartoons and get a preview before the big show. [Scott] is all smiles in the video below, and we’ll bet [Alain] is too.

Pi-based media player builds are a dime a dozen on Hackaday, but one that helps kids with autism is pretty special. The fact that we’ve only featured a few projects aimed at autistics, like this 2015 Hackaday Prize entry, is surprising. Maybe you can come up with something like [Alain]’s build for the 2016 Hackaday Prize.

Continue reading “Custom Media Player Helps Hacker’s Autistic Son” →

Alarm System Upgrade Tips The Functionality Scale

April 18, 2016 by Dan Maloney 29 Comments

Residential-grade commercial alarm systems are good at a few things but terrible at others, like keeping pace with telephone technology. So what to do when a switch to VOIP renders your alarm system unable to call in reinforcements? Why not strip out the old system and roll your own value-added alarm and home automation system?

Generally, the hardest part about installing an alarm system is running the wires to connect sensors to the main panel, so [Bill Dudley] wisely chose to leverage the existing wiring and just upgrade the panel. And what an upgrade it is. [Bill]’s BOM reads like a catalog page from SparkFun or Adafruit – Arduino MEGA 2560, Ethernet shield, a sound board, stereo amplifier, X10 interface, and a host of relays, transformers, and converters. [Bill] is serious about redundancy, too – there’s an ESP8266 to back up the wired Ethernet, and a DS3231 RTC to keep the time just in case NTP goes down. The case is a bit crowded, but when closed up it’s nicely presentable, and the functionality can’t be beat.

Rehabilitating old alarm systems is a popular project that we’ve covered plenty of times, like this Arduino upgrade for a DSC 1550 panel. But we like the way [Bill] really went the extra mile to build add value to his system.

The AAduino Is An Arduino In An AA Battery

April 18, 2016 by Jenny List 35 Comments

You might think that there could be no form factor that has not as yet had an Arduino fitted in to it. This morning a new one came our way. [Johan Kanflo]’s AAduino is an Arduino clone with an onboard RF module that fits within the form factor of an AA battery. Putting the Arduino inside its own battery pack makes a very neat and compact self-contained unit.

At the heart of the board is an ATmega328 clocked at 8MHz to reduce power consumption and fused to drop out at 1.7V. The radio module is a HopeRF RFM69C which as supplied is a little bit too big for the AA form factor so [Johan] has carefully filed away the edge of the PCB to make it fit. Enough room is left within the shape of an AA cell for a couple of DS18B20 temperature sensors and an indicator LED. He provides a handy buyer’s guide to the different versions of a 3xAA box with a lid, and all the files associated with the project are available in his GitHub repository.

Especially with the onboard radio module we can see that the AADuino board could be a very useful piece of kit. Perhaps for instance it could be used as a very low power self-contained UKHASnet node.

We’ve featured quite a few Arduino clones over the years that try to break the size mould in some way. This stripboard Arduino almost but not quite equals the AAduino’s size, as does this PCB version barely wider than the DIP package of its processor. But the AADuino is a bit different, in that it’s a ready-made form factor for putting out in the field rather than just another breadboard device. And we like that.

Colored Filament From A Can

April 18, 2016 by Kristina Panos 8 Comments

On the last day of MRRF, the guys from Lulzbot were printing a vase with some clear Taulman t-glase on their TAZ 6 prototype. It was probably the third or fourth one they had printed, but I was compelled to go over there because they were painting the filament with a blue Sharpie right before it went into the extruder.

It immediately made me think of this video that hit our tips line last fall and fell through the cracks—a short one from [Angus] at Maker’s Muse about creating your own colored filament by spraying clear PLA with cheap spray paint. This is a neat alternative to painting a finished print because the color isn’t going to rub off. The pigment fuses with the PLA in the hot end, providing consistent coloring.

Disclaimer time: [Angus] ran his spray-painted PLA through a WANHAO i3, which is a cheap, modified Prusa that actually has pretty good reviews. The point is, he doesn’t care if the nozzle gets clogged. But the nozzle didn’t clog. Nothing bad happened at all, and the prints turned out great. As you can see in the video after the break, he tried silver and blue separately on short lengths of filament, and then alternated the colors to make the striped Marvin in the main image. [Angus]’ main concern is that the paint probably affects the strength of the print.

Have you tried spray painting filament? How did it go? Let us know in the comments. If you long to print in any color on the cheap but don’t want to seriously risk clogging your hot end, there’s always the drilled-out Sharpie method.

Continue reading “Colored Filament From A Can” →

Digital Images And The Amiga

April 18, 2016 by Brian Benchoff 54 Comments

There was a time in the late 80s and early 90s where the Amiga was the standard for computer graphics. Remember SeaQuest? That was an Amiga. The intro to Better Call Saul? That’s purposefully crappy, to look like it came out of an Amiga. When it comes to the Amiga and video, the first thing that comes to mind is the Video Toaster, hardware and software that turns an Amiga 2000 into a nonlinear video editing suite. Digital graphics, images, and video on the Amiga was so much more than the Video Toaster, and at this year’s Vintage Computer Festival East, [Bill] and [Anthony] demonstrated what else the Amiga could do.

Continue reading “Digital Images And The Amiga” →

ImplicitCAD: Programmatic CAD Built With 3D Printing In Mind

April 18, 2016 by Moritz Walter 27 Comments

Cornerstone of many useful things: This Prusa i3 part was modeled in OpenSCAD.

Programmatic CAD, in particular the OpenSCAD language and IDE, has accompanied the maker movement for a while now. After its introduction in 2009, it quickly found its way into the 3D printing toolbox of many makers and eventually became what could be called an Industry Standard among open hardware labs, makerspaces and tinkerers. The Prusa i3, one of the most popular DIY 3D printers, was designed in OpenSCAD, and even Makerbot, the company that sold 100.000 3D printers, uses the language for its “Customizer” – an online tool that allows users to customize 3D printable models with minimal effort.

OpenSCAD is indeed a wonderful tool, and we have been using it a lot. We have become used to its quirks and accepted working with polygon mesh approximations of the models we are trying to design. We have made our peace with excessive rendering times, scripting workarounds and the pain of creating fillets, and we have learned to keep our aesthetic expectations low. We are happy with the fact that there is a way to programmatically create and share virtually any object, but sometimes we wish there was a better way in the open source world. Hint: there is.

Continue reading “ImplicitCAD: Programmatic CAD Built With 3D Printing In Mind” →

The Predictability Problem With Self-Driving Cars

April 18, 2016 by Elliot Williams 93 Comments

A law professor and an engineering professor walk into a bar. What comes out is a nuanced article on a downside of autonomous cars, and how to deal with it. The short version of their paper: self-driving cars need to be more predictable to humans in order to coexist.

We share living space with a lot of machines. A good number of them are mobile and dangerous but under complete human control: the car, for instance. When we want to know what another car at an intersection is going to do, we think about the driver of the car, and maybe even make eye contact to see that they see us. We then think about what we’d do in their place, and the traffic situation gets negotiated accordingly.

When its self-driving car got into an accident in February, Google replied that “our test driver believed the bus was going to slow or stop to allow us to merge into the traffic, and that there would be sufficient space to do that.” Apparently, so did the car, right before it drove out in front of an oncoming bus. The bus driver didn’t expect the car to pull (slowly) into its lane, either.

All of the other self-driving car accidents to date have been the fault of other drivers, and the authors think this is telling. If you unexpectedly brake all the time, you can probably expect to eventually get hit from behind. If people can’t read your car’s AI’s mind, you’re gonna get your fender bent.

The paper’s solution is to make autonomous vehicles more predictable, and they mention a number of obvious solutions, from “I-sense-you” lights to inter-car communication. But then there are aspects we hadn’t thought about: specific markings that indicate the AIs capabilities, for instance. A cyclist signalling a left turn would really like to know if the car behind has the new bicyclist-handsignal-recognition upgrade before entering the lane. The ability to put your mind into the mind of the other car is crucial, and requires tons of information about the driver.

All of this may require and involve legislation. Intent and what all parties to an accident “should have known” are used in court to apportion blame in addition to the black-and-white of the law. When one of the parties is an AI, this gets murkier. How should you know what the algorithm should have been thinking? This is far from a solved problem, and it’s becoming more relevant.

We’ve written on the ethics of self-driving cars before, but simply in terms of their decision-making ability. This paper brings home the idea that we also need to be able to understand what they’re thinking, which is as much a human-interaction and legal problem as it is technological.

[Headline image: Google Self-Driving Car Project]