For my parental leave, I have just bought myself a Lego Mindstorm NXT 2.0 kit. It is not much fun for our youngest, who mostly gets a bit scared by a piece of Lego driving around making noises, but I hope to be able to use it to teach my older child (almost five) to program. Let’s see how that turns out. It looks hard to make the NXT environment provide the kind of Roborally-style programming blocks that I had hoped to create, as I cannot for some reason get a sufficiently custom icon onto custom blocks.
It also presented me with an opportunity to try some domain-specific high-level graphical programming. The programming environment provided for the NXT series of Mindstorms kits is based on LabView from National Instruments, and it really does seem to work. It even features parallel tasks, which I tried to use…
It turned out that it is not that easy to get it right. I was trying to have a few different tasks look at different sensors and steer the robot in different directions based on the sensor readings. However, this quickly turned into a literal deadlock: the robot just sat there, doing nothing, after the first time that my ultrasound sensor task tried to steer it. Failure.
The manual is quite silent on the tasking semantics, and there are no (or I have not yet found) shared variables, locks, or message-passing mechanisms to synchronize the tasks.
Looking for an answer on the web, I came across a nice tutorial on tasking:
It is a video, and it ends with the note that the only reliable way to multitask in the NXT environment is to NOT try to control the same thing from multiple tasks. If I want to listen to multiple sensors, the only way is to create a loop with switching on inputs. I.e., manual polling. So much for using the natural language of tasks to handle naturally concurrent activities. At some point, I might figure out if I can construct it from tasks and data value transfers, but for now, I will just go with the flow and write (or rather draw) some polling loops.
Here is an example from the manual. Note that the top “beam” controls motor A, and the bottom controls motors B and C:
That last part about data wires is intriguing… but I will need to find some more reference materials.
Anyway, the way to express parallel tasks here is really quite neat. At least as long as they are dealing with completely separate aspects of the control of the robot.
If this had been a more hard-core environment, it would have been fun to put different tasks on the ARM7 and AVR processors that are inside the NXT 2.0 brick. Yes, it is a true multiprocessor, if very limited in capabilities. At http://mindstorms.lego.com/en-us/whatisnxt/default.aspx you have the specs. ARM7, 256 kB of FLASH, 64 kB of RAM, and the AVR has 512 bytes of RAM and 4 kB of FLASH. A nice real embedded machine!
Jakob,
I also experiment with the NXT with my 10 year old son.
There are lots of ways to program it besides using LabView.
One that I like is Urbi:
http://www.gostai.com/
http://www.urbiforge.com/
Congratulations on the baby.
Jason
Yes, there seems to be a plethora of programming options out there. I am also thinking about trying the C compiler from my old employer IAR, at http://www.iar.se/website1/1.0.1.0/1483/1/ .
But I am also making a point of trying to use Labview, in order to see how it is to use a graphical programming system for some “real” work (even if it is with a toy). So far, I am very impressed with the ease of getting going, with programs done within minutes of installation. Sure, it is very limiting in some ways, but also liberating in its simplicity. That is supported concurrency was an unexpected bonus.
I keep being reminded of the characterization of “CASE tools” that I got back in the mid-1990s from the excellent Professor Jochen Ludewig (http://www.iste.uni-stuttgart.de/se/people/ludewig.html) in Stuttgart, Germany. He basically said “it is like building with Lego Duplo compared to regular Lego — you quickly build something big, but not with as much detail or freedom”.