The Triumph of 3D Printing

Please read a better version of this post on Medium and like it there.

Maker Faire Rome 2015 (MFR)

I just got back from Maker Faire Rome 2015 (MFR), where my friend Mr. Anjan Contractor and I spoke about how the Maker movement can help Engineers Without Borders.

MFR impressed on me that 3D printing continues to grow explosively.

We snuck in on Thursday night as the booths were being set up. The revolution is taking place by many baby steps, in a stream of evolution that I think has ripened into a revolution. There must be 20 firms making 3D printers and services.  There is some redundancy in low-end printers (below $800), but in general each firm is adding a small new capability. The fact that so much of the 3D printing movement is open source, in software and hardware, enables this.  Designers share printable designs via sites like Thingiverse.

In the courtyard of MFR, there stood a space frame 30 meters high and 12 meters across.  It's purpose: 3D print in clay on a house-sized scale.

I immediately wanted to print a small version of the Colosseum for children who can't travel to understand that 1900 years ago with no electricity and no gasoline the Romans built a stadium that sat 60,000 people and is still standing. Since our kind host spoken limited English and we spoke no Italian at all, I couldn't tell if he had thought of this already. But in fact these tremendous innovators may not have, because the truth is there is only so much time and energy in the world, even for brilliant Makers.

http://www.thingiverse.com/thing:927907 -- by Andyroohoo

And that means, gentle reader, that we need your thoughts as well. We cannot all participate in every technological trend, but I assure you that you have not missed the 3D printing revolution. It is still in the hyperbolic growth part of its lifecycle. There are 30 years of fruitful development in this field awaiting our creativity.

A Relatively Expensive ($2000) WASP Delta Printer

When I first heard about 3D printing, I thought it was an interesting fad. Now that I have done it, I believe it will provide tremendous benefits to humanity.

3D printing frees the creator to make her gifts available more widely, just as photography democratized visual arts. As Edward Weston said, photography should make art affordable for everyone---and it has. In so doing, it made painting not less ubiquitous, but no less important.

3D printing will do the same for the sculptor. The sculptor and designer will be indistinguishable. Now, as John Ruskin and William Morris wanted, everything in your house can be beautiful and useful. We will be able to build lamps and tables which are not just stronger and cheaper, but far more beautiful, because they are freed from the cost of hand-manufacture.  They will be made not "by hand", but "by mind".

Stronger, Faster, Cheaper

The most impressive thing I saw at MFR was OpenROV, an inexpensive underwater exploration submarine. This gentleman gave a talk about it right before our talk. The robot is the white thing on the table.

You can't see it, but inside it has a complicated 3D printed structure. They could not have gotten the prototype working so easily and so well without a 3D printer, I assert. Perhaps when they are producing unit quantities in the thousands they will injection-mold the inner structure, but the point remains that their prototyping needed 3D printing.

Of course 3D printers were used early to make architectural models:

Humanizing Technology

What can be more intimate than a 3D printed brassiere?

Wait---don't answer that.

Unless it is perhaps 3D printed dental models or 3D printed jaw showing the major blood vessels:

Are you short? Or tall? Or fat, or thin? Do you want to see your alma mater's logo on everything? Now your chairs can be just right for you, because there is no reason they should not be tailored specifically to and for you. Today a wealthy man can have a bespoke suit. Tomorrow we can all have a bespoke furniture set, because it will cost nothing more to to customize it.

Eventually, there will be a machine that creates for you, cheaply and quickly, any beautiful object you may desire. Today, this can almost be done---in plastic. Tomorrow it will be done in bronze, or cut from marble, and whatever electronics you desire will be embedded within it at nominal cost.

Tomorrow when you read your child's favorite book to them at bedtime, you will be able to hand them a sculpture of each of their favorite scenes. The princess and her dragon will be there, glittering in glory, perhaps even ready to take wing---because, why not? Printing a flying toy dragon will be commonplace.

When an earthquake or a fire destroys your home, how long do you think it will take for us to rebuild it? Thirty days? Thirty hours? Thirty minutes?

H.P. Lovecraft wrote in At The Mountains of Madness of a space-faring race that used sculpture and bas-relief in place of writing. We may do this same. Trigonometry will now be explained with a manipulable object. You will see and feel the surface of the function.  You will understand the four chambers of the heart better when we hand you one.

Our smartphones produce maps---why not models?

http://www.thingiverse.com/thing:47622 -- work of ibudmen

3D Printing vs. Other Technologies

Tim O'Reilly once said that he thought computer controlled manufacturing is the real story, of which 3D printing is just a subset.  He is right, of course. At TechShop Austin, the 2D laser cutters are more heavily used than the 3D printers. Laser cutters can be similarly humanizing:

But of the CNC milling, laser cutting, and other related making technologies, none of them quite come as close to producing items of stand-alone value. None of them quite changed my way of thinking as much as my experience with 3D printing:

Getting Involved

If you have any interest in this sort of thing do yourself a favor and find a way to borrow or rent the use of a 3D printer and print out a few objects.

This is a great time to become interested in 3D printing. Maker spaces commonly allow professional 3D printers to be shared as part of membership and offer support and community. I have enjoyed TechShop Austin because of the excellent advice and support given by their staff.  Alternatively, you can just buy one for your home if you are willing to do some assembly and learning on your own. Here is a small basic model:

 A basic 3D printer at work

Every child should be given a chance to hold in their hands something that they designed and made themselves. 3D printing does not replace, but rather augments sculpting, drawing or painting.

Teaching Arduino to a 14-Year Old

Teaching enthusiastic students is my greatest joy. I just spent four days teaching a very bright young man, my nephew Ethan Read, Arduino programming.

Ethan had a basic understanding of electricity, and had done some very simple programming with the Lego Mindstorms system.  The Lego system teaches the basics. It is less fun because  it is less real than the Arduino and true electronics.

We began by making LEDs blink.  It's simple. Ridiculous, almost. But it charms us because we can do something basic to being a human being: we can build a working machine. Ethan immediately began changing the speed of the blinking lights, which of course if the first principle of programming: debugging by being able to change the program.

The Arduino Experimenter's Kit (ARDX) is a great teaching tool for this, or anyone.  It includes LEDs, a small servo, a small motor, and lots of nice sensors.

Ethan and I worked on two projects.  I had brought my Gluss Pusher invention, and in fact made excellent progress on it, perhaps because, as Richard Feynman elegantly argued, teaching and research always go hand in hand, and the best way to quit thinking is to quit teaching.

However, Ethan and his father wanted to do something practical around their ranchette. I had brought Hall sensors to work on the Gluss Pusher. Ethan and I quickly redeployed these, along with some powerful rare earth magnets, to make something that could sense when the bathroom door was open and turn on a blue LED.

As I have mentioned before, if you plan to do anything real with an Arduino you are going to have to deal with packaging and power management.  In our case, packaging meant mounting the sensor on the end of the wire so that we could put it at the corner of the bathroom door and mount the Arduino on the towel hook.  And this required soldering.

Like many things in life, it helps to have someone show you how it is done, but Ethan needed only one demonstration before he was ready to complete the rest of our soldering, which included soldering a pull-up transistor directly to one leg of the Hall sensor.

It worked.  Uncle Rob could now pee in the middle of the night with less chance of a mishap.

However, we decided that more valuable for the the homestead would be an audio alarm on the freezer door.  A freezer door had been left open previously, at some considerable cost.

We took a trip to Radio Shack, which does an excellent job stocking Arduinos and Arduino-comaptible electronics.  I found there a Relay Shield, and we bought a siren---a very, very loud siren that runs on 12 Volt power that we could switch with a relay that come with the ARDX.  By combining two programs and circuits from the ARDX, we were able to control power to the siren.

The freezer had a steel door, so by taping the sensor in place and sticking magnets onto the door, we had it working. Once the door opens, a horrifyingly loud siren will sound 30 seconds later.

We had to explain to Ethan that although we are proud of this project, it is not a patent-worthy invention, and we are not the first persons to build such an alarm.

Nonetheless, this was a very satisfying project.  We built something that is actually useful and deployed it in a (probably) reliable way. Doing this simple project opens a door to building almost anything we can imagine. I wish every child that has the engineering inclination could have this experience.

A super short introduction to using GitHub for hosting a non-profit website.

GitHub is a for-profit firm that effectively has created a social network of open-source hackers.  It is now a "place" to go for hackers.  Fundamentally it is a repository for tracking, versioning, and retrieving files---but EFFECTIVELY it is a social work place for files.

By files, we mainly mean computer programs, which really require versioning.  But you can put anything there.  

GitHub makes it completely free as long as you are public/open source in your files.  You have to pay to have private files.  GitHub graciously gives 501c3 charities $25/month of services for free.  You can do this if we need a private repo.  For example, I am on a board where we keep private files, and also have a public face.

Additionally, GitHub implements "GitHub pages", which is a lot like WordPress or BlogSpot.  The main difference is that content is mostly not created with a "What you see is what you get (WYSIWYG)" editor. In general, you create content using a very, very simple version of HTML called "markdown".  

Here is a site that is implemented with GitHub pages: http://presidentialinnovation.org. The "repo" for it is here: https://github.com/presidential-innovation-foundation/presidential-innovation-foundation.github.io, where you can partially see how the site is constructed if you study.  Anyone can make a "pull request" which will be taken as a suggestion by the owning organization.

I think it looks rather nice.  To make it look nice, you have to do some extra work, but it is just "plain old HTML and CSS".  This is more or less easy.  By using GitHub pages, you are sort of using the "plainest" and simplest hosting technology that we can.

When you start with github pages, you get a URL like http://github.io/yournewsite.  However, you can point any domain you own at it.  That is how "presidentialinnovation.org" gets pointed there.

One of the great things about GitHub is that you can create an "Organization" which can then own "teams" and "repos", which are ways to organize projects and subproject.  This means that you can control who is empowered to post things on the site.

Someone will NOT be able to post things on the site unless they either:

*) Get a free github account and you add them to the "team", or,

*) They submit a "pull request", and someone on the team "merges" it.

This is how open source is organized.  ANYONE could make a pull request (that is, "request us to pull their change into they site"), but only YOU can merge it.  It is not uncommon for people to make pull requests to fix typos, or to augment information, for example.

I believe for many charities, clubs, and organizations, hosting a web site with GitHub Pages should be a defacto starting point.

A Cold Calculus Conversation with a Neonatologist

Today, following the surface-level success of the ATX Hackathon, I spoke for an hour with a person who had a lot of experience in Africa and Bangladesh with premature babies.

She informed me of a number of difficulties with the Premature Baby Warmer project, although she confirmed some thoughts that preserve a slight hope for the usefulness of the project:

• Warmers are certainly needed.
• A system that could use cell-phone batteries successfully is potentially valuable.
• In most of the developing world, the Ministry of Health provides most of the supplies to clinics. This is a top-down model, and the idea of publishing an open-source solution is at odds with this, being a bottom-up approach.
• It might be true that 10% of the babies that need it could be helped by people who have the kind of internet access that would allow them to use internet instructions to build a warmer.
• Kangaroo Care is effective in approximately the same conditions that we are trying to address, so it may be that only a fraction of births, when the mother if disabled, benefit from this idea anyway.

In other words: if we manage to build an easy to construct $25 warmer than is 100% safe and effective, the number of babies we can hope to save with this approach is just a fraction of those that might need it.

Of course, perhaps more than 100,000 low birth-weight babies die every year.  Perhaps 10% of those will be close to someone with a good internet connection and the skills to build the Arduino-based warmer. Perhaps 10% of those will have a mother that, at least temporarily, needs a warmer.

One in a 100 of 100,000 is still 1,000.  I'm willing to put more time into a project that might save 1,000 babies a year.

Furthermore, it is possible that the know-how from the creation of this will help someone smarter build something better---or build something completely unrelated which is valuable.

So, without believing that I am very close to producing much good in this world, I think this project is worth some more of our time.

Contact me if you want to volunteer---there is no lack of work to be done, with almost any skill.

Report: ATX Hack for Change 2015 Preemie Baby Warmer

This weekend I led a team at the ATX Hack for Change Hackathon improving the Preemie Baby Warmer project of the Austin chapter of Engineers Without Borders.

Each year more than 100,000 babies born prematurely without access to Western medicine die needlessly. There are at least two attempts to address this problem.  The Embrace warmer is an elegant solution available in theory for $25.  However, it is made by a for-profit company, and its design is not open-source, and depends on difficult-to-manufacture phase change material.  I would prefer to empower local people to construct their own using inexpensive and readily available material.

Rice University's Oshman Engineering Design Kitchen has created a different solution: a $250 box-style isolette.  However, this is clearly an "in clinic" solution.

Engineering seeks practical solutions.  There is usually a design spectrum, and it is better to have a richly populated design spectrum.  We are producing a different point in the design space than either of these solutions.

I had previously constructed a prototype that I exhibited at the Austin Mini Maker Faire.  My friend Chip Rosenthal came by our table and invited me to the ATX Hack for Change Hackathon, specifically because I was working on a hardware project, something that would diversify the ATX hackathon. As one experienced hacker said, "I've never seen a sewing machine at a Hackathon before."

I was very lucky to get two brilliant young people on my team, and the help of an small team of IBM engineers as well. This is Josh Benson, who is a very clearly thinking and helped me with the electronics and programming, as well as just thinking about what to do.

 This is Cameron Lagrone, who was our MVP. She designed and constructed the "swaddle" completely from scratch in a single Saturday, and frankly it is more elegant and beautiful than anything I could have done.  She combined the sewing chops with the ability to think of innovative simplifications.

 Here is a picture of the "swaddle" that she produced, with our "Test Preemie" inside it.

It is not obvious from the photo, but inside the swaddle is a pocket holding the electric heating cloth controlled by the Arduino.  The tremendous beauty of this design is:

• It can be made from two t-shirts and a shoestring an an hour or two of sewing.  That means it can be made so easily you DON'T have to make it before a child is born prematurely---which is of course unpredictable.  If you have the open-source instructions and pattern, you can make it before the mother needs to sleep from the delivery! And everyone has some cotton cloth and some string.
• It needs no fasteners.  You just "swaddle" the baby almost as you would with a blanket. It imposes minimal cultural strangeness, as most of the world swaddles newborns with cloth in this way.
• It is a separate module from the electronics.  You can use it just as a "blanky" without the electronics.
• The "hoodie", when a fairly stiff material such as felt is used as the middle layer, protects the infants airway, while still insulating the head, probably better than a simple blanket could do.

The swaddle allows us to perform experiments we could not meaningful perform before.

The first observation that we could make is that, as I had previously conjectured, the Test Preemie that I created is a poor test object at present because it does not conduct heat significantly.

We fixed this with a quick trip to the pharmacy to get an gel-based hot/cold compress that weighs about two pounds (about the size of an underweight baby.)

A basic premise of this approach is that a large percentage of people have enough electrical power to charge cell phones, but don't have grid power.  However, the Warmer will only be practical if it can maintain body temperature for the infant with available battery power. This will require more research than we could do in the hackathon, but we could now move forward.

Oliver D. Rodriguez and the IBM team came to our aid here. They did something I have never done---they wrote an outside reader (in Python) which read from the output from the serial port written by the Arduino.  This allowed us to make a running data log of the temperature. (That's Oliver on the left most, with Kay Freund seated, who also helped.)

Using two 6 Volt lantern batteries, we were able to raise the gel pack from room temperature (25C) to skin temperature (35C) in 37 minutes inside the swaddle.  This was a successful test, although the actual use case is much easier---an infant should never have a room temperature body!  So I deemed this an encouraging result.

If you have ever been to a hackathon, you know how exhausting they can be.  I went home at 10:00 hoping to perform a far better "maintain the body heat" test---and collapsed.

In the morning, we finished our presentation, and mostly socialized, until the presentation.

We made what I consider a lot of progress:

• We have a replicable set of instructions for making a practical, cheap swaddle.
• We tested our ability to heat with encouraging (though incomplete) results.
• We also added a sonic alarm for when the baby is too cold or too hot---which is a big improvement in safety and robustness.

I am pleased that the Austin hackathon is not competitive as some are.  Nonetheless, the judges gave out a few superlatives.  We won "Most Hacked Forward".

People seemed to generally really admire our project.  It felt great.

I now feel two things very strongly:

1. It is my duty to document this as well as possible.  If others cannot use it, all of the energy and love is meaningless.  It is fine with me if people use it as an example to improve upon, rather than a tool for saving lives.
2. In fact this approach is very far from changing the world, an a lot of work remains to be done.  I would estimate about 10 times the total work that has been done so far.

The Agile Maker's Dilemma: How Shabby is the Right Amount?

I am currently trying to invent a new kind of linear actuator to enable producing the "Gluss" robots: omni-triangulated robots built only out of members that change their length.

I am dedicated to applying Agile software methodology to my hardware making.

I just spent a precious three hours trying to build a spool of the proper size to hold a homemade magnetic coil. Was this the right thing to do? (I'm writing this essay as the epoxy dries.)

The fact is physical making brings to the fore decisions that are not as difficult in software development.  Agile methods have been described as "The Scientific Method applied to software development".  That is, the fundamental thing Agile methods try to do is to learn things as quickly as possible.  Generally, this is "learn what makes the customer happy."

Kent Beck created Test-Driven Development as a way to be Agile without actually being shabby.  That is, in TDD, you are always in the control, and you always have a set of a running tests that define the correctness and quality of your system.

In a way, TDD allows you to always be "correct", but to always be developing on the dimension of completeness.  You start with a correct but very, very incomplete system.  You always stay in control by staying in control of your tests, so you're software is almost never "wrong", but it is constantly getting more "complete".  In other words, quality is always improving, and all errors are in the form of things not yet done, not mistakes.

This is a very successful strategy, in part because software, whatever other problems it may have, is extremely repeatable.  The same program always does the same thing with the same input.  Software doesn't really wear out or rot, or stick, or rust, or get gummed up, or overheat.

But physically devices, especially my home-frabricated ones, do.  In TDD software, you have a smooth, monotone improvement, with small refactoring, but there are more variables and more compromises in physical making.

If I wind my coil too broadly as I did recently, I have no recourse but to rewind it.  If my piston doesn't fit properly in my cylinder, I may be able to adjust it, but I may have to make a new piston or a new cylinder.  Either a bad fit or a bad coil is likely to prevent my fundamental test from being successful: the actuator may not move.

I do not mean that you should not try to make physical things via a series of small tests. But I believe it is harder to do this when physically making than making software.

The worlds really needs a book entitled "Test Driven Development for Physical Makers: How to Choose When to Invest Where for Maximum Learning."

Some Simple Lessons for the Arduino Hacker Who Started As a Programmer

To the software hacker with no experience in electronics, working with an Arduino poses some problems. The programming will seem like a breeze. The breadboarding is straightforward. But practical, deployable electronics pose some problems that software programming does not prepare one for.

• Packaging is difficult and requires creative engineering. Essentially every connection becomes a potential point of failure. Wires break. Solder joints look good but don't actually make good connections. Wires proliferate and strangle the beauty of the project.
• Power management is tricky. Batteries require yet another set of connections and are physically heavy. They must generally be packaged, either together or separately, with your project. Their lifetime in any given application is harder to predict than a software programmer typically imagines.
• PCBs >> Soldering >> Breadboards.  Breadboards are great for prototyping, but terrible even for demoing for more than about an hour---they are very delicate, and once a wire is pulled out it takes a long time to figure out how to replace it. Soldering is a major step up in ruggedness, but error-prone for the beginner. I have not yet sent out a schematic to have my own PCB board made, but I now understand why people do, and why there are so many "breakout boards" at Sparkfun. PCBs are another step up in ruggedness and ease of use (and another step down in terms of mutability.) As your design stabilizes, there is a natural progression toward ruggedness and away from changeability.
• In my limited experience, success depends just as much on methodical testing in hardware as it does in software, if not more. Breadboards seem to make testing easier because they give you places to put your multimeter probes. 
• You will end up using your basic software debugging skills, such as proper logging sent through the serial interface back to the computer, just as much in Arduino programming as in pure software, if not more.
• Be gentle and forgiving with yourself. A lot of things can go wrong in the construction of even simple circuits. To be successful, you will have to tolerate this frustration and treat yourself as you would a child that you are mentoring.

Success with the Relay and Basic layout

After the MOSFET disaster I used the other component available to me from the Arduino Experiment Kit (ARDX), the relay.

A relay is a physical switch that actually moves and is controlled by a small current.  They are less reliable than solid state switches. But I had one.

I basically followed the example of using a relay that came with my ARDX. (This is Circuit 11 in that book.) It is important to note that it requires a transistor to switch power to the relay.  The Arduino digital outputs provide so little current they can't reliably switch the relay.

The coil inside the relay is also an inductive load, requiring a fly-back diode to protect the circuit.

I dutifully:

• Spent an hour breadboarding this circuit,
• Spent about an hour laying out the soldered circuit board (this is a separate skill which I am very bad at),
• Spent about an hour stripping jumper wires and placing the components on the board in preparation for soldering,
• Spent about two hours soldering, and correcting my soldering.

Here is the circuit board with the transistor (there is a resistor on its input), the relay, and the diode. Soldered to it are the battery leads for power, and four wires going back to the Arduino: +5V and GND for powering the transistor and the temperature sensor. Their is one signal wire fro controlling the relay (basically "turn on the heater") and one wire leading back from the temperature sensor.

I had misunderstand the pinouts for the Relay --- I have to say that in my experience data sheets are not written well for beginners. 

Finally, after about 6 hours of labor, the system works, by which I mean the heating cloth gets hot on demand.

Below are the components of the system laid out.

Note the Arduino and Breadboard system on the left --- I originally used the breadboard, which is now empty. Although not powered on in the photo, the doll has an LED which shows if it is too cool, too hot, or just right. Note the doll and its Arduino, its temperature sensor and LED, are completely separated from the Incubator itself. I call the test system the "Test Preemie".

The Incubator (which is an ambitious title for a warmer with a thermostat) consists of the components on the left. I drive it with a lantern battery in part to show that the heating circuit is completely separate form the Arduino system as well.  In fact you can hook up the batteries in series which gives 12V, and four times the wattage, as a demonstration.  At 12V the heating cloth heats up VERY quickly, but of course the Preemie has much more thermal mass than the cloth. It is possible that people who might need this would have 6-12 V available from batteries or cell phone chargers or something.

I am now ready for real testing, I hope.  I just have to take the sensor off the old circuit and solder it in here, and then I can make a physical incubator, adjust the temperatures in the "Test" sketch and the "Incubator" sketch and see if I can keep the Test Preemie happy.

Let me remind everyone that this project is in its early phases, and that I am doing it mostly to support Engineers Without Borders. I don't think we have done enough research into neonatology to understand the fitness of this system for actually trying to keep a child alive. However, I believe it is reasonable for prototyping and research to advance hand-in-hand.

There are a number of things that are potentially weird about this approach. Not least of them is that you could do the control of the heater at body temperature with a simple circuit, eliminating the Arduino and its expense and complexity. However, if you did that you would not have a platform available for other enhancements, and it is easier to control and report on this with the Arduino first.

Lessons from An Electronics Noob

One of my great heroes, Jeri Ellsworth, has spoken publicly (and made a great video) about the importance of trying and failing in learning electronics.

I personally am tempted to generalize her statement to everything else. In fact I would say that is the great genius of Agile methodologies and Test-Driven Development in particular.

On Saturday, I got my "test preemie" working---a success.  Monday I started on the incubator, thinking it would take about 3 hours.

And failed, and failed, and failed some more.

I had it all working on the breadboard---easy as pie.  But breadboards are fragile. I don't want to go to Mini Maker Faire with a breadboard.  I wanted to solder up a prototyping board to make a sturdier solution.

Using tips suggested by this gentleman for prototyping, I laid out my protoboard, and bent the components into place.

I soldered it up, and it didn't work. I had missed a connection.  I fixed it, and tried again, and it didn't work. I realized I had soldered the MOSFET in backwards.  This is easy to do---the little ICs are little on 3/10ths of an inch wide and they aren't "marked" in anyway---you have to look at the data sheet to which pin goes where.

So I painstakingly desoldered it. Desoldering is harder than soldering; you have to use a "solder sucker" and then "soldering braid" to wick up the molten solder.

And, if you bent the pins of the components over as hinted above, it is even harder to get them out.

Then I carefully resoldered the MOSFET back in --- the WRONG WAY AGAIN. Imagine a face palm that evacuates the brain pan.

So I carefully desoldered the MOSFET again.  With each operation, my board was getting messier and messier.

Then I put a clean MOSFET in---and it worked!  For about 4 minutes. Then I broke one of the pins leading to the Arduino off.  No worries---I could just solder a new lead in place. To make it sturdier this time, I stripped a solid 24 gage wire and soldered it in.

Then, nothing.

It seemed to draw current but wouldn't heat the little 8 Ohm resistance cloth to keep the baby warm.  So, to try to isolate it, I took it over to my power supply, away from the Arduino, and tested the MOSFET and heater load in isolation---or so I thought.  It soaked up every amp my power supply would give and converted into heat---INSIDE THE MOSFET, which began to smoke, right before it melted the plastic off my leads.

Trying again and again, it behaves as if there is a short INSIDE the MOSFET.  I don't know if this possible, or if somehow I have a stray gob of solder which neither my eye, nor the multimeter can see.

I spent at least 10 hours debugging this, and am completely stuck.  So, I am retreating but not surrendering---I ordered some new MOSFETs and will build a completely new board when I get them.

Until then, I will try to do the same thing a "relay", a physical switch which does what a MOSFET does more reliably.

I have learned:

• This stuff is hard and takes practice to develop basic skills.
• It is easy to make mistakes which make things very confusing.
• You could probably learn a lot from watching someone experienced do this. YouTube videos are the best I have in that department.
• Breadboards are fragile.
• Soldering sucks.
• This is an excellent way for a grown man to feel stupid.

An Artificial Test Preemie for an Incubator

I've been working with the Greater Austin Chapter of Engineers without Borders.

One of our projects is the creation of a low-cost incubator for premature babies.  Preemies can't keep themselves warm. This is similar to the excellent work of Embraceglobal.org, but we are aiming for an even cheaper cost-point.  We are beginners; we do not believe we are going to outperform or compete with Embrace or make a life-saving tool in the short term.

I have been strongly influenced by the my acquaintance Kent Beck and his methodology of "Test Driven Development" (TDD). I don't claim to always use TDD in my career managing programmers, but I use it in most of the programming that I completely control.

If you want to build an incubator, you need a test baby.

As part of trying to learn to use the Arduino (and some basic electronics), I built a Test Preemie.  The basic idea is to have a physical doll smaller than a full-term infant that lets you have a visual indication of when it is a proper temperature.  Additionally, it lets you read the precise temperature from the USB port of the Arduino (and its history.)  You can't put the Arduino in the incubator because it is its own source of heat. I needed a way to put a visual indicator and the temperature sensor on the end of a wire so that the Arduino controller for the Test Preemie can be kept separate.

Presumably, a completely different Arduino or other control mechanism will actually control the heat, or the alarm, for the incubator.

What we are trying to do with the Artificial Test Preemie is to make testing easier by giving you both an independent temperature measurement, and a physical object to test with.

Obviously, there are improvements to this---we'll discuss that at the end of the article---but for now I would like to tell you what I did, in order to document it.  I'm not particularly proud of this work, but in the PIFAH project I try to document everything.

(I documented all of this as I did at EWB GitHub Repository, but am rewriting it for this article.)

So the basic approach is to use a standard TMP36 temperature sensor.  This requires 3 wires: +5V, Ground, and the signal (temperature) wire.  As an initial design, I just want to let you say if the preemie is too cold, just right, or too hot.

Luckily, both the TMP36 and a multi-color RGB that can glow blue (too cold), green (just right), and red (too hot) is included with the Arduino Experiment Kit (ARDX), including a nice explanation and bread-board diagrams for how to use use them.

The code, which is called a "sketch" in Arduino programming, for using these basic circuits is also included.

So basically I just implemented these circuits separately (and simultaneously) on my Arduino, and mashed together the C-code for each circuit.

It is traditional, and almost always best, to build a circuit first on a breadboard as shown above, which is included with the ARDX. However, breadboard are fragile.  I wanted something sturdier for the testing of the actual incubator (which I haven't started yet).  Also, I wanted something to show at the upcoming Austin Mini Maker Faire, and something sturdier was required.

I had some old 8-wire telephone interface network wire.  I used this to run the wires the foot and half from the Arduino to the Preemie.

Arduino experts build "shields", which are pluggable components for expanding the Arduino. However, I didn't have one, and I wanted a stand alone system.

Remember, I am not very experienced with electronics, not even the basic of how to make connections.  So I'm describing below a home-grown solution---I don't claim this is good or recommend it.

What I actually did:

1. I got my daughter to volunteer an old doll for this purpose that is at least smaller than a normal full-term child. 
2. I tested the RGB LED circuit from the ARDX, and made sure that I could control the color.
3. I tested the Temperature sensor, and made sure I could measure temperature correctly.
4. I put both of these on a breadboard, and wrote a sketch that controlled the RGB LED circuit from the temperature, seeing a minimum and maximum temperature to control the color.
5. I cut 18" of telephone wire, and carefully cut away the vinyl wrapping, then carefully stripped the insulation of the end of each of the colored wires (I only needed 7 of the 8.)
6. I carefully wrote out a plan of what color I would use for the pins on the Arduino and the pins on the TMP36 and the LED.
7. I soldered the correctly colored wire to my RGB LED. I wired the resistor in-line.  This is critical---if you miss the resistor it calls for, even for 1 second, you will burn out your LED.
   
   
   
   
   
8. I tested again by plugging back into my breadboard (which still had the temperature sensor).
9. I scored a Radio Shack perf board and broke off a single line of pad to be able to solder.
10. I broke off a line of 3 male-to-male connectors that came with Arduino spare parts kit.
    
11. A soldered the correct wires that connected to the RGB LED to the short sides of the male-to-male connectors, making a tiny "plug" that I could insert into holes 9,10, and 11 of the Arduino digital output (as the original circuit called for.)
12. I tested this again.
13. Then I soldered in the TMP36, and tested that that worked at the end of my wire.
    
14. Then I soldered that to a different 3-pin plug that I made (different because it is physically on the other side of the Arduino Uno.)
15. Then I tested that again.
16. I soldered the TMP36 signal wire to a single male-to-male connector (because it is in a different location and could not be grouped with the others.
17. Then I tested that again.
    
18. I carefully wrapped all the exposed wires in electrical tape.
19. I inserted the LED at my doll's neck, and put the temperature sensor at her belly.
20. I tested again, and used some extra electrical tape to try to combat the fragility of my solder joints.

Note that in doing all of this my soldering and wire-stripping failed several times.  Once the power wire broke.  I tested each solder connection with my multimeter before I accepted it.

Doing hardware work requires just as much testing as software! If I had been working with someone else, I would have treated this as a series of written stories with estimates and tests.

Then net result is a physical Test Preemie which is more sturdy than a breadboard (but still dangerously fragile.) The photo at the top of this article shows that.

I now feel ready to work on using a completely different Arduino, a MOSFET, and a lantern battery, and a heating strip to try to actually keep the Preemie warm enough to survive.  By building a test apparatus first, I can follow the "Red/Green" testing paradigm. I am beginning with a failing test---they baby is cold---and will try to create a Green test and keep the test Preemie alive.

The Sketch for the Arduino can be found here.

I invite you to collaborate with me and Engineers Without Borders in this open-source project of building a new kind of infant warmer!  Maybe, maybe, after a lot of testing, we will save a life.

* * *

I hope that the reader will think of improvements and open them as Issues at the GitHub Repo: https://github.com/PIFAH/EWB/issues.

However, it is clear that this could be made sturdier, could use a smaller wire, could be a complete datalogger, could have an LCD temperature readout, could be made out of a doll the mass, heat capacity and thermal conductivity of a baby, and could be turned into a training tool.  I'm not going to enter those thing as issues, because my goal here is to get involvement from others.  There is no need for the test apparatus to get TOO far ahead of the actual incubator.

How I Spent April and Engineers Without Borders

When I resigned from the government, I had planned to spend the entire month of April watching movies.

Instead, I built and electronics lab, published 25 of my ideas, and have been trying to learn basic electronics.

Possibly this is a sign of mental instability.

I have been working a great deal for the Instrumentation Group of the  Austin Chapter of Engineers Without Borders (EWB).  I'm doing this in part to stay involved with other people and avoid navel-gazing.

EWB does engineering. They are not really doing "invention" in the sense that I want to do it.  They are producing potentially novel solutions but they are "designs" not "inventions".  For the most part, what we are trying to accomplish is relatively straightforward electrical engineering based on using an Arduino.

This is aligned with what I want to do, however, because:

• It is helping me to learn basic electronics.
• Many of published ideas require computer control in one way or another, and mastering micro-controllers will help.  In particular, my various ideas around biochar production will benefit from this.
• I have always believed the greatest room for invention is that intersection of software and they physical world, despite the fact that I personally am more expert at pure software.

EWB Austin is heavily influenced by the University of Texas members. It is going to shut down for the summer.  We have been invited to the Austin Mini Maker Faire, and am working to have several of our Arduino project ready by May 16th.

When I have done this, however, I am going to go back to more of the invention-oriented work I have written about.

As always, I welcome collaboration---y'all don't be shy.  I'm happy to shift priorities based on what excites others.

My Best 22 Ideas, and a Personal Invitation

The public inventor works in the light.

Transparency facilitates cooperation. I've published my best 22 ideas at GitHub, a platform for shared collaboration. Comments are welcome. The quality of my presentation will improve, but never delay publication to improve quality---release early and often.

 I apologize for those of you who may be unfamiliar with GitHub. You should be able to at least read the ideas above, and you are free to email me, but I would rather you comment publicly at GitHub by opening an issue there so that all can see your comment.

I believe the goals of PIFAH deserve a full explanation, which I have not prepared. However, you can find my personal invitation and a vision statement at the GitHub repo. Here is the README at the GitHub repo:

 Public Invention for All Humanity 

 A Personal Invitation 

The creation of new technology is not the only or best way to help our fellow-beings. Love is more important than lasers, and kindness more important than computers. Still, many of us are better suited to serve humanity in code than in a sermon, or holding a test tube rather than the hand of the dying. If you are one of those persons, I invite you to participate with me in a project I call Public Invention For All Humanity (PIFAH). Throughout 2015, we hope to run a number of projects best described as “inventions” that will be valuable to humanity. This is not particularly original. This is yet another project in the exponentially growing tradition of working for the public good.

What we do hope to use some modern principles:

• We will be completely transparent and open from the first. 
• Everything we produce will be shared to everyone without exception. 
• We will organize our using an Agile methodology, whether our work is software, hardware, research, or education. 

In other words, this will be an free-libre open-source project that welcomes participation from the public and seeks to organize work so that the work so that as many hands can pitch in as possible, and so that as many voices can contribute as possible.

 I am not committed to this project. If I find an existing project that can utilize my talents better, I may drop PIFAH to assist others. I don’t want this to be about me.

But of course that is inevitable, at least at the beginning. There is no point in false humility. I really want to act as the head coach of PIFAH, and I think I can do it well. I have an adequate technological resume, particularly as a computer programmer. More importantly, however, I enjoy leading teams and am good at it. I mentor people well. Finally, I am able and willing to devote myself full-time to this project, at least for a while.

You may wish to examine our project concepts to see if any appeal to you.

-- Robert L. Read, PhD

How to Contribute 

We welcome your participation. You are welcome to email me at <read.robert@gmail.com>. However, as a public project, it is even better for you to comment publicly. You can do this by opening an "issue" here at GitHub. If you want to add to or improve one of the existing documents, you can do this with a "pull request". 

 In general, each project will have a set of "stories". This is a technique developed by the Agile community. We welcome you to take on the execution of a story if that fits your talents. Writing new stories is also very important activity. 

I hope that we will have need for many talents. I am a computer scientist. I greatly admire artists but don't pretend that I can create art. We will always have a need for artists, writers, and educators. We will also need chemists, welders, mechanical engineers, 3D modellers, software engineers, physicists, biologists, mycologists---we exclude no field of endeavor. 

In summary, you can contribute by:

• Suggesting a new project, 
• Working on a story,
• Offering to improve our art or writing, 
• Offering to lead a project, 
• Teaching us something new, or 
• Even suggesting non-PIFAH proejcts that we should contribute to. 

If you are not familiar with GitHub or git, please email me to give you assistance.

Warning 

Some of the projects proposed here involve dangerous chemicals, powerful forces, fire, explosive gases, and biological hazards.

The important thing is to remain safe  at all times and not to proceed with an experiment until you have proper safety equipment and training. In particular, although we encourage young people to participate in PIFAH, they should not participate without adult supervision.

We will attempt to discuss safety precautions within each project. However, because this is a distributed project and each participant may be creating their own experiments and machines, it will not be possible for us to provide safety guidance in all cases. Please proceed carefully at your own risk.
 
PIFAH Personal Invitation by Robert L. Read is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Based on a work at https://github.com/PIFAH/PIFAH.

Waterfall Assisted-Acquisition Services, Training, and Education

by Dave Zvenyach and Robert L. Read, PhD

18F Consulting cares about our customers. We want to give you not what you need, but what you want. Developing software is difficult; we understand you want a methodology that provides you with plausible deniability. So, today, we are proud to pre-announce our latest offering: “Waterfall Assisted-Acquisition Services, Training, and Education” (WAASTE).

The federal government has spent literally years perfecting this WAASTE methodology. When it
is released, we promise it will support these features:

• No matter how simple the use case, every component will be highly engineered using the most baroque processes currently available. 
• WAASTE ensures a turnaround time comfortable for government: no faster than 2 years for the first set of deliverables. 
• With WAASTE, project managers have no work to do beyond the initial requirements, ensuring maximum vendor ability to slavishly follow your initial thoughts through to a final product.

18F Consulting is committed to delivering WAASTE to you before our money runs out. In the
mean time, any agency interested in WAASTE should spend two years carefully analyzing
exactly how your software will be Blackberry-enabled 5 years from now. Technology changes
quickly, but the ideas of government are eternal and unchanging. WAASTE guarantees lock-in
of the current understanding of technology through this protracted process.

Through our proprietary WAASTE Requirements™ gathering process we guarantee at least
1500 small, isolated, capricious, and incongruous WAASTE Requirements™ presented to you
electronically in a state-of-the-art XML file. For an additional fee we will conduct focus groups to
provide the exculpatory appearance of respect for user input, but of course their input will not
affect the WAASTE Requirements™. Completely free of charge, we will prioritize all WAASTE
Requirements™ based on our feelings at the time.

In recent years, pernicious new fads such as “Test-Driven Development” (TDD) have emerged,
threatening the very core of the WAASTE methodology. 18F Consulting is reacting by
developing our own alternative test restriction system, called Delay-Oriented Assessment
(DOA). Our methodology prevents duplicate effort by assiduously postponing testing until the
last possible moment. DOA permits testing only by entrusted QA experts, untainted by
knowledge of the project or its users.

To be completely WAASTE-ful, we limit communications to tightly defined narrow channels
through detailed memoranda, a process we call MemOnly (patent pending). In-person
interactions create the possibility that teams will deviate from the WAASTE Requirements™.
For maximum WAASTE, you control all communications. You get to specify your project in
excruciating detail. Eventually, your precise vision will be implemented. If the project is deemed
overbudget, past-deadline, and a total failure by end-users and higher-ups with unrealistic
expectations of working software, you can simply exhibit mountains of paperwork and walk
away.

We realize that others might promote “modern” software development practices such as set
forth in the “Agile Manifesto.” We at 18F Consulting are preparing our own comprehensive
response in a Waterfall PowerPoint Presentation, drawn from the outstanding track record of
success in Federal IT procurement. We expect it will be published any year now.

If you would like to make your next major project WAASTE-ful, please fax us a detailed
memorandum.

(Please note, the WAASTE methodology is proprietary to 18F Consulting, notwithstanding 17
U.S.C. § 105 or 18F’s Open Source Policy)

Happy 1st of April!

LibrePlanet 2015 Was Great, and Some Suggestions for 2016

LibrePlanet 2015 was good. I learned:

• That VMWare is flatly refusing to comply with the GPL and the Software Freedom Conservancy has felt compelled, after years of trying to work with them, to sue them. I am becoming a member of the SFC as of right now.
• That freedoms are continually eroded, and every expansion of freedom leads to new attempts to subvert it, often very subtly.
• The fact that most hardware systems are making it very difficult to run free software.
• I learned of software systems I had not known of before:
• eleg.io, a system for automatically finding the provenance of images: http://elog.io
• Tahoe-lafs, a distributed file system: https://www.tahoe-lafs.org/trac/tahoe-lafs
• Scala, apparently an emerging winner of functional languages: http://www.scala-lang.org
• A secure social network (doesn't look ready for prime time): http://pump.io
• TOR, secure browsing: https://www.torproject.org
• PublicLaboratory, Do-it-yourself science with an environmental focus: http://publiclab.org

Mostly, I was reminded the precious gift that Free Software has given the world.  Without the GPL, there would be no Linux. The would be no Wikipedia. No Android OS. Probably no Mac OS either. All of us benefit from the the work of the Free Software Foundation, whether we know it or not and whether we contribute back or not.

And I would like to see even more next year.  Here are some things that I would like to participate in next year.  I believe if these could be organized alongside the typical tracks it would make the conference far more life-altering.

• Hack parties.  Perhaps these were going on, and I just didn't get invited. But I believe organized, or at least, seeded, or suggested, work parties, would allow participates to have the pleasure of more strenuous stimulation and deeper social interaction.
• Activism exercises. We could, for example, have a one-hour session specifically to inform people about the Software Freedom Conservancy and their action to defend the GPL by bring VMWare into compliance.
• Crypto parties.  I don't know much about practical cryptography, and I care less about it than a lot of people.  But I want to learn. This would be a great place to invite outsiders and the media.
• A "Learn about Licensing" practical session.  This could also be opened to the public. I believe this could be combined with a campaign to get GitHub users to use, or switch to, or "fork into" free licenses instead of merely permissive licenses.

Learnings from sewing a Nightie

I sewed this nightie for my wife for Valentine's Day.  Of course, I bought her one from Macy's as a backup---some risks aren't worth taking.

I used primarily a video by GiannyL as a basis.  However, I made some modifications---I made the spaghetti straps myself out of the same material, and my wife wasn't interested in any lace trim.

How does it compare to store-bought night gown?

The neck curve puckered a little because I didn't notch it.

You could probably buy a comparable garment for $25-50.  I spent $20, and ten hours.  The looks are comparable.  My seams are imperfect, but if you don't look closely you wouldn't notice, and when my wife is wearing it I have better things to look at.  I suspect my garment is "sturdier" --- but who needs a sturdy nightgown?  The one advantage is that I did get to choose precisely the color I wanted.  My wife is a redhead and looks great in royal blue.  The "satin" is really polyester with a shiny side and a less shiny side. The less shiny side is a little coarse to be against skin, so I made this harder than GiannyL's construction by using a French seam on the sides.

A French seam runs up the side, but the bottom doesn't need it.

What I Learned

• I need to research fabric more. Satin looks nice, but isn't really a great fabric for sleepwear.
• Sewing curves perfectly requires cutting notches or some other technique that I have yet to master.
• Satin has zero give. You have to fit it perfectly. Luckily, I was able to do that.
• I tried to make this with a fitted waist as GiannyL shows.  But my wife's bust is a few inches bigger than her waist.  I made the first model to my wife's waist size, and she couldn't get the waist over her bust. I know this must be obvious to any woman, but now I understand why a standard tight-fitting woman's dress has a zipper in the back: otherwise you can't put it on!  That is really the difference between this garment and a cocktail dress.  To make a dress, I would take in the waist and add a zipper.  Instead, I cut it completely straight down the sides, so basically the waist is the same size as the bust.
• You can fix things with a seam ripper---but not using the kind of thread I was using with short stitch on satin.  It was impossible to unpick a seam in this situation.
• Taking body measurements work, but with this fabric, you have to be very precise.
• Sometimes the garment ends up looking good even when you do a poor job with the details.

Was it worth it?

Once again, in pure economic terms, this was a catastrophic failure: I made about $1 per hour, and have some scrap satin left over. However, if the lessons learn allow me to someday make a properly tailored dress that my wife might be willing to wear, it might be more economical.  In terms of learning and the finished garment, it was another step up the learning curve.

Altering sleeves of a used coat and adding buttons

I'm interested in all things involving home economics, including sewing.  I love doing things that make me feel stupid.  Sewing is hard.  However, with each project I get a little a more comfortable with it.

Of course, it is almost impossible to save any money making your own clothes, now that so many clothes are made by low-paid workers in Asia.  However, altering and mending is much more economical.  I can fix rips and torn seams, and reattach buttons and other fasteners.  I've done this for about ten garments in total from every member of my family in the last year.

Beyond repairing buttons, the next sewing level is to be able to alter clothes.  I like to buy consignment clothes, and have bought a number of blazers for $10 at Goodwill which look great---if they fit correctly.  I weigh about 235 pounds and am only 5'10", so my torso is quite thick compared to the length of my arms.  Also, I have a separated left shoulder, which makes my left arm about 3/4" longer than my right. I can sometimes find clothes which were altered by the previously owner so they fit well---but that of course limits my options to about 1/5th of the clothes that fit me in the chest and shoulders (which is they basic, unalterable sizing for men's coats and shirts.)

So I bought a blue plaid blazer at Goodwill, while I was buying some clothes for my son, as an experiment in alteration.  It fits me in the shoulders.  It is too tight in the tummy---possibly it is is a trim cut.  I didn't even think to button it in the store, but the point is to experiment in any case.  But the sleeves were 2" too long.  I studied a 45 minute video by a professional tailor on how to shorten the sleeves on a man's jacket---but I STILL don't understand how to do it so that you can machine stitch the lining back into the sleeves.  It has something to do with making a hole in the lining so you can turn it inside out---but apparently I am too stupid to understand it.  Finally I gave up and found an article that just said to whip-stitch the lining in place by hand, which worked well.

Like all but the most expensive men's jackets, the buttons on the sleeves are not functional.  They are just decoration left over from the day when men wore coats as a matter of course, and might have to actually "roll up their sleeves".  In the case of this jacket, the 2" taken off actually removed the entire "vent" on the sleeve.  If you shorten a jacket sleeve, you always have to move the buttons---but that is one of the easy things I know how to do.

In fact, I used this opportunity to replace the very plain plastic buttons with hand-made ceramic buttons that are much nicer---little blue dragonflies on a Navy background that went better with the blazer, which, being plaid, will always be a somewhat informal blazer.  I got the buttons from BeadFreaky for $18, which is a little weird for a $10 jacket. It took me about 90 minutes to replace the buttons, and about 5 hours to alter the sleeves---which could probably be cut down to 2 hours with more practice.

The result is, I think, pretty nice.  The blazer now fits if it is unbuttoned---you can see the stretch marks below showing that the waist is too tight, but I don't really need to button it. The sleeves, although sloppy if you look close, fit my arms, and the buttons make the jacket 3 times more interesting than it was.  I learned a lot, am wearing a tiny bit of human love in my buttons, am supporting Goodwill and get a few more years of use out of a quality garment.