Open Design. It Is The Way.

It seems like I’m constantly having the same discussions with different people about the Open Design aspect of The Hackaday Prize. I get arguments from both sides; some attest that there should be no “openness” requirement, and others think we didn’t set the bar nearly high enough. Time to climb onto my soap box and throe down some sense on this argument.

Open Design is Important

When you talk about hardware there is almost always some software that goes into making a finished product work. Making the information about how a product works and how it is manufactured available to everyone is called Open Design; it encompasses both Open Hardware and Open Source Software. Open Design matters!

First of all, sharing how something is designed and built goes much further than just allowing others to build their own. It becomes an educational tool and an innovation accelerator (others don’t need to solve the same problems over and over again). When using a new chip, protocol, or mechanical part you can learn a lot by seeing how someone else already did it. This means faster prototyping, and improvements on the design that weren’t apparent to the original creator. And if it breaks, you have a far easier time trying to diagnose and repair the darn thing! We all benefit from this whether we’re creating something or just using an end product because it will work better, last longer, and has the potential to be less buggy or to have the bugs squashed after the fact.

nest-300x293
Nest thermostat rooted by [cj]
There is also peace-of-mind that comes with using Open Design products. The entries in The Hackaday Prize need to be “connected devices”. With open design you can look at the code and see what is being done with your information. Can you say that about Nest? They won’t even allow you to use the thermostat in a country that hasn’t been pre-approved by decree from on high (we saw it hacked to work in Europe a few years back). Now it has been rooted so that you can do with it what you please.

But I contest that it would have been better to have shipped with options like this in the first place. Don’t want to use Nest’s online platform? Fine, let the consumer own the hardware they pay for! My wager since the day they announced Google’s acquisition of Nest is that this will become the “router” for all the connected devices in your home. I don’t want the data from my appliances, entertainment devices, exercise equipment, etc., being harvested, aggregated, and broadcast without having the ability to look at how the data is collected, packaged, and where it is being sent. Open Design would allow for this and still leave plenty of room for the big G’s business model.

I find it ironic that I rant about Google yet it would be pretty hard to deny that I’m a fanboy.

Decentralize the Gatekeeper

I’m going to beat up on Google/Nest a bit more. This is just an easy example since the hardware has the highest profile in the field right now.

If Nest controls the interface and they retain the power to decide whose devices can participate the users lose. Imagine if every WiFi device had to be blessed by a single company before it would be allowed to connect to any access points? I’m not talking about licensing technology or registering a MAC address for a chip. I’m talking about the power, whether abused or not, to shut any item out of the ecosystem based on one entity’s decisions.

If connected devices use a known standard that isn’t property of one corporation it unlocks so many good things. The barrier for new companies to put hardware in the hands of users is very low.

Let’s consider one altruistic part of this; Open Design would make small run and single unit design a possibility. Think about connected devices specialized for the physically challenged; the controller project makes specialized controls for your Xbox, what about the same for your oven, dishwasher, the clock on your wall, or your smart thermostat?

The benefits really show themselves when a “gatekeeper” goes out of business or decides to discontinue the product line. This happened when the Boxee servers were shut down. If the source code and schematics are available, you can alter the code to use a different service, build up your own procotol-compliant home server, or even manufacture new devices that work with the system for years to come. There are already pleas for belly-up manufacturers to open-source as the last death throw. Hacking this stuff back into existence is fun, but isn’t it ridiculous that you have to go to those lengths to make sure equipment you purchased isn’t turned into a doorstop when they shut the company lights off?

home-automation-from-1985To drive the point home, consider this Home Automation System from 1985 [via Reddit]. It’s awesome, outdated, and totally impossible to maintain into the future. I’m not saying we should keep 30-year-old hardware in use indefinitely. But your choices with this are to source equally old components when it breaks, or trash everything for a new system. Open Design could allow you to develop new interfaces to replace the most used parts of the system while still allowing the rest of the hardware to remain.

Why not disqualify entries that aren’t Open Hardware and Open Source Software?

Openness isn’t a digital value

Judging preferences are much better than disqualifying requirements. This is because ‘openness’ isn’t really a digital value. If you publish your schematic but not your board artwork is that open? What if you’re using parts from a manufacturer that requires a Non-Disclosure Agreement to view the datasheet and other pertinent info about the hardware?

In addition to deciding exactly where the threshold of Open or Not-Open lies, we want to encourage hackers and companies to try Open Design if they never have before. I believe that 1% open is better than 0% open, and I believe that there is a “try it, you’ll like it” experience with openness. If this is the case, The Hackaday Prize can help pollinate the virtue of Open Hardware far and wide. But only if we act inclusively and let people work their way toward open at their own pace.

There are more benefits to Open than there are drawbacks.

open-hardware-is-goodThe biggest worry I hear about open sourcing a product is that it’ll get picked up, manufactured, and sold at a cut-throat rate.

If you build something worth using this is going to happen either way. The goal should be to make a connection with your target users and to act ethically. Open Design allows the user to see how your product works, and to add their own features to it. Most of the time these features will appeal to a very small subset of users, but once in a while the community will develop an awesome addition to your original idea. You can always work out a way to include that in the next revision. That right there is community; the true power of open.

So yeah, we’re giving away a trip to space and hundreds of other prizes. But these are really just a carrot to entice hackers, designers, and engineers to feed the hungry world of Open Hardware and Open Source Software.

 

Stubby, The Adorable And Easy To Build Hexapod

stubby

A while back, we had a sci-fi contest on Hackaday.io. Inspired by the replicators in Stargate SG-1, [The Big One] and a few other folk decided a remote-controlled hexapod would be a great build. The contest is long over, but that doesn’t mean development stopped. Now Stubby, the replicator-inspired hexapod is complete and he looks awesome.

The first two versions suffered from underpowered servos and complex mechanics. Third time’s the charm, and version three is a lightweight robot with pretty simple mechanics able to translate and rotate along the XYZ axes. Stubby only weights about 600 grams, batteries included, so he’s surprisingly nimble as well.

The frame of the hexapod is designed to be cut with a scroll saw, much to the chagrin of anyone without a CNC machine. There are three 9g servos per leg, all controlled with a custom board featuring an ATMega1284p and an XBee interface to an old Playstation controller.

Video of Stubby below, and of course all the sources and files are available on the project site.

Continue reading “Stubby, The Adorable And Easy To Build Hexapod”

[Tymkrs] Tombstone Guitar Amplifier

tymkrsTombstone

[Atdiy and Whisker], the team behind [The Tymkrs] YouTube channel, are at it again with a tombstone guitar amp project.(YouTube playlist link) Their amp began life as a Philco Tombstone radio which had seen better days. By the time [Tymkrs] got their hands on it, it was just a shell of its former self, as someone had already stripped all the electronics.

The amplifier itself is a disused Leslie tube amp [Tymkrs] had on hand. An LM386 serves as the pre-amp, making this a hybrid solid and vacuum state machine.

The tombstone speaker is especially interesting. [Tymkrs] went with an electrodynamic field coil speaker. Field coil speakers have no magnets, instead using a high voltage (approx 90V DC) coil to create a magnetic field for the voice coil to push against. This sort of speaker was commonplace in the 1930’s, as large magnets couldn’t be made lightweight enough to be used in a speaker. As magnet technology improved, permanent magnets became a staple in speakers.

[Tymkrs] paid special attention to the finish of the amplifier. They brought the tired old radio back to a high shine, then added a Metropolis inspired overlay from aged copper-clad board. The result is an amp that looks great and sounds great!

Continue reading “[Tymkrs] Tombstone Guitar Amplifier”

A Cloud Of Lightning Detectors

strikes

Here’s an interesting project to plot every lightning strike on Earth. Blitzortung is a project that uses many extremely low-cost sensor boards packed with an amplifier, microcontroller, and an Ethernet socket to detect lightning strikes. When multiple stations send all that data up to a server, the location of lightning strikes can be calculated, even if they’re hundreds of miles away from any station.

Each station works by detecting a change in the local EM field caused by a lightning strike with either a large loop antenna or a smaller ferrite core antenna. These signals can be amplified and turned into usable data, time stamped, and sent out on the Internet. From there, it’s a simple time of flight calculation to precisely locate where lightning strikes.

The hardware is actually pretty simple, with based on an STM32F4 Discovery board. A controller includes an Ethernet port, GPS unit, LCD, and all the hardware associated with detecting lightning strikes.

If you’d like to see what’s possible with a huge network of lightning detectors connected to the Internet you can check out LightningMaps for a look at what’s possible.

Thanks [Sean] for sending this in.

Tetris Duel With The Raspberry Pi

Tetris Duel

Building a multiplayer network game with multiple Raspberry Pis can be very difficult. Doing it in assembly is outright insane! This is exactly what a group of first year students at Imperial College London did; they created a network based multiplayer Tetris game for the Raspberry Pi.

[Han], [Piotr], [Michal], and [Utsav] have created this entire game from bare metal assembly, and it only consists of 4000 lines of code! The code is well documented, so be sure to look through their Github repository. This project is a great reference for those looking to learn bare metal assembly and networking. They even chose to use the old NES controllers, a very nice touch. While we have featured what seems like a million different Tetris games in the past, this is the first multiplayer version. See Tetris Duel in action in the video after the break!

This is a shout-out to all of you students out there. Take the time to create quality documentation for your class project, and upload it to the internet. Not only is it a great resume boost, but it could very well end up on Hackaday!

Continue reading “Tetris Duel With The Raspberry Pi”

Hackaday Links: June 29, 2014

hackaday-links-chain

Ever see a really cool build on YouTube with no build details at all? Frustrating, right? That’s us with the NES Keytar covering the Game of Thrones theme. He’s using a Raspi with the sound chip in the NES to do live chiptunes. Freakin’ awesome. There’s also the ST:TNG theme as well.

A few years ago the folks at Oculus had an idea – because of cellphones, small, high resolution displays are really cheap, so why not make VR goggles? At Google IO this week someone figured out everyone already has a cellphone, so just wrap it in some cardboard and call it a set of VR goggles. You can get a kit here, but the only difficult to source components are the lenses.

What happens when you put liquid nitrogen under a vacuum? Well, it should evaporate more, get colder, and freeze. Then it breaks up into solid nitrogen snow. No idea what you would do with this, but there ‘ya go. Oh, [NC], we’re going to need a writeup of that LN2 generator.

About a month ago, the House4Hack hackerspace in South Africa told us of their plans to bring a glider down from 20km above the Earth. They finally launched it, The CAA only allowed them to glide back from 6km (20,000 feet), but even from there the foam glider hit 230kph (124 knots). That’s a little impressive for a foam FPV platform, and we’re betting something with a larger wingspan would probably break a spar or something. Shout out to HABEX.

All the electronic dice projects we’ve seen have one thing in common: they’re not cubes. Thus uberdice. It’s six nine-pixel displays on the faces of a cube, powered by a battery, and controlled by an accelerometer. Yes, it is by far the most complicated die ever made, but it does look cool.

Simple Touch Controller Frees Up USB Port

touch screen demonstration using text

[typ.o] was working on a Raspberry Pi project and found himself running short on USB ports. The project required a touch screen interface, which takes up one of the ports. Since he was only using the screen in text mode, he decided to ditch the original USB controller and make his own.

The ever popular Attiny85 is deployed to handle the task, and is interfaced between the resistive touch panel and the Raspberry pi, using only three pins from the GPIO port. The Attiny85 runs off the 3 volt supply from the raspi, so no level shifter is needed, helping to keep his board super simple.

The calibration and calculation of the touched character location is done by a Python script running on the raspi. [typ.o] is a fan of the KISS principle, and it shows. Be sure to check out his site for all source code, schematics and a video demonstrating this simple but effective solution.