Patterns Everywhere

I studied physics in college, and I’m always surprised how fundamental some of the concepts are. Take waves for example. You really wouldn’t expect the same underlying concept to be at work on surface of a pond, the string of a guitar, light passing through two slits, and then in the probabilistic behavior of electrons orbiting inside nuclei. But here we are, in a world filled with wave-like phenomena.

What little control theory I know, I’ve learned in the school of hard knocks. But it’s equally amazing that the same basic concepts govern the tuning of car shock absorbers, PID controllers, active audio filters, and other more complex systems where feedback matters. Crucial in all of these systems is the judicious balance of amplification and damping.

And last week on vacation, learning to drive a covered wagon pulled by a heavy draft horse, I saw the same patterns again. The horse likes to pull, and when the wagon comes over the crest of the top of a hill, it starts to roll forward into his harness, pushing him from behind. This makes the horse uneasy, and he slows down, the wagon pushes him harder, and positive feedback gets out of control.

The man who was teaching me to drive the wagon said, “it’s not like a car” in that you don’t tap the brakes to slow down and then let go. Rather, you hold on the brakes for a lot longer than you think is necessary – until the horse tells you that he feels like pulling again – and then you let up only a tiny bit at a time. Otherwise, you end up in the under-damped case, where you let the wagon go too much, it slows the horse, you slam the brakes, the horse pulls hard, and you let up on the brakes, and the cycle continues anew.

What he meant by “not like a car” was that the brakes aren’t just slowing down the wagon, they’re adding damping to keep the horse-wagon system from oscillating. Once that clicked in my mind, everything was smooth sailing. After a couple of days, I even started adding some feed-forward to my mental PID controller, letting the brakes go a little bit more when the horse was approaching the bottom of a hill, and he obviously wanted to pick up a little more speed before the grade ahead.

The horse seemed happy that I was finally getting it, but I don’t think he had any understanding of tuning PID loops. He did have me pondering, on a long stretch of rolling hills on a summer morning, if there were a good minimal set of patterns that explained a maximal breadth of phenomena. I’m starting with the physics of waves and the control of feedback systems, but what’s next?

Copy Or Redesign?

We got asked a great question in the mailbag segment on the Podcast this week: are there hacks that we have read about on Hackaday that we use in our everyday life? The answer was absolutely yes, and I loved Tom’s take it often goes the other way – he sees a hack, tests it out, and then writes it up.

But I started looking around the office and I found more examples of projects that were absolutely inspired by projects I had seen on Hackaday, yet weren’t the same. I made a DIY mechanical keyboard because I saw someone else do it. There are a few home-made battery packs that I probably wouldn’t have attempted without having read about someone doing the same thing. I riffed on [Ted Yapo]’s Tritiled project, making a slightly inferior, but workable knockoff, and they’ve been glowing for many years now.

That got me to thinking about reproducing a project versus taking inspiration from it, and though I enjoy both, I’m find myself most often in the “inspiration” mode. I just can’t leave well enough alone, even when I’m fundamentally copying someone. NIH syndrome? Expediency? Probably both, and sometimes with a dose of hubris or feature creep.

Looking back at [Ted]’s TritiLED, though, I found some great examples in both the rebuild and redesign modes on Hackaday.io. [schlion]’s Making Ted Yapo’s TritiLED couldn’t be a clearer example of the former, and it’s great to look over his shoulder and appreciate all the lessons he learned along the way. [Stephan Walter]’s Yet another ultra low power LED is inspired by [Christoph Tack]’s Ultra low power LED, which is in turn inspired by [Ted]’s project, like a conceptual grandchild.

In a way, I look at this like with music: sometimes you play the notes the way they were written down, and sometimes you riff on someone else’s theme. Both are equally valid, and both owe a debt to the upstream source. Is Hackaday the hackers’ jazz club? And which of these modes do you find yourself working in most?

Peripherals Hacks

Custom peripheral projects are among the most rewarding. Especially if you’re like me and you sit at the computer eight hours per day, anything that you can use on a daily basis is super satisfying. This topic of DIY peripherals came up on the podcast while chatting with Kristina, who is no stranger to odd inputs herself.

We were talking about a trackball that had been modified to read twisting gestures, by a clever hijacking of the twin mouse sensors inside. If you do a lot of 3D modeling, you can absolutely get by with just a mouse and shift-ctrl-alt as modifiers, but it’s so much more immediate to use a dedicated 3D input device. (I’ve got an ancient serial Space Mouse just under my left hand as I type this.)

My old favorite, which I haven’t used in ages, is the guts of a 5” hard-drive platter stack that I turned into a scroll wheel. Unfortunately, I don’t have space for it on my desk anymore, but it was just so pleasing to scroll through a document with something that had some real chonky momentum to it.

And it’s easier than ever to make your own. The classic blocky macropad is a great introduction, but as long as you’re doing the design yourself, why not extend it, or at least make it fit your hand? Or take your flights of fancy even further away from the mainstream. Consider the Bluetooth mouse ring, for instance.

Point is, the software side of almost any peripheral device you can imagine is sorted out already, and interfacing with the hardware is equally simple. Peripheral hacks have such a low barrier to entry, but afford so many creative hardware possibilities. And nothing says “Jedi” like building your own lightsaber.

Tool Embodiment And The Dead Trackball

There is a currently ongoing debate in the neuropsychology world about how we relate to the tools that we use. The theory of “tool embodiment” says that when we use some tools frequently enough, our brain recognizes them similarly to how it recognizes our own hands, for instance. There is evidence and counter-evidence from experiments with prosthetics, trash-grabber arms, and rubber dummy arms, just to name a few. It’s fair to say the jury is still out.

All I know is that today my trackball broke, and using a normal gaming mouse to edit the podcast was torture. It would be an exaggeration to say that I felt like I’d lost a hand, but I have so much motor memory apparently built up in my use of the trackball that switching over to another tool to undertake the exact same series of hundreds of small audio edits – mostly compensating for the audio delay across continents, but also silencing coughs and background noises – took an extra hour.

Anyone who has switched from one keyboard to another, or heck even from emacs to vim, knows what I experienced. My body just knows how to flick my wrist to make the cursor on the screen move over to the beginning of that “umm”. It’s not like I don’t conceptually know how to use a mouse either, and it does exactly the same job. But the mouse wasn’t my tool for this application. And saying that out loud makes it almost sound like I’m bordering on embodying my trackball.

I probably should have taken the trackball apart and replaced the bad tact switch on the left-click – that would have taken maybe twenty minutes – but I completely underestimated how integral the tool had become to the work. Anyway, as I write this, tomorrow is Saturday and I’ll have time to fix it. But today, I learned something pretty neat about myself in the process, even if I don’t think my single datapoint is going to rock the academic psych world.

What’s Your Favorite Kind Of Hack?

Talking with [Tom Nardi] on the podcast this week, he mentioned his favorite kind of hack: the community-developed open-source firmware that can be flashed into a commercial product that has crappy firmware, thus saving it. The example, just for the record, is the CrossPoint open e-book reader firmware that turns a mediocre cheap e-book into something that you can do anything you want with. Very nice!

And that got me thinking about “kinds of hacks” in general. Do we have a classification scheme for the hacks that we see here on Hackaday? For instance, the obvious precursor to many of Tom’s favorite hacks is the breaking-into-the-locked-firmware hack, where a device that didn’t want you loading your own firmware on it is convinced to let you do so. Junk-hacking is probably also a category of its own, where instead of finding your prey on AliExpress, you find it on eBay, or in the alleyway. And the save-it-from-the-landfill repair and renovation hacks are close relatives.

The doing-too-much-with-too-little hacks are maybe my personal favorite. I just love to see when someone manages to get DOOM running in Linux on a computer made with only 8-pin microcontrollers. Because of the nature of the game, these often also include a handful of abusing-a-component-to-do-something-it’s-not-meant-to-do hacks. Heck, we even had a challenge for just exactly those kind of hacks.

Then there are fine-art-hacks, where the aesthetic outcome is as important as the technical, or games-hacks where fun is the end result.

What other broad categories of hacks are we missing? And which are your favorite?

Re-Learning How To Run

As I write this, four astronauts are on their way around the moon for the first time in 50 years. A lot us have asked ourselves just exactly why you’d send people out that far when the environment is so hostile and we have increasingly competent robots that could do the jobs in their place. If anything, that’s even more true now than it was back in the day of the Apollo program, when the remote operations capability was a lot more constrained. But having people, potentially in the near future, on the lunar surface remains qualitatively different.

I was recently re-watching some of the footage from Apollo 16 when the astronauts were driving around in the Lunar Roving Vehicle, and the discussions that they’re having about the lunar geology that they can see for the first time with their own eyes is very convincing. Having people in situ tightens the loop of “hey, that’s interesting”, “let’s take a closer look”, and “I wonder what that means” in a way that minutes or hours of transmission time, and sterile observation of photos on a computer monitor just break. In comparison, our Mars rovers move excruciatingly slowly, the data comes back through a very thin pipe, and it takes months or years to analyze.

Of course, there is danger to human life; it’s a lot more expensive to get people safely to, and importantly back from, the moon than it would be with a disposable robot. Comparison with the Mars rovers is also unfair because travel to Mars is another scale entirely. Even if it does make sense to send humans for exploration on the moon, it may not make sense to do the same on the red planet, in the near future or ever. Given all that, I’m stoked that we can see through the robots eyes, but if all else were equal, I’m sure that we’d learn more from human explorers.

While in a lot of ways the Artemis I and now the Artemis II missions are underwhelming in comparison to the many “firsts” of Apollo, I absolutely appreciate them for what they are: a shakedown trial of a set of technologies and practices that we used to grasp, but which have atrophied over the last five decades. If a new generation of scientists is to put feet onto regolith, we need to learn to walk before they can run, or rover. In that spirit, I’ll be crossing my fingers for the future of manned spaceflight over the next week and a half.

For Art’s Sake

Hackers can be a strange folk. Our idea of beauty, for instance, can be rather odd. This week, Hackaday saw a few projects that were not just functional – the aesthetics were the goal. I don’t think we’ll be taking over the fine art world any time soon, but I’m absolutely convinced that the same muse that guides the hand that holds the paintbrush sometimes also guides the hand holding the soldering iron.

Take “circuit sculpture”, for instance. Heck, we even give it an art-inspired name that classifies it correctly. This week’s project that got me thinking about the aesthetics of hand-bent wire circuits was this marvelous clock build, but the works of Mohit Bhoite or Kelly Heaton are also absolute must-sees in this category.

Outside of the Hackaday orbit, one of my all-time favorite artists in this genre was Peter Vogel, who made complex audience-reactive sound sculptures that looked as good as they sound.

Is a wireframe animated moving jellyfish art? It was certainly intended to be beautiful, and I personally find it so. Watch some of the video clips attached to the project to get a better sense of it.

In the sculpture world, there is a sub-genre of kinetic art pieces where the work itself is secondary to the beauty of the motions that the pieces pull off. Think ballet, but mechanical. Perhaps my absolute favorite of these artists is Arthur Ganson. If you haven’t seen his work before, check out “Thinking Chair” for the beauty of movement, but don’t miss “Machine with Concrete” if you’re feeling more conceptual.

If you’re willing to buy an insane geartrain as art, what about these 3D printed wire strippers? Is this “art”? It’s clear that they were designed with real intent and attention to the aesthetics of the final form, and am I wrong for finding the way they move literally beautiful?

What’s your favorite offbeat hacker artform?