As a result of making progress n the Scheme->Forth compiler (for the LEGO Mindstorm), an interesting possible focus came up. The initial event-based interface we’ve devised is na?ve; this was known from the outset, but it wasn’t until one of my students put a good problem to me that we realized the ease with which student programs could fall into race conditions. Semaphores, locks, or some other mechanism would be necessary for them to get predictable behavior from their bots.
I talked with Bryce about this, and in particular how they did systems control at Cummins in the diesel engines. Typically, they’d work off the clock, and have an executor that would manage all their event handling. This single point of control, tied to the clock, eliminates a lot of problems and allows for profiling of code and other forms of analysis that are valuable to someone writing code that interfaces with hardware.
From talking with Felix about the same, I learned more about his Masters work,
which involved a state-machine representation of autonomous robots.
While I still need to read his thesis, I thought about this some.
Motors and other stateful aspects of the robot would be at the nodes,
and conditions on sensors would be on the edges; then, in each state,
I would simply “poll” each of the edges until one of them was true—then,
you transition.
While all this is very cool, the point is that there are several reasonable ways to program the bot, all easily implemented, and all run into good, meaty CS/systems topics. With some more thought about the pedagogy, this could be something that I can narrow down to a tight topic, do a few small-scale experiments on, and have a nice dissertation at the end of the process. Put another way, it narrows both the CS content and the scope of the pedagogy involved, and therefore seems to be a worthwhile avenue for further thought.
