The Simplest Possible DIY Ultrasonic Levitator

We thought that making things levitate in mid-air by the power of sound was a little bit more like magic, or at least required fancy equipment. It turns out that you can do it yourself easily enough with parts that any decent hacker’s closet should have in abundance: a motor-driver IC, two ultrasonic distance pingers, and a microcontroller. This article shows you how (translated here, scroll down).

But aside from a few clever tricks, there’s not that much to show. The two HC-SR04 ultrasonic distance sensors are standard fare, and are just being used as a cheap source of 40 kHz transducers. The circuit uses a microcontroller, but any source of 40 kHz square waves should suffice. Those of you who could do that with a 555 (or a Raspberry Pi), this one’s for you! A stepper motor driver bumps up the voltage applied to the transducers, but you could use plain-vanilla transistors as well.

It’s all the little details that count, however. You need to position the two ultrasonic drivers fairly precisely to create a standing wave, and while you can start at 8.25 mm and trial-and-error it, the article demonstrates using an oscilloscope to align the capsules by driving one and reading the signal out of the other and tweaking them until they’re in phase. Clever!

The author also takes the ultrasonic-transparent grille from one of the unused receivers and uses it as a spoon to help position the styrofoam bits in the sound waves. We always wondered how you’d do that!

It turns out that it’s easy to make a DIY ultrasonic levitation desk toy, and none of the parts are expensive or critical. The missing ingredient is just the gumption to try it, and now we have that, too.

As cool as they are, the HC-SR04 modules aren’t perfect for all distance sensing applications. Here’s everything you need to know about them, including hacks to make them work up-close. And since HC-SR04 sensors come cheapest in ten-packs, you’ll be wondering what you’re going to do with the other eight. That problem has apparently also been solved.

Two-Cent Temperature Sensors

When they need to add temperature control to a project, many hackers reach for a K-type thermocouple for their high-temperature needs, or an integrated temperature-sensing IC when it doesn’t get that hot. The thermocouple relies on very small currents and extremely high gain, and you pretty much need a dedicated IC to read it, which can be expensive. The ICs aren’t as expensive, but they’re basically limited to boiling water. What do you do if you want to control a reflow oven?

There’s a cheaper way that spans a range between Antarctic winter and molten solder, and you’ve probably already got the parts on your shelf. Even if you don’t, it’s only going to run you an extra two cents, assuming that you’ve already got a microcontroller with an ADC in your project. The BOM: a plain-vanilla diode and a resistor.

I’ve been using diodes as temperature sensors in three projects over the last year: one is a coffee roaster that brings the beans up to 220 °C in hot air, another is a reflow hotplate that tops out around 210 °C, and the third is a toner-transfer iron that holds a very stable 130 °C. In all of these cases, I don’t really care about the actual numerical value of the temperature — all that matters is reproducibility — so I never bothered to calibrate anything. I thought I’d do it right for Hackaday, and try to push the humble diode to its limits for science.

What resulted was a PCB fire, test circuits desoldering themselves above 190 °C, temperature probes coming loose, and finally a broken ramekin and 200 °C peanut oil all over my desk. Fun times! On the other hand, I managed to get out enough data to calibrate some diodes, and the results are fantastic. The circuits under test included both best practices and the easiest thing that could possibly work, and the results are pretty close. This is definitely a technique that you want to have under your belt for most temperature ranges. The devil is in the details, of course, so read on!

Continue reading “Two-Cent Temperature Sensors”

One-Pixel Attack Fools Neural Networks

Deep Neural Networks can be pretty good at identifying images — almost as good as they are at attracting Silicon Valley venture capital. But they can also be fairly brittle, and a slew of research projects over the last few years have been working on making the networks’ image classification less likely to be deliberately fooled.

One particular line of attack involves adding particularly-crafted noise to an image that flips some bits in the deep dark heart of the network, and makes it see something else where no human would notice the difference. We got tipped with a YouTube video of a one-pixel attack, embedded below, where changing a single pixel in the image would fool the network. Take that robot overlords!

We can’t tell what these are either..

Or not so fast. Reading the fine-print in the cited paper paints a significantly less gloomy picture for Deep Neural Nets. First, the images in question were 32 pixels by 32 pixels to begin with, so each pixel matters, especially after it’s run through a convolution step with a few-pixel window. The networks they attacked weren’t the sharpest tools in the shed either, with somewhere around a 68% classification success rate. What this means is that the network was unsure to begin with for many of the test images — making it flip from its marginally best (correct) first choice to a second choice shouldn’t be all that hard.

This isn’t to say that this line of research, adversarial training of the networks, is bogus. The idea that making neural nets robust to small changes is important. You don’t want turtles to be misclassified as guns, for instance, or Hackaday’s own Steven Dufresne misclassified as a tobacconist. And you certainly don’t want speech recognition software to be fooled by carefully crafted background noise. But if a claim of “astonishing results” on YouTube seems too good to be true, well, maybe it is.

Thanks [kamathin] for the tip!

Continue reading “One-Pixel Attack Fools Neural Networks”

Mc Lighting Takes the Pain out of Blinking

If you want to blink a ton of WS2812-alike LED pixels over WiFi, the hardware side of things is easy enough: an LED strip, and ESP8266 unit, and a beefy enough power supply to feed them. But the software side — that’s where it can be a bit of a pain.

Enter Mc Lighting. It makes the software side of things idiot-proof. Flash the firmware onto the ESP8266, and you’ve got your choice of REST, WebSockets, or MQTT to get the data in. This means that it’ll work with Homekit, NodeRed, or an ESP-hosted web interface that you can pull up from any smartphone.

The web interface is particularly swell, and has a bunch of animations built in. (Check out the video below.) This means that you can solder some wires, flash an ESP, and your least computer-savvy relatives can be controlling the system in no time. And speaking of videos, Mc Lighting’s author [Tobias] has compiled a playlist of projects that use the library, also just below. The docs on GitHub are great, and also check out the wiki.

So what are you waiting for? Do you or your loved ones need some blink in your life? And while you’re ordering LED strips, get two. You’re going to want to build TWANG! as well.

Continue reading “Mc Lighting Takes the Pain out of Blinking”

Kniwwelino Is An ESP8266 Micro:Bit

Kniwwelino is the latest in a line of micro:bit-inspired projects that we’ve seen, but this one comes with a twist: it uses an ESP8266 and WiFi at the core instead of the nR51 ARM/BTLE chip. That means that students can connect via laptop, cellphone, or anything else that can get onto a network.

That’s not the only tradeoff, though. In order to get the price down, the Kniwwelino drops the accelerometer/magnetometer of the micro:bit for a programmable RGB LED. With fewer pins to break out, the Kniwwelino is able to ditch the love-it-or-hate-it card-edge connector of the micro:bit as well. In fact, with all these changes, it’s hard to call this a micro:bit clone at all — it’s more like a super-blinky ESP8266 development kit.

So what have they got left in common? The iconic 5×5 LED matrix in the center, and a Blockly visual programming dialect dedicated to the device. Based on the ESP8266, the Kniwwelino naturally also has an Arduino dialect that students can “graduate” to when they’re tired of moving around colored blobs, and of course you could flash the chip with anything else that runs on an ESP8266.

We don’t have one in our hands, but we like the idea. An RGB LED is a lot of fun on Day One, and the fact that the Kniwwelino fits so neatly into existing bodies of code makes the transition from novice to intermediate programmer a lot easier. These things are personal preference, but WiFi beats Bluetooth LE in our book, for sheer ubiquity and interoperability. Finally, the Kniwwelino comes in at about half the manufacturing cost of a micro:bit, which makes it viable in schools without large manufacturer subsidies. They’re estimating $5 per unit. (Retail is higher.) On the other hand, the Kniwwelino is going to use more juice than its ARM-based competitor, and doesn’t have an accelerometer.

Kniwwelino is apparently derived from a luxembourgish word “kniwweln” that apparently means to craft something. The German Calliope Mini is named after Zeus’ daughter, the programmer’s muse. We’re stoked to see so many cute dev boards getting into the hands of students, no matter what you call them.

Self-Driven: Uber and Tesla

Self-driving cars have been in the news a lot in the past two weeks. Uber’s self-driving taxi hit and killed a pedestrian on March 18, and just a few days later a Tesla running in “autopilot” mode slammed into a road barrier at full speed, killing the driver. In both cases, there was a human driver who was supposed to be watching over the shoulder of the machine, but in the Uber case the driver appears to have been distracted and in the Tesla case, the driver had hands off the steering wheel for six seconds prior to the crash. How safe are self-driving cars?

Trick question! Neither of these cars were “self-driving” in at least one sense: both had a person behind the wheel who was ultimately responsible for piloting the vehicle. The Uber and Tesla driving systems aren’t even comparable. The Uber taxi does routing and planning, knows the speed limit, and should be able to see red traffic lights and stop at them (more on this below!). The Tesla “Autopilot” system is really just the combination of adaptive cruise control and lane-holding subsystems, which isn’t even enough to get it classified as autonomous in the state of California. Indeed, it’s a failure of the people behind the wheels, and the failure to properly train those people, that make the pilot-and-self-driving-car combination more dangerous than a human driver alone would be.

A self-driving Uber Volvo XC90, San Francisco.

You could still imagine wanting to dig into the numbers for self-driving cars’ safety records, even though they’re heterogeneous and have people playing the mechanical turk. If you did, you’d be sorely disappointed. None of the manufacturers publish any of their data publicly when they don’t have to. Indeed, our glimpses into data on autonomous vehicles from these companies come from two sources: internal documents that get leaked to the press and carefully selected statistics from the firms’ PR departments. The state of California, which requires the most rigorous documentation of autonomous vehicles anywhere, is another source, but because Tesla’s car isn’t autonomous, and because Uber refused to admit that its car is autonomous to the California DMV, we have no extra insight into these two vehicle platforms.

Nonetheless, Tesla’s Autopilot has three fatalities now, and all have one thing in common — all three drivers trusted the lane-holding feature well enough to not take control of the wheel in the last few seconds of their lives. With Uber, there’s very little autonomous vehicle performance history, but there are leaked documents and a pattern that makes Uber look like a risk-taking scofflaw with sub-par technology that has a vested interest to make it look better than it is. That these vehicles are being let loose on public roads, without extra oversight and with other traffic participants as safety guinea pigs, is giving the self-driving car industry and ideal a black eye.

If Tesla’s and Uber’s car technologies are very dissimilar, the companies have something in common. They are both “disruptive” companies with mavericks at the helm that see their fates hinging on getting to a widespread deployment of self-driving technology. But what differentiates Uber and Tesla from Google and GM most is, ironically, their use of essentially untrained test pilots in their vehicles: Tesla’s in the form of consumers, and Uber’s in the form of taxi drivers with very little specific autonomous-vehicle training. What caused the Tesla and Uber accidents may have a lot more to do with human factors than self-driving technology per se.

You can see we’ve got a lot of ground to cover. Read on!

Continue reading “Self-Driven: Uber and Tesla”

Scotty Allen Visits Strange Parts, Builds an iPhone

Scotty Allen has a YouTube blog called Strange Parts; maybe you’ve seen his super-popular video about building his own iPhone “from scratch”. It’s a great story, and it’s also a pretext for a slightly deeper dive into the electronics hardware manufacturing, assembly, and repair capital of the world: Shenzhen, China. After his talk at the 2017 Superconference, we got a chance to sit down with Scotty and ask about cellphones and his other travels. Check it out:

The Story of the Phone

Scotty was sitting around with friends, drinking in one of Shenzhen’s night markets, and talking about how bizarre some things seem to outsiders. There are people sitting on street corners, shucking cellphones like you’d shuck oysters, and harvesting the good parts inside. Electronics parts, new and used, don’t come from somewhere far away and there’s no mail-ordering. A ten-minute walk over to the markets will get you everything you need. The desire to explain some small part of this alternate reality to outsiders was what drove Scotty to dig into China’s cellphone ecosystem.

Continue reading “Scotty Allen Visits Strange Parts, Builds an iPhone”