Hackability Matters

January 16, 2021 by Elliot Williams 42 Comments

The Unix Way™ provides extreme hackability. The idea is that software should be written as tools to accomplish discrete tasks, and that it should be modular, extensible, and play well with others. It’s like software as a LEGO set — you can put the blocks together however you want, within limits, and make stuff that’s significantly cooler than any of the individual blocks alone.

Clearly this doesn’t work for all applications — things like graphics editors and web browsers don’t really lend themselves to being elegant tools that integrate well with others, right? It’s only natural that they’re bloaty walled gardens. What happens in the browser must stay in the browser, right?

But how sad is it that the one piece of software you use all day, your window into cyberspace, doesn’t play well with the rest of your system? I’d honestly never really been bothered by that fact until stumbling on TabFS. It’s an extension to Chrome that represents the tabs on your browser as if they were files on your local system — The Unix Way™. And what this means is that any other program that can read from or write to a file can open tabs, collect them, change webpages on the fly, and so on. It opens up the browser to you.

This is tremendously powerful. Don’t like the bookmarking paradigm of your particular browser? Writing your own would be a snap in Python — and you could do cleverer things like apply a little machine learning to handle putting them in categories. Want to pop open (or refresh) a set of webpages at a particular time every day? Cron, or its significantly more complicated counterpart systemd, and a couple lines of code will do that. Want to make a hardware button that converts dark mode to light mode and vice-versa for every website starting with “H”? Can do.

I’m picking on browsers, but many large pieces of software are inaccessible in the same way — even if they’re open source, they don’t open up channels for interaction with user code or scripts. (Everything “in the cloud” or “as a service”, I’m looking at you! But that’s a further rant for another day.) And that’s a shame, because most of these “big” pieces of software actually do the coolest things.

So please, if you’re working on a big software package, or even just writing a plug-in for one, do think about how you can make more of its abilities available to the casual scripter. Otherwise, it’s just plastic blocks that don’t fit with the rest of the set.

The Shell And The Microcontroller

January 9, 2021 by Elliot Williams 104 Comments

One of the nicest amenities of interpreted programming languages is that you can test out the code that you’re developing in a shell, one line at a time, and see the results instantly. No matter how quickly your write-compile-flash cycle has gotten on the microcontroller of your choice, it’s still less fun than writing blink_led() and having it do so right then and there. Why don’t we have that experience yet?

If you’ve used any modern scripting language on your big computer, it comes with a shell, a read-eval-print loop (REPL) in which you can interactively try out your code just about as fast as you can type it. It’s great for interactive or exploratory programming, and it’s great for newbies who can test and learn things step by step. A good REPL lets you test out your ideas line by line, essentially running a little test of your code every time you hit enter.

The obvious tradeoff for ease of development is speed. Compiled languages are almost always faster, and this is especially relevant in the constrained world of microcontrollers. Or maybe it used to be. I learned to program in an interpreted language — BASIC — on computers that were not much more powerful than a $5 microcontroller these days, and there’s a BASIC for most every micro out there. I write in Forth, which is faster and less resource intensive than BASIC, and has a very comprehensive REPL, but is admittedly an acquired taste. MicroPython has been ported over to a number of micros, and is probably a lot more familiar.

But still, developing MicroPython for your microcontroller isn’t developing on your microcontroller, and if you follow any of the guides out there, you’ll end up editing a file on your computer, uploading it to the microcontroller, and running it from within the REPL. This creates a flow that’s just about as awkward as the write-compile-flash cycle of C.

What’s missing? A good editor (or IDE?) running on the microcontroller that would let you do both your exploratory coding and record its history into a more permanent form. Imagine, for instance, a web-based MicroPython IDE served off of an ESP32, which provided both a shell for experiments and a way to copy the line you just typed into the shell into the file you’re working on. We’re very close to this being a viable idea, and it would reduce the introductory hurdles for newbies to almost nothing, while letting experienced programmers play.

Or has someone done this already? Why isn’t an interpreted introduction to microcontrollers the standard?

Remoticon Video: The Mechanics Of Finite Element Analysis

December 31, 2020 by Elliot Williams 6 Comments

Hardware hacking can be extremely multidisciplinary. If you only know bits and bytes, but not solder and electrons, you’re limited in what you can build. The same is true for mechanical design, where the forces of stress and strain suddenly apply to your project and the pile of code and PCBs comes crashing to the ground.

In the first half of his workshop, Naman Pushp walks you through some of the important first concepts in mechanical engineering — how to think about the forces in the world that act on physical objects. And he brings along a great range of home-built Jugaad props that include a gravity-defying tensegrity string sculpture and some fancy origami that help hammer the topics home.

In the second half of the workshop, Naman takes these concepts into computer simulation, and gives us good insight into the way that finite-element analysis simulation packages model these same forces on tiny chunks of your project’s geometry to see if it’ll hold up under real world load. The software he uses isn’t free by any definition — it’s not even cheap unless you have a student license — but it’s nonetheless illuminating to watch him work through the flow of roughly designing an object, putting simulated stresses and strains on it, and interpreting the results. If you’ve never used FEA tools before, or are looking for a compressed introduction to first-semester mechanical engineering, this talk might be right up your alley. Continue reading “Remoticon Video: The Mechanics Of Finite Element Analysis” →

Remoticon Video: KiCad To Blender PCB Renders

December 23, 2020 by Elliot Williams 8 Comments

We seem to want our PCB design software to do everything these days, and it almost delivers. You can not only lay it all out, check electrical and design rules, and even spit out a bill of materials, but many PCB tools produce 3D models that are good enough to check parts clearance or are useful in designing enclosures. But when it comes to producing photorealistic output, whether for advertising or just for eye-candy, you might want to turn to 3D design tools.

In this workshop, Anool Mahidharia takes the output of KiCad’s VRML export, gets it rendering in Blender, and then starts tweaking the result until you’re almost not sure if it’s the real thing or a 3D model. He starts off with a board in KiCad, included in the project’s GitHub repo, and you can follow along through the basic import, or go all the way to copying the graphics off the top of an ATtiny85 and making sure that the insides of the through-plated holes match the tops.

If you don’t know Blender, maybe you don’t know how comprehensive a 3D modelling and animation tool it is. And with the incredible power comes a notoriously steep learning curve up a high mountain. Anool doesn’t even try to turn you into a Blender expert, but focuses on the tweaks and tricks that you’ll need to make good looking PCB renders. You’ll find general purpose Blender tutorials everywhere on the net, but if you want something PCB-specific, you’ve come to the right place.

Continue reading “Remoticon Video: KiCad To Blender PCB Renders” →

Label Your Shtuff!

December 19, 2020 by Elliot Williams 18 Comments

Joshua Vasquez wrote a piece a couple of weeks ago about how his open source machine benefits greatly from having part numbers integrated into all of the 3D printed parts. It lets people talk exactly about which widget, and which revision of that widget, they have in front of them.

Along the way, he mentions that it’s also a good idea to have labels as an integrated part of the machine anywhere you have signals or connectors. That way, you never have to ask yourself which side is positive, or how many volts this port is specced for. It’s the “knowledge in the head” versus “knowledge in the world” distinction — if you have to remember it, you’ll forget it, but if it’s printed on the very item, you’ll just read it.

I mention this because I was beaten twice in the last week by this phenomenon, once by my own hand costing an hour’s extra work, and once by the hand of others, releasing the magic smoke and sending me crawling back to eBay.

The first case is a 3D-printed data and power port, mounted on the underside of a converted hoverboard-transporter thing that I put together for last year’s Chaos Communication Congress. I was actually pretty proud of the design, until I wanted to reflash the firmware a year later.

I knew that I had broken out not just the serial lines and power rails (labelled!) but also the STM32 SWD programming headers and I2C. I vaguely remember having a mnemonic that explained how TX and RX were related to SCK and SDA, but I can’t remember it for the life of me. And the wires snake up under a heatsink where I can’t even trace them out to the chip. “Knowledge in the world”? I failed that, so I spent an hour looking for my build notes. (At least I had them.)

Then the smoke came out of an Arduino Mega that I was using with a RAMPS 1.4 board to drive a hot-wire cutting CNC machine. I’ve been playing around with this for a month now, and it was gratifying to see it all up and running, until something smelled funny, and took out a wall-wart power supply in addition to the Mega.

All of the parts on the RAMPS board are good to 36 V or so, so it shouldn’t have been a problem, and the power input is only labelled “5 A” and “GND”, so you’d figure it wasn’t voltage-sensitive and 18 V would be just fine. Of course, you can read online the tales of woe as people smoke their Mega boards, which have a voltage regulator that’s only good to 12 V and is powered for some reason through the RAMPS board even though it’s connected via USB to a computer. To be honest, if the power input were labelled 12 V, I still might have chanced it with 18 V, but at least I would have only myself to blame.

Part numbers are a great idea, and I’ll put that on my list of New Year’s resolutions for 2021. But better labels, on the device in question, for any connections, isn’t even going to wait the couple weeks until January. I’m changing that right now.

How Much Is Too Much?

December 12, 2020 by Elliot Williams 52 Comments

I definitely tend towards minimalism in my personal projects. That often translates into getting stuff done with the smallest number of parts, or the cheapest parts, or the lowest tech. Oddly enough that doesn’t extend to getting the project done in the minimum amount of time, which is a resource no less valuable than money or silicon. The overkill road is often the smoothest road, but I’ll make the case for taking the rocky, muddy path. (At least sometimes.)

There are a bunch of great designs for CNC hot-wire foam cutters out there, and they range from the hacky to the ridiculously over-engineered, with probably most of them falling into the latter pile. Many of the machines you’ll see borrow heavily from their nearest cousins, the CNC mill or the 3D printer, and sport hardened steel rails or ballscrews and are constructed out of thick MDF or even aluminum plates.

All a CNC foam cutter needs to do is hold a little bit of tension on a wire that gets hot, and pass it slowly and accurately through a block of foam, which obligingly melts out of the way. The wire moves slowly, so the frame doesn’t need to handle the acceleration of a 3D printer head, and it faces almost no load so it doesn’t need any of the beefy drives and ways of the CNC mill. But the mechanics of the mill and printer are so well worked out that most makers don’t feel the need to minimize, simply build what they already know, and thereby save time. They build a machine strong enough to carry a small child instead of a 60 cm length of 0.4 mm wire that weighs less than a bird’s feather.

I took the opposite approach, building as light and as minimal as possible from the ground up. (Which is why my machine still isn’t finished yet!) By building too little, too wobbly, or simply too janky, I’ve gotten to see what the advantages of the more robust designs are. Had I started out with an infinite supply of v-slot rail and ballscrews, I wouldn’t have found out that they’re overkill, but if I had started out with a frame that resisted pulling inwards a little bit more, I would be done by now.

Overbuilding is expedient, but it’s also a one-way street. Once you have the gilded version of the machine up and running, there’s little incentive to reduce the cost or complexity of the thing; it’s working and the money is already spent. But when your machine doesn’t quite work well enough yet, it’s easy enough to tell what needs improving, as well as what doesn’t. Overkill is the path of getting it done fast, while iterated failure and improvement is the path of learning along the way. And when it’s done, I’ll have a good story to tell. Or at least that’s what I’m saying to myself as I wait for my third rail-holder block to finish printing.

Sufficiently Advanced Technology And Justice

December 5, 2020 by Elliot Williams 74 Comments

Imagine that you’re serving on a jury, and you’re given an image taken from a surveillance camera. It looks pretty much like the suspect, but the image has been “enhanced” by an AI from the original. Do you convict? How does this weigh out on the scales of reasonable doubt? Should you demand to see the original?

AI-enhanced, upscaled, or otherwise modified images are tremendously realistic. But what they’re showing you isn’t reality. When we wrote about this last week, [Denis Shiryaev], one of the authors of one of the methods we highlighted, weighed in the comments to point out that these modifications aren’t “restorations” of the original. While they might add incredibly fine detail, for instance, they don’t recreate or restore reality. The neural net creates its own reality, out of millions and millions of faces that it’s learned.

And for the purposes of identification, that’s exactly the problem: the facial features of millions of other people have been used to increase the resolution. Can you identify the person in the pixelized image? Can you identify that same person in the resulting up-sampling? If the question put before the jury was “is the defendant a former president of the USA?” you’d answer the question differently depending on which image you were presented. And you’d have a misleading level of confidence in your ability to judge the AI-retouched photo. Clearly, informed skepticism on the part of the jury is required.

Unfortunately, we’ve all seen countless examples of “zoom, enhance” in movies and TV shows being successfully used to nab the perps and nail their convictions. We haven’t seen nearly as much detailed analysis of how adversarial neural networks create faces out of a scant handful of pixels. This, combined with the almost magical resolution of the end product, would certainly sway a jury of normal folks. On the other hand, the popularity of intentionally misleading “deep fakes” might help educate the public to the dangers of believing what they see when AI is involved.

This is just one example, but keeping the public interested in and educated on the deep workings and limitations of the technology that’s running our world is more important than ever before, but some of the material is truly hard. How do we separate the science from the magic?