Boxes.py Has Your Lasercut Box Needs Covered

I needed something to test out a low-power laser cutter, and thought that some small cardboard boxes would fit the bill nicely, so off I went to scour the Interwebs for a quick-and-dirty finger-joint box generator. And the best of the best was to be found, drumroll please, on Hackaday.io. [Florian Festi]’s boxes.py not only has a sweet web interface, covers an absurd number of box styles, and includes kerf tests to ensure that your joints are tight, but it’s also written in easy-to-extend Python for when you have really particular needs.

But you won’t need to design anything of your own. There are already boxes with living hinges, boxes that fit 19″ racks, Eurorack skiff boxes with laser-cut mounting rails, and even a generic electronics project box with mounting ears for your PCB. Console2 has integrated clips on the rear service hatch.

You need a pentagonal prism with a round opening? What size? I guess a complete arcade-style console is technically a box. Naturally, there are also geartrains and even a robot arm design. Wait, what?

Each of the box designs is fully customizable, so it’s easy to make something like a box with customized dividers, where the different compartments are specified in a sweet text markup. [Florian]’s example box set for the game Agricola is amazing.

Underpinning the code is a LOGO-like finger-joint drawing routine. This makes it relatively easy to draw your own funny shapes, and have the hard work of thinking through the joining fingers taken care of by the computer. [Florian] seems open to taking pull requests for new box shapes, but I haven’t thought of one yet.

I can’t say enough about how cool boxes.py is, and most of the demo applications are worth a look on their own. This was an entry in the Hackaday Prize back in 2017, and it’s been growing and improving ever since. Way to go, [Florian] and Co.

Waterjet-Cut Precision Pastry

We need more high-end, geometric pastry in our lives. This insight is courtesy of a fairly old video, embedded below, demonstrating an extremely clever 2D CNC mechanism that cuts out shapes on a cake pan, opening up a universe of arbitrary cake topologies.

The coolest thing about this machine for us is the drive mechanism. A huge circular gear is trapped between two toothed belts. When the two belts move together the entire thing translates, but when they move in opposite directions, it turns. It seems to be floating on a plastic platform, and because the design allows the water-jet cutting head to remain entirely fixed, only a small hole underneath is necessary, which doubtless simplifies high-pressure water delivery and collection. Rounding the machine out are cake pans make up of vertical slats, like on a laser- or plasma-cutter table, that slip into registration pins and let the water pass through.

The kinematics of this machine are a dream, or perhaps a nightmare. To cut a straight line, it does a cycloid-shaped dance of translation and turning that you simply have to see in motion. Because of this intricate path, the cake-feed speed varies along the way, so this machine won’t be perfect for all applications and relies on a thin kerf. And we can’t help thinking how dizzy the cake must get in the process.

Indeed, the same company put out a relatively pedestrian two-arm motion cutter (another video!) that poses different kinematic problems. It’s essentially a two-arm plotter with a moving table underneath that helps increase the working area. Details are scarce, but it looks like they’re minimizing motion of the moving table, doing the high frequency small stuff with the stiff arms. Presumably someone turned the speed on the previous machine up to 11 and spun a cake off into the room, causing them to rethink the whole move-the-cake-around design.

Of course, watercut pastry isn’t limited to exotic CNC mechanisms. This (third!) video demonstrates that a simple Cartesian XY bot can do the job as well.

If you think about it, using high-pressure pure water to cut foodstuffs is a win on many levels. We’d just miss out on licking the knife. Thanks [Adam G DeMuri] for the awesome comment that lead us to a new world of watercut edibles.

Continue reading “Waterjet-Cut Precision Pastry”

99% Inspiration, 99% Perspiration, And 99% Collaboration

I was watching an oldish TEDx talk with Rodney Mullen, probably the most innovative street skater ever, but that’s not the point, and it’s not his best talk either. Along the way, he makes a claim that ideas — in particular the idea that a particular skateboard trick is even possible — are the most important thing.

His experience, travelling around the world on skateboard tours, is that there are millions of kids who are talented enough that when they see a video demonstrating that a particular trick idea is possible, they can replicate it in short order. Not because the video showed them how, but because it expanded their mind’s-eye view of what is possible. They were primed, and so what pushed them over the edge was the inspiration.

On the other side of the street, we’ve got Thomas Edison and his “1% inspiration, 99% perspiration” routine. Edison famously tried a bazillion filament recipes before settling on tungsten, and attributes his success to “putting his time in” or “good old-fashioned hard work” or similar. So who’s right?

The inventor of Casper Slide and the phonograph are both right. Rodney is taking it for granted that these kids have put their time in; they are skaters after all, they skate. He doesn’t see the 99% perspiration because it is the natural background, while the inspiration flashes out in Eureka moments.

Similarly, Thomas E. way underestimates inspiration. He’s already fixated on this novel idea to take an arc lamp and contain it in a glass envelope — that’s what he’s spending all of his perspiration on, after all. But without that key inspiration, all he’d be is sweaty.

And they’re also both wrong! They’re both missing a third ingredient: collaboration. Certainly Mullen, who spent his life hanging out with other skaters, teaching them what he knows, and learning from them in turn, wouldn’t say the community of skaters didn’t shape him. Even in the loner’s sport of skating, nobody is alone. And Edison? His company profited greatly from broader advances in science, and the scientific literature. Menlo Park existed to take bright, well-trained minds and put them all in one place, sharing, teaching, and working together. It embodied the idea of collaborative innovation, and that’s where some of his best work was done.

So I’m with Isaac Newton, “standing on the shoulders of giants“. Success is 99% collaboration. This leaves us with one problem: the percentages don’t add up. But that’s alright by me.

Printing Yoda Heads: Re-Makers Riffing!

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!”

It Ain’t Broke, But Should I Fix It?

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?)

Open Source: It’s The Little Things

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!

Hands-On: The RISC-V ESP32-C3 Will Be Your New ESP8266

We just got our hands on some engineering pre-samples of the ESP32-C3 chip and modules, and there’s a lot to like about this chip. The question is what should you compare this to; is it more an ESP32 or an ESP8266? The new “C3” variant has a single 160 MHz RISC-V core that out-performs the ESP8266, and at the same time includes most of the peripheral set of an ESP32. While RAM often ends up scarce on an ESP8266 with around 40 kB or so, the ESP32-C3 sports 400 kB of RAM, and manages to keep it all running while burning less power. Like the ESP32, it has Bluetooth LE 5.0 in addition to WiFi.

Espressif’s website says multiple times that it’s going to be “cost-effective”, which is secret code for cheap. Rumors are that there will be eight-pin ESP-O1 modules hitting the streets priced as low as $1. We usually require more pins, but if medium-sized ESP32-C3 modules are priced near the ESP8266-12-style modules, we can’t see any reason to buy the latter; for us it will literally be an ESP8266 killer.

On the other hand, it lacks the dual cores of the ESP32, and simply doesn’t have as many GPIO pins. If you’re a die-hard ESP32 abuser, you’ll doubtless find some features missing, like the ultra-low-power coprocessor or the DACs. But it does share a lot of the ESP32 standouts: the LEDC (PWM) peripheral and the unique parallel I2S come to mind. Moreover, it shares the ESP-IDF framework with the ESP32, so despite running on an entirely different CPU architecture, a lot of code will run without change on both chips just by tweaking the build environment with a one-liner.

One of these things is not like the other

If you were confused by the chip’s name, like we were, a week or so playing with the new chip will make it all clear. The ESP32-C3 is a lot more like a reduced version of the ESP32 than it is like an improvement over the ESP8266, even though it’s probably destined to play the latter role in our projects. If you count in the new ESP32-S3 that brings in USB, the ESP32 family is bigger than just one chip. Although it does seem odd to lump the RISC-V and Tensilica CPUs together, at the end of the day it’s the peripherals more than the CPUs that differentiate microcontrollers, and on that front the C3 is firmly in the ESP32 family.

Our takeaway: the ESP32-C3 is going to replace the ESP8266 in our projects, but it won’t replace the ESP32 which simply has more of everything when we need it. The shared codebase and peripheral architecture makes it easier to switch between the two when we don’t need the full-blown ESP32. In that spirit, we welcome the newcomer to the family.

But naturally, we’ve got a lot more to say about it. Specifically, we were interested in exactly what the RISC-V core brought to the table, and ran the module through power and speed comparisons with the ESP32 and ESP8266 — and it beats them both by a small margin in our benchmarks. We’ve also become a lot closer friends with the ESP-IDF SDK that all of the ESP32 family chips use, and love how far it has come in the last year or so. It’s not as newbie-friendly as ESP-Arduino, for sure, but it’s a ton more powerful, and we’re totally happy to leave the ESP8266 SDK behind us.

Continue reading “Hands-On: The RISC-V ESP32-C3 Will Be Your New ESP8266”