Keep It Simple, Smartly

September 5, 2020 by Elliot Williams 13 Comments

“Keep it simple” sounds like such good advice, but what exactly is the “it”; what parts of a project should you try to keep simple? You can’t always make everything simple, can you? Are all kinds of “simplicity” equally valuable, or are there aspects of a design where simplicity has multiplier effects on the rest of the project?

I ran into two seemingly different, but surprisingly similar, design problems in the last couple weeks, and I realized that focusing on keeping one aspect of the project simple had a multiplier effect on the rest — simplifying the right part of the problem made everything drastically easier.

The first example was a scratch-built airplane design. I’d made a few planes over the summer, focusing on plans on the Interwebs that emphasize simplicity of the actual build. Consequently, the planes were a bit heavy, maybe not entirely aerodynamic, and probably underpowered. And this is because the effort you expend building the plane doesn’t fundamentally have anything to do with flight. Keeping the build simple doesn’t necessarily get you a good plane.

Weight, on the other hand, is central. Wings produce lift, whether measured in grams or ounces, and anything heavier just isn’t gonna fly. But reducing weight has a multiplier effect. Less weight means smaller and lighter motors and batteries. Structures don’t need to be as stiff if they’re not subject to heavier bending forces. And, important to the noob pilot, planes with less weight per wing area fly slower, giving me (ahem, the noob pilot) more reaction time when something goes sideways. Trying to simplify the design by trimming weight has knock-on effects all around.

My latest fully-DIY design threw out anything that brought weight along with it, including some parts I thought were necessary for stiffness or crash resistance. But with the significantly lowered weight, these problems evaporated without needing me to solve them — in a way, the complexity of design was creating the problems that the complexity of design was supposed to solve. Ditching it meant that I had a slow plane, with simple-to-build wings, that’s capable of carrying a lightweight FPV camera. Done and done! Simply.

At the same time, I’m building a four-axis CNC foam cutter. I’ve built many 3D printers, and played around with other folks’ DIY CNC machines, so I had a few design ideas in my head starting out. My first iteration of an XY axis for the machine runs on metal angle stock with a whopping eight skate bearings per axis. It’s strong and rigid, and clumsy and overkill, in a bad way for this machine.

3D printers want to move a relatively light tool head around a small volume, but relatively quickly. CNC mills need to be extremely rigid and shoulder heavy side loads, subject to some speed constraints. A foam cutter has none of these needs. The hot wire melts the foam by radiation, so there are no loads on the machine because it doesn’t even contact the workpiece. And because it cuts by melting, it has to go slow. These are the places in the design where simplification will bear the most fruit.

I write this in retrospect, or at least from the perspective of a second prototype. I wanted the first design to hold the cutting filament taut, hence the rigid frame. But separating the tension from the motion, by using a lightweight external bow to keep the filament tight, meant that the machine could be dead simple. I could use smaller plastic sliders instead of complex bearings, on thin rods instead of bulky rails. In a day after having this realization, I got twice as far as I had on the previous machine design in a week, and it takes up a lot less space in my basement.

So take your KISS to the next level. Brainstorm a while about the binding constraints on your design, and what relaxing any of them can do. Do any particular simplifications enable further simplifications? Those are the ones that you want to start with. Keep it simple, smartly. And because it’s not always easy to find these multiplier effects, tell your friends!

Impossibilities And 3D Printing

August 29, 2020 by Elliot Williams 43 Comments

This week our own [Donald Papp] wrote a thought-provoking piece on buying and selling 3D-printer models. His basic point: if you don’t know what you’re getting until you’ve purchased it, and there’s no refund policy, how can you tell if your money is being well spent? It’s a serious problem for these nascent markets, because when customers aren’t satisfied they won’t come back.

It got me thinking about my own experience, albeit with all of the free 3D models out there. They are a supremely mixed bag, and even though you’re not paying for the model, you’re paying in printing time, filament, and effort. It pays to be choosy, and all of [Donald]’s suggestions hold in the “free” market as well.

Only download models that have been printed at least once, have decent documentation about things like layer height, filament type, and support, and to the best of your abilities, be critical about the ability to fabricate the part at all. Fused-deposition printers can only print on top of previous layers, and have a distinct grain, so you need to watch out for overhangs and print orientation. With resin printers, you need to be careful about trapped volumes of uncured resin. You want to be sure that the modeler at least took these considerations into account.

But when your parts have strength requirements, fits, and tolerances, it gets even worse. There’s almost no way a designer can know if you’re overextruding on your first layers or not. Different slicers handle corners differently, making inner surfaces shrink to varying degrees. How can the designer work around your particular situation?

My personal answer is open-source. Whenever possible, I prefer models in OpenSCAD. If you download an STL with ten M8 bolt holes, you could widen them all in a modeling program, but if you’ve got the source code, it’s as easy as changing a single variable. Using the source plays to the customizability of 3D printing, which is perhaps its strongest suit, in my mind. Nobody knows exactly how thick your desk is but you, after all. Making a headphone hook that’s customizable is key.

So even if the markets for 3D prints can solve the reliability problems, through customer reviews or requirements of extensive documentation, they’ll never be able to solve the one-size-fits-nobody issue. Open source fixes this easily. Sell me the source, not the STL!

Seeing The Skill Is Better Than Seeing The Project

August 22, 2020 by Mike Szczys 12 Comments

Pulling off a flashy project that gets the viral-media hug of widespread approval feels great. Getting there is no easy path to walk and often times the craft that went into a finished project doesn’t even take the back seat but gets no mention at all. Often I find I’m more impressed by — or a least my attention is more strongly captured by — the skills put on display as prominently as the finished build.

Case-in-point this week comes from the model railroad work of [Diorama111]. Seeing an OLED screen in the nose of an HO scale locomotive just like the real-life version is impressive, but how many people missed the one-off soldering masterpiece that went into this one? You’ll marvel at the SMD techniques used with through-hole protoboard on this one.

Occasionally we do get to look over the shoulder of the master as decades of skills are shared for the purpose of passing them on. So was the case back in May when we watched as [Leo] walked through his tips and tricks for prototyping at the electronics bench. This included a lot of non-obvious but clever stuff; tips on working with copper tape for solder buses, using Teflon tubing with bare wire instead of stripping PVC-insulated wire, and a deep dive into copper clad prototyping.

So remember all of us hardware geeks when you look to tell the story of your project. We want to know how it was done at least as much as what was done. There was a time when electronic designers were a separate work group from electronic technicians (and wow, those technicians were in a league of their own). These days we all have that technician hat hanging on our workbenches and I’m always interested in packing in yet another unlearnt skill. Throw us a bone!

Hammer Seeks Nail

August 15, 2020 by Elliot Williams 22 Comments

People sometimes say “when you have a hammer, everything looks like a nail” as if that were a bad thing. Hitting up Wikipedia, they’re calling it the Law of the Instrument or Maslow’s Hammer and calling it a cognitive bias. But I like hammers…

I’m working on a new tool, a four-axis hot-wire foam cutter based roughly on this design, but built out of stuff in my basement so far. I want it primarily to turn out wings for RC airplanes so that I can play around with airfoils and construction methods and so on. But halfway through building this new “hammer”, I’m already getting funny ideas of other projects that could be built with it. Classic nail-seeking behavior.

And some of these thoughts are making me reconsider the design of my hammer. I originally wanted to build it low, because it’s not likely that I’ll ever want to cut wing sections taller than 50 mm or so. But as soon as cutting out giant letters to decorate my son’s room, or maybe parts for a boat hull enter my mind, that means a significantly taller cutter, with ensuing complications.

So here I am suffering simultaneously from Maslow’s Hammer and scope creep, but I’m not sad about either of these “ills”. Playing with a couple manual prototypes for the CNC hot-wire cutter has expanded my design vocabulary; I’ve thought of a couple cool projects that I simply wouldn’t have had the mental map for before. Having tools expands the possible ways you can build, cognitive bias or not.

One person’s scope creep is another’s “fully realizing the potential of a project”. I’m pretty sure that I’ll build a version two of this machine anyway, so maybe it’s not a big deal if the first draft were height-limited, but the process of thinking through the height problem has actually lead me to a better design even for the short cutter. (Tension provided by an external bow instead of born by the vertical CNC towers. I’ll write the project up when I’m done. But that’s not the point.)

Maybe instead of lamenting Maslow’s cognitive bias, we should be celebrating the other side of the same coin: that nails are tremendously useful, and that the simple fact of having a hammer can lead you to fully appreciate them, and in turn expand what you’re capable of. As for scope creep? As long as I get the project done over my vacation next week, all’s well, right?

DIY HID, OMG!

August 8, 2020 by Elliot Williams 15 Comments

William English, one of the creators of the mouse back in the 60s, passed away last week. And that got me thinking of how amazing it would have been to be in the place that was inventing what would become modern computing interfaces. What a special time! Of course, they probably had no idea.

From here, it looks like the mouse changed everything, but you have to realize that they were working in a world with light-pens, where you could actually draw on the screen. In contrast, the mouse seems positively non-futuristic. They must have known they’d come up with an improvement over the status quo, but did they know they’d created a revolution?

So where has the revolutionary spirit in DIY human interface devices gone? I’d claim it’s still alive and kicking. Indeed our own Kristina Panos has a series called “Inputs of Interest” and we’ve seen a ton of DIY keyboards of late. Then there are many varieties of dial inputs. I used to have a dedicated scroll wheel made out of a hard-drive platter, and when I was reading lots of PDFs on-screen, I have to say it earned its desk-space. Heck, we’ve even seen people make their own mouse.

But what I love about the story of the development of the mouse is that they asked the question “what is the best way to locate a point on a screen” and tried to answer it. Half of their success is probably in simply asking the right question, and the other half in prototyping something half-workable. My gut says that we don’t have inputs figured out 100% on mobile yet. This sounds like a job for Hackaday. What’s the next big human-interface design need? And have you got any crazy ideas to solve it?

Hackaday Remoticon

And this week, we announced the Hackaday Remoticon, our shelter-in-place version of the Supercon. It’s going to take place in November as usual, but online instead of IRL.

The good news? It’s going to be chock full of workshops, all streamed online and recorded for posterity. And for that we need your proposals. If you’d like to teach a group of distributed hackers learning your favorite techniques and tricks, this is your chance!

The bad news is of course that we won’t get to see you all in person. That’s going to make the 2021 Hackaday Supercon seem even more super.

Stop Bad Laws Before They Start

July 25, 2020 by Elliot Williams 88 Comments

With everything else going on this summer, you might be forgiven for not keeping abreast of new proposed regulatory frameworks, but if you’re interested in software-defined radio (SDR) or even reflashing your WiFi router, you should. Right now, there’s a proposal to essentially prevent you from flashing your own firmware/software to any product with a radio in it before the European Commission. This obviously matters to Europeans, but because manufacturers often build hardware to the strictest global requirements, it may impact everyone. What counts as radio equipment? Everything from WiFi routers to wearables, SDR dongles to shortwave radios.

The idea is to prevent rogue reconfigurable radios from talking over each other, and prevent consumers from bricking their routers and radios. Before SDR was the norm, and firmware was king, it was easy for regulators to test some hardware and make sure that it’s compliant, but now that anyone can re-flash firmware, how can they be sure that a radio is conformant? Prevent the user from running their own firmware, naturally. It’s pretty hard for Hackaday to get behind that approach.

The impact assessment sounds more like advertising copy for the proposed ruling than an honest assessment, but you should give it a read because it lets you know where the commission is coming from. Reassuring is that they mention open-source software development explicitly as a good to be preserved, but their “likely social impacts” include “increased security and safety” and they conclude that there are no negative environmental impacts. What do you do when the manufacturer no longer wants to support the device? I have plenty of gear that’s no longer supported by firmware updates that is both more secure and simply not in the landfill because of open-source firmware.

Similarly, “the increased capacity of the EU to autonomously secure its products is also likely to help the citizens to better protect their information-related rights” is from a bizarro world where you can trust Xiaomi’s home-automation firmware to not phone home, but can’t trust an open-source replacement.

Public comment is still open, and isn’t limited to European citizens. As mentioned above, it might affect you even if you’re not in the EU, so feel free to make your voice heard. You have until September, and you’ll be in some great company if you register your complaints. Indeed, reading through the public comments is quite heartening: Universities, researchers, and hackers alike have brought up reasons to steer clear of the proposed approach. We hope that the commission hears us.