Hardware Vs Software: Fight!

It’s one of the great cliches in the hacker world: the hardware type and the software type. You can tell which of these two you are quite easily. When a project is actually 20% done, but you think it’s 90% done, and you say to yourself “And the rest is a simple matter of software”, you’re a hardware type. Ask anyone who has read my code, and they’ll tell you, I’m a hardware type.

Along with my blindness to the difficulties of getting the code right, I’ve also admittedly got an underappreciation of what powers lie in the dark typing arts. But I am not too proud to tip my hat when I see an awesome application of the soft stuff. Case in point: this Go board sequencer that we ran last week. An overhead webcam parses players’ moves as they put black and white stones down while playing the game of Go, and turns this into music.

The pure software type will be saying “but there’s a webcam and a Go board”. And indeed, that’s true. There are physical elements to this project that anchor it in the shared reality of the two people playing. But a hardware project this isn’t; it’s OpenCV and Max/MSP that make it work.

For comparison, look at the complexity of this similar physical sequencer. It’s got a 16 x 16 array of LEDs and switches and a CNC milled, primed, and painted surface that’s the size of a twin bed. Sawdust and hand-soldering: that’s a hardware project.

What I love about the Go sequencer is that it uses software just right. The piece is still physical. It could have just as easily been a VR world, where the two people would interact with each other only inside their goggles. But somehow that’s not quite as human as putting stones on a wooden board, sitting across from, and maybe even looking at, your opponent. The players aren’t forced to think about the software. They don’t feel like they’re playing a video game.

But at the same time, the software side of things makes all of the horrible hardware problems go away. Nobody is soldering a rat’s nest of 169 switches. There’s a webcam plugged into the USB port of a laptop. There’s a deep simplicity there.

Should you always trade out arcade buttons for OpenCV? Absolutely not! But is it worth considering the soft side when doing it in hardware is just too, well, hard? I’m open.

Paying It Forward

It’s all those little things. A month ago, I was working on the axes for a foam-cutting machine. (Project stalled, will pick back up soon!) A week ago, somewhere else on the Internet, people were working on sliders that would ride directly on aluminum rails, a problem I was personally experiencing, and recommended using drawer-glide tape — a strip of PTFE or UHMW PE with adhesive backing on one side. Slippery plastic tape solves the metal-on-metal problem. It’s brilliant, it’s cheap, and it’s just a quick trip to the hardware store.

Just a few days ago, we covered another awesome linear-motion mechanical build in the form of a DIY camera rig that uses a very similar linear motion system to the one I had built as well: a printed trolley that slides on skate bearings over two rails of square-profile extruded aluminum. He had a very nice system of anchoring the spacers that hold the two rails apart, one of the sticking points in my build. I thought I’d glue things together, but his internal triangle nut holders are a much better solution because epoxy doesn’t like to stick to anodized aluminum. (And Alexandre, if you’re reading, that UHMW PE tape is just what you need to prevent bearing wear on your aluminum axes.)

Between these events, I got a message thanking me for an article that I wrote four years ago on debugging SPI busses. Apparently, it helped a small company to debug a problem and get their product out the door. Hooray!

So in one week, I got help from two different random strangers on a project that neither of them knew I was working on, and I somehow saved a startup. What kind of crazy marvelous world is this? It’s become so normal to share our ideas and experience, at least in our little corner of the Internet, that I sometimes fail to be amazed. But it’s entirely amazing. I know we’ve said it before, but we are living in the golden era of sharing ideas.

Thanks to all of you out there, and Read More Hackaday!

Twitter: It’s Not The Algorithm’s Fault. It’s Much Worse.

Maybe you heard about the anger surrounding Twitter’s automatic cropping of images. When users submit pictures that are too tall or too wide for the layout, Twitter automatically crops them to roughly a square. Instead of just picking, say, the largest square that’s closest to the center of the image, they use some “algorithm”, likely a neural network, trained to find people’s faces and make sure they’re cropped in.

The problem is that when a too-tall or too-wide image includes two or more people, and they’ve got different colored skin, the crop picks the lighter face. That’s really offensive, and something’s clearly wrong, but what?

A neural network is really just a mathematical equation, with the input variables being in these cases convolutions over the pixels in the image, and training them essentially consists in picking the values for all the coefficients. You do this by applying inputs, seeing how wrong the outputs are, and updating the coefficients to make the answer a little more right. Do this a bazillion times, with a big enough model and dataset, and you can make a machine recognize different breeds of cat.

What went wrong at Twitter? Right now it’s speculation, but my money says it lies with either the training dataset or the coefficient-update step. The problem of including people of all races in the training dataset is so blatantly obvious that we hope that’s not the problem; although getting a representative dataset is hard, it’s known to be hard, and they should be on top of that.

Which means that the issue might be coefficient fitting, and this is where math and culture collide. Imagine that your algorithm just misclassified a cat as an “airplane” or as a “lion”. You need to modify the coefficients so that they move the answer away from this result a bit, and more toward “cat”. Do you move them equally from “airplane” and “lion” or is “airplane” somehow more wrong? To capture this notion of different wrongnesses, you use a loss function that can numerically encapsulate just exactly what it is you want the network to learn, and then you take bigger or smaller steps in the right direction depending on how bad the result was.

Let that sink in for a second. You need a mathematical equation that summarizes what you want the network to learn. (But not how you want it to learn it. That’s the revolutionary quality of applied neural networks.)

Now imagine, as happened to Google, your algorithm fits “gorilla” to the image of a black person. That’s wrong, but it’s categorically differently wrong from simply fitting “airplane” to the same person. How do you write the loss function that incorporates some penalty for racially offensive results? Ideally, you would want them to never happen, so you could imagine trying to identify all possible insults and assigning those outcomes an infinitely large loss. Which is essentially what Google did — their “workaround” was to stop classifying “gorilla” entirely because the loss incurred by misclassifying a person as a gorilla was so large.

This is a fundamental problem with neural networks — they’re only as good as the data and the loss function. These days, the data has become less of a problem, but getting the loss right is a multi-level game, as these neural network trainwrecks demonstrate. And it’s not as easy as writing an equation that isn’t “racist”, whatever that would mean. The loss function is being asked to encapsulate human sensitivities, navigate around them and quantify them, and eventually weigh the slight risk of making a particularly offensive misclassification against not recognizing certain animals at all.

I’m not sure this problem is solvable, even with tremendously large datasets. (There are mathematical proofs that with infinitely large datasets the model will classify everything correctly, so you needn’t worry. But how close are we to infinity? Are asymptotic proofs relevant?)

Anyway, this problem is bigger than algorithms, or even their writers, being “racist”. It may be a fundamental problem of machine learning, and we’re definitely going to see further permutations of the Twitter fiasco in the future as machine classification is being increasingly asked to respect human dignity.

Dynamic Soaring: 545 MPH RC Planes Have No Motor

The fastest remote-controlled airplane flight ever recorded took place in 2018, with a top speed of 545 miles/hour. That’s 877 km/h, or Mach 0.77!

What was the limiting factor, preventing the pilot-and-designer Spencer Lisenby’s plane from going any faster? The airstream over parts of the wing hitting the sound barrier, and the resulting mini sonic booms wreaking havoc on the aerodynamics. What kind of supercharged jet motor can propel a model plane faster than its wings can carry it? Absolutely none; the fastest RC planes are, surprisingly, gliders.

Dynamic soaring (DS) was first harnessed to propel model planes sometime in the mid 1990s. Since then, an informal international competition among pilots has pushed the state of the art further and further, and in just 20 years the top measured speed has more than tripled. But dynamic soaring is anything but new. Indeed, it’s been possible ever since there has been wind and slopes on the earth. Albatrosses, the long-distance champs of the animal kingdom, have been “DSing” forever, and we’ve known about it for a century.

DS is the highest-tech frontier in model flight, and is full of interesting physical phenomena and engineering challenges. Until now, the planes have all been piloted remotely by people, but reaching new high speeds might require the fast reaction times of onboard silicon, in addition to a new generation of aircraft designs. The “free” speed boost that gliders can get from dynamic soaring could extend the range of unmanned aerial vehicles, when the conditions are right. In short, DS is at a turning point, and things are just about to get very interesting. It’s time you got to know dynamic soaring.

Continue reading “Dynamic Soaring: 545 MPH RC Planes Have No Motor”

Code For Hackers

Mike and I were talking about two very similar clock projects we’d both built recently: they both use ESP8266 modules to get the time over WiFi and NTP, and they both failed. Mike’s failed because he was visiting relatives in a different timezone with different WiFi credentials, and mine failed because daylight savings time caught me off-guard. In both cases, we hard-coded stuff that could obviously change, but we drew vastly different conclusions.

Mike thought he’d solve his WiFi problem with a fallback to a captive portal, and maybe would have to figure out some web interface for configuring the timezone. A very clean, professional solution. Me? I’ve got good comments in the code, can find the UTC offset (or the WiFi creds) in a few minutes, and flash the new version up simply by fetching a USB cable, for something that happens twice a year. It’s hardly worth the trouble to cobble together a web interface.

There’s an XKCD for everything.

We’ve accidentally embodied a quandary that spans both the hardware and software worlds: should flexibility be exposed to the end-user or to the hacker who can peer under the hood or open up the source code? (And what if the end-user is the hacker?) What are the tradeoffs, in project complexity and in ease of use?

And in this, Mike is on the side of right and good, and I’m the heretic. I don’t always write my code to be extensible or re-usable. I sometimes write it to be quickly re-edited and patched whenever I need to. Is it full of magic numbers? Sure! But I know just where they are and how to change them. Heck, most are even well documented in their own header file. You could probably figure it out just about as fast. Would my father-in-law be able to tweak the timezone? Nope! But this ain’t his project anyway.

Dare to code for hackers! Don’t over-generalize or over-abstract. Less is more. Don’t be afraid to edit code. Tweak, compile, and re-flash when the situation changes. After all, that’s how you got the code there in the first place.

And although I’m on the wrong end of history, in this case I was right. You see, before daylight savings time could come around again, and I could have made use of that captive portal that I didn’t bother coding up anyway, my son entered first grade. Everything needs to be changed, from the hardware to the software. Will I code up the next version with flexible time regimes? As flexible as I need it to be, but not more.

Plastic Prosthetics For Rubber Duckies

Will someone please think of the rubber duckies?!

For decades they’ve been reduced to a laughing stock: a caricature of waterfowl. Left without a leg to stand on, their only option is to float around in the tub. And they don’t even do that well, lacking the feet that Mother Nature gave them, they capsize when confronted with the slightest ripple. But no more!

Arise!

Due to the wonders of 3D printing, and painstaking design work by [Jan] from the Rubber Ducky Research Center, now you can print your own rubber ducky feet. We have the technology! Your ducks are no longer constrained to a life in the tub, but can roam free as nature intended. The video (embedded below) will certainly tug at your heartstrings.

OK, it’s a quick print and it made my son laugh.

The base and legs probably don’t fit your duck as-is, but it’s a simple matter to scale them up or down while slicing. (Picture me with calipers on the underside of a rubber ducky.) The legs were a tight press-fit into the body, so you might consider slimming them down a tiny bit when doing the scaling, but this probably depends on your printer tolerances.

It looks snazzy in gold-fleck PETG, and would probably work equally well for some more elaborate rubber duckies as well.

Continue reading “Plastic Prosthetics For Rubber Duckies”

Mirror Turns Webcam Into Document Camera

This is one of those so-simple-I-wish-I-invented-it hacks. Professor [Michael Peshkin] is teaching his engineering students remotely. While he has a nice second camera that he can use to transmit whatever he doodles on paper, most of his students just have the single webcam built into their laptops.

The solution is to put a mirror in front of the laptop cam, and flip the image left-to-right in software. They use Zoom, which has a mirror mode. Done.

The trick is making a nice frame. [Michael] has bent one out of wire, but suggests that a mirror compact works about as well in a pinch. It’s super important that his students can ask him questions backed up by drawings, and this reduces the startup cost to nearly nothing, making it universally useful.

[Prof. Peshkin] is not a stranger to mirror-based pedagogical hacks. Seven years ago, he showed us how to make a transparent whiteboard for video lectures, and it blew up on Hackaday. Since then, there are hundreds or thousands of Lightboards in the wild. We hope this idea catches on as well!