Programming the NXT

Choice choice choice!

The programming options for the NXT are wide and bewildering, and unfortunately at this point, somewhat immature. This isn't much of a surprise for a product that has been out less then a year. Indeed the variety of options is a good indication of the potential for the NXT as a development platform. There seems to be two main classes of programming interfaces. The first is a representative system that uses icons and flow chart arrows to control program flow. Both NXT-G and Microsoft's Robotics Studio use this method of programming. While I am sure that this means is effective to program most functionality, this isn't the first time I have seen programming software try this interface method and without exception they have all failed. One of the biggest reasons for this failure has been the lack of flexibility that these programs offer. They are excellent for programming physical actions, have a very fast and shallow learning curve but break down once you try and apply advanced mathematics, logic or formalization.
Compiled vs. Interpretive Programming Languages

This leaves the more traditional method of text based coding. Here is an example written in RobotC to make a robot move forward;

// move robot forward

task main ()
{
motor[motorA] = 100; // Activate Motor A and provide 100% power to it
motor[motorb] = 100; // Activate Motor B and provide 100% power to it
wait1msec(1000); // Wait 1000 milliseconds.
}

// Program ends and motors shut off

The above program will make the robot move forward for one second or 1000 milliseconds. The naming of this language is somewhat of a misnomer as it is a C like programming language and not actually C. C and C++ are compiled programming languages and Robot C and it's brethren are interpretive languages, like Java. Here is the explanation as to why they choose this route from the Robot C FAQ;

Why use an interpretative system rather than native code generation?

By interpretative system, we mean that RobotC generates code for a pseudo “virtual machine” (VM) rather than directly generating instructions for the native instruction set of the robotics controller. The instructions for the VM are downloaded to the robotics controller; execution of a program then utilizes an interpreter that acts on each of the VM instruction.
Interpretative systems are well known and popular in the industry. The JAVA programming language is an interpretative system. Microsoft uses VM and interpretative systems in their latest programming languages.
An interpretative VM enables a robust solution that can be more defensively oriented against end user programming errors. When programming in native instructions, it’s relatively easy to corrupt a program or memory. In a VM environment, it’s possible to check and validate instructions to (usually) ensure that they don’t provide unexpected actions – e.g. ensuring memory accesses are to valid locations, better checking for overwrites, etc.
The NXT firmware program is over 100K bytes in size. In RobotC, you only have to download a small user program (typically 500 bytes or less in size) instead of a complete 100K firmware operating system. Download times are significantly reduced – seconds vs a minute or so.
We believe the existing NXT device drivers and the surrounding “Operating System” best fit an interpretative environment. More details can be provided once the NXT firmware is open-sourced.

I don't really accept this logic. The advantages of Interpretive systems come at the price of performance, size and memory usage. Java is an excellent example of this as it is, to say the least, a hog. I won't even go into Microsoft languages. Unfortunately, it would seem, that the more you know about MS products and languages, the less you know about how things actually work. MS goes a long way to hide or obfuscate these details in their projects and programming applications for Intellectual Property reasons. This is one of the main "advantages" of interpretive systems from Microsoft's view point. Programmers enter in commands that are interpreted into system calls. The programmer doesn't have to have any detailed knowledge of how the system works, just know the commands to give a certain result. For detail into Microsoft's reasons for switching to interpretive languages you really have to start to look at .NET, its methodology and the reasons it hasn't been accepted as an industry standard. Automated handling of variable types, and memory management are another advantage of interpretive systems.

In defence interpretive programming systems the logic is often given that modern computers have so much RAM and processor speed that the extra required to run the interpreter and load the code is a moot point. However, this argument breaks down when you apply it to the NXT brick. Lets take a look at the processor and memory specifications of the Brick;

Main processor: Atmel® 32-bit ARM® processor, AT91SAM7S256

• - 256 KB FLASH

• - 64 KB RAM

• - 48 MHz

Co-processor: Atmel® 8-bit AVR processor, ATmega48

• - 4 KB FLASH

• - 512 Byte RAM

• - 8 MHz

As you can see, we aren't exactly working with a beefy system with a lot of RAM here. While this is more then sufficient for the application, obviously with only 256KB of storage and 64KB of RAM, program size and memory performance is critical. Especially with interpretive systems as the interpreter must be loaded into RAM along with the code itself, rather then just a, much smaller, compiled binary file.

RobotC

RobotC is a new commercial product from Carnegie Mellon University that is being marketed towards an educational environment. Carnegie Mellon is a leader in Robotics development, so you know that this is a product with some balls. Lets face it, these guys have some serious coding skill.

RobotC isn't just for NXT and also will be providing support for the VEX platform as well as a complete 18 week educational curriculum geared towards high school and middle school students. This is an ambitious project and until I find a compiled solution, it is the product that I have the greatest expectations for. The syntax closely follows C programming and as such I feel it is a better educational product then the interfaces using Windows Icons and Mouse Pointing. As this is a commercial product my standards reflect this and I expect this product to be ready for prime time with complete documentation before it is offered for commercial sale.

In their FAQ the creators of RobotC have made claims that their interpretive system makes impressive speed gains, especially when compared to compiled code which are impressive to say the least.

. . . The RobotC opcode interpreter is extremely fast. Interpretation of a single opcodes take 2 to 5 microseconds (integer arithmetic) and slightly longer (5 to 12 microseconds) for float arithmetic. On an individual opcode basis RobotC is 10 to 30 times faster than standard firmware. The performance improvements are even more dramatic when compared to compiled code since RobotC generates far more compact code (i.e. less opcodes generated)..

I am not sure if this is a comparison to compiled code running on the LEGO Firmware or a overall speed increase. I emailed one of the developers for confirmation but haven't yet received a response. One thing is for certain. The RobotC firmware enables the use of float variables and allows for much more mathematical flexibility. That alone makes it superior to the standard offering by LEGO.

Support

Here I must say we come to what has to be the shining jewel of RobotC. More then even the slick interface the willingness to help that I encountered from the developers was very impressive. When I filed Bug Reports they quickly answered with solutions to try. Even when I had already posted a fix they filed notes to help better understand the issue I had. I do have some serious concerns with the documentation, but if the development team can keep that customer focused approach, I think it can be more than overcome.

Installation

The installation of RobotC was not a smooth experience for me, which for some reason seems to be a constant property so far with the Mindstorms NXT product. The experience was very similar what happened when I updated my firmware using the NXT-G. I have a feeling that the issue doesn't reside with RobotC but rather with the NXT brick itself.

Installation of this product is a two step procedure that involves upgrading the firmware on the NXT device to the custom firmware provided by RobotC. There are very good instructions available on the RobotC website to help with most situations. Unfortunately it was not fated for me to have an uneventful install. Following the instructions I started the firmware update process from within the RobotC interface and pressed the button to start. Much like when I was upgrading the standard firmware my brick just started clicking softly; however, this time, on the screen in front of me was the "Found New Hardware Wizard". For those of you who read my first Blog post you will recall that when I was updating standard firmware the computer wouldn't recognize the brick at all. So I thought to myself "At least we get THAT far!". I wasn't too scared, having been through this before so I reset the brick by pressing the reset for a good ten seconds and plugged the USB cable back into the brick.

This is when my difficulties really began. Again the computer recognized the NXT Brick as a new device, and again couldn't find drivers for it. I scoured the RobotC website for drivers, looked in the program folder, everything I could think of with no luck. By the time I started looking for a method to contact the developers I was getting a tad upset and very worried that I now had a seriously FUBARed brick. After a somewhat vitriolic posting on the Bug report site I did a complete uninstall/reinstall of everything NXT related and that managed to fix the problem and let me continue on with a regular setup.

Interface

One of the strongest features of RobotC is their compiler interface. Of course one can always program code in a text editor; however, using a interface can make things a great deal easier. RobotC has taken things one step father along these lines and added a side bar containing common coding functions that can be dragged into the main editing window giving you a easy template to fill out, letting you not worry so much about syntax.

One of the nice things about RobotC is that it was written especially for NXT. The entire product has a very cohesive feel and it is nice to have all the functionality working. RobotC also has a very well thought out sensor polling function that allows you to easily see levels and configurations of both sensors and motors in real time. Throughout there is the feeling of a professional coding environment.

There are a few flies in the ointment; however, they are minor. The editing window can only handle one open document at a time. This is somewhat annoying when you are trying take code segments from one file to another or compare code in two different files. I am also not a great fan of the sensor setup dialogs as they tend to dump a lot of useless text comments along with the code. In the end it is usually easier to just type in the sensor set-up command yourself like this;

const tSensors touchSensor = (tSensors) S1;

The above segment would be used to connect the touch sensor to port one with the variable name of touchsensor. I recommend using the setup wizard to find out what the syntax is for each individual sensor.

Beyond those minor points using the interface has been a real joy. I am sure that it will only get better as this product matures.

Documentation

My Gold Standard for documentation for any project is the OpenBSD FAQ. This is the first stop for anyone needing to know how to do something in OBSD and, despite its fearsome reputation, is usable by both experts and beginners alike. More importantly, no change that is visible to the user, in any way, is implemented before complete documentation is created and available. It is a philosophy I appreciate.

In this regard I feel that the developers have jumped the gun and offered the product for sale before it was ready. You can purchase RobotC from LEGO Education for $49, At the time of this article the product is listed as Out Of Stock, but as it is available for order I am not banging on about nothing.

The RobotC documentation is an attempt to do more then just provide a manual for their product. They endeavor to provide a complete 18 week course curriculum. This course covers introductory programming as well as the specific commands needed to work with the NXT and eventually VEX platforms. The course assumes that the student starts with no programming knowledge and works to build up from there. It is presented as a series of videos, PowerPoint presentations and worksheets, all of which are extremely professionally packaged in a manner that can only be described as "slick". They are clearly presented and easy to follow, even if I did find that some segments would be better as a single video rather then several separate smaller presentations. The whole thing fell down around PowerPoint #5 with a simple IF statement. I copied and pasted a program example from the presentation slide and it refused to compile at all, even after I had corrected the obvious syntax errors.

I filled another bug report and, with blinding speed, not only was I rewarded with a response, but an entire site change! I can't comment on the current documentation, as I haven't yet had a chance to look it over yet. One, somewhat ominous, sign is a large BETA mouse-over on the Software Training section on the site and the total absence of a section marked Documentation. One very obvious omission in basic documentation is any kind of manual at all. There is an excellent start on course materials for beginners, but these haven't even progressed as far as structured programming, leaving an experienced teacher or programmer wondering what syntax is used for more advanced programming structures. This is only partially made up for by a reasonable selection of sample code that comes with the application and there is a user Wiki where the community can help out.

Conclusion

The documentation of the RobotC project is its real downfall. The application is professional and well polished but its documentation resources have the feeling of a poorly organized Open Source attempt. Amazingly slick at one moment, incomplete and inaccurate at another. Development to overcome these downfalls is on-going and has great potential; however, as this product is sitting on the shelves as we speak, it falls far short of the expectations appropriate to a commercial release. The lack of a manual combined with the Beta state of the course materials unfortunately cripple a otherwise excellent product. Without the manual, teachers can't create material to cover the holes not yet documented by the RobotC team, nor would they be able to correct problems with the code examples handed out to the students except by deconstructing the example programs. This may be all well and good for the single, highly technical user, but hardly a good use of time for a teacher who has students to think about. Eventually this will, undoubtedly, be the premiere interface for teachers who wish to have a more flexible environment then the NXT-G or Microsoft Robotics interfaces but until the documentation at least approaches the promise of the interface I would recommend sticking with the demo versions and keeping your wallet in your back pocket.

Originally I was going to try and also do a overview of BricX, the open source C based solution. BricX supports a wide variety of platforms including VEX, RCX and includes support for both standard firmware and third party offerings. I have seen a number of extremely impressive projects coding using BricX and the NQC (Not Quite C) language. This includes projects on evolutionary learning robotics such as the 6.836 project so it has proven application in scientific study. As my copy of RobotC is about to expire, it looks like I will spending time using NBC, at least for the next little while. Tune in next week when I take a closer look at BricX.

Stay tuned!