Bare feet, bare hands, and bare chest – if it weren’t for the cargo shorts and the brief sound of a plane overhead, we’d swear the video below was footage that slipped through a time warp. No Arduinos, no CNC or 3D anything, but if you doubt that our Stone Age ancestors were hackers, watch what [PrimitiveTechnology] goes through while building a tile-roofed hut with no modern tools.
The first thing we’ll point out is that [PrimitiveTechnology] is not attempting to be (pre-)historically accurate. He borrows technology from different epochs in human history for his build – tiled roofs didn’t show up until about 5,000 years ago, by which time his stone celt axe would have been obsolete. But the point of the primitive technology hobby is to build something without using any modern technology. If you need a fire, you use a fire bow; if you need an axe, shape a rock. And his 102 day build log details every step of the way. It’s fascinating to watch logs, mud, saplings, rocks and clay come together into a surprisingly cozy structure. Especially awesome if a bit anachronistic is the underfloor central heating system, which could turn the hut into a lovely sauna.
Software hackathons are an old hat these days. They’re a great scouting opportunity for talented candidates looking for a job, and they provide the battleground for coding enthusiasts to prove themselves by developing a project from start to finish overnight, albeit, with a few kinks. Hardware hackathons are an entirely different beast. By trading APIs for components and Python libraries for soldering irons, they pull the excitement out of the text editor and onto the workbench for everyone to see.
While hardware hackathons might be “the next big thing” with you and your four best DIY-pals, the broad range of physical components, from Arduinos to CNC milling time, makes rule-establishment, safety enforcement, and winning criteria far more difficult to constrain within a single night. Enter Muddhacks. This past October, three students from Harvey Mudd College set out to deliver a hardware hackathon that would open their student community’s mind to the thought of tinkering-for-fun in their spare time outside the lab and beyond their homework.
Students [Benjamin Chasnov], [Apoorva Sharma], and [Akhil Bagaria] had just finished their experimental engineering class: E80. Along the way, they designed a custom sensor payload into a meter-long rocket and launched both rocket and payload to measure the rocket’s fundamental frequencies in flight. With a victory behind them, they were ready for their next big project.
As the next semester waned onwards, however, they realized that any big project–no matter how modular–would be a serious time commitment. After some thought, they refactored their idea entirely. Tinkering was a passion shared by each of them; why not spread the love school-wide and bring together a community of engineers-by-night? To resolve their craving for after-hours engineering and to inspire a culture of collaborative tinkering, they set out to bootstrap a hardware hackathon; an event where many projects could be realized by many students in a single night.
Everyone Says Hardware is Hard
For the unitiated, hardware looks hard. Breadboards, LEDs, r`esistors? To those who have never put together a simple circuit before, taking that first leap is a challenge set by a box of components that almost seems to glare back menacingly. The three teammates took this first-timer roadblock as a challenge unto themselves to break down that barrier. Thus, HackWeek was born.
HackWeek was the MuddHacks teams’ answer to get students comfortable gluing modules together to produce a functional project in a short time. How do I make things move? How do I connect things to the internet? What parts do I choose? All of these questions-worth-answering became topics of the three-day event before the hackathon. The idea behind HackWeek was simple: give eager students enough theory and a functional demo that they could probe, tweak, and recompile so that they could feel more comfortable developing their own ideas into projects. On day one, the MuddHacks team brought functional demos of various motors into the hands of eager students. By day two, the three teammates actually assembled a functional hack of their own before the eyes of their listeners: an internet-enabled microwave that could remotely start warming up that cup of ramen on your way back from class.
Unlike software hackathons, a successful hardware hackathon involves parts, and the MuddHacks team was well-prepared to bring the participants the parts that they wanted. With ten days to go before the event, [Ben] took orders from each team’s desired list of parts. With a day to go, all parts arrived before the event and made it to their respective user’s hands in “goodie bags” on the last day of HackWeek. On this last day, teams opened their bags and explored the parts given to them and to other teams while taking advice from the mentors present to offer tips for using various components. This time for “open-exploration” ensured that the following night spent hacking would be more fruitful, now that teams had cleared the starting questions for various parts on the previous day.
On the night of MuddHacks, [Ben], [Apoorva], and [Akhil] had completely turned their original aim to build their own project into a night spent mentoring the projects of others. Throughout the night, they became the “ground crew,” bringing advice to debugging teams and keeping the night culture alive with two waves of snacks. “We felt that if students were going to come to our event, it was our responsibility to keep them both awake and happy,” Apoorva mentioned. Classrooms refilled for the night with students eager to bring their robots, LEDs, and gantries to life, but other parts of the school came to life as well. The machine shops reopened, and old oscilloscopes and test equipment emerged from the engineering stock room for loan to any teams that needed them. Even a few professors happened to wander into classrooms and offer advice.
For [Ben], [Apoorva], and [Akhil], fostering a sense of community in tinkering became their top priority. As they wandered between teams, they encouraged stellar performers to take a brief break and help out another team through a bug. At the night’s end, a number of early-rising professors joined the crowd of students to judge the winners. Oddly enough, the MuddHacks team didn’t spend any money on the prizes–but no one seemed to notice or care. For the eighth of the entire undergraduate student body that attended, these students weren’t coming for the prizes. They came to join that culture of tinkerers–to be a fellow hardware-hacker-by-night–eager to do their part to make the world blink.
When was the last time you burned yourself downloading someone else’s API? Probably never. With a hardware hackathon, comes a new wave of challenges not seen before in the software variant. With one successful hackathon under their belt, we asked the MuddHacks Team to share some insights for other teams looking to assemble their own hardware hackathon. Here’s what they came up with.
Charging participants an entrance fee may solve the problem of funding, but for the thrifty, starving student, entrance fees may also weed out people who had a slight curiosity but weren’t eager to throw a few bucks down to support it. The solution? Bring participants in for free and support the hackathon with external funding. The MuddHacks team reached out to a number of companies and encouraged them to take a sincere look at their website and cause.
The Muddhacks team handled most of their administrative work online. Among the tools they chose were
Google Forms for parts orders and feedback
Slack and email lists for real-time updates during the event
Google Spreadsheets for keeping track of order requests
Bootstrap for deploying a website
The Muddhacks team mandated that students form teams to enter the hackathon, mostly to foster community and collaboration. They reasoned: “If you already build things for fun on your own, you don’t need a hackathon to get you excited about hardware for the first time.” Most teams self-assembled, but the Muddhacks team also suggests a submission form for stragglers to pair up.
Ten days before the hackathon, [Ben] put out a call to order parts in a $100 budget range. Each team made part requests, and [Ben] then ordered each of these parts in time for the hackathon. In addition, the Muddhacks team also ordered a collection of additional stock hardware (think: Arduinos and shields).
Setting the Stage
The Muddhacks team received permission to host the night event on the third floor of one of their buildings filled with classrooms. Among points to consider for the setting are:
reliable Wi-Fi connectivity
power outlet access
Soldering irons and sleep-deprivation don’t mix well. Among the points to consider for safety are tools that will keep users safe (safetly glasses and ventilation in this case). The MuddHacks team also recommends a safety waiver.
Advertising and Swag
Getting people excited is key. Logos, T-shirts, and Mugs all add to the authenticity of the one-night event. The Muddhacks Team brought in each of these to its participants. In addition, they printed posters, deployed a website and facebook page, and pitched to students directly in their computer science and engineering classes.
Keeping the Night Moving
Feed the masses. The MuddHacks team reminds us that, as the hosts and organizers of the event, it’s your responsibility to make sure that attendees are both awake and enjoying their time. Not only did the team provide two rounds of food, they also walked around and engaged participants that needed some help debugging, effectively becoming an extra set of eyes to track down bugs as mentors throughout the night.
The MuddHacks team brought in their favorite professors to judge teams’ projects. At this event, the MuddHacks team stresses that all participants deserve to see all projects. Not only can they witness something awesome, they can also engage their peers with questions, effectively learning a few extra tricks that they didn’t discover while working on their own project.
Priming for Next Year
From the MuddHacks Team: “Take pictures!” While the first website and facebook page were filled with images of the tools and the setting, next years website and advertisements could be filled with pictorial proof of the promise to participants of a genuine experience. As the first hackathon closes, they also stress that you, the organizers and founders, learn too; and the best way to do so is to collect feedback with some manner of online form. At the same time, this form could also recruit additional hands for assembling next year’s hackathon.
We hope these tips from a stellar hackathon serve as a starting point for developing one of your own. To learn more about MuddHacks, take a quick visit to their website: MuddHacks.com, or follow them on their Facebook page.
This article was specifically written for the Hackaday Omnibus vol #02. Order your copy of this limited edition print version of Hackaday.
Halloween is when the ghouls start haunting and the hackers start hacking. All hallows eve is the perfect holiday for eerie blinking LEDs, spooky audio oscillators, and wild animatronics. We had a double dose of Halloween hacks last year on the Hacklet. This year we’re bringing you even more of the best Halloween hacks on hackaday.io!
We start with [dougal] and Halloween Blinky Eyes. [Dougal] wanted to create the effect of creatures peeking at you from the dark corners of the room, and he’s certainly nailed it. A strip of WS2812 LEDs is the trick here. Pairs of LEDs light up, blink, and fade away like spooky eyes. The Strip is controlled by a Particle Core using Adafruit’s NeoPixel Library, though [Dougal] plans to move to the FastLed library. Everything is powered by a USB power pack. This hack isn’t much to look at with the lights on, so check out the video to see these eyes really shine!
Next up is [controlmypad] with Blair the Witch Project. A normal trip to Home Depot turned paranormal when [controlmypad] spotted an awesome witch decoration. The free-standing mannequin had some basic animatronics and the all important manual trigger. [controlmypad] already had a discarded electric wheelchair. After replacing the chair batteries he modified it with a Sabertooth 2×32 Motor Controller and a standard radio control receiver. A spare channel was connected to Blair’s manual trigger. An aluminum tube joins the witch and the scooter. The hardest part of this hack was keeping Blair’s skirt out of the scooter wheels. Home Depot to the rescue! A simple hoop made of lawn edging plastic keeps the fabric and wheels apart.
[Alex Cordonnier] and his team participated in Boilermake 2015, a 24 hour Hackathon at Purdue University. The fruit of their labor is Trick or Tweet, the tweeting Jack-o’-lantern. Yes folks, we now have the internet of gourds. Hiding inside Trick or Tweet is a Raspberry Pi and a Pi Camera. The pumpkin itself is also a giant capacitive touch switch. Touching the pumpkin triggers a count down after which Trick or Tweet snaps a photo. It then adds some spooky Halloween overlays, a pun or two, and throws the whole thing up on twitter @PumpkinPiPics. [Alex] hasn’t uploaded the code yet, but we’re guessing it consists of a few Python scripts. Pretty awesome for 24 hours of work!
Sometimes Halloween hacks take on a life of their own. That’s exactly what happened when [Hari Wiguna] sat down with a few parts he ordered from China. Happy Halloween 2015 is the result. [Hari’s] order included some potentiometers, a two color OLED display, and some Arduino clones. In no time [Hari] had three pots wired up to the Arduino’s analog inputs. The OLED quickly followed, displaying graphics via the Arduino’s I2C bus. He really wanted a Jack-o’-lantern though. It took a bit more tweaking, but eventually [Hari] was successful. The first pot sets eye size. The second controls eye rotation. The third pot changes the width of Jack’s mouth. [Hari] has all the code for this hack up on his most recent project log.
Not spooked enough? If you want to see more Halloween projects, check out our newly updated Halloween hacks list! Did I miss your project? Don’t be shy, just drop me a message on Hackaday.io. That’s it for this week’s Hacklet; As always, see you next week. Same hack time, same hack channel, bringing you the best of Hackaday.io!
With the summer’s big security conferences over, now is a good time to take a look back on automotive security. With talks about attacks on Chrysler, GM and Tesla, and a whole new Car Hacking village at DEF CON, it’s becoming clear that autosec is a theme that isn’t going away.
Up until this year, the main theme of autosec has been the in-vehicle network. This is the connection between the controllers that run your engine, pulse your anti-lock brakes, fire your airbags, and play your tunes. In most vehicles, they communicate over a protocol called Controller Area Network (CAN).
A number of talks were given on in-vehicle network security, which revealed a common theme: access to the internal network gives control of the vehicle. We even had a series about it here on Hackaday.
The response from the automotive industry was a collective “yeah, we already knew that.” These networks were never designed to be secure, but focused on providing reliable, real-time data transfer between controllers. With data transfer as the main design goal, it was inevitable there would be a few interesting exploits.
Clearing brush is no fun. Sure, swinging a machete on a hot, humid day sounds great, but when you’re sitting in an oatmeal bath the next day because you didn’t see the poison ivy, you’ll be looking for a better way. [RoboMonkey] did just that with a field-expedient brush trimmer that’s sure to help with his chores.
This is a hack in the true Junkyard Wars sense of the word. A cast-off electric push mower deck caught [RoboMonkey]’s eye, and a few spare brackets and bolts later his electric hedge trimmer was attached across the front of the mower. With a long extension cord trailing behind, he was able to complete in 10 minutes what would normally take him an hour to accomplish, without spending a dime on either a specialized brush cutter or a landscaping service. The video after the break reveals that it may not be the most powerful tool in the shed, and it won’t likely stand up to daily use, but for this twice a year chore, it’s more than sufficient. And since the hedge trimmer wasn’t modified, it’s still available for its original purpose. Reduce, reuse, recycle – and repurpose.
While we haven’t seen many brush cutters before, we seen plenty of mower mods. From LiPo electrics to a gas-powered RC unit, the common push-mower seems to be a great platform for all kinds of hacking.
There comes a time when you need to wire up three, four, or more identical i2c devices to a common microcontroller. Maybe you’re thinking about driving 128 seven-segment displays with eight of those MAX6955 16-way digit drivers, or maybe you have a robot full of joints–each of which needs a BNO055 inertial sensor for angle estimation. (See above.) Crikey! In both of those cases, you’re best bet might be a schnazzy I²C device that can do most of the work for you. The problem? With a single I²C bus, there’s no standard way defined in the protocol for connecting two or more devices with the same address. Shoot! It would’ve been handy to wire up three BNO055 IMUs or eight MAX6955s and call it a day. Luckily, there’s a workaround.
We’ve seen some clever tricks in the past for solving this problem. [Marv G‘s] method involves toggling between a device’s default and alternate address with an external pin. This method, while clever, assumes that the device (a) has an alternate I²C address and (b) features an external pin for toggling that address.
I’ll introduce two additional methods for getting the conversation started between your micro’ and your suite of identical sensors. The first is “a neat trick,” but somewhat impractical for widespread use. The second is far more production-worthy–something you could gloat over and show off to your boss! Without further ado, let’s get started with Method 1.
Lastly, if you’d like to follow along, feel free to check out the source code on Github.
The Test Setup:
In both methods, I’m using the same sensor setup to check that each circuit behaves correctly. I happened to have a bunch of extra BMA180s on the bench, so I rolled out an example based on these chips. Back in the day, the BMA180 was a pretty common three-axis digital accelerometer. It has an I²C interface with two optional addresses. For the purpose of this example, I’m fixing them all with the same address. I’ve mounted three of these guys on mutually perpendicular axes of my acrylic “test cube,” and I’m reading each chip’s Z-axis. In this configuration I can easily pick out the gravity vector from the corresponding sensor as the data goes flying by my serial port window. If I can uniquely address each sensor and read the data, I’ve got a working circuit.
Method 1: Splicing Clocks into Chip-Selects
This method tips its hat towards SPI in that it behaves in an oddly similar fashion. If you’re feeling rusty on SPI, here’s a quick recap.
A Quick SPI Refreshment:
SPI, like I²C, is another protocol that shares both its clock and data lines with multiple slave devices. The difference, though, lies in the addressing scheme to talk to these devices that share the same bus. With SPI, while clock and data lines are shared, devices are addressed with separate chip-select (CS) lines.
The master microcontroller dedicates a unique output pin to each device (~SS1, ~SS2, and ~SS3 in this illustration). When the master micro’ wants to talk to a device, it asserts that device’s chip-select input pin by pulling it to logic LOW, and the conversation begins over the data bus. With the chip select LOW, the corresponding slave listens to the data on the bus. Meanwhile, all other devices ignore the conversation between the master and it’s chosen slave by keeping their bus pins in a high impedance state.
Giving I²C Its Own Chip-Selects:
With I²C, Clock (SCL) and Data (SDA) lines are still shared between all I2C slave devices, but the addressing scheme happens by sending a message heard by all devices on the bus. To single out one device on the shared bus, the master first passes down the address of the slave device it wants to talk to, after which that slave replies with an ACKnowledge, and all other slaves ignore the data that follows until both data transmission is complete and the bus is “released.”
Because we have the problem of multiple devices with shared addresses, in theory, all of these devices would reply when the master passes down their shared address, and there’s no way for the master to single out a single device. In reality, this behavior is undefined on the I²C protocol.
Yikes! Anything goes when we wander away from defined behavior, so we try to avoid these things in practice.
According to the I²C spec, It just so happens that an I²C slave device will ignore changes on the data line (SDA) provided that the clock line (SCL) is held high. In this method, I’ll “split” the SCL line into multiple SCL lines such that each shared I²C device gets its own SCL. By selectively rerouting the clock to each I²C device one-at-a-time, I’ve essentially turned the SCL line into a “chip select.”
To chop up that clock line, I’ll need a demultiplexer. A demultiplexer (or decoder) takes a logical input and reroutes it to one of several outputs based on the binary select lines.
I’ve dropped in the 74AC11138 eight-way demultiplexer for this task. It’s fast, capable of switching at megahertz rates, and its outputs default to logic HIGH. That second note is handy since idle SCL lines also default to logic HIGH.
The setup is shown in a simplified schematic above. In it, I’m using a Teensy 3.0 posing as the I²C bus master. To the right of the Teensy is the collection of identical chips, BMA180 accelerometers in this case. In the middle is the 74AC11138 eight-way demultiplexer.
Cons of this Method:
There’s a minor drawback with this technique, though, in that it doesn’t support I²C’s clock-stretching feature. Taking a step back, this method assumes that the SCL line is inherently unidirectional, controlled by only the I²C bus master. In other words, we’re making the assumption that data on the SCL line is only sent from master to slave and never the other way around. If your I²C slave devices implement clock-stretching, however, this assumption breaks down.
What is Clock Stretching?
Clock stretching is a method defined by the I²C protocol where the chip needs to “buy itself more time” and holds the SCL line low, hence, signalling to the master that it’s not ready for the upcoming data. In this scenario, the slave actively controls the SCL line, and it happens to be the only case where data moves up the SCL line from slave to master. In a setup with our demultiplexer between the master and our set of identical slaves, these slaves won’t be able to send back the clock-stretching signal to the master to indicate that they aren’t ready for data, if they happen to implement clock stretching. That said, clock stretching is a pretty rare feature among I²C-compatible devices, so this method is likely to work among a number of chips out now.
More Next Week
That’s all for Method 1. Thanks for tuning in, and check back next week for a slightly-more-professional method of tackling this same problem.
Everyone’s first microcontroller project is making an LED blink. It’s become the de-facto “Hello World” of hardware hacking. There’s something about seeing wires you connected and the code you wrote come together to make something happen in the real world. More than just pixels on a screen, the LED is tangible. It’s only a short jump from blinking LEDs to making things move. Making things move is like a those gateway drug – it leads to bigger things like robots, electric cars, and CNC machines. Computer Numerical Control (CNC) is the art of using a computer to control movement. The term is usually applied to machine tools, which cut, engrave, or perform other operations on wood, plastic, metal and other materials. In short, tools to make more things. It’s no surprise that hackers love CNCs. This week’s Hacklet is all about some of the best CNC projects on Hackaday.io!
We start with [Charliex] and Grizzly G0704 CNC Conversion. [Charliex] wanted a stout machine capable of milling metal. He started with a Grizzly G0704, which is small compared to a standard knee mill, but still plenty capable of milling steel. [Charliex] added a Flashcut CNC conversion kit to his mill. While they call them “conversion kits” there is still quite a bit of DIY ingenuity required to get a system like this going. [Charliex] found his spindle runout was way out of spec, even for a Chinese mill. New bearings and a belt conversion kit made things much smoother and quieter as well. The modded G0704 is now spending its days cutting parts in [Charliex’s] garage.
Next up is [brashtim] with Makesmith CNC. Makesmith was [brashtim’s] entry in the 2014 Hackaday prize. While it didn’t win the prize, Makesmith did go on to have a very successful Kickstarter, with all the machines shipping in December of 2014. The machine itself is unorthodox. It uses closed loop control like large CNC machines, rather than open loop stepper motors often found in desktop units. The drive motors are hobby type servos. We’re not talking standard servos either – [brashtim] picked microservos. By using servos, common hardware store parts, and laser cut acrylic, [brashtim] kept costs down. The machine performs quite well though, easily milling through wood, plastic, foam, and printed circuit boards.
Next we have [Kenji Larsen] with Reactron material processor: Wireless CNC mill. [Kenji] started with a Shapeoko 2, and gave it the Reactron treatment. The stock controller was replaced with a Protoneer shield, which is connected to the Reactron network via a HopeRF radio module. The knockoff rotary tool included with the kit was replaced with a DeWalt DW660 for heavy-duty jobs, or a quieter Black and Decker RTX-6. A tool mounted endoscope keeps an eye on the work. [Kenji] mounted the entire mill in a custom enclosure of foam and Roxul insulation. The enclosure deadens the sound, but it also keeps heat in. [Kenji] plans to add a heat exchanger to keep things cool while maintaining relative quiet in his shop.
Finally we have a [hebel23] with DIY Multiplex Plywood CNC Router. [hebel23] wanted to build a big machine within a budget – specifically a working area of 400 x 600 x 100 mm and a budget of 800 Euro. As the name implies, [hebel23] used birch plywood as the frame of his machine. He chose high quality plywood rather than the cheap stuff found in the big box stores. This gives the machine a stable frame. The moving components of the machine are also nice – ball screws, linear bearings, and good stepper controllers. The stepper motors themselves are NEMA-23 units, which should give the CNC plenty of power to cut through wood, plastic, and even light cuts on metal. [hebel23] spent a lot of time on the little details of his CNC, like adding an emergency stop switch, and a wire-chain to keep his gantry control wires from ending up tangled up in the work piece. The end result is a CNC which would look great in anyone’s workshop.