Do You Have An Endangered Craft?

It is probably fair to say that as Hackaday readers, you will all be people with the ability to make things. Some of you can make incredible things, as your writers we are in constant awe of the projects that pass through our hands. But even if you feel that your skills in the maker department aren’t particularly elite, you’ll have a propensity for work in this direction or you wouldn’t be here.

Most of the craft we feature involves technologies that are still very modern indeed to the majority of the population. We for example know that the first 3D printers were built decades ago and that we take them for granted on our benches, but to the Man In The Street they are still right up there with flying cars and time-travelling police telephone boxes.

We use 3D printers and microcontrollers because they are the tools of our age, but how different might our crafts have been if we’d been born a few centuries ago? Apprenticed to a master craftsman as teenagers, we (well, at least you boys!) would have learned  a single craft to a high level of expertise, making by hand the day-to-day products of life in those times.

The Industrial Revolution brought mechanisation and mass production, and today very few of the products you use will be hand-made. There may still be a few craftsmen with the skills to produce them by hand, but in the face of the mass-produced alternative there is little business for them and they are in inevitable decline. In an effort to do something about this and save what skills remain, the Heritage Crafts Association in the UK has published a list of dying crafts, that you can view either alphabetically, or by category of risk.

It’s a list with a British flavour as you might expect from the organisation behind it, after all for example hand stitched cricket balls are not in high demand in the Americas. But it serves also as a catalogue of some fascinating crafts, as well as plenty that will undoubtedly be of interest to Hackaday readers. Making hand-made planes, saws, or spades, for example, or at least where this is being written, coracle making.

As your Hackaday scribe this is close to home, a blacksmith carrying on her father’s business can’t earn enough to live in Southern England while an electronic engineer and technical journalist can. Eventually there will be one less blacksmith plying the craft, and though his tools and some of his skills will live on here, the business will not. Take a look at the list of crafts, do any of you have them? Or do you know of any craftspeople who have any of the skills listed, that the HCA might not know about? Let us know in the comments.

Treadle lathe image: Patrick-Emil Zörner (Paddy) [CC BY-SA 2.0].

Superconference Interview: Akiba

Akiba sits at a very interesting intersection of technology and culture. He is well known for his experience with manufacturing in Shenzhen — but he has a few other unique dimension I’ll get to in a minute. His experience manufacturing in China goes far beyond the electronics you might expect and covers, well, everything that could possibly be made. His talk, Shenzhen in 30 Minutes, at last year’s Hackaday Superconference is a crash course in the area, the culture, and the business side of things.

After his talk Sophi Kravtiz caught up with Akiba for an interview and it is surprising to learn that he was a bit nervous for the talk. Obviously he pulled it off without a hitch and we hope this inspires you to give a talk at the 2017 Hackaday Superconference in Pasadena on Nov 11 and 12. The call for proposals closes this Monday so spend some time this weekend and submit your proposal.

Now about those other dimensions. In the interview, Akiba and Sophi discuss two other areas where he has an incredibly unique viewpoint. The first is his founding of a hacker collective in the rural areas outside of Tokyo. Hacker Farm has been growing like crazy of the last three or four years. It seems that people come to visit and realize renting in the area is so cheap they can’t leave. This led to a culture boom around the camp; a self-feeding engine that attracts more visitors (and often visiting chefs who literally feed the group handsomely) and grows the collective.

They’re working on new applications of technology for farming in the area. One aspect of this is water level sensors for the rice farmers in the area which he wrote about at length for Hackaday. Wildlife turns out to be a huge challenge here — apparently spiders will exploit any hole or crevice to build a web which usually renders the sensor worthless. The group is also beginning experiments with the “three sisters” of gardening: corn, beans, and squash and plan to use this as a test bed for all kinds of agricultural automation.

Although touched on only briefly at the end of the interview, Akiba also works with wearable technology at an extreme level. He builds lighting and other interactivity into suits for the Wrecking Crew Orchestra. It’s always a treat to hear his experience dealing with wear and tear, communications latency, and a user interface for the dancers themselves.

Hackaday Prize Entry: FabDoc Is Version Control For Project Images

FabDoc is an interesting concept that attempts to tackle a problem many of us didn’t realize we had. There are plenty of version control systems for software, but many projects also have a hardware element or assembly process. Those physical elements need to be documented, but that process does not easily fit the tools that make software development and collaboration easier. [Kevin Cheng] sums FabDoc up as “a system to capture time-lapse pictures as pre-commits.”

With FabDoc a camera automatically records the physical development process, allowing the developer to focus on work and review later. The images from the camera are treated as pre-commits. Upon review, the developer selects relevant key images (ignoring dead ends or false starts) and commits them. It’s a version control and commit system for the physical part of the development process. The goal is to remove the burden of stopping the work process in order to take pictures, automatically record the development process and attach it to a specific project, and allow easy management of which images to commit.

The current system uses a Raspberry Pi Zero with a camera mounted on safety glasses, and some support software. Some thought has certainly gone into making the system as easy to use and manage as possible; after setting up a repository, scanning a QR code takes care of telling the system what to do and where to put it. The goal is to make FabDoc fast and easy to use so that it can simply work unattended.

We saw a visual twist on version control some time ago with a visual diff for PCBs, which was a great idea to represent changes between PCB designs visually, diff-style. It’s always exciting to see someone take a shot at improving processes that are easy to take for granted.

Testing Distance Sensors

I’m working on a project involving the need to precisely move a tool based on the measured distance to an object. Okay, yeah, it’s a CNC mill. Anyway, I’d heard of time of fight sensors and decided to get one to test out, but also to be thorough I wanted to include other distance sensors as well: a Sharp digital distance sensor as well as a more sophisticated proximity/light sensor. I plugged them all into a breadboard and ran them through their paces, using a frame built from aluminum beams as a way of holding the target materials at a specific height.

Continue reading “Testing Distance Sensors”

Explore Venus With A Strandbeest Rover

There’s a little problem with sending drones to Venus: it’s too hostile for electronics; the temperature averages 867 °F and the pressure at sea level is 90 atmospheres. The world duration record is 2 hours and 7 minutes, courtesy of Russia’s Venera 13 probe. To tackle the problem, JPL has created a concept for AREE, a mechanical robot designed to survive in that environment.

AREE consists of a Strandbeest configuration of multiple legs with a monster fan propelling it, and one can imagine it creeping over the Venusian landscape. While its propulsion system might be handled by the Strandbeest mechanism, it will still have to navigate and transmit data. We’re not sure how a mechanical radio wave might work–maybe like those propeller arrow-cutters that [Dain of the Iron Hills] busts out in movie version of the Hobbit? Chemical rockets that somehow don’t spontaneously ignite? Or maybe it can just “transfer all energy to life support” and AC the heck out of the radio.

We’re space nerds here at Hackaday–check out our piece about NASA employees’ talks at the 2016 Hackaday Superconference and our extracurricular tour of JPL.

Continue reading “Explore Venus With A Strandbeest Rover”

Books You Should Read: IGNITION!

Isaac Asimov described the business of rocket fuel research as “playing footsie with liquids from Hell.” If that piques your interest even a little, even if you do nothing else today, read the first few pages of IGNITION! which is available online for free. I bet you won’t want to stop reading.

IGNITION! An Informal History of Liquid Rocket Propellants is about how modern liquid rocket fuel came to be. Written by John D. Clark and published in 1972, the title might at first glance make the book sound terribly dry — it’s not. Liquid rocket fuel made modern rocketry possible. But most of us have no involvement with it at all besides an awareness that it exists, and that makes it easy to take for granted.

Most of us lack any understanding of the fact that its development was the result of a whole lot of hard scientific work, and that work required brilliance (and bravery) and had many frustrating dead ends. It was also an amazingly dangerous business to be in. Isaac Asimov put it this way in the introduction:

“[A]nyone working with rocket fuels is outstandingly mad. I don’t mean garden-variety crazy or a merely raving lunatic. I mean a record-shattering exponent of far-out insanity.

There are, after all, some chemicals that explode shatteringly, some that flame ravenously, some that corrode hellishly, some that poison sneakily, and some that stink stenchily. As far as I know, though, only liquid rocket fuels have all these delightful properties combined into one delectable whole.”

At the time that the book was written and published, most of the work on liquid rocket fuels had been done in the 40’s, 50’s, and first half of the 60’s. There was plenty written about rocketry, but very little about the propellants themselves, and nothing at all written about why these specific substances and not something else were being used. John Clark — having run a laboratory doing propellant research for seventeen years — had a unique perspective of the whole business and took the time to write IGNITION! An Informal History of Liquid Rocket Propellants.

Liquid rocket propellant was in two parts: a fuel and an oxidizer. The combination is hypergolic; that is, the two spontaneously ignite and burn upon contact with each other. As an example of the kinds of details that mattered (i.e. all of them), the combustion process had to be rapid and complete. If the two liquids flow into the combustion chamber and ignite immediately, that’s good. If they form a small puddle and then ignite, that’s bad. There are myriad other considerations as well; the fuel must burn at a manageable temperature (so as not to destroy the motor), the energy density of the fuel must be high enough to be a practical fuel in the first place, and so on.

The actual process of discovering exactly what materials to use and how precisely to make them work in a rocket motor was the very essence of the phrase “the devil is in the details.” For every potential solution, there was a mountain of dead-end possibilities that tantalizingly, infuriatingly, almost worked.

The first reliable, workable propellant combination was Aniline and Red Fuming Nitric Acid (RFNA). “It had the one – but magnificent – virtue that it worked,” writes Clark. “Otherwise it was an abomination.” Aniline was difficult to procure, ferociously poisonous and rapidly absorbed through skin, and froze at an inconvenient -6.2 Celsius which limited it to warm weather only. RFNA was fantastically corrosive, and this alone went on to cause no end of problems. It couldn’t be left sitting in a rocket tank waiting to be used for too long, because after a while you wouldn’t have a tank left. It needed to be periodically vented while in storage. Pouring it gave off dense clouds of remarkably toxic gas. This propellant would go on to cause incredibly costly and dangerous problems, but it worked. Still, no one wanted to put up with any of it one moment longer than they absolutely had to. As a result, that combination was not much more than a first step in the whole process; there was plenty of work left to do.

By the mid-sixties, liquid rocket propellant was a solved problem and the propellant community had pretty much worked themselves out of a job. Happily, a result of that work was this book; it captures history and detail that otherwise would simply have disappeared.

Clark has a gift for writing, and the book is easy to read and full of amusing (and eye-widening) anecdotes. Clark doesn’t skimp on the scientific background, but always in an accessible way. It’s interesting, it’s relevant, it’s relatable, and there is plenty to learn about how hard scientific and engineering development actually gets done. Download the PDF onto your favorite device. You’ll find it well worth the handful of evenings it takes to read through it.

Enigma neural network

Decoding Enigma Using A Neural Network

[Sam Greydanus] created a neural network that can encode and decode messages just as Enigma did. For those who don’t know, the Enigma machine was most famously used by the Germans during World War II to encrypt and decrypt messages. Give the neural network some encrypted text, called the ciphertext, along with the three-letter key that was used to encrypt the text, and the network predicts what the original text, or plaintext, was with around 96-97% accuracy.

The type of neural network he used was a Long Short Term Memory (LSTM ) network, a type of Recurrent Neural Network (RNN) that we talked about in our article covering many of the different types of neural networks developed over the years. RNNs are Turing-complete, meaning they can approximate any function. [Sam] noticed the irony in this, namely that Alan Turing both came up with the concept of Turing-completeness as well as played a big part in breaking the Enigma used in World War II.

How did [Sam] do it?

Continue reading “Decoding Enigma Using A Neural Network”