It turned out that trying to show a group of ten impatient kids that the robot read instruction codes and moved accordingly failed. Using a chaser program, where the robot drove around waiting for something to show up close in front of it and then drove full speed forward to try to hit it, was much easier to appreciate.  Classics like driving around avoiding to hit walls was also just as much fun as ever. Like my previous attempts, the kids piled up on the robot and tried to make it turn the way they wanted.

Clearly, physical exercise is easier to sell than cerebral exercise.

That said, I did manage to get some more thoughtful kids interested in getting the robot to go particular places. The setup I used was to put the robot on a starting square marked on the floor, and then putting a red bucket out on the floor some distance away. The kids were asked to help me program the robot to either hit the bucket or drive around it. I explained what the robot did as taking steps forward and turning, and actually the approximately 50 cm long runs it did for each blue programming tile was fairly similar to a serious step by a five-year-old (some kids instead started tip-toeing forward, which did not quite provide the correct stride).

As a safety device and to retain a semblance on intelligence on the part of the robot, I equipped it with a bumper in front. As soon as the bumper is hit, the robot is supposed to say “stop” and stop all activities.

The problems we tried were:

• Put the bucket down in front and try to hit it, needing three forward to get there
• Drive around said bucket, which required a program like blue, green, blue, yellow, blue, blue, yellow, blue, green (forward, right, forward, left, forward, forward, left, forward, right).
• Leave the base and drive to the back instead of front.

I sat down with a group of three kids who really got into this part (even with ten other kids running around playing cops and robbers at a very high level of intensity). They did get the idea and did propose steps towards the solution. However, it is clear that at least initially; one cannot expect them to plan out an entire program in their heads.

Rather, we ended up in a style quite familiar to anyone learning a new programming language or taking their first programming course. Try one step, see where it takes us, add another step or two to the program, and try again. Very much how I myself solve programming and scripting problems where I interact with a complex and possibly unpredictable environment. In this way, we did manage to solve some problems, and I do think the kids understood what was going on.

To me, I feel the idea of the Lego-programmable robot as a preschool-level programming course is at least partially proven. As in most other educational ventures, what is needed is a good overall teaching environment. Next time, I will have to try this with a small group of kids, just after they have had a snack so that they are alert and fresh. I will also make sure to break up the hard work with some simple play, since that is needed to keep the kids from being bored.

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”:

When I was a PhD student in Uppsala back around 2000, we bought a pile of the Lego Mindstorms RCX kits, for use in real-time courses. Obviously, the students loved the opportunity to play with Lego (including the few females). What was less obvious and much more interesting was what happened when we brought in a bunch of children from a local kindergarten to visit — they really took a liking to our little yellow robots running around a classroom. They treated the robots as little animals, wondering what they were doing and why…

With that in mind, I decided to try to reprise this myself with my own son and his kindergarten friends. Last week, I took my robot kit with me and went to meet the kids.

My top-level goal with exercise was really to get the kids interested in technology as a future field of study and venture… you have to start early to counteract the prevalent tendency of people to want to be famous and work in media or something… Only time will tell if this had any effect at all (I doubt it).

In addition to the top-level goal, I wanted to communicate some about how things work. Make technology more understandable and less magical, and more accessible. In particular:

• Autonomy: the robot is not under remote control, it acts autonomously based on its programming.
• Sense-compute-actuate: the robot perceives the world and makes decisions that get sent to the motors.
• Limited sensors: the robot does not see like we do, it uses far simpler sensing.
• Programmability: the same physical setup can do a lot of different things just by switching to a different program.
• Concurrency: the robot can do several unrelated things at once.
• Stupidity: the robot is really dumb and just reacts very predictably to its environment.

I think these points can be brought across using an indirect approach. You cannot tell a four-year-old about programmability. But you can show that if you go to the robot’s control unit and press some buttons it does something different.

Note that some of the points above are artificial, in that you could build much smarter programs with more complex behaviors and less direct reactions. But that would make things more magical and “human-like”, which is not what I wanted to communicate.

Anyway, in the end I used two configurations of a driving base, with a few different programs.

The first configuration is shown below, using a color sensor pointing downwards and an ultrasound sensor pointing forward.It also had a shooter pointing forward (in this picture, the organic styling of the Lego Bionicle Zamor-derived shooter comes across very nicely, as well as the apparently quite special silver- and gold-colored balls I picked up on a sale).

First, I had this robot follow a black line on the floor. Putting the line down was fun, watching the robot follow the line did not work out as intended. Too hard to explain the algorithm for following the contrast between black and not-black. Adding the behavior to stop when the robot hit a red line was also too subtle.

Next, I tried to put the robot on a table with the program “stay within black lines”. Or rather “reverse and turn if you hit a black line”. Problem was that the table had a spotted pattern that included small specks of black, and the robot just kept doing avoidance maneuvers… so that failed. I still want to do a table-dancing robot, but I guess relying on an ultrasound sensor pointing downwards to detect the chasm at the edge will work better.

What was fun though was when I activated the ultrasound sensor and the shooter: the robot would crawl along the line, and if something got in the way, it would fire a ball. That was huge fun! All the kids crowded around to get the robot to shoot and collect the balls. Note for future attempts: dramatic actions are great!

It was even better when I set the robot to rove freely, using the ultrasound sensor to turn when something got in its way. This was an easy-to-understand behavior that the kids appreciated, putting feet and hands in the way of the robot to make it turn. The poor robot was often the center of a pile of kids that were all trying to make it turn.

I also tried a configuration using bumper sensors:

Here, the robot only had one program, to move forward until it hit something, and based on the side that hit, back up and turn to avoid hitting the same obstacle again. This was a very successful configuration. The kids started to play “don’t touch the robot” with it, having it drive between their legs or bending over the robot to make a bridge – but not touching it and making it turn.

Note that I did not bring any computer with me, all programs were preloaded on the NXT brick. Very handy, actually.

In summary, I had a great time doing this, and I will be back with new configurations and programs. Creating the programs was very quick and easy in the Mindstorms environment, proving the value of domain-specific programming.

The kids have hopefully learned that you can play with and control technology, and that you should not be too respectful. Maybe someone also picked up some of the ideas I presented at the start of this blog post.

Gender-Theoretical Notes

I do have to end with a slightly sad note.

It was surprising to me just how differently the boys and the girls reacted and behaved. I had assumed that kids would just be kids at this age (three to five years old), with no gender-related differences. It was very striking that this was not the case in reality. The boys just ran in and started playing, and very quite hard to get to listen to anything I had to say. The girls walked in and quietly waited for instructions, and took some warming-up before they would interact with the robot.

I cannot blame our kindergarten for this, they are definitely trying to avoid gender-based stereotypes.I guess it shows that fighting societal norms is just as hard as everyone says it is.

It was also interesting that the kids were surprised to see a parent build with Lego and have a great time. For some reason, that was not expected behavior from a dad. Sad too.

Last week, it resurfaced at Embedded.com, with an attribution that was initially wrong.

However, now these issues have been resolved, and the article is online as part 5 of a series of book chapter excerpts from the Firmware Handbook.

I do think the material still has value, and that it is a good intro to how compilers work. The coding tips seem to have stood the test of time, but I would love to know how they can be updated given compiler technology updates in the past eight years.

Please note that Embedded.com are still struggling to get authorships right, so now I have been attributed a bit more material than is fair. Hopefully, they can resolve this soon:

First some background.

A key idea in the setup is to use the approach of assuming some processing time for the hardware accelerator, rather than creating detailed code and determining the actual processing time for a particular implementation. Given some assumed time, we can then see how it impacts program performance. This is a way of designing hardware where we look to how fast something needs to be to have a positive impact, rather than trying to make it as fast as possible. It also lets us analyze how performance in hardware is seen when using a complete OS stack and a real device driver rather than simple bare-metal software (which tends to show the performance in the best possible light). Essentially, it is loosely timed design-space exploration.

Initial tests of the driver used very short completion times, on the order of 1 microsecond. The read() call at this point simply waited for the hardware completion flag to become true, and then returned the results. That is not the kind of behavior that a driver should have, since if the hardware gets some kind of hiccup, we will be stuck looping  inside a kernel context. Instead, I implemented a blocking read variant that would put the calling process to sleep until a result arrives.

In order to test that my driver did the sleep function correctly, I changed the processing delay into the level of seconds… and promptly found a set of issues that forced several rewrites of the code. The most important was the need to switch to a software flag for completion rather than relying on the hardware flag, and the implementation of an interrupt handler to get a notification from the hardware.

Then, on Friday, I demonstrated the setup along with some new performance analysis tools to go with it to some students testing the setup. And the test program suddenly stopped working, obviously hanging at the first call to read() without ever getting unblocked.

The reason was a classic race condition: the code in the write() device driver call that sent input data into the hardware device waited until after the writing was complete (and then some more) before clearing the operation complete flag. Here is the relevant piece of code:

for(i=0;i<words;i++) {
  write_register(SIMPLE_INPUT, kbuf[i]);
}
*f_pos = 0;
kfree(kbuf);
clear_completion_state();

With a sufficiently short delay to completion, the completion interrupt fired, was handled, and set the completion flag before the write() function even got to clear_completion_state(). After this, the test program called read() to read the result, and was blocked as the completion flag was not set. The interrupt to signal completion from the hardware had already triggered and its result deposited in the software flag, which had then been promptly overwritten inside write(). Thus, inside read(), the flag never became set, and the process waited forever.

The fix is obvious: just move the clearing of the flag to before the writing to the hardware begins.

To generalize from this brilliant example of concurrency carelessness, this is a really good accidental demonstration of the power of varying timing in a virtual platform to shake code and find timing-related bugs in a manner much more efficient than possible on physical hardware.

Had I described the exact (or even approximate) timing of a particular hardware implementation, this kind of bug would not have been found and the driver code would not have been as robust. An implementation relying on a very short completion time could check the hardware operation complete flag directly, but that broke down when the delay was long. The buggy implementation above worked fine with a long completion time, but broke down with a short. The fixed implementation works across a span of times from 10 ns to 10 s or more, which is all you can ask for I think.

A short fun Simics note on this: changing that timing parameter is a run-time change. It is possible to change it during a run, from the Simics command-line, using a simple one-line command:

simics> sd0->time_to_result = 10.0e-9

It is really nice working with a system like that!

There are times when working with virtual hardware and not real hardware feels very liberating and efficient (not to mention safe). Bringing up, modifying, and extending operating systems is one obvious such case. Recently, I have been preparing an open-source-based demonstration and education systems based on embedded PowerPC machines, and teaching myself how to do Linux device drivers in the process. This really brought out the best in virtual platform use.

The final result of my efforts will be more public early next year, when the students I have put to work on my Linux-based setup come back and show me what they accomplished (or not). Until then, here are some small tidbits on how easy it is to work with kernel-level code in a virtual machine. Actually, if I had been working on real hardware, I am not that certain that I would have had anything but a bricked machine in front of me — to put it simply, flash reprogramming seems to hate me, and I have managed to fail or destroy a few embedded boards that have been unlucky enough to cross my path.

The virtual platform was really very helpful to diagnose all the mistakes I made while creating my driver and making it talk to my custom hardware.

First of all, it was dead easy to test a new version of the driver: start the simulation from a checkpoint of a booted and configured machine, load the driver into the target file-system using the Simicsfs backdoor (similar to the VmWare hostfs solution), and then insmod it. This was automated in a script that typed the needed commands on the target-command line with no manual intervention. Each iteration takes a few seconds, which is just as fast an convenient as testing a simple program directly on the host.

Diagnosing what went wrong was greatly facilitated by the simulator: did the driver access the device I had prepared for it? Were values read as expected? Obviously, there were a lot of such cases, I am not the most expert device driver programmer (yet).

Here is one particularly interesting example: I empirically learnt that the Linux kernel “readl” function is always reading data little-endian, even on a big-endian machine. You have to use “readl_be” to get the big-endian data from a big-endian device attached to a big-endian machine. I guess the behavior makes sense for reuse of drivers across architectures, but it sure confused me when my driver was reading the right register but complaining about bad contents.

The simulator showed the problem very plainly:

• “value read is 0xabcd0101 (BE)”. Ok that looks right.
• “register r3 contains 0x0101cdab”. Strange, looks like the wrong byte order. WHY I screamed to myself.
• Using reverse execution to step back one instruction showed that the load instruction used was a byte-swapping 32-bit access. Aha!.
• Go into Linux kernel headers (include/asm/io.h) to find that there were a bunch of other varieties available, and guess that readl_be() was the right solution.
• Change device driver code, recompile, and retest. Now it worked.

I would have assumed that the book I was using as my guide, the highly-recommended Linux Device Drivers, 3rd edition” would have told me this. But it did not, as it is annoyingly tied to the horrible standard PC. It could really do with some extra chapters on drivers for PowerPC, ARM, and MIPS (to name some of the most important non-x86 architectures out there).

On the other side of the fence, I am using Virtutech DML to do the actual device, and that is working out very well. In my setup right now, I can change the device driver and the hardware it drives, recompile both, and then run an automated test script that starts from a checkpoint, inserts the hardware model in target memory, loads the device driver, and tests it in about five seconds. Very handy, and all completely automatic. The ability to load and insert hardware models on the fly during simulation is really very convenient here — I would have to have to reboot the target Linux from scratch each time I wanted to add or remove things from the virtual platform hardware setup.

To sum things up, so far, I have learnt quite a lot about doing Linux device drivers and how to setup hardware in a Linux system, and I think it would have been much harder to learn and experiment like I have done had I been stuck with physical hardware (not to mention the plain impossiblity of just inserting a  new piece of hardware in a simple way into a physical system).

It really shows that quite often, virtual hardware is “even better than the real thing”.

For fun, here is a screenshot of a complete test run of loading the device driver: