Unless you’re a collector or a hunter, waterfowl decoys are pretty boring. Radio controlled decoys that can putt around are kind of cool. But a radio controlled animatronic fire-breathing decoy? That’s the very opposite of boring.
This is another one of those projects from the “Why the Hell Not?” files, and [David Windestål] is pretty clear that there’s no practical purpose for a flame-throwing, floating fowl. This doesn’t stop him from including 100-plus pictures as well as the video below in his detailed build log, and there are actually some tips to be had here. The remains of an RC racing boat that can hit 30 km/h are used for the floating gear; sadly the decoy superstructure reduces the speed by a factor of 10, so if you’re hoping for a high-performance decoy you’ll be disappointed. The rotating head and evil glowing LED eyes make up for that, though, as does the articulated beak. But the butane flame thrower, with laser-cut acrylic frame and servo flow control, really adds to the menace of the Duck from Hell. Or goose. Whatever.
As with most projects of this type, this is clearly a “do not try this at home” build, but it looks like a bunch of fun. For more ill-advised fun check out this mini RC flame thrower or the Doof warrior ukulele.
Last weekend was Sparklecon, the premier meetup in Southern California of dorks dorking around, fire, electricity, welding, and general mischief. Just imagine a party of a hundred or so like-minded individuals at a hackerspace. Now imagine the entire party is the after party. That’s a pretty good idea of what happened.
The event was held at the 23b shop in Fullerton, a true hackerspace tucked away in a small industrial park. The people at 23b are using their location to their advantage: no one in the neighborhood really cares what happens after 5pm on a Friday. This allows for some very loud, very bright, and very dangerous hijinks.
There weren’t many pages missing from the Hackaday Omnibus donated to the 23b shop. Oddly, the only pages missing were the articles written by Benchoff.
There was something for everyone at Sparklecon, including:
Electric Pickle. Take a stick welder, and put a few hundred amps through a pickle. First, the pickle turns into a sodium light. Then, it turns into a carbon arc light. Best done after dark.
FPV drone racing. Flying around and crashing into trees in an abandoned lot. FPV from a few quads were projected onto the side of a building
Live music! Analog synths and Game Boys!
Tesla coils! This was a 300 amp monster, and completely analog. The spark gap was impressive by itself, but it gets really cool when you steal a fluorescent light from a fixture and stand 20 feet away from the Tesla coil.
Hammer Jenga! Cut some 2x4s up and make a tower of Jenga. Get a hammer, some colorful commentators, a dozen people, and make some competition brackets. Hackaday’s own [Jasmine] was the first champion of the night.
Sparklebot Death Battle! It’s like BattleBots, only things break more often and we don’t have [Bil Dwyer].
Hebocon! Battling robots, but much crappier than the Sparklebot Death Battle. These robots broke more often.
Analog synths provided the tunes
The Sparklebot Death Battle ring
Tesla Coils and Spark Gaps
A Hebocon bot, using a mouse trap as a weapon
A lady tribble, vibrating her way across the Hebocon ring
The basic premise of Hammer Jenga
Art was made out of the spare parts left over from the Hebocon build-off. This robot is named Art
The main event was, of course, Sparklecon’s own version of Battlebots. There were only four competitors the entire night, but the competition was fierce.
Three of the bots were wedge designs, in keeping with the ramp-ification of battling robots. The lone exception to this was [Charlie]’s Slow Bot, a cube design equipped with a spinning steel blade. The blade moves fast, but Slow Bot doesn’t. It’s a purely defensive design, meant to destroy bots trying for an easy kill. The test video of Slow Bot can be seen here:
The first fight of Slow Bot did not live up to the hype, unfortunately. After Slow Bot’s primary weapon got up to speed, the opposing bot moved in for the kill. The bolts on Slow Bot‘s blade sheared, ending the match, and leaving five or six people looking around the 23b shop for M5 bolts, or some larger bolts and a tap.
Is it all hilarously unsafe? Well, there were some plexiglas shields in front of the crowd, and most people viewed the fights on the projector beaming against the wall, anyway.
Is it worth it to go to Sparklecon? If you like dangerous experiments, soldering wires directly onto AA batteries, fire, electricity, electromagnetic fields, broken robots, and hanging out by a fire, yes. It’s a party at a proper hackerspace, making it the best kind of party ever. If history repeats itself, there will also be an afterparty at 23b following the LayerOne conference in May.
Sometimes there’s just no place like your desktop. You’ve already got your favorite development tools and references setup or installed and it’s a pain when you’re trying to work on an unfamiliar, or simply uncustomized, system. On your desktop everything is at your fingertips. If you want to search the web, the browser is just an alt-tab away. If you need a calculator, it’s right there to run. Your editor highlights syntax in your favorite colors already.
When developing on a Raspberry Pi, you leave all these creature comforts behind unless you spend the time to configure the Pi to your liking. Then it all gets wiped when you install a new distribution, like the recent change from Wheezy to Jessie. Even then it’s frustrating to switch back and forth between the desktop and the Pi because there is always something on the other system that you need. My usual comment is, “dirty word”, literally.
Cross-developing on your desktop is a very workable solution. We’re going to walk through setting up your desktop and a Pi to do this. This means loading a Pi ARM toolchain on your desktop and a debugging server on the Pi. This’ll let you develop and debug from in the comfort of your desktop. An added advantage is when you put that Pi in a robot you can debug over a wireless link.
If you’ve never used a solder paste dispenser, you’re missing out. Think about always using a crappy soldering iron, and then for the first time using a high-end one. Suddenly you’re actually not bad at soldering things! It’s kind of like that.
Most solder paste dispensers make use of compressed air, which requires an extra setup to use that you might not have. The goal of this project was to make a solder paste dispenser that doesn’t use compressed air, and doesn’t have any 3D printed parts (in case you don’t have a 3D printer) — and it looks like the inventor, [MikeM], succeeded!
We live in a world transformed by our ability to manipulate the nucleus of atoms. Nuclear power plants provide abundant energy without polluting the air, yet on the other hand thousands of nuclear warheads sit in multiple countries ready to annihilate everything, even if it’s not on purpose. There are an uncountable number of other ways that humanity’s dive into nuclear chemistry has impacted the lives of people across the world, from medical imaging equipment to smoke detectors and even, surprisingly, to some of the food that we eat.
After World War 2, there was a push to find peaceful uses for atomic energy. After all, dropping two nuclear weapons on a civilian population isn’t great PR and there’s still a debate on whether or not their use was justified. Either way, however, the search was on to find other uses for atomic energy besides bombs. While most scientists turned their attention to creating a viable nuclear power station (the first of which would only come online in 1954, almost ten years after the end of World War 2), a few scientists turned their attention to something much less obvious: plants.
Photogrammetry is a real word, and [shapespeare] built himself a nice setup to take high-res 3d scans using it. A good set of images for photogrammetry are: in sharp focus, well lit, precisely indexed, and have a uniform background. The background was handled by a 3d printed stand and some copier paper. To get even lighting he used four adjustable LED lamps from Ikea.
In order to precisely index the object, he built an indexing set-up with an Arduino and a stepper motor (housed in the, self proclaimed, most elegant of 3d printed enclosures). The Arduino rotates the platform a measured increment, and then using [Sebastian Setz]’s very neat IR camera control library, snaps a photo. This process repeats until multiple photos of the object have been taken.
Once the photos have been taken, they need to be run through a photogrammetry processor. [shapespeare] uses Agisoft Photoscan, but says Autodesk Memento and 123d Catch do pretty well too. After all this work it appears that [shapespeare] used his new powers to 3d print a giant decking screw. Cool.
Decades after the end of the space race, an American rocket took off from Cape Canaveral. This was a routine launch to send a communications satellite into orbit, but the situation was an historic first. The rocket in question was driven by a powerful Russian engine unlike any ever built in the States. Although this particular engine was new, the design dated back to the space age.
By the early 1960s, the Russians were leaps and bounds ahead of the United States in terms of space exploration. They had already launched Sputnik and sent Yuri Gagarin to orbit the Earth. All in all, the Russians seemed poised to send a man to the moon. Russian technology had the Americans worried enough to spy on them with satellites, and the images that came back revealed something spectacular. Out in the Kazakh desert, the Russians were building an enormous causeway and two launch pads. As it turns out, the US had every reason to be worried.
