Performing over-the-air updates of devices in the field can be a tricky business. Reliability and recovery is of course key, but even getting the right bits to the right storage sectors can be a challenge. Recently I’ve been working on a project which called for the design of a new pathway to update some small microcontrollers which were decidedly inconvenient.
There are many pieces to a project like this; a bootloader to perform the actual updating, a robust communication protocol, recovery pathways, a file transfer mechanism, and more. What made these micros particularly inconvenient was that they weren’t network-connected themselves, but required a hop through another intermediate controller, which itself was also not connected to the network. Predictably, the otherwise simple “file transfer” step quickly ballooned out into a complex onion of tasks to complete before the rest of the project could continue. As they say, it’s micros all the way down.
In the older days of open source software, major projects tended to have their Benevolent Dictators For Life who made all the final decisions, and some mature projects still operate that way. Guido van Rossum famously called his language “Python” because he liked the British comics of the same name. That’s the sort of thing that only a single developer can get away with.
However, in these modern times of GitHub, GitLab, and other collaboration platforms, community-driven decision making has become a more and more common phenomenon, shifting software development towards democracy. People begin to think of themselves as “Python programmers” or “GIMP users” and the name of the project fuses irrevocably with their identity.
What happens when software projects fork, develop apart, or otherwise change significantly? Obviously, to prevent confusion, they get a new name, and all of those “Perl Monks” need to become “Raku Monks”. Needless to say, what should be a trivial detail — what we’ve all decided to call this pile of ones and zeros or language constructs — can become a big deal. Don’t believe us? Here are the stories of renaming Python, Perl, and the GIMP.
We hackers just can’t get enough of sorters for confections like Skittles and M&Ms, the latter clearly being the superior candy in terms of both sorting and snackability. Sorting isn’t just about taking a hopper of every color and making neat monochromatic piles, though. [JohnO3] noticed that all those colorful candies would make dandy pixel art, so he built a bot to build up images a Skittle at a time.
Dubbed the “Pixel8R” after the eight colors in a regulation bag of Skittles, the machine is a largish affair with hoppers for each color up top and a “canvas” below with Skittle-sized channels and a clear acrylic cover. The hoppers each have a rotating disc with a hole to meter a single Skittle at a time into a funnel which is connected to a tube that moves along the top of the canvas one column at a time. [JohnO3] has developed a software toolchain to go from image files to Skittles using GIMP and a Python script, and the image builds up a row at a time until 2,760 Skittle-pixels have been placed.
The downside: sorting the Skittles into the hoppers. [JohnO3] does this manually now, but we’d love to see a sorter like this one sitting up above the hoppers. Or, he could switch to M&Ms and order single color bags. But where’s the fun in that?
Sometimes we forget how awesome laser cutters really are. After all, they’re essentially giant plotters that shoot infrared lasers to cut and engrave almost anything. Most of the time, we’ll use the cutting feature in order to make rapid prototypes for different projects. We might engrave a logo or text on there too — but with a bit of image pre-processing, you can actually etch grey scale images that look really good.
[miststlkr] has been experimenting with different processes to get the best engraving, and he’s decided to share his findings. He’s created a guide on Instructables, and it’s a pretty quick read. You’re going to need some image editing software, for which [miststlkr] recommends Gimp — as do we.
From there it’s just a matter of a few steps to simplify the image. Start by converting the image to indexed colors — this limits the number of colors the image can have, he recommends limiting to about 4 colors for now. From there, convert to grey scale and import into your favorite laser software. Now it’s time to start testing.
Check out the resistor color code reference cards I just whipped up. I was inspired by the PCB versions that Octopart has been crowdfunding this week. Those didn’t have the information I would normally be looking up, so I decided to whip up a few of my own and put them out there for inspiration or for you to print yourselves.
Put your face close to the screen and cross your eyes until the two images above become one. You may need to adjust the tilt of your chin to make it happen, but when they come together you’ll see [John Lennon] pop out in 3D. This was made using a 3D rendering script for The Gimp.
The process is not entirely automatic, but it won’t take too long to mask off the outlines for different depth layers. The script makes three different layers from the image. One of them is a color-coded depth map that uses a custom color palatte to choose distance for each item. If you paint the background dark blue it will be processed at the furthest distance from the viewer’s cross-eyed perspective, yellow is the nearest.
[Don] mentions a parallel output and a cross-eyed output in his write up. We understand the cross-eyed version, but are just guessing that the parallel version would be used in a stereoscopic viewer that puts a partition between the two images so that each eye sees a different frame. You know, like a View-Master.
[Pixel_Outlaw] has been working on a method to capture 360 images with his camera. He’s using a shiny Christmas ball ornament to reflect the entire room into the lens of the camera. In the unwrapped image you can make out the three legs of his tripod. In that snapshot he laid the ornament on the floor and pointed the camera straight down from above.
What catches our attention is the post processing he used to unwrap the image. He loaded up The Gimp, an open source image manipulation program, and used just three steps to unwrap the image. First he cropped the picture so that it was square and the spherical ornament was perfectly centered. Then he ran the polar coordinates filter. Finally he scaled the image, setting the width to be Pi times the height. Works pretty darned well for something that doesn’t take much fiddling.
The ornament wasn’t perfectly smooth (or maybe it was a bit dirty) but you can get a much better starting image if you use a bulb with a silver reflector like we saw in this older hack.