For the last decade or so, [Jason] has wanted to build an underwater robot. Can you blame him? More recently, he’s been researching sonar sensing and experimenting with the relatively inexpensive HC-SR04 module. Since he had good luck getting it to work with a PC sound card and a Stellaris Launchpad, he figured it was time to try using it underwater.
Hydrophone research led him to the idea of submerging the sensor in mineral water oil to both seal it and couple it with the water. Unfortunately, the HC-SR04 only sends one pulse and waits for echo. Through the air, it reliably and repeatedly returned a small value. Once inside a pill bottle filled with mineral oil, though, it does something pretty strange: it fluctuates between sending back a very small value and an enormous value. This behavior has him stumped, so he’s going to go back to the Launchpad unless you can help him figure out what’s going on. Should he use a different method to seal it?
Fail of the Week is a Hackaday column which runs every Thursday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.
Filed under: Fail of the Week, Hackaday Columns
Need something to get you revved up for the Hackaday get-together in Munich next month? Don’t miss out on this year’s Make Munich.
The two-day festival will be held in Munich on November 1st and 2nd. Last year there were about 2500 in attendance and this year is shaping up to be even bigger! Wander through the exhibits to see what others have been building during their spare time. You’ll see everything from 3D printing, to custom electronics, crafts, art pieces, talks, and more. What a wonderful way to draw inspiration for the projects you want to pull off this winter!
What’s that you say? You have something to show off at Make Munich? You could always just carry it around with you but maybe it’s better to apply for a booth or to give a talk.
Seeing all that Make Munich has to offer should get you excited about doing some hands on hacking and you’ll have the chance just a couple of weeks later. The Hackaday crew is hard at work planning our own afternoon hackathon and evening party. Block out your calendar on Thursday, November 13th. We’re not quite ready to give away free tickets but watch the front page for an announcement soon!
We’re lucky to have a lot of people in the Munich area helping get the word out. A special thanks to [Nils Hitze] who is organizing Make Munich and has already connected us with a lot of interesting parts of the hacker community in the area.
Filed under: cons
If we were running a contest to give away a trip to space for building the most innovative open hardware project a few years ago, the winner would inevitably be a 3D printer. Times have changed, 3D printing is reaching the limits of what can be done with simple plastic extrusion, and there are new hardware challenges to be conquered. One of the challenges facing hardware designers is the ability to create and assemble electronic circuits quickly. For that, there are a few pick and place machines being developed, the lowest cost being the FirePick Delta. It sells itself as a $300 pick and place machine borrowing heavily from the RepRap project, enabling tinkerers and engineers to assemble PCBs quickly.
[Neil Jansen] is the project lead for the FirePick Delta, and along with team members ranging from software developers in the bay area, to electronics technicians and high school students, they’ve created what will become the lowest cost and most capable pick and place machine available. Already the machine has tape feeders, tray feeders, a vision system, and modules to dispense solder paste. It’s an astonishing accomplishment, and were it not for some damage in shipping, we would have a video of [Neil] demoing the FirePick at Maker Faire NY.
In lieu of that, we do have a bio on [Neil] and what challenges he’s faced in building the FirePick. You can read that below, or check out their second demo video for The Hackaday Prize:
Robotics, and Extreme Circuit Boarding. The world does not yet recognize Extreme Circuit Boarding as a sport. But it basically consists of consuming large amounts of Red Bull, listening to loud Dubstep and Electro music, and designing crazy circuits, and then building them as quickly as possible when the boards and parts arrive. It’s extreme because you have to get the designs right on the first rev, with no rework. Kind of in the spirit of a hackathon or a Tattoo Inkmaster reality show. Since no one knows about this sport yet, I’m the unofficial world champion for 2014.
Aerospace, GPS / GNSS receivers, radios, autopilots, transponders, and collision avoidance systems, blah blah blah… My job is the hardware/software testing and verification of these boxes. These days I mostly write software, but at my last job, on a typical day, I’d be doing CAD in SolidWorks, schematic capture and pcb layout, writing embedded code, wiring test jigs and harnesses, requirements capture, and lots of other stuff. I only have a high school background, everything else is self-taught. Even though it’s a big stuffy company, I still get to do lots of different things, which keeps me happy. Our other team members have day jobs as well. Karl Lew works as a full stack software developer in Bay Area, California. Christian Lerche is an electronics technician in Denmark and works in a lab that works on locomotive electronics. Dayton Pid is our youngest member at 16 and is in high school. And Thomas Kilbride is in college at Indiana University.
My passion is basically the pursuit of reality through objectivism, critical thinking, and logic, and the propagation of those ideas leading by example, living by principles, appreciating the beauty of life, and taking personal accountability for my actions.
That honor almost went to my 2009 model MacBook Unibody recently. I have been using it as my main development platform for our Hackaday project, mostly while dual-booted into Windows 7. It’s extremely slow, sometimes requiring a few minutes to switch between different apps. It was maxed out at 4GB of RAM, and of course, every time I needed to dual-boot back to OSX to do photo editing or whatever, that was time lost. The battery has been dead for almost two years, so it’s pretty much anchored to the desk. I was almost about to take it out back and destroy it office-space style, while playing the obligatory “Still” from the Geto Boys from iTunes until it wouldn’t play any more. But instead, I hobbled together a new PC out of pieces I had lying around, and a new motherboard, CPU, and 16 GB of RAM. My productivity towards the HaD project since has probably tripled since I’ve gotten that taken care of.
I’m OS agnostic for the most part. On a typical day, I’m using Windows, OS X, BSD, Linux (both desktop and embedded), and occasionally esoteric RTOS platforms. I’m forced to run Windows for CAD, but it’s my least favorite to program on, and I agree with it the least philosophically. I use my MacBook for video editing, audio editing, photoshopping, and other graphic or A/V type stuff. Linux is awesome for embedded and server applications, but I can’t run Cubify Design on it, and I feel that the A/V apps on OS X are more matured and polished than anything available on Linux.
Linux would be my absolute favorite, but big corporations that make important pieces of software still won’t write programs for it, for some reason. In my dream universe, Microsoft would do like Apple did, and ditch their underlying operating system and .NET crap, and go with something POSIX (say, BSD) for their backend, thereby making it easier to write multi-platform software applications. They could even keep their crappy desktop look the same. But we all know they’d never, ever do that.
- Create an open-source micro-factory, capable of creating amazing things locally and sustainably.. Ideally this is what Karl and I hope FirePick will evolve into. We see this as the logical progression of 3D fuse-filament printing, 3D metal printing, laser cutting, and SMT component assembly. If we can make it profitable for companies to at least make prototypes and small runs in America (or pretty much any other country for that matter), rather than everything coming from China, then we can say that we’ve done something truly empowering.
- “Hard” Artificial Intelligence (as opposed to the status quo “soft” AI). When I was a kid, I dreamed of pioneering in this field. Google claims to be working on this sort of stuff. These days, I’d be happy to be a cog in the wheel of some grand decades-long project to accomplish true AI.
- I have to at some point finish a few pointless projects that I put off to work on this project… If I get the pick and place working well, then these will be a slam dunk. I want to finish my Nixie Tube wrist watch, that uses some Burroughs B-4998 tubes, aka, the smallest Nixie tubes in the world. Second, I want to make a really tiny robot (40mm x 40mm) with two wheels and a camera, that can sort a pile of M&Ms by color. Hopefully with a powerful ARM processor and lots of sensors, running SLAM technique, kalman filtering, etc. Third is a telepresence robot with two robotic arms and gimbal stereo vision on a segway syle inverted pendulum, controlled with a LEAP motion controller and an Oculus Rift. Then I could just mail my artificial self around the world and see cool places, and get to interact with stuff, while staying on schedule.
I was really intrigued by the metal 3D printer that was one of the first projects to be tagged with TheHackadayPrize. I think it would have required a crazy amount of metallurgy skills to pull off successfully, and I’m not sure they had said skills, but the concept was still really cool.
We actually have an incredibly complicated project, compared to say, OpenMV (which we love by the way). We’ve had problems with our delta arm linkages, backlash / accuracy problems, Hierarchical BOM generation, and feeder problems. However, we’ve got some really innovative ways to mitigate them that will hopefully be documented on our site by the Sept 29th milestone. We’d be a month further along if we didn’t have hundreds/thousands of BOM items to document, so, uh, thanks for making us do all of that :)
Thanks to the FirePick Delta core team, and all the people who skulled our project and believe in our idea. You guys rock.
Filed under: 3d Printer hacks, The Hackaday Prize
Don’t throw out that old printer! Not that you would, but even if you’ve already scavenged it for parts, you can use the shell and the rollers to make a rock/coin/what-have-you tumbler. If your printer is part scanner, it might end up looking as cool as [th3_jungle_inv3ntor]‘s. You’ll have to laser-cut your own arachnid to supervise from above, though.
Somewhere between having an irreparable printer, being inspired by another tumbler, and the desire to make a mancala set for his sister-in-law, [th3_jungle_inv3ntor] was sufficiently motivated to get out his hacksaw and gut the printer. He used the main paper roller and its motor to do the tumblin’, and a smaller roller to help accommodate different jar sizes.
Aside from adding those sweet blue LEDs, he wired in a toggle switch, a speed control pot, and an LM317 to govern the tumbling rate. Unfortunately, the rocks in [th3_jungle_inv3ntor]‘s town are too soft and crumbly, so he can’t make that mancala set after all. But hey, (almost) free stuff tumbler.
No dead printers lying around? If you have a drill and a vise, you could always make a tumbler that way, and nothing is compromised but the peaches jar.
Filed under: green hacks, how-to
When we first heard about it a few weeks ago, we knew the ESP8266 UART to WiFi module was a special beast. It was cheap, gave every microcontroller the ability to connect to a WiFi network, and could – possibly – be programmed itself, turning this little module into a complete Internet of Things solution. The only thing preventing the last feature from being realized was the lack of compiler support. This has now changed. The officially unofficial ESP8266 community forums now has a working GCC for the ESP8266.
The ESP8266 most people are getting from China features a Tensilica Xtensa LX3 32-bit SOC clocked at 80 MHz. There’s an SPI flash on the board, containing a few dozen kilobytes of data. Most of this, of course, is the code to run the TCP/IP stack and manage the radio. There are a few k left over – and a few pins – for anyone to add some code and some extended functionality to this module. With the work on GCC for this module, it’ll be just a few days until someone manages to get the most basic project running on this module. By next week, someone will have a video of this module connected to a battery, with a web-enabled blinking LED.
Of course that’s not the only thing this module can do; at less than $5, it will only be a matter of time until sensors are wired in, code written, and a truly affordable IoT sensor platform is created.
If you have a few of these modules sitting around and you’d like to give the new compiler a go, the git is right here.
Filed under: Microcontrollers, wireless hacks
Students at the University of Rochester have developed a clever optical system which allows for limited invisibility thanks to a bit of optic sorcery physics.
Almost all invisibility technologies work by taking light and passing it around the object as if it were never there. The problem is, a lot of these methods are very expensive and not very practical — and don’t even work if you change your perspective from a head on view.
[Joseph Choi] figured out you can do the same thing with four standard achromatic lenses with two different focal lengths. The basic concept is each lens causes the light to diverge to a tiny point in between itself and the next lens — at which point it begins to diverge again, filling the following lens. This means the cloaked area is effectively doughnut shaped around the tightest focal point — if you block the center point of the lens, it won’t work. But everything around the center point of the lens? Effectively invisible. Take a look at the following setup using lasers to show the various focal points and “invisibility zones”.
Pretty cool stuff — let’s see someone in our community make one! Any cool applications come to mind? It’d be quite fun with giant lenses, but we think that would probably get quite expensive pretty fast…. More info can be found in their paper on Paraxial Ray Optics Cloaking.
Filed under: misc hacks
When it was first announced in 2010, the Boxee remote was a stroke of genius. Not because it controlled the BoxeeBox, the set-top media center PC, mind you. It was impressive because the reverse side of the remote had a small qwerty keyboard, just the thing for searching menus loaded up with movies and TV shows and entering URLs. [Martin]‘s BoxeeBox loved his BoxeeBox, but it’s an old device now, with some support for web streaming (including Netflix) gone.
Other media center devices have filled the void in [Martin]‘s life, but he loved that Boxee remote. Getting it working on his XBMC-equipped PC was a top priority. This meant figuring out a way to connect the RF receiver from a BoxeeBox to a USB port. It turns out this is pretty easy, requiring only a few parts and half of a USB cable.
[Martin] traced out the connectors on the RF receiver for the BoxeeBox, and found the usual V+, V-, Power, and Ground connections found in a USB cable. The receiver operated at 3.3 Volts, so stepping down the voltage required regulator. The rest of the project was simply putting everything in a project box and stuffing it behind his PC.
Windows identifies the RF receiver as a normal keyboard, so everything went swimmingly. Since [Martin] built this small device, a few people have come up with better keyboard layouts for XBMC and the Boxee remote, allowing this device to function far into the future.
Filed under: peripherals hacks
Back in the day, and by that we mean the late 80s and early 90s, arcade machines started using the JAMMA standard, a means for a single arcade board to be wired in to the controllers, video output, and other ephemera found in arcade cabinets. Since then, quite a few people have amassed a collection of these vintage arcade boards. Putting them to use requires a means of providing power, video output and controller connections. The usual way of wiring in a joystick and buttons is with a wiring harness, but [Mike] and [Jasen] are connecting Xbox 360 and PS3 controllers to their machines with the help of a Raspberry Pi Hat.
[Mike] and [Jasen] created Project Kajitsu to replace the expensive ‘Supergun’ controllers arcade game collectors usually use to play Street Fighter, X-Men, and Battletoads. They’re using the USB ports on a Raspberry Pi B+ to listen to two XBox or PS3 controllers and translate button mashing into something these old games can understand.
The guys are using a custom Linux Kernel that boots in just a few seconds, providing the bare minimum of an OS to support the controllers. The board itself is extremely simple; just a few bus transceivers, caps, resistors, and headers. They have an iPhone-quality vertical video proof of concept video (below), and although they’re still figuring out the best way to simplify the Bluetooth pairing process, they’re well on their way to supporting wireless controllers.
This board only provides controller input. If you have one of these old boards, you will need video output. That’s another project entirely, but very simple if you have an SCART monitor.
Filed under: playstation hacks, xbox hacks
Unless you’ve been living under a high voltage transformer, you’ve probably heard that NASA has grounded the Space Shuttle fleet. This makes getting stuff to and from the International Space Station slightly more difficult. With the growing need to get small experiments back to the surface quickly and safely, NASA is researching an idea they call Small Payload Quick Return, or SPQR (pdf warning). Basically, they toss the experiment out of the window, use drag to slow it down, and then use a High Altitude High Opening (HAHO) self guiding parafoil to steer the thing down to a predefined location on the surface.
Now, what we’re interested in is the self guided parafoil part, as it takes place in known hacker territory – around 100,000 feet. This is the altitude where most high altitude balloon experiments take place. NASA is throwing a bunch of money and brainpower to research this part of the system, but they’re having problems. Lots of problems.
Stick around after the break and see if you can help, and maybe pick up some ideas on how to steer your next High Altitude Balloon project back to the launch pad.
Want to get on NASA’s radar? Send up a HAB payload to the Stratosphere and return it to a specific GPS address in one piece. Post it on Hackaday.io and keep your phone handy. Because they are having a lot of trouble doing this, and would surely be interested in your tech.
So the basic idea is:
- Deploy para foil
- Get GPS lock.
- Use a microcontroller to move some servos and steer the Near Space Craft to a specified GPS address.
- Corkscrew down to the surface.
Pulling this off is not as easy as it sounds, and NASA is finding this out the hard way. The AMES Research Center has delegated the HAHO part of the SPQR project to a handful of select universities. They have done several studies and experiments, most of which have ended in complete failure. (All links are pdf)
To summarize just a few of the problems -
- There is a tendency for the system to develop a flat spin, where the payload and para foil ‘orbit’ each other at a high speed, proving to be unrecoverable.
- The para foil will not inflate because of the low air density.
- The lines get tangled easily.
Be sure to check out some of the studies and let us know your thoughts. NASA just might be listening. How would you solve these difficult problems?
Filed under: Ask Hackaday, Hackaday Columns
I became aware of harmonics and the sound of different shaped waveforms early in my electronics career (mid 1970’s) as I was an avid fan of [Emerson Lake and Palmer], [Pink Floyd], [Yes], and the list goes on. I knew every note of [Karn Evil 9] and could hear the sweeping filters and the fundamental wave shapes underneath it.
I remember coming to the understanding that a square wave, which is a collection of fundamental and (odd) harmonics frequencies, could then be used to give an indication of frequency response. If the high frequencies were missing the sharp edges of the square wave would round off. The opposite was then true, if the low frequencies were missing the square wave couldn’t “hold” its value and the top plateau would start to sag.
Using a copy of [SPICE] a free circuit simulation application, I have created several sine wave sources and summed them together. Seen here, the waves combine into a square wave with it looking squarer as I add more and more signals that are multiples of the main frequency called harmonics. When building a square wave only odd harmonics are used as even harmonics tend to cancel themselves out.
Knowing now that we can build a square wave from multiple signals it then stands to reason that we can take a waveform apart and display its constituent pieces or signals.
Enter the Spectrum Analyzer; In this case it’s some math that occurs in my Digital [Tektronix] scope in the form of a Fast Fourier Transform (FFT). For this demonstration I left the 102 pound [HP] RF Spectrum Analyzer in its nook below the bench.
Sure enough, the odd harmonics stand out right where they are supposed to be. I could lay a small ruler touching the tips of the waves and they form a straight line. This is possible as the display itself has already been converted to a logarithmic scale.
My inclination is to launch into a diatribe of how these frequencies, always higher than the fundamental, combine to create noise in the RF Spectrum and how the interaction of these waves also get caught up in transmission lines, ground planes, apertures and antennas. Instead I will go back to my roots and put the signals to a speaker so that they might be heard. It’s easy to hear a note from [ELP Lucky Man] and when listening carefully one can start to equate sine wave distortions with “spray” or the extra harmonics that give some depth to a note being played on a synth. Play around with this. Who knows, maybe you’ll end up getting the band back together?
Filed under: classic hacks, Featured
Yeah, check out that line-up poster. We’re so lucky to have an unreal collection of talented people pitching in to make this event happen. This Saturday is going to be Epic! Good thing since we’re celebrating 10-years-of-Hackaday!
What’s that you say? You don’t live in Los Angeles and are going to miss out? We’ll be live-streaming the event on:
You should put this feed on in the background while you hone your solding skills on that project you’ve been meaning to finish.
We will also be recording and posting the talks so that you may watch at your leisure.Here’s a quick run-through of all that we have going on:
The day will start with three workshops, the first is a tiny-robot build based on [shlonkin's] design. The second is a lockpicking workshop hosted by [datagram] and [Jon King]. And the third is a Lithium charger workshop and build hosted by [Todd Black].
The afternoon brings the mini-conference with major talks by [Ryan '1o57' Clarke], [Steve Collins], [Quinn Dunki], [Jon McPhalen], and [ThunderSqueak]. There will be Lighting Talks by [Tod Kurt] and [Arko], as well as special appearances by Hackaday head editors from the past decade.
Of course there will be a handful of the Hackaday writers in town for the event as well. [Adam Fabio] will be leading the robot workshop, [James Hobson] will be leading a build-off throughout the day, and [Mike Szczys], [Brian Benchoff], and [Bil Herd] will be on hand to do whatever is needed.
If you are interested in attending there may still be tickets available. We have been sold out but we’ve asked anyone who is unable to attend to cancel their ticket so new tickets become available as that happens. Yep, fans of Hackaday are courteous people. Yet another reason to celebrate.
Filed under: Featured
The development of the Hackaday community offline password keeper has been going on for a little less than a year now. Since July our beta testers have been hard at work giving us constant suggestions about features they’d like to see implemented and improvements the development team could make. This led up to more than 1100 GitHub commits and ten thousand lines of code. As you can guess, our little 8bit microcontroller’s flash memory was starting to get filled pretty quickly.
One of our contributors, [Miguel], recently discovered one compilation and one linker flags that made us save around 3KB of Flash storage on our 26KB firmware with little added processing overhead. Hold on to your hats, this write-up is going to get technical…
Many coders from all around the globe work at the same time on the Mooltipass firmware. Depending on the functionality they want to implement, a dedicated folder is assigned for them to work in. Logically, the code they produce is split into many C functions depending on the required task. This adds up to many function calls that the GCC compiler usually makes using the CALL assembler instruction.
This particular 8-bit instruction uses a 22-bit long value containing the absolute address of the function to call. Hence, a total of 4 flash bytes are used per function call (without argument passing). However, the AVR instruction set also contains another way to call functions by using relative addressing. This instruction is RCALL and uses an 11-bit long value containing the offset between the current program counter and the function to call. This reduces a function call to 2 bytes and takes one less clock cycle. The -mrelax flag therefore made us save 1KB by having the linker switch CALL with RCALL instructions whenever possible.
Finally, the -mcall-prologues compiler flag freed 2KB of Flash storage. It creates master prologue/epilogue routines that are called at the start and end of program routines. To put things simply, it prepares the AVR stack and registers in a same manner before any function is executed. This will therefore waste a little execution time while saving a lot of code space.
Filed under: Hackaday Columns
You’d think we would be done with the World Maker Faire posts by now, but no! We keep looking at our memory cards and finding more awesome projects to write about.
[Renaud Iltis] flew over from France to show off MiniCut2D, his CNC hot wire foam cutter. MiniCut2D uses X, Y, and Z stepper motors much like a 3D printer. Rather than print though, it pulls a heated nichrome wire through styrofoam. Foam cutting is great for crafts, but it really takes off when used for R/C aircraft. [Renaud] was cutting some models out of Depron foam in his booth. [Renaud] has set up FrenchFoam.com as a central location for users to upload and share designs in DXF format.
One of the neater features of MiniCut2D is that it can be loaded with a stack of foam boards to make several cuts at once. Not only is this a time saver when cutting repeating designs like wing ribs, but it also ensures the cut pieces are identical. Hey, even CNCs make mistakes once in a while.Omniwheel Robot
In the MakerShed booth, we found [Victor Aprea] showing off Wicked Device’s new product, the Omniwheel Robot. Omniwheel utilizes a holonomic drive with omnidirectional wheels. The kit comes with a Nanode Zero, Wicked Devices’ own Arduino Uno clone, a motor control board, 3 motors, 3 omnidirectional wheels, and a whole list of hardware. The only thing needed to complete the kit is a radio control unit and receiver. Omniwheel may be simple, but we found driving it around to be mesmerizing – and a bit challenging.It’s a good thing [Victor] brought that plexiglass cover, as we bumped it a few times.
We’d love to see one of these little bots with a couple of sensors and autonomous control. If you build one, make sure to post it to Hackaday.io!
Filed under: robots hacks, tool hacks
If you want to take a photograph with a professional look, proper lighting is going to be critical. [Richard] has been using a commercial lighting solution in his studio. His Lencarta UltraPro 300 studio strobes provide adequate lighting and also have the ability to have various settings adjusted remotely. A single remote can control different lights setting each to its own parameters. [Richard] likes to automate as much as possible in his studio, so he thought that maybe he would be able to reverse engineer the remote control so he can more easily control his lighting.
[Richard] started by opening up the remote and taking a look at the radio circuitry. He discovered the circuit uses a nRF24L01+ chip. He had previously picked up a couple of these on eBay, so his first thought was to just promiscuously snoop on the communications over the air. Unfortunately the chips can only listen in on up to six addresses at a time, and with a 40-bit address, this approach may have taken a while.
Not one to give up easily, [Richard] chose a new method of attack. First, he knew that the radio chip communicates to a master microcontroller via SPI. Second, he knew that the radio chip had no built-in memory. Therefore, the microcontroller must save the address in its own memory and then send it to the radio chip via the SPI bus. [Richard] figured if he could snoop on the SPI bus, he could find the address of the remote. With that information, he would be able to build another radio circuit to listen in over the air.
Using an Open Logic Sniffer, [Richard] was able to capture some of the SPI communications. Then, using the datasheet as a reference, he was able to isolate the communications that stored information int the radio chip’s address register. This same technique was used to decipher the radio channel. There was a bit more trial and error involved, as [Richard] later discovered that there were a few other important registers. He also discovered that the remote changed the address when actually transmitting data, so he had to update his receiver code to reflect this.
The receiver was built using another nRF24L01+ chip and an Arduino. Once the address and other registers were configured properly, [Richard's] custom radio was able to pick up the radio commands being sent from the lighting remote. All [Richard] had to do at this point was press each button and record the communications data which resulted. The Arduino code for the receiver is available on the project page.
[Richard] took it an extra step and wrote his own library to talk to the flashes. He has made his library available on github for anyone who is interested.
Filed under: Arduino Hacks, radio hacks
At all the big Maker Faires, the Power Racing Series makes an appearance, turning old Power Wheels into race cars that whip around the track at dozens of miles an hour. [Charles] is somewhat famous in the scene – there’s even a clause in the official rules named after him – so of course anything he brings to race day will be amazing. It was. It used a battery pack from a Ford Fusion plugin hybrid, a custom body, and a water cooling unit from a dead Mac G5.
A few months ago, we saw [Charles] tear into the battery pack he picked up for $300. This is the kind of equipment that will kill you before you know you’ve made a mistake, but [Charles] was able to take the pack apart and make a few battery packs – 28.8v and 16Ah – enough to get him around the track a few times.
The chassis for the Chibi-Mikuvan was built from steel, and the bodywork was built from machined pink foam, fiberglassed, and finished using a few tips [Charles] gleaned from [Burt Rutan]‘s book, Moldless Composite Sandwich Aircraft Construction. The motor? That’s an enormous brushless motor meant for a 1/5th scale RC boat. The transmission is from an angle grinder, and the electronics are a work of art.
The result? A nearly perfect Power Wheels racer that has a curb weight of 110 pounds and tops out at 25 mph. It handles well, too: in the videos below, it overtakes the entire field of hacky racers in the Power Wheels Racing competition at Maker Faire NYC, and afterwards still had enough juice to tear around the faire.
Filed under: transportation hacks
Pain is a good thing. It tell us to pull our hand away from the stove and to stay off a turned ankle. But we all have different experiences of pain, and chronic pain degrades our quality of life. A person’s reports of pain will vary from one day to the next based on many factors, so the 1-10 scale isn’t universally effective in determining a person’s pain level. [Scott]‘s entry into The Hackaday Prize is based on the classic cold pressor testing device, which measures changes in heart rate and blood pressure in a patient while their hand is immersed in ice water for one minute.
[Scott] has tentatively dubbed his device The Pain Machine, but it does more than the typical cold pressor apparatus; it also delivers simulated pain relief in the form of warm water when the valves are reversed. In addition, the subject under testing can push a button when they’ve had enough. While his original plan used external sources of hot and cold water, [Scott] pulled a couple of Peltier coolers from some wine chillers for a more contained design.
The Pain Machine uses an Arduino ATMega 2560 to control gravity flow solenoids, collect temperature data, and send the data cloudward. A couple of 110V pumps circulate the water. [Scott] will open up the code once he has finished commenting it and fleshed it out with use cases. For now, you can check out his two-minute entry video after the break.
Filed under: The Hackaday Prize
It’s starting to be that time of year again; the Halloween-themed hacks are rolling in.
[John Lauer] needed a propane-powered flame effect for his backyard ICBM “crash site”. Rather than pony up for an expensive, electronically-controlled propane
valve, he made a custom bracket to connect a stepper motor to the propane burner’s existing valve.
The hack is almost certainly a case of “everything looks like a nail when you have a hammer” but you have to admit that it works well and probably didn’t take [John] all that much time to whip up. Maybe everyone should have a couple spare stepper motors with driver circuitry just lying around ready to go? You know, just in case.
All the details of the build are in the video. If you’re done watching the flames, skip to around 2:50 where we see the adapter in action and then [John] steps us through its construction.
You may have seen coverage of the TinyG motor controller here before.
Additional thanks to [Alden Hart] for the tip.
Filed under: cnc hacks, Holiday Hacks
There are a few ways of playing .WAV files with a microcontroller, but other than that, doing any sort of serious audio processing has required a significantly beefier processor. This isn’t the case anymore: [Paul Stoffregen] has just released his Teensy Audio Library, a library for the ARM Cortex M4 found in the Teensy 3 that does WAV playback and recording, synthesis, analysis, effects, filtering, mixing, and internal signal routing in CD quality audio.
This is an impressive bit of code, made possible only because of the ARM Cortex M4 DSP instructions found in the Teensy 3.1. It won’t run on an 8-bit micro, or even the Cortex M3-based Arduino Due. This is a project meant for the Teensy, although [Paul] has open sourced everything and put it up on Github. There’s also a neat little audio adapter board for the Teensy 3 with a microSD card holder, a 1/8″ jack, and a connector for a microphone.
In addition to audio recording and playback, there’s also a great FFT object that will split your audio spectrum into 512 bins, updated at 86Hz. If you want a sound reactive LED project, there ‘ya go. There’s also a fair bit of synthesis functions for sine, saw, triangle, square, pulse, and arbitrary waveforms, a few effects functions for chorus, flanging, envelope filters, and a GUI audio system design tool that will output code directly to the Arduino IDE for uploading to the Teensy.
It’s really an incredible amount of work, and with the number of features that went into this, we can easily see the quality of homebrew musical instruments increasing drastically over the next few months. This thing has DIY Akai MPC/Monome, psuedo-analog synth, or portable effects box written all over it.
Filed under: ARM, digital audio hacks
As the Cold War conflict expanded in the 1950s, the Soviet Union dry-tested a hydrogen bomb and defense tactics became a top priority for the United States. Seeking to create a long-range nuclear missile option, the Air Force contracted Convair Astronautics to deliver SM-65 Atlas, the first in series of ICBMs. In the spotlight this week is a sort of video progress report which shows the first launch from Cape Canaveral’s LC-14 on June 11, 1957.
After the angle of attack probe is unsheathed, everyone moves out of the way. The launch is being monitored by base central control, but the swingin’ spot to spectate is the blockhouse. They have a periscope and everything. As the countdown continues, liquid oxygen pipelines whistle and wail into the idyllic Florida afternoon with the urgency of a thousand teakettles. Cameras and tracking equipment are readied, and the blockhouse’s blast door is sealed up tight.
Around T-3 minutes, it’s time to run down the go/no-go checklist in the blockhouse. It is at this point that we find out this launch was under a 10-hour countdown, which has gone exactly as planned. Some top-secret things are bleeped out on the soundtrack, but we are allowed to know the objectives of this test, which are to prove the basic elements. These include the durability of the airframe, the launching mechanics, autopilot fallback, propulsion, and overall flight stability. There’s another checklist at the two-minute warning, and the angle is set to [redacted]. At long last, it’s time to launch the [redacted] thing.
Atlas launched successfully and was stable for a little while. Shortly after launch, one engine failed and then another. Because of this, the Range Safety Officer remotely destroyed it. Debris fell all over the base and in the sea, but most of the major components were recovered for their precious data. All in all, many things went well or at least satisfactorily, and the Convair Astronautics division of General Dynamics didn’t lose their contract.
Atlas models were only in the ICBM business for a short time. Most notably, they launched the first American astronauts into orbit and enjoyed a long, illustrious career launching satellites.
Retrotechtacular is a weekly column featuring hacks, technology, and kitsch from ages of yore. Help keep it fresh by sending in your ideas for future installments.
[Thanks for sending this in, James. Happy Space Week!]
Filed under: Retrotechtacular
Atmel and Arduino teamed up at World Maker Faire to introduce the Wi-Fi shield 101. [Gary] from Atmel gave us the lowdown on this new shield and its components. The shield is a rather spartan affair, carrying only devices of note: an Atmel WINC1500 WiFi module, and an ATECC108 crypto chip.
The WINC1500 is a nifty little WiFi module in its own right. WINC handles IEEE 802.11 b/g/n at up to 72 Mbps. 72Mbps may not sound like much by today’s standards, but it’s plenty fast for most embedded applications. WINC handles all the heavy lifting of the wireless connection. Connectivity is through SPI, UART or I2C, though on the Arduino shield it will be running in SPI mode.
The ATECC108 is a member of Atmel’s “CryptoAuthentication” family. It comes packaged in an 8-pin SOIC, and is compatible with serial I2C EEPROM specifications. Internally the similarities to serial EEPROMs end. The ‘108 has a 256-bit SHA engine in hardware, as well as a Federal Information Processing Standards (FIPS) level random number generator. Atmel sees this chip as being at the core of secure embedded systems. We think it’s pretty darn good, so long as we don’t hear about it at the next DEFCON.
The Wi-Fi shield 101 and associated libraries should be out in January 2015. We can’t wait to see all the new projects (and new ways to blink an LED) the shield will enable.
Filed under: Arduino Hacks, wireless hacks