We had a comment recently from a nasty little troll (gasp! on the Internet!). The claim was that most makers are really just “copiers” because they’re not doing original work, whatever that would mean, but instead just re-making projects that other people have already done. People who print other peoples’ 3D models, or use other peoples’ hardware or software modules are necessarily not being creative. Debunking a cheap troll isn’t enough because, on deeper reflection, I’m guilty of the same generic sentiment; that feeling that copying other people’s work isn’t as worthy as making your own. And I think that’s wrong!
In the 3D printing world in particular, I’m guilty of dismissively classifying projects as “Yoda Heads”. About ten years ago, [chylld] uploaded a clean, high-res model of Yoda to Thingiverse, and everyone printed it out. Heck, my wife still has hers on her desk; and alone this is proof that straight-up copying has worth, because it made a sweet little gift. After a while, Yoda gave way to Baby Groots, and strangely enough we’re back to Yoda again, but it’s Baby Yoda now. Continue reading “Printing Yoda Heads: Re-Makers Riffing!”→
When you make something, what does version one look like? What I mean is, how much thought do you put into the design? Do you try to make it look nice as you go along, or do you just build something that functions and say screw the presentation? Do you try to solve for everything upfront, or just plow through it and promise to fix your mistakes in version two? What if you never make version two?
No matter what you like to make, there’s a first time for everything. And it doesn’t seem to matter if you need the thing you’re making or just want to have it around: it’s a given that version one will probably be a bit rough around the edges. That’s just how it goes. Even if you’re well-versed in a skill, when you try a new type of project or a new pattern, it will be a new experience. For example, I’ve sewn a dozen different purses, but when I took on a new challenge I found I was only somewhat prepared to make my first backpack.
Great is the enemy of good, and perfection is the enemy of progress. Shooting for a pristine prototype on the first go steep and rocky path that never leads to finishing the build. So our goal here is to decide what makes rev1 good enough that we still love it, even if rev2 never happens.
Five years ago, I wrote a series on getting started with your own MQTT-based home information/automation network. Five years is a long while in Hackaday time. Back then, the ESP8266 was a lot newer, and the 8266 Arduino port wasn’t fully in shape yet, and the easiest software framework to get MQTT up and running was NodeMCU; so that’s what I used for the article series, and as a consequence a handful of devices around my house run minor modifications of that basic “hello world”, but doing useful stuff.
Since then, NodeMCU has changed a bunch of its libraries and the ESP32 has replaced the ESP8266 in my parts drawer. If you tried to run my code, you’d find that it won’t run on an ESP8266 without porting or compiling an old version of NodeMCU for yourself anyway, and it won’t run on an ESP32 at all. When [Chris Lott] tried to follow my guide, he discovered that Micropython is probably a better language choice in 2021. To minimize lines of code, I’d agree, although the Arduino and Espressif’s own native IDF have grown into the job just about as well. In short, anything but NodeMCU.
Built in an hour, survived for five years.
But my home automation system doesn’t care. Those little guys are running 24/7, flipping bits like it was still 2016. Thermometers, light sensors, and power meters haven’t changed much in five years, and although I’ve revamped the databasing, display, and user control a number of times since then, using a fixed communication transport protocol means that they’re still talking the same language. Indeed, even if NodeMCU is dead to me, the MQTT content of my original series is all still valid, and installing a broker on a Raspberry Pi has only become easier in the intervening five years.
So I’ve got a bunch of legacy code running within the walls of my own home, and it makes me nervous. If the devices fail, or maybe when they eventually fail, it’s not going to be “just flash another ESP8266 and replace it”, because even though I have some ancient NodeMCU binaries sitting around, I know when to throw in the towel. But there’s no good reason to pull them down and start reflashing either. Except that it makes me a little bit itchy, just knowing that there’s orphaned, dead-end code running all around me. Surrounding me. Staring deep into my hacker’s heart.
I know better than to tear down a running system, even though I could do it one device at a time, and each module would surely be a simple, independent fix; even though I’d love the excuse to play around with Micropython and its MQTT implementation on the ESP8266, or maybe even swap some of them out for ESP32s; even though these were all temporary quick hacks that have somehow served for five (5!) years. I certainly know better, right? (Right?)
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!
I use open source software almost exclusively; at least on the desktop — the phone is another matter, sadly. And I do a lot of stuff with and on computers. Folks outside of the free software scene are still a little surprised when small programs are free to use and modify, but they’re downright skeptical when it comes to the big works of professional software. It’s one thing to write xeyes, but how about something to rival Photoshop, or Altium?
Of course, we all know the answer — mostly. None of the “big” software packages work exactly the same as their closed-source counterparts, often missing a few features here and gaining a few there, or following a different workflow. That’s OK, different closed-source programs work differently as well. I’m not here to argue that GIMP is better than Photoshop, but rather to point out what I really love about open software: it caters to the little guys and gals, the niche users, and the specialists. Or rather, it lets them cater to themselves.
I just started learning FreeCAD for a CNC milling project, and it’s awesome. I’ve used Fusion 360, and although FreeCAD isn’t “the same” as Fusion 360, it has most of the features that I need. But it’s the quirky features that set it apart.
The central workflow is to pick a “workbench” where specific tasks are carried out, and then you take your part to each bench, operate on it, and then move to the next one you need. But the critical bit here is that a good number of the workbenches are contributed to the open project by people who have had particular niche needs. For me, for instance, I’ve done most of my 3D modelling for 3D printing using OpenSCAD, which is kinda niche, but also the language that underpins Thingiverse’s customizer functionality. Does Fusion 360 seamlessly import my OpenSCAD work? Nope. Does FreeCAD? Yup, because some other nerd was in my shoes.
And then I started thinking of the other big free projects. Inkscape has plugins that let you create Gcode to drive CNC mills or strange plotters. Why? Because nerds love eggbots. GIMP has plugins for every imaginable image transformation — things that 99% of graphic artists will never use, and so Adobe has no incentive to incorporate.
Open source lets you scratch your own itch, and share your solution with others. The features of for-pay, closed-source software are driven by the masses: “is this a feature that enough of our customers want?” The features of open-source software are driven by the freaky ideas of nerds just like me. Vive la différence!
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!
We’re knee-deep in new microcontrollers over here, from the new Raspberry Pi Pico to an engineering sample from Espressif that’s right now on our desk. (Spoiler alert, review coming out Monday.) And microcontroller peripherals are a little bit like Pokemon — you’ve just got to catch them all. If a microcontroller doesn’t have 23 UARTS, WiFi, Bluetooth, IR/DA, and a 16-channel 48 MHz ADC, it’s hardly worth considering. More is always better, right?
No, it’s not. Chip design is always a compromise, and who says you’re limited to one microcontroller per project anyway? [Francesco] built a gas-meter reader that reminded to think outside of the single-microcontroller design paradigm. It uses an ATtiny13 for its low power sleep mode, ease of wakeup, and decent ADCs. Pairing this with an ESP8266 that’s turned off except when the ATtiny wants to send data to the network results in a lower power budget than would be achievable with the ESP alone, but still gets his data up into his home-grown cloud.
Of course, there’s more complexity here than a single-micro solution, but the I2C lines between the two chips actually form a natural division of work — each unit can be tested separately. And it’s using each chip for what it’s best at: simple, low-power tasks for the Tiny and wrangling WiFi on the ESP.
Once you’ve moved past the “more is better” mindset, you’ll start to make a mental map of which chips are best for what. The obvious next step is combination designs like this one.
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!
I was reading Sonya Vasquez’s marvelous piece on the capstan equation this week. It’s a short, practical introduction to a single equation that, unless you’re doing something very strange, covers everything you need to know about friction when designing something with a rope or a cable that has to turn a corner or navigate a wiggle. Think of a bike cable or, in Sonya’s case, a moveable dragon-head Chomper. Turns out, there’s math for that! Continue reading “Run The Math, Or Try It Out?”→
I know it is a common stereotype for an old guy to complain about how good the kids have it today. I, however, will take a little different approach: We have it so much better today when it comes to access to information than we did even a few decades ago. Imagine if I asked you the following questions:
Where can you have a custom Peltier device built?
What is the safest chemical to use when etching glass?
What does an LM1812 IC do?
Who sells AWG 12 wire with Teflon insulation?
You could probably answer all of these trivially with a quick query on your favorite search engine. But it hasn’t always been that way. In the old days, we had to make friends with three key people: the reference librarian, the vendor representative, and the old guy who seemed to know everything. In roughly that order. Continue reading “Before Google, There Was The Reference Librarian”→
