As discussed in my previous blog post about Kindergarten robots, I wanted to see if I can teach kids the core idea of programming. This project has now progressed to the point that I have a working prototype of a programmable robot.
Essentially, the robot is programmed by putting colored Lego bricks in a sequence on top of the robot. This should be accessible and direct enough to work with kids — and with no computer needed, just direct physical interaction with the system. For some reason, I think the extra level of abstraction from a screen to a robot is just an unnecessary obstacle at this level.
For an example run, see the Youtube video linked below:
The robot is shown in the picture below. Since I use the same base as a fast chaser robot, it uses the large wheels from a Technic kit I happened to have around, and a decent swiveling rear wheel. Using treads for the drive would probably have given me a bit more precision, but this is faster and simply feels more fun.
The inspiration for the programming method came from the boardgame Roborally, where you are dealt a set of card with meanings like “forward”, “back”, “turn right”, “turn around”, etc., and have to make your robot navigate a hazardous landscape to get to a destination. In my kindergarten robot, I simplified the programming to just forward, left, and right. And there are no conveyor belts, lasers, pits, or other hazards on the field.
The program steps available are the following (the color sensor can only distinguish a few primary colors):
- Black – start bit
- Blue – move forward
- Green – turn right
- Yellow – turn left
- Red – honk the horn (beep)
- White – stop bit
As a programming language, this is definitely not Turing-complete and nothing that you could program anything useful with. In particular, the programming model lacks decision statements, loops, and variables. However, it conveys what I feel is at the heart of programming: obtaining a goal by putting together a sequence of very small and simple steps. If you cannot grasp the idea of many small steps, you will never be able to program in any meaningful way.
User Testing
I have not tested this with a group of kids yet, but only with myself and my five-year-old son. So far, it seems to work. After some initial confusion, he is starting to get the idea of putting steps in order and having the robot execute them.
Here are some very simple missions that can be used to get the programming thinking going:
- Turn around a corner (of the fridge in this case)
- Move to hit a balloon lying on the floor some distance away
- Move in a square pattern to get back where it started
I am sure I will think of more as I go along. I will blog some more once I have more experience with the robot.
Details of the Program Memory
The major problem that had to be solved to build this robot was creating a working program memory. I have decided to call the program memory MEPROM, for “Mechanically Erasable Programmable Read-Only Memory”. It is a ROM, since the robot itself cannot change it. Since you can both remove program steps and put in new steps using mechanical means (human hands, typically), it is definitely an M-EPROM.
The idea for the memory is simple: use Lego bricks to represent moves. It took a while to come up with the current form, as there are many ways to move colored bricks past a sensor.
Two of the program steps can be seen below: I used 3×1 standard lego bricks (which I borrowed from my son’s Legos, since it seems very hard to find good kits containing this particular type of brick):
To move these programming blocks past the color sensor in order to read them, I used some classic Lego treads (which seems to have been in use since the late 1970s!). Today, these can be best obtained by buying the Mini Bulldozer kit (8259). The program steps are put on alternate tread elements:
The Mindstorms color sensor only sees six colors, as discussed above. Worse, it tends to see black in dark shadows. For this reason, it needs to read the bricks head-on to be reliable. I have tried in vain to make the system self-adjusting, so currently, the program start has to be manually aligning the start bit (black brick) in front of the sensor. For the rest of the run, turning the driving motor 90 degrees reliably puts the next brick in place in front of the sensor.
The program turns out to be quite simple in the NXT programming environment. Turn program motor 90 degrees, sample the color sensor, and act accordingly using a “switch statement”:
Konstant ljus, dvs exempelvis bygga in läshuvudet i en svart låda med innerbelysning? HAr du testat det för att lösa färgavkänningsproblemet?
(ENGLISH: Constant lightinng conditions — did you try that for the reading color problem? E.g. enclosing the color sensor in a tight box which has a built in light.)
Unfortunately, there is no lamp included in the Mindstorms kit. The lamp is the color sensor, and it is lighted to detect the colors. I fear that putting a box around it all will just make everything appear black to the robot. Still, the color sensor is a huge step up from the old light sensor on the RCX.
This is pretty cool. As for making the system self-adjusting, have you considered using the touch sensor for alignment? i.e., the instruction brick would hit a latch connected to the touch sensor, which in turn causes the color sensor to sample the brick’s color and execute the corresponding ‘instruction’. This has the added advantage of more timing control, e.g., you could let the robot drive for how long it takes for the belt to rotate X number of times (assuming there are X gaps).
I noticed from your earlier post that you’re using both sensors for the bumper, but I believe that a one-sensor bumper is reliable enough.
The bumper is a single-sensor one now. But using one for alignment seems hard, as it would tend to block the bricks coming along. They don’t sit that hard on the tread, they fall off at the least resistance alsmot.