Monday, July 20, 2015

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.

Tuesday, June 9, 2015

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.

Monday, June 8, 2015

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.

Thursday, June 4, 2015

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."

Tuesday, May 26, 2015

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.

Thursday, May 7, 2015

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.