The Arduino Ladder

An Arduino is a very small computer on a flat board. It has no screen and no keyboard. What it can do is control electricity: switch on a light, read a sensor, move a motor, and decide what to do about what it finds.

This course teaches you to use one. It assumes you know nothing at the start, and it does not skip steps. Every instruction says what you should see afterwards, and what to do if you do not see it.

You work at your own speed. There is no class to keep up with, nothing to fall behind on, and no way to be late.

Work through them in order. Each one needs the one before it, and each one ends with something real.

The first six bands teach you the parts and the ideas. The last three are about what happens when a project has to leave your desk: it has to push something, it has to speak for itself, and somebody who is not you has to be able to use it.

Most bands now offer a second build that reaches the same place by a different route. A keypad instead of four buttons. A rain plate instead of a light sensor. A fan on a transistor instead of the servo gate. Same band, same evidence, different hardware and a different afternoon.

They exist for three reasons.

• Kits differ. If your box has no servo but does have a stepper, Band 6 is still open to you.
• Groups are not all doing the same thing at once. Six people and two keypads is a problem. Six people, two keypads and four other routes through Band 3 is a timetable.
• Doing a band twice by two roads is the fastest way to find out what you actually understood. If you can only build the one you were shown, you learnt the build. If you can build the other one, you learnt the band.

Every band page that has alternatives lists them near the top, under Choose your build. Each project page says exactly what it swaps out, what it does not teach, and what you still owe the band before you can claim it.

You can finish all nine bands, understand every one, and have nothing to show for it but a box of parts and a notebook. That is the ordinary ending and it is a waste, because nobody deciding about a job or a place on a course can look inside your head.

So every band ends with one more thing, and it is deliberately small: one video under sixty seconds, and one post of five lines.

It is not extra work. The video is the same one the band already asks for as evidence. You are doing one piece of work once, somewhere a person can see it, instead of doing it privately and describing it later from memory.

Nine videos and nine posts, made while you were learning rather than remembered afterwards, is a portfolio. Very few people who finish an electronics course have one. Writing about a build is also where you find out whether you understood it, which is the part that catches everybody.

Every band follows the same six steps, in the same order. After two bands you will stop needing to be told what comes next.

The order is not random. You read working code before you write any. You commit to a guess before you find out the answer. You change somebody else's program before you write your own from nothing. Each of those is easier than the one after it, and each one prepares you for it.

1. Think first. A short activity away from the computer, with ordinary things like a rope, a door or a torch. It gives you the idea before you meet the word for it.
2. Guess. You read a finished program and write down what you think it will do. Do not skip this. A guess you got wrong is the fastest way to find out what you actually believed.
3. Run it. Build the circuit, upload the program, and compare what happens with your guess.
4. Look closer. Follow the code by hand, find a planted bug, put shuffled lines back in order, and explain why one particular line is there.
5. Change it. Three tasks, getting harder: Bronze, Silver, Gold. You are changing working code, not starting from a blank screen.
6. Make your own. A real thing to build, with a list of what it must do, and somebody to test it on. Every band also says how to do that step if you are working entirely alone.

The minutes shown on each part are for the activity itself, if nothing goes wrong. They do not include your build log, finding someone to test your build, or fixing it afterwards. The band totals allow for all of that.

Being stuck is part of this. Everybody is stuck often, including people who have been doing it for years. What matters is what you do next.

1. First 30 minutes. Go to the problems list at the bottom of the band page and work down it in order, without skipping. Most faults are on that list.
2. At 30 minutes, stop. Photograph your breadboard from directly above, in good light, with the whole board in the picture.
3. From Band 3 onwards, copy some serial output too. Ten lines will often tell somebody exactly what is wrong, faster than any photograph.
4. Say what last worked. "Buttons 1 to 3 tested fine, button 4 always reads 0" can be answered in a minute. "It does not work" cannot.
5. Do not rebuild it before you ask. A rebuilt board has thrown away the evidence.
6. If there is nobody to ask right now, write down what you tried, move on to the next part, and come back tomorrow. Fresh eyes solve a surprising number of these.

If you are a facilitator, parent or teacher rather than a learner, there is a separate page for you: how a band is passed, what to collect, the faults that account for most problems, and how to read a photograph of a breadboard.

Open the facilitator guide →