Making A Wooden Multi-Mirror Display Device

January 1, 2016 by 21 Comments

Do you have 835 servo motors sitting around? Why not build your own binary wood-pixel-display-device?

Using the same basic concept as a DMD (Digital Micromirror Device) — the heart of all DLP projection technology — an artist created this wooden mirror. It features 835 wood “pixels” which are controlled by servo motors. Each pixel or wood chip can flip 30 degrees down, and 30 degrees up. A series of spot lights shining on the mirror provides lighting so shadows form when the pixels are “off”. The result is quite fascinating.

A small camera mounted in the middle of the display takes a black and white image of whoever (or whatever) is standing in front of the mirror. A bit of image processing later, and the mirror displays what it sees.

Continue reading “Making A Wooden Multi-Mirror Display Device” →

32C3: My Robot Will Crush You With Its Soft Delicate Hands!

January 1, 2016 by 2 Comments

In his talk at 32C3 [Matthew Borgatti] talked both about his company’s work with NASA toward developing robotic spacesuits and helping people with Cerebral Palsy better control their limbs. What do these two domains have in common? “One-size fits all pneumatic exoskeletons.”

[Matthew] makes a tremendously compelling case for doing something new and difficult in robotics — making robotic systems out of squishy, compliant materials. If you think about it, most robots are hard: made of metal and actuated by motors and gears, cables, or (non-compressible) pneumatic fluid. If you want to build suits that play well with soft and squishy people, they’ll need at least a layer of softness somewhere.

But [Matthew]’s approach is to make everything soft. In the talk, he mentions a few biological systems (octopus arms and goat’s feet) that work exactly because they’re soft. Why soft? Because soft spreads force around automatically and accommodates uneven terrain. And this makes it easier on the people who wear robotic suits and on the designers of the robots who don’t need to worry about the fine detail of the ground they’re walking on.

The talk ended up being very short, but there’s a fantastic Q&A at the end. It’s a must-see. And if you can’t get enough of [Matthew] or squishy robots, we’ve covered his robots before and he even had an entry in the Hackaday Prize.

Truck-Sized Star Destroyer Takes Flight

December 31, 2015 by 27 Comments

While some of you may have been to see the new Star Wars movie, you might be sad that everything happened a long time ago in a galaxy far away. But there’s a group of RC enthusiasts called [Flite Test] who are trying to bring at least a little bit of that fantasy into real life. They’ve created a truck-sized Star Destroyer that actually flies. It looks kind of terrifying, too.

While it’s not as big as a “real” Star Destroyer, it’s certainly one of the biggest we’ve ever seen in real life. Built out of foam, this monstrosity is 15 feet long and powered by two huge electric motors and a large lithium polymer battery. Of course they didn’t start out by building this huge flying spaceship; they created a smaller model as proof-of-concept and flew that one around for a while to make sure everything was shipshape. While it’s exciting to see the small model in flight, it’s another thing to see the 15-foot version swooping around.

We’re sad to report that the Star Destroyer did meet a similar fate as the one that Rey was scavenging at the beginning of the movie (spoilers: it crashed), we hope that the RC team rebuilds it so it’s space worthy again. Maybe they can even add a real-life ion drive or a few lasers to make it even more real.

Continue reading “Truck-Sized Star Destroyer Takes Flight” →

Art For Planespotters

December 31, 2015 by 6 Comments

We don’t know art, but we know what we like. And this gizmo by [Johan Kanflo] is right up our alley.

First, [Johan] gutted an old Macintosh Classic computer and stuffed a Raspberry Pi inside. Now this is not really a new idea, but [Johan] did a very nice job with the monitor and his attention to detail shows in the rebuilt floppy-drive eject mechanism. He gives it back that characteristic “schlurp” noise.

Then he outfitted the Raspberry Pi with an RTL dongle running dump1090 software to listen to the ADS-B radio signals. The data extracted from the SDR is piped off to an MQTT server with all sorts of data about the airplanes overhead. Another script subscribes to the MQTT topic and figures out which is the closest and runs an image search for the plane type in question, publishing the results back to another MQTT topic. One final script subscribes to this last topic and displays the relevant images on the screen. Pshwew!

The end result is a Macintosh Classic that’s continually updated with whatever planes are closest to being overhead. We’re not at all sure if this is fine art, or part of the useful arts, or maybe even none of the above. But we really like the nice case job and think that using MQTT as a back-end for coordinating multiple concurrent Python scripts (on the same computer) is pretty cool.

Portable, DIY Radiography

December 31, 2015 by 31 Comments

[Matt] has a background in radiation, electronics, and physics, which means building a device to generate X-rays was only a matter of time. It’s something not everyone should attempt, and [Matt] discourages anyone from attempting anything like this, but if you’re looking for a project with a ‘because it’s there’ flair to it, building your own X-ray machine can be a fun and rewarding project.

Despite being scary and mysterious, X-rays are a rather old technology that date back to some of the first purposeful experiments in electronics. Most X-ray devices today are built around the same parts they were 100 years ago, namely, a Coolidge tube. Apply a high enough voltage to the Coolidge tube and electrons whizz from cathode to anode, and slam into a heavy metal target. This produces Bremsstrahlung radiation – breakingbraking X-rays – that can be directed to film or an X-ray intensifier screen that fluoresces in visible light when being struck by X-rays.

Aside from a cheap Coolidge tube, [Matt] constructed the rest of his X-ray generator with a voltage multiplier made out of sufficiently derated Chinese caps, a flyback transformer, and a transformer driver originally made for induction heating applications. The electronics were installed in a Tupperware container and insulated with mineral oil.

Being able to generate X-rays is one thing, viewing them is another matter entirely. For this, [Matt] is using an old X-ray intensifier screen from the 60s or 70s. This screen fluoresces blue, not the easiest color to photograph in low-light settings, but enough to capture images of the inside of tools sitting around his workbench. Following in the footsteps of [Roentgen], [Matt] also took an X-ray image of his hand. This is something he doesn’t recommend, and something he won’t do again, but it is a very cool example of what you can do with sufficient knowledge and respect for what can kill you.

32C3: So You Want To Build A Satellite?

December 31, 2015 by 46 Comments

[INCO] gave this extremely informative talk on building a CubeSat. CubeSats are small satellites that piggyback on the launches of larger satellites, and although getting a 10 cm3 brick into orbit is cheap, making it functional takes an amazing attention to detail and redundant design.

[INCO] somehow talks through the entire hour-long presentation at a tremendous speed, all the while remaining intelligible. At the end of the talk, you’ve got a good appreciation for the myriad pitfalls that go along with designing a satellite, and a lot of this material is relevant, although often in a simpler form, for high altitude balloon experiments.

satellite_2-shot0002CubeSats must be powered down during launch, with no radio emissions or anything else that might interfere with the rocket that’s carrying them. The satellites are then packed into a box with a spring, and you never see or hear from them again until the hatch is opened and they’re pushed out into space.

[INCO] said that 50% of CubeSats fail on deployment, and to avoid being one of the statistics, you need to thoroughly test your deployment mechanisms. Test after shaking, being heated and cooled, subject to low battery levels, and in a vacuum. Communication with the satellite is of course crucial, and [INCO] suggests sending out a beacon shortly after launch to help you locate the satellite at all.

satellite_2-shot0003Because your satellite is floating out in space, even tiny little forces can throw it off course. Examples include radiation pressure from the sun, and anything magnetic in your satellite that will create a torque with respect to the Earth’s magnetic field. And of course, the deployment itself may leave your satellite tumbling slightly, so you’re going to need to control your satellite’s attitude.

Power is of course crucial, and in space that means solar cells. Managing solar cells, charging lithium batteries, and smoothing out the power cycles as the satellite enters the earth’s shadow or tumbles around out of control in space. Frequent charging and discharging of the battery is tough on it, so you’ll want to keep your charge/discharge cycles under 20% of the battery’s nominal capacity.

mpv-shot0001In outer space, your satellite will be bombarded by heavy ions that can short-circuit the transistors inside any IC. Sometimes, these transistors get stuck shorted, and the only way to fix the latch-up condition is to kill power for a little bit. For that reason, you’ll want to include latch-up detectors in the power supply to reset the satellite automatically when this happens. But this means that your code needs to expect occasional unscheduled resets, which in turn means that you need to think about how to save state and re-synchronize your timing, etc.

In short, there are a ridiculous amount of details that you have to attend to and think through before building your own CubeSat. We’ve just scratched the surface of [INCO]’s advice, but if we had to put the talk in a Tweet, we’d write “test everything, and have a plan B whenever possible”. This is, after all, rocket science.

Code Craft-Embedding C++: Hacking The Arduino Software Environment

December 31, 2015 by 72 Comments

The Arduino software environment, including the IDE, libraries, and general approach, are geared toward education. It’s meant as a way to introduce embedded development to newbies. This is a great concept but it falls short when more serious development or more advanced education is required. I keep wrestling with how to address this. One way is by using Eclipse with the Arduino Plug-in. That provides a professional development environment, at least.

The code base for the Arduino is another frustration. Bluntly, the use of setup() and loop() with main() being hidden really bugs me. The mixture of C and C++ in libraries and examples is another irritation. There is enough C++ being used that it makes sense it should be the standard. Plus a good portion of the library code could be a lot better. At this point fixing this would be a monumental task requiring many dedicated developers to do the rewrite. But there are a some things that can be done so let’s see a couple possibilities and how they would be used.

Continue reading “Code Craft-Embedding C++: Hacking The Arduino Software Environment” →