Follow-up of my previous articles (first and second) about my experience hosting a robotic class in a junior high school. Here is a little wrap-up of the third session.

Good session

This session was a bit more successful than previous one I think. This time I assigned them a broad goal of “playing around” with the motored wheels of the robot (which is what they wanted to do from day 1!). I could not resist preparing a single sheet of paper with some instructions on the different steps they could follow that I gave to each group. For example the first steps were:

• go straight for 1 second
• go straight for 1 second and then back for 1 second
• go around the foot of your chair with the Robot
• start playing around with the ultra-sound sensor…

Most of the kids followed this guidance and were able to reach some satisfying results. Important to note that although the group was only made of 12 people, it was of great help that I came with a colleague to help me manage the session!  An interesting lesson from this session is the common programming mistakes kids did.

No Looping

The most typical error is to write an event-driven program without an event-waiting loop :

So here, the resulting program does…. nothing! The “if” is done immediately (and most probably the button is not yet pressed), and then it’s over. The solution is to surround the “if” with a “forever” loop:

This error is sort of satisfying at first because it allows to explain the whole “computer is dumb and only do what you ask it to”, but it’s a bit untrue to say that nowadays to a young programmer because, well, computer is super smart is does A LOT for us. We just have to assemble colored bricks to have a robot move, so why this “forever” loop should not be included in all this framework? The “computer does only what you tell it to do” sounds true only for those who did some assembly language…

No Waiting

The second most typical error is to write an series of statement that are changing the state of the machine, but without waiting between each statement:

Here the user might expect to see blinking led, but they won’t see it because the program will execute too quickly for a human to see it. So here the solution is to add some wait command between each change of state:

Once the kids had those 2 fundamental rules in mind (looping and waiting), they were able to make some good progress!