In one hand you hold the soldering iron, in the other the solder, and in two more hands the parts you’re trying to solder together. Clearly this is a case where helping hands could be useful.
One reason is to take advantage of standardized, open source creativity. Anyone can share a model of their design for all to use as is, or to modify for their needs. A case in point is the ball and socket model which I downloaded for a helping hand. I then drew up and printed a magnifying glass holder with a matching socket, made a variation of the ball and socket joint, and came up with a magnetic holder with matching ball. Let’s takea look at what worked well and what didn’t.
When is a hot glue stick not a hot glue stick? When it’s PLA, of course! A glue gun that dispenses molten PLA instead of hot glue turned out to be a handy tool for joining 3D-printed objects together, once I had figured out how to print my own “glue” sticks out of PLA. The result is a bit like a plus-sized 3D-printing pen, but much simpler and capable of much heavier extrusion. But it wasn’t quite as simple as shoving scrap PLA into a hot glue gun and mashing the trigger; a few glitches needed to be ironed out.
Why Use a Glue Gun for PLA?
Some solutions come from no more than looking at two dissimilar things while in the right mindset, and realizing they can be mashed together. In this case I had recently segmented a large, hollow, 3D model into smaller 3D-printer-sized pieces and printed them all out, but found myself with a problem. I now had a large number of curved, thin-walled pieces that needed to be connected flush with one another. These were essentially butt joints on all sides — the weakest kind of joint — offering very little surface for gluing. On top of it all, the curved surfaces meant clamping was impractical, and any movement of the pieces while gluing would result in other pieces not lining up.
An advantage was that only the outside of my hollow model was a presentation surface; the inside could be ugly. A hot glue gun is worth considering for a job like this. The idea would be to hold two pieces with the presentation sides lined up properly with each other, then anchor the seams together by applying melted glue on the inside (non-presentation) side of the joint. Let the hot glue cool and harden, and repeat. It’s a workable process, but I felt that hot glue just wasn’t the right thing to use in this case. Hot glue can be slow to cool completely, and will always have a bit of flexibility to it. I wanted to work fast, and I wanted the joints to be hard and stiff. What I really wanted was melted PLA instead of glue, but I had no way to do it. Friction welding the 3D-printed pieces was a possibility but I doubted how maneuverable my rotary tool would be in awkward orientations. I was considering ordering a 3D-printing pen to use as a small PLA spot welder when I laid eyes on my cheap desktop glue gun.
If you’ve ever worked on a small PCB, you know how much of a hassle it can be to hold on to the thing. It’s almost as if they weren’t designed to be held in the grubby mitts of a human. As designs have become miniaturized over time, PCBs are often so fragile and festooned with components that tossing them into the alligator clips of the classic soldering “third hand” can damage them. The proper tool for this job is a dedicated PCB vise, which is like a normal bench vise except it doesn’t crank down very hard and usually has plastic pads on the jaws to protect the board.
Only problem with a PCB vise is, like many cool tools and gadgets out there, not everybody owns one. Unless you’re doing regular PCB fabrication, you might not take the plunge and buy one either. So what’s a hacker on a budget to do when they’ve got fiddly little PCBs that need attention?
Luckily for us, we live in a world where you can press a button and have a magical robot on your desktop build things for you. Online model repositories like Thingiverse and YouMagine are full of designs for printable PCB vises, all you have to do is pick one. After looking through a number of them I eventually decided on a model designed by [Delph27] on Thingiverse, which I think has a couple of compelling features and more than deserves the few meters of filament it will take to add to your bench.
Of course the best part of all of this is that you can customize and improve the designs you download, which is what I’m about to do with this PCB vise!
As hackers, we like to think of ourselves as a logical bunch. But the truth is, we are as subject to fads as the general public. There was a time when the cool projects swapped green LEDs out for blue ones or added WiFi connectivity where nobody else had it. Now all the rage is to connect your project to a personal assistant. The problem is, this requires software. Software that lives on a publicly accessible network somewhere, and who wants to deal with that when you’re just playing with custom Alexa skills for the first time?
If you have a computer that faces the Internet, that’s fine. If you don’t, you can borrow one of Amazon’s, but then you need to understand their infrastructure which is a job all by itself. However, there is a very simple way to jump start an Alexa skill. I got one up and running in virtually no time using a website called Glitch. Glitch is a little bit of everything. It is a web hosting service, a programming IDE for Node.js, a code repository, and a few other things. The site is from the company that brought us Trello and helped to start Stack Overflow.
Glitch isn’t about making Alexa skills. It is about creating web applications and services easily. However, that’s about 90% of the work involved in making an Alexa skill. You’ll need an account on Glitch and an Amazon developer’s account. Both are free, at least for what we want to accomplish. Glitch has some templates for Google Home, as well. I have both but decided to focus on Alexa, for no particular reason.
Here on Hackaday, we’re generally designers of hacks that live in the real world. Nevertheless, I’m convinced that some of the most interesting feats are at the mercy of what’s possible in software, not hardware. Without the right software, no 3D printer could print and no quadcopter could fly. The source code that drives these machines may take months of refinement to flesh out their structure. In a nutshell, these software packages are complicated, and they don’t happen overnight.
So how do they happen; better yet: how could we make that happen? How do we write software that’s flexible enough to coexist peacefully on all sorts of hardware variations?
What separates the big open-source software projects like ROS, LinuxCNC, and Multiwii from the occastional hackathon code are the underlying principles that govern how they’re written. In object-oriented programming, these principles are called design patterns. In the next couple posts, I’m going to crack the lid on a few of these. What’s more, I’ll package them into real-world examples so that we can see these patterns interact with real hardware. The next time you pop open the source code for a big open source hardware project, I hope you can tease out some of these patterns in the code. Better yet, I hope you carry these patterns into your next robot and machine project. Let’s get started.
For readability, all of the examples run in Python3. The snippets below are truncated for brevity, but the real examples in the repository will work if you’ve got a similar hardware setup.
Given the incredibly low prices on some of the models currently on the market, it’s more than likely a number of Hackaday readers have come out of the holiday season with a shiny new desktop 3D printer. It’s even possible some of you have already made the realization that 3D printing is a bit harder than you imagined. Sure the newer generation of 3D printers make it easier than ever, but it’s still not the same “click and forget” experience of printing on paper, for instance.
In light of this, I thought it might be nice to start off the new year with some advice for those who’ve suddenly found themselves lost in a forest of PLA. Some of this information may seem obvious to those of us who’ve spent years huddled over a print bed, but as with many technical pursuits, we tend to take for granted the knowledge gained from experience. For my own part, the challenges I faced years ago with my first wooden 3D printer were wholly different than what I imagined. I assumed that the real challenge would be getting the machine assembled and running, but the time it took to build the machine was nothing in comparison to the hours and hours of trial and error it took before I gained the confidence to really utilize the technology.
Of course, everyone’s experience is bound to be different, and we’d love to hear about yours in the comments. Grand successes, crushing defeats, and everything in between. It’s all part of the learning process, and all valuable information for those who are just starting out.
What do you do, when you need a random number in your programming? The chances are that you reach for your environment’s function to do the job, usually something like rand() or similar. This returns the required number, and you go happily on your way.
A shift register configured as a pseudo-random number generator. [by KCAuXy4p CC0 1.0]Except of course the reality isn’t quite that simple, and as many of you will know it all comes down to the level of randomness that you require. The simplest way to generate a random number in software is through a pseudo-random number generator, or PRNG. If you prefer to think in hardware terms, the most elementary PRNG is a shift register with a feedback loop from two of its cells through an XOR gate. While it provides a steady stream of bits it suffers from the fatal flaw that the stream is an endlessly repeating sequence rather than truly random. A PRNG is random enough to provide a level of chance in a computer game, but that predictability would make it entirely unsuitable to be used in cryptographic security for a financial transaction.
There is a handy way to deal with the PRNG predictability problem, and it lies in ensuring that its random number generation starts at a random point. Imagine the shift register in the previous paragraph being initialised with a random number rather than a string of zeros. This random point is referred to as the seed, and if a PRNG algorithm can be started with a seed derived from a truly unpredictable source, then its output becomes no longer predictable.
Selecting Unpredictable Seeds
Computer systems that use a PRNG will therefore often have some form of seed() function alongside their rand() function. Sometimes this will take a number as an argument allowing the user to provide their own random number, at other times they will take a random number from some source of their own. The Sinclair 8-bit home computers for example took their seed from a count of the number of TV frames since switch-on.
The not-very-random result of a thousand analogRead() calls.
The Arduino Uno has a random() function that returns a random number from a PRNG, and as you might expect it also has a randomSeed() function to ensure that the PRNG is seeded with something that will underpin its randomness. All well and good, you might think, but sadly the Atmel processor on which it depends has no hardware entropy source from which to derive that seed. The user is left to search for a random number of their own, and sadly as we were alerted by a Twitter conversation between @scanlime and @cybergibbons, this is the point at which matters start to go awry. The documentation for randomSeed() suggests reading the random noise on an unused pin via analogRead(), and using that figure does not return anything like the required level of entropy. A very quick test using the Arduino Graph example yields a stream of readings from a pin, and aggregating several thousand of them into a spreadsheet shows an extremely narrow distribution. Clearly a better source is called for.
Noisy Hardware or a Jittery Clock
As a slightly old-school electronic engineer, my thoughts turn straight to a piece of hardware. Source a nice and noisy germanium diode, give it a couple of op-amps to amplify and filter the noise before feeding it to that Arduino pin. Maybe you were thinking about radioactive decay and Geiger counters at that point, or even bouncing balls. Unfortunately though, even if they scratch the urge to make an interesting piece of engineering, these pieces of hardware run the risk of becoming overcomplex and perhaps a bit messy.
The significantly more random result of a thousand Arduino Entropy Library calls.
The best of the suggestions in the Twitter thread brings us to the Arduino Entropy Library, which uses jitter in the microcontroller clock to generate truly random numbers that can be used as seeds. Lifting code from the library’s random number example gave us a continuous stream of numbers, and taking a thousand of them for the same spreadsheet treatment shows a much more even distribution. The library performs as it should, though it should be noted that it’s not a particularly fast way to generate a random number.
So should you ever need a truly random number in your Arduino sketch rather than one that appears random enough for some purposes, you now know that you can safely disregard the documentation for a random seed and use the entropy library instead. Of course this comes at the expense of adding an extra library to the overhead of your sketch, but if space is at a premium you still have the option of some form of hardware noise generator. Meanwhile perhaps it is time for the Arduino folks to re-appraise their documentation.
Some solutions come from no more than looking at two dissimilar things while in the right mindset, and realizing they can be mashed together. In this case I had recently segmented a large, hollow, 3D model into smaller 3D-printer-sized pieces and printed them all out, but found myself with a problem. I now had a large number of curved, thin-walled pieces that needed to be connected flush with one another. These were essentially butt joints on all sides — the weakest kind of joint — offering very little surface for gluing. On top of it all, the curved surfaces meant clamping was impractical, and any movement of the pieces while gluing would result in other pieces not lining up.
