Fail Of The Week: Ferrofluid

It’s more of a half-fail than a full fail, but [Basti] is accustomed to getting things right (eventually) so it sticks in his craw that he wasn’t able to fully realize his ferrofluid dreams (German, translated here). Anyway, fail or demi-fail, the project is certainly a lesson in the reality of ferrofluid.

ferro

We’ve all seen amazing things done with ferrofluid and magnets. How hard can it be to make an interactive ferrofluid wedding present for his sister? Where ferrofluid spikes climb up a beautifully cut steel heart in a jar? (Answer: very hard.)

Continue reading “Fail Of The Week: Ferrofluid”

MicroPython On The ESP8266: Kicking The Tires

Scripting languages are for large computers, right? “Real” embedded device work is a hellish, never-ending cycle of code, compile, and re-flash. Well, I used to think so too, but with the proliferation of scripting and other interactive languages to microcontrollers over the last few years, the hurdle to interactive development on the small chips has gotten a lot lower.

On the ESP8266 platform, I’ve tried out NodeMCU’s Lua and ESP8266 BASIC. (For the last half-year, I’ve been using the awesome Mecrisp-Stellaris almost exclusively on the STM32F1xx and F4xx chips, but haven’t dipped into ESP8266 Forth yet.)

NodeMCU is great because it’s got everything you could want built in, and through cloud services it’s easy to get a tailored build made that maximizes free flash memory for your projects. I just don’t dig the asynchronous Lua thing (you might, try it!). ESP BASIC has a different set of libraries, and is missing MQTT for my purposes. Still it’s pretty slick, and worth a look.

So when the MicroPython folks announced that they were releasing the binary builds for the ESP, I thought it was time to give it a spin. I’ve used Python for nearly twelve years now, so it’s like a comfortable shoe for me. Would MicroPython be the same on the ESP8266? The short answer is yes and no.

Continue reading “MicroPython On The ESP8266: Kicking The Tires”

Simple Clock Is Great Stepper Motor Project

You’d think that we’ve posted every possible clock here at Hackaday. It turns out that we haven’t. But we have seen enough that we’ve started to categorize clock builds in our minds. There are the accuracy clocks which strive to get every microsecond just right, the bizzaro clocks that aim for most unique mechanism, and then there are “hello world” clocks that make a great introduction to building stuff.

Today, we’re looking at a nice “hello world” clock. [electronics for everyone]’s build uses a stepper motor and a large labelled wheel that rotates relative to a fixed pointer. Roll the wheel, and the time changes. It looks tidy, it’s cyclical by design, and it’s a no-stress way to get your feet wet driving stepper motors. And it comes with a video, embedded below.

Continue reading “Simple Clock Is Great Stepper Motor Project”

Ourobot: What Happens When A Snake Bot Swallows Its Own Tail

For all their joking about “reinventing the wheel”, the team behind Ourobot made a very cool robot (German, automatic translation here). The team, at the University of Applied Sciences in “Bielefeld, Germany“,  built their wheel out of twelve segments, each with its own servo motor, a 3D-printed case, and a pressure sensor mounted on the outside of the wheel. The latter, plus some clever programming, allows the robot wheel to vary its circular gate and climb up over obstacles automatically.

One link in the chain
One link in the chain

There are a bunch of interesting constraints in designing the control for this bot. The tracks on the ground, naturally, have to adjust their relative angles so that they lie each flat on the surface, even if that surface isn’t itself flat or level. The segments in the air are unconstrained, but the sum of all the servos’ interior angles has to add up to 1800 degrees, and these angles control where its center of gravity is.

Our head is spinning. The paper, “OUROBOT – A Self-Propelled Continuous-Track-Robot for Rugged Terrain” is unfortunately behind the IEEE paywall, but goes into detail if you can find it. Continue reading “Ourobot: What Happens When A Snake Bot Swallows Its Own Tail”

Hot Russian Tubes

On the heels of our post on retro-Soviet transistor teardowns and die-shots, [nikitas] wrote in to tell us about a huge thread on rare vacuum devices of all varieties: oddball cathode-ray tubes, obscure Nixies, and strange Soviet valves. We thought the other forum post was overwhelming at just over 110 pages, but how about 391 pages (and counting) of blown-glass electronics?

If you read through the decaptholon, we mentioned that a particularly enthusiastic poster, [lalka], looked to be cataloguing every Soviet oscillator circuit. It turns out that he’s also the one behind this incredible (random) compendium of everything that’s had the air sucked out of it.

Continue reading “Hot Russian Tubes”

What Could Go Wrong? I2C Edition

I should really like I2C more than I do. In principle, it’s a brilliant protocol, and in comparison to asynchronous serial and SPI, it’s very well defined and clearly standardized. On paper, up to 127 devices can be connected together using just two wires (and ground). There’s an allowance for multiple clock-masters on the same bus, and a way for slaves to signal that the master needs to wait. It sounds perfect.

In reality, the tradeoff for using only two wires is a significantly complicated signalling and addressing system that brings both pitfalls and opportunities for debugging. Although I2C does reduce the number of signal wires you need, it gets dangerous when you have more than a handful of devices on the same pair of wires, and you’re lucky when they all conform to the same standard. I’ve never seen twenty devices on a bus, much less 127.

But still, I2C has its place. I2C was designed to connect up a bunch of slower, cheaper devices without using a lot of copper real estate compared to its closest rival protocol: SPI. If you need to connect a few cheap temperature sensors to a microcontroller (and their bus addresses don’t clash) I2C is a great choice. So here’s a guide to making it work when it’s not working.

Continue reading “What Could Go Wrong? I2C Edition”

Never Gonna Give Up Free WiFi

Our conscience almost prevented us from posting this one. Almost.

What do people all around the world want most? Free WiFi. And what inevitable force do they want to avoid most, just after death and taxes? Rick Astley. As a getting-started project with the ESP8266, Hackaday.io user [jaime] built a “free WiFi portal” that takes advantage of people’s deepest desires. Instead of delivering sweet, high-bandwidth connectivity, once you click through the onerous terms and conditions, it delivers you a looped GIF with background music.

And all of this on $4 worth of hardware, with firmware assembled in the cloud and easily available to anyone. We live in a truly frivolous glorious age.

Digging through our archives, we found a number of Rickroll posts that we’d rather forget, but this steam-powered record player bears a second look.