CIS 690-Project Final Paper

Paul Kavich

Dr. Mitch Neilsen

13 May 2002

Over the semester I have worked on three main parts to my project. The first being working with the PowerPC board, second developing programs using Not Quite C (NQC) with the Lego MindStorms, and lastly verifying the NQC programs using Uppaal. This paper will be broken down into each of these three sections and I will provide documentation as to what I did and how one might go about running these programs. My journal log and various links to websites I used can be found at I have kept an update on my weekly progress at this website.

Phase I – PowerPC

The initial project that came about was developing programs to be used with the PowerPC board. I began researching using the example programs found on the supplied documentation CD, which can also be found at A simple Hello World program was the basis for my initial research. I was able to load this program to the chip, but unable to get the correct output to show on the terminal window. It was to display “Hello World” each time a key was pressed and was to run straight from the flash memory in the chip. However I found it was printing out cryptic messages that could not be understood. Another method was provided in the documentation where the program ran from the utility program that is embedded into the chip. Here the program executes by calling the go command using the specific block in memory. This provided the same roadblock and returned cryptic messages. I did look into the possibility of using the Cgywin GNU tools to flash the chip, but ran into difficulties as it required a port to Linux. I was unable to progress with this phase of the project due to license issues with the IDE provided which allowed the conversion of C programs into the .s19 format which could be programmed to the chip.

Phase II-Not Quite C

The next phase of my project deals with the use of Not Quite C (NQC) to develop programs for the Lego MindStorms. NQC is a language similar to C/C++ and can be easily learned. The main reason for the use of NQC over the graphical program Lego provides is to give more functionality to the brick and allow the user to program in text rather than images. For younger users however using the simple pictures seems to be a smart way to learn. I was able to find however, a file with the NQC code while experimenting with the GUI, but the Lego program stores it with the .lsc extension. Within this section I will provide documentation on how to install NQC in Windows as well as some of my programs and other examples I used to aid in my research.

I found two methods of installing NQC on a machine. The first being the traditional command line interface and an IDE. Since I used both methods, documentation will be provided for each.

How to install NQC on a Windows terminal:

First be sure you have the most up to date version of the firmware on the RCX brick. If you need the firmware it can be found in the SDK at Documentation can be found there to install the new firmware.
If the firmware is installed, then you are ready to begin the installation of NQC which can be found at David Baum’s website, who created NQC.
Click the link for the latest version and it will take you to a download page.
Select the Win32 executable file.

Once the download completes, execute the file to begin the installation.

How to Run NQC in Windows:

NQC is similar to java and uses the command line, so it must be executed within a DOS window.
To run NQC using DOS, be in the directory the .nqc file is contained, for example if your file is named test.nqc, then type “nqc -d test.nqc”. This command will download the file to the brick and make it executable.
The RCX should now be ready to run the program.

How to install NQC with an IDE (BricxCommandCenter):

Go to and download the executable installer for Windows.
Once the download completes, run the file and go through the setup wizard. One can install more documentation if the custom method is selected. This contains a few useful examples and other documents.
The installation should complete and then you should be able to run the program. (Note: David Baum’s NQC does not need to be installed for the IDE to work, it is embedded into the installation of BricxCommandCenter.)

How to run BricxCommandCenter:

Either click the shortcut placed on the desktop or use the start menu in Windows to open the program.
You will first see a window which asks you for the type of IR tower you have and the type of RCX. Select the type you have and then click OK to execute the program. This will make a connection both to the tower and brick.
Once in the program, a familiar IDE interface appears which should be familiar to anyone who has used one in the past. The unique item is the window containing the most frequently used NQC commands. It makes it very easy to make “on the fly” programs.

Figure 1: BricxCommandCenter shown with useful templates and other various features of an IDE.

I found using the BricxCommandCenter to be very helpful as most IDE’s are. It has various features which enable programs to be analyzed before they are run using a simulator. This feature was very helpful when developing my temperature sensor program for open house. NQC and the RCX also have the ability to use a log file. I used this feature to graph all of the temperature readings taken at open house.

Most of my research with NQC involved looking at example programs I found on Baum’s website as well as The Unofficial Guide to Lego MindStorms. I focused my study on the use of sensors with the RCX. These provide uniqueness to the robot and make for an interesting project. I looked at examples of programs which used the touch sensor, light sensor and heat sensor. I based my program for open house from an example I found which used a heat sensor. My program takes a reading from a thermistor setup on a breadboard and then records the reading to a log file on the RCX. Many of the sensors can be homemade and this allows for inexpensive, efficient programs to be developed. The code for my program can be found from a link on my webpage. Many of the examples I looked at can be found here I found Baum provides some excellent examples based on his work in developing NQC. They were easy for me to understand and helped me get a better feel for the language.

Phase III-Uppaal

The third and final phase of my project involves the use of Uppaal to verify my temperature program. Uppaal is a program which allows a user to create states based on a program and then diagram a finite state machine. The states can then be run to determine if the program has deadlock or not. In this section, I will provide documentation on how I tested specific states of the simple temperature program used at open house and discuss some unique queries run on the system. The final version of my verification can be found on my website.

How to install Uppaal:

First make sure the latest version of java is installed on the machine. If you need to download it, see for instructions to download the java environment onto your computer.
Go to to download Uppaal for Windows. You must fill out a simple agreement by giving your name and other information.
Once the form is complete, the download will begin and the program will be zipped up.
Unzip the file to the location of your choice and it will create various folders associated with Uppaal.
If java is installed, simply click on uppaal2k.jar to execute the program in Windows.

For my finite state machine, I created two systems. One was a system to handle the states of the program, while the other handled the user responses. I was able to find the examples provided with the installation to be very useful in creating my machine. The temperature machine has three states; one which waits for the user’s interaction, another which tells the machine it, has been pressed and finally one which writes the data to the log file. I thought these states seemed the most logical and can easily be traced back to the code. The user machine has two states; one stays idle and waits for the thermistor to be pressed and the other tells the machine it has been pressed and signals the main machine of the instance. The most interesting part of the verification process was developing some unique parameters to test the machine with. Once again, the example programs provided aid in devising these models. I have developed some simple cases to prove the system does not deadlock, each state works, and no two states can function at the same time. With the aid of Uppaal, the models can be verified. These queries can be found on my website and viewed in Uppaal. I had difficulty initially verifying the pressed state reaches the waiting state after it cycles through but after changing waiting and writing to committed states I was able to verify that case. After that problem, the program checked out smoothly and I was able to get the results found on my website. Below is a figure of Uppaal open with the system I developed.

Figure 2: Uppaal simulation tab showing the processes and trace running.

Figure 3: Uppaal verification tab showing the queries developed to test the state of the machine.

In conclusion, I have discussed the three main phases of my project which I feel has been a success. These being the PowerPC board, NQC, and the use of Uppaal to verify my NQC programs. I have gained knowledge in each of these areas over the semester which has provided a unique experience. Understanding how NQC can make Legos more unique and powerful was very rewarding. The verification process was not as painful as I initially though it would be. After I managed around the roadblock of proving states do eventually reach one another I found it to be a powerful tool I will use in the future.

Sources:

1) Baum, David--

2) AalborgUniversity, “Model-Checking Real-Time Control Programs”

3) Knudsen, Jonathan B. “The Unoffical Guide to Lego MindStorms Robots”