ACCU :: The Code Is Not the Most Important Thing

Choose the right sort of problem, focus on strategies for solving it, and the code will come easily. Seb Rose teaches kids to code.

I want to tell you a story. Two stories, actually.

A few years ago I found myself in one of those huge, soulless, air-conditioned conference halls, listening to one of those keynote speeches on a subject that had no discernible relevance to my work. But despite my preconceptions, I found myself surprisingly moved by the presentation. The speaker was inventor Dean Kamen, and he was talking about something called First Lego League.

I was inspired. Returning to the UK, I chased down our local FLL and registered. I coerced my children, aged ten and twelve, into participating. I put notices around the local junior schools, gathering another eight local offspring. I booked a room in a local hall one night a week for the rest of the year, bought the lumber needed to build the competition table, and waited for the kit to arrive.

The kit, right. I see Iâ€™m getting ahead of myself. Iâ€™d better back up and explain a bit about the FLL.

The First Lego League

The First Lego League [FLL] is an annual, international competition for teams of 9- to 16-year-olds that involves programming Lego MindStorms to solve challenges, doing a piece of original research, and presenting the results of that research. You can read more about it at the website. Itâ€™s interesting reading, really.

Anyway, about the kit. Each year FLL chooses a theme of global significance (in 2010 it was Biomedical Engineering) and devises a number of robotic challenges around it. And they send you this kit to get you started. The competition board is 8' x 4' and they provide a roll-out map to use as the base for your constructions, as well as a box of Lego bits and pages of instructions about how to put together the Lego challenges. Just building all of the challenges took our group 2 whole sessions.

Once the challenges are assembled and laid out on the board, itâ€™s time to start designing and programming your robot. The robot construction rules are strict â€“ only Lego-manufactured material allowed, no more than 4 motors, no more than 1 of each sensor, no non-standard software environments â€“ and you only get 2Â½ minutes to complete as many challenges as you can. Whenever the robot returns to base, a small area at one corner of the board, youâ€™re allowed to touch it, modify its attachments, start a different program. At all other times it must be completely autonomous (NOT remote controlled) and any interference with it leads to penalty points.

So there I was, with ten 9- to 12-year-olds with no engineering or programming experience. Mercifully, the role of coach in FLL, they explain, is not to teach, but to enable. Good. So I printed out the challenges, loaded the Lego programming environment onto some school laptops, and asked them to pick a few challenges to have a go at. There were 17 to choose from, and no way to accomplish all of them in the short time available.

There was teaching involved, but once they had selected the challenges, it was pretty straightforward. We started with the engineering, because that was a more tractable problem, and you need to have an idea of the robotâ€™s physical characteristics before trying to control it with software. Then came the challenge of introducing them to software. The Lego programming environment is fully graphical â€“ you drag action, sensor, conditional, and branching â€˜blocksâ€™ around, linking them together to achieve the required behaviour. We started with simple, dead-reckoning approaches â€“ â€˜turn both wheels for 8 revolutions at 5 revolutions per minute,â€™ â€˜turn left 90 degrees,â€™ â€˜lift arm 45 degreesâ€™ â€“ and just that is enough to get a lot of the challenges done.

What the team noticed, though, was that this style of control wasnâ€™t very robust. It was susceptible to small variations in the robotâ€™s initial position. The state of the batteries affected the distance the robot travelled. Even with identical starting conditions, the end position of the robot could differ significantly. This is when I introduced them to the sensors.

The most useful sensor was the light sensor. They used this to detect colour changes on the map and trigger a change in behaviour of the robot. Different groups of children would work on different parts of the robotâ€™s route, and these would then be joined together by â€˜blocksâ€™ switched by the sensors. This was particularly effective for the â€˜pill dispenserâ€™ challenge, where the robot needed to push a panel to dispense 2 Lego â€˜pillsâ€™, but leave the third â€˜pillâ€™ in the dispenser. There were handy black markings on the map that could be used to count how far the robot had travelled, and hence how many â€˜pillsâ€™ had been dispensed.

Another useful sensor was the push button, which was useful to ensure the robot kept the right distance from obstacles. We never found a use for the ultrasonic sensor-it was just too unreliable. And the microphone would probably have been thought of as a remote control, so we never even tried that.

What interested me about the whole experience was that we rarely talked about programming. The team was always trying to solve a problem â€“ sometimes the solution was a new attachment for the robot, sometimes it was a new behaviour. They quickly picked up control and conditionals. Looping was harder, and I donâ€™t think they ever really got there â€“ they were much happier copying and pasting sections of the program to get the number of iterations they wanted.

Second story

The local group lost its funding the next year and FLL in Scotland lapsed until this year, when a local company, Lamda Jam [JAM] brought it back. This year, as part of the local British Computer Society [BCS] branch I was asked to judge the robot competition. There were seven schools competing â€“ two high schools and five junior schools.

One difference in this competition was that, although there was a lot of inventive engineering, there was no use of sensors at all. Even the best teams were controlling their robots using dead reckoning alone. One of the side effects of this was that scores for the same team, using the same programs, varied wildly. Each team played 3 heats, and the winning teamâ€™s scores varied between 125 and 348.

So what did I learn from these two experiences in teaching kids to code?

Having seen FLL from both the participant and judging sides Iâ€™m confident that the FLL can be an excellent vehicle for getting children to learn to code. Because there are so many different angles to the challenge, itâ€™s easy for the team to do a little bit of everything without getting overwhelmed by any one aspect. The programming part of the challenge does introduce them to simple constructs, and with the right coach this can go a lot further. I can easily see a team building on its experience over a number of years, with some of the members eventually getting to be quite sophisticated practitioners.

But the counterintuitive insight was that itâ€™s not so much about the code.

A comment in a thread on the accu-general [ACCU] mailing list with the subject line â€˜Programming for teenagersâ€™ captured nicely what I learned from my experiences:

I think that finding an interesting and reasonable-sized project that can be expanded upon is more important than the choice of tools and environment. That is the hook to keep her interested and search for ways to learn more, and I also think the very first visible result must be reached quickly.

A good project, room to grow, and getting visible results quickly. Those are key. And one more thing: a good mentor. That, of course, would be you.

I encourage anyone with even the slightest interest in introducing children to programming to take a look at what FLL has to offer. You may end up doing more Lego than programming, but youâ€™ll be giving the children exactly the right role model â€“ us. Because weâ€™re people who solve problems and get results quickly.