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.
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 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.
Last week, I wrote about two recent projects of mine that serve as cautionary tales in keeping projects simple — you probably can’t simplify everything, so it’s worth the time to find out which simplifications have the most bang for the buck. This week, I’d like to share a tale of lack of design focus.
German has the eierlegende Wollmilchsau: a mystical animal that lays eggs, while producing wool, milk, and meat to boot. It’s a little bit like the English “jack of all trades, master of none” except that the eierlegende Wollmilchsau doesn’t do each job badly, it plainly can’t exist. This is obviously a bad way to start a design.
The first surfboard that I made by myself was supposed to be an eierlegende Wollmilchsau. It was going to be a longboard, because we had months with smaller waves that just weren’t all that suitable for shortboarding, but it was also going to turn sharply off the rails like a shortboard. To help it turn, it was going to have tons of camber (bend like a banana), and small fins. And along the way, I thought I’d make it thin to cut through the water.
Of course what I ended up with, not helped by my heavy fiberglassing hand, was a plow that dug into the water, would turn unexpectedly when you managed to get it onto the rails, and couldn’t pick up a small wave to save its life due to the camber and aforementioned plowing. I surfed it anyway, as a matter of pride, but I had no illusions of it being anything but the the worst board I owned. And that’s comparing it to the $30 used rasta-graphic plank that had been taking on water for at least five years, unrepaired, and was rotting out from the inside. At least it had design focus.
My surfboard didn’t suffer from feature creep, where you start piling on features until the project crumbles from overload, but rather from wanting to have my cake and eat it too. Or from failing to realize that certain design goals were necessarily tradeoffs. The “raily” behavior that I wanted when it was in bigger waves was necessarily “diggy” in small waves. Good boards trade off these features, and getting the balance between them is the art of shaping a board.
So when you start up a new project, think about which facets of your design are jointly achievable, and which are necessarily tradeoffs. Ignoring tradeoffs is a recipe for disaster, designing an eierlegende Wollmilchsau. But viewed constructively, it’s exactly these nuanced decisions that separates the simply possible from the truly marvelous. May you identify your trades, and make them well!
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
“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.
Nope. Too complex.
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!
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
[Serge Vaudenay] and [Martin Vuagnoux] released a video yesterday documenting a privacy-breaking flaw in the Apple/Google COVID-tracing framework, and they’re calling the attack “Little Thumb” after a French children’s story in which a child drops pebbles to be able to retrace his steps. But unlike Hänsel and Gretl with the breadcrumbs, the goal of a privacy preserving framework is to prevent periodic waypoints from allowing you to follow anyone’s phone around. (Video embedded below.)
The Apple/Google framework is, in theory, quite sound. For instance, the system broadcasts hashed, rolling IDs that prevent tracing an individual phone for more than fifteen minutes. And since Bluetooth LE has a unique numeric address for each phone, like a MAC address in other networks, they even thought of changing the Bluetooth address in lock-step to foil would-be trackers. And there’s no difference between theory and practice, in theory.
In practice, [Serge] and [Martin] found that a slight difference in timing between changing the Bluetooth BD_ADDR and changing the COVID-tracing framework’s rolling proximity IDs can create what they are calling “pebbles”: an overlap where the rolling ID has updated but the Bluetooth ID hasn’t yet. Logging these allows one to associate rolling IDs over time. A large network of Bluetooth listeners could then trace people’s movements and possibly attach identities to chains of rolling IDs, breaking one of the framework’s privacy guarantees.
This timing issue only affects some phones, about half of the set that they tested. And of course, it’s only creating a problem for privacy within Bluetooth LE range. But for a system that’s otherwise so well thought out in principle, it’s a flaw that needs fixing.
Why didn’t the researchers submit a patch? They can’t. The Apple/Google code is mostly closed-source, in contrast to the open-source nature of most of the apps that are running on it. This remains troubling, precisely because the difference between the solid theory and the real practice lies exactly in those lines of uninspectable code, and leaves all apps that build upon them vulnerable without any recourse other than “trust us”. We encourage Apple and Google to make the entirety of their COVID framework code open. Bugs would then get found and fixed, faster.
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!
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
The best thing about field-programmable gate arrays (FPGAs), when you have a massively parallel application, is that everything runs in parallel. The worst thing about FPGAs, when you need a lot of stuff to happen in sequence, is that everything runs in parallel. If you have a multi-step computation, for example, you need to break it up into chunks, figure out the timing between them, and make sure that each chunk clears before it is fed new data. This is pipelining, and taking care of all the low-level details yourself is one of the things that can sometimes make FPGA a four-letter word beginning with “F”.
[Julian Kemmerer]’s PipelineC is a C-like language that compiles down into VHDL so that you can use it in an FPGA, and it does the pipelining for you. He has examples of how you’d use it to construct a simple state machine, and after you’ve written a few hundred state machines the long way, you’ll know why this is a good idea.
PipelineC isn’t the only high level synthesis language out there, but it sits in an interesting place. It doesn’t take care of memory or define interfaces. It just takes care of pipelining. We haven’t tried it out yet, but it looks like it would be interesting for moderately complex projects, where the mechanics of pipeline signalling is a hassle, but you don’t require the deluxe treatment. Check it out, and if you like it, let us (and [Julian], natch) know.
If you want to dive head-first into pipelining, give [Al Williams]’ two-part mini-series a look.
