The NXT is the second generation of LEGO’s MINDSTORMS product line.

The first generation was introduced in the mid-1990s and centered on the RCX programmable brick. There were several derivatives of the RCX, with slightly different features. They all shared the same Hitachi H8 8-bit computer and had a similar programming language. The Cybermaster brick had two built-in motors and used a wireless link instead of an infrared link. The Scout brick was a lower-functionality subset of the RCX. The NXT is far more capable than the RCX. Some of the improvements include in the following:

The NXT has its own operating system, just like a PC has a Windows or Linux operating system. The operating system is a powerful “executive” program that manages all of the devices (sensors, motors, buttons, LCD display, timers, memory, etc.) that are part of the NXT.

In an embedded system such as the NXT, the operating system is often called firmware — in other words, software for an embedded system stored in nonvolatile flash memory—and it provides control over the hardware of the embedded system.

An operating system also provides other base capabilities that are found on the NXT. On the NXT, it implements a file system that can store up to 64 files. It provides a menu system for managing files—in other words, execute, run, or delete the files—similar to, but naturally not as powerful as, the functionality found in the Windows desktop and Explorer menus!

You write your program for the NXT using one of the programming environments. Then the PC “compiles” the program into a compact format suitable for execution by a computer and transfers it to the NXT. Once it’s on the NXT, you use the buttons to navigate to the operating system’s “run program” menu item. Pushing the Enter button (the orange button) will “run” the program contained in the selected file.

This compact format of a program is often called bytecode. A byte contains a single character of data. A user program is composed of a series of instructions that describe the desired or programmed behavior. It takes several bytes of data to describe one instruction—hence, the term bytecode. “Set motor power level” is a typical instruction; the first byte is the opcode specifying the instruction type, the second byte indicates which of the three motors to manipulate, and the third byte is the power level to apply.

Bytecode is not instructions that the NXT’s CPU can execute directly. Instead, the operating system contains an “interpreter” application that looks at each bytecode and converts it to the appropriate functionality. Interpretative programming languages are very common— Java is a popular example, where a user’s program is converted into Java bytecode which is then interpreted when the program is run.

NXT-G (NXT Graphical) is the graphical integrated development environment (IDE) provided with the NXT set. NXT-G is targeted at children and adults with no programming experience, and for this reason it is very easy to use.

You write a program simply by dragging and connecting code blocks into a sequence of instructions, more or less like using actual LEGO bricks. Different kinds of code blocks correspond to different functions: You can control motors, watch sensors, introduce delays, play sounds, and direct the flow of your code according to the state of sensors, timers, and so forth. NXT-G also provides a simple way to organize your code into MyBlocks, or groups of code blocks that you can call from your main program as though they were a single code block.

When you think your code is ready to be tested, the NXT-G IDE will compile (translate) your code into bytecode and download it to the NXT through the USB or Bluetooth link as a file on the NXT.

The intuitiveness of NXT code makes it the ideal companion for inexperienced users, but as you become more expert, you may notice some drawbacks:

Sooner or later, you may start to want a more powerful language. Fortunately, alternatives such as the RobotC programming environment are still easy to use but provide more power and flexibility.

The NXT Byte Codes (NBC) and NXC (Not Exactly C (NXC) languages use the same firmware as NXT-G. The advantage of this approach is that you can program in either the NXT-G graphical language or in NBC/NXC without having to reload the NXT firmware. The other solutions utilize different firmware interpreters that do not support NXT-G programs. (A dual-version firmware solution is currently in development for RobotC that also supports NXT-G-based programming; it should be available by the time this book is published.)

NBC was developed first; it is a very low-level language requiring detailed knowledge of the individual NXT-G opcodes. It has subsequently been superseded by the higher-level NXC language which is similar to, but different from, C.

NBC is generally similar to the C programming language but has many differences due to the limits and capabilities found in the NXT-G bytecode. For example, it does not support floating-point variables. In addition, it implements arrays, but in a proprietary fashion that is not common to standard programming languages.

NXC and Bricx Command Center (BricxCC) are the most advanced of the alternative programming environments for the NXT. NXC + BricxCC is quite a powerful combination. The drawbacks are that the programming language is unique to the NXT—it is not C—and it is constrained by the limitations and performance of the NXT-G interpreter. For example, it doesn’t support floating-point variables, and array support is different from that found in most other programming languages.

BricxCC is quite a powerful IDE. It was originally developed for the RCX and has been subsequently enhanced to add support for the NXT and NBC/NXC.

The pbLUA language (the name stands for programmable brick LUA) is the result of Ralph Hempel’s experience in designing and programming embedded systems. According to Wikipedia.org, “Lua is a dynamically typed language intended for use as an extension or scripting language, and is compact enough to fit on a variety of host platforms. It supports only a small number of atomic data structures such as boolean values, numbers (double-precision floating point by default), and strings. Typical data structures such as arrays, sets, hash tables, lists, and records can be represented using Lua’s single native data structure, the table, which is essentially a heterogeneous map.”

LeJOS NXJ (the name stands for Lego Java Operating System NXJ) is a subset of the Java language. It was originally developed for the MINDSTORMS RCX and many of the original developers have been involved in a similar port to the NXT. LeJOS is an open source project and is under continuous development. It became available in early 2007 as a limited-feature alpha release, and it is still incomplete for widespread use.

Significant effort is still required to get the full NXT feature set enabled in leJOS. For example, a menu system is not available, so after you have downloaded your program, you can run it only once. If you want to run it a second time you have to download it again.

We didn’t cover all the programming environments for the NXT. There simply isn’t room to cover them in depth. There are two other environments that are worth mentioning, though.

ROBOLAB is a graphical IDE that was originally developed for the RCX. It’s very popular in the educational market; hundreds of thousands of students use ROBOLAB every year. In fact, it is the language of choice for RCX in the education market. ROBOLAB has been significantly enhanced and extended to support the NXT. It has also been upgraded for the RCX version.

We do not cover ROBOLAB in this chapter because, if you don’t already have RCX bricks and ROBOLAB, the NXT-G IDE is the best choice for graphical programming. If you do have RCX bricks, you’re already familiar with ROBOLAB and the transition to ROBOLAB on the NXT is straightforward.

Numerous evolving solutions treat the NXT as a dumb device with all the intelligence provided by programs running in the PC. The PC communicates with the NXT over the wireless Bluetooth link. We do not consider these in this book, for two reasons:

The logic for implementing a clock is very simple:

We could write this as a single long sequence of instructions. But it is better to break it up into several smaller “modular” units. Each unit of code is a subroutine or function. The highest-level “logic” for our program instructions is show here:

//

// Declare   variables   to hold the time and initialize   them to zero

//

int second    =  O;

int minute    =  0 ;

int hour      =  0 ;



task main()

{

  setTimeBeforeStartingClock() ;

  runClock () ;

  return;
}

This program code is short and easy to understand. It shows a few elements of the C programming language syntax:

The displayTime function that follows nicely formats the time variables into a text string and then displays it on the NXT’s LCD screen. This feature is used in several spots in the program so it’s been defined as a function to make efficient and clean use of code. When you want to display the time you make a call to this display function. displayTime uses advanced formatting techniques to convert the internal format of variables into text strings—for example, the format code %02d will convert a variable into two characters (02) as an integer number (%d) without the fractional part.

void displayTime()
{

  string sTime;

  string sSecond;
  //

  // Build time string in format "hh-mm-ss"

  //

  StringFormat(sTime, "%2d:%02d", hour, minute);

  StringFormat(sSecond, ":%02d", second) ;

  sTime = sTime + sSecond- // concatenate the two strings;

  //

  // Now display it on the LCD

  //

  nxtDisplayBigStringAt(2, 16, sTime) ;

  return;

}

The runClock function is small and easy to understand. It simply updates the time every second. The minute and hour variables are updated appropriately as well, as shown here:

void runClock ( )
{

  while (true)
  {
    //

    // Loop forever incrementing second, minute, hour

    //

          displayTime();

          waitlMsec(1000) ; // Waits one second

          second = second +   I;

          if (second >= 60)
          {

            second = 0;

            minute = minute + I;

            if (minute >=   60)

            {

              minute =  0;

              hour = hour +   I;

              if (hour >=   12)

                hour =  0;

            }
          }
        }
     }

The setTimeBeforeStartingClock function is used to set the start time for the clock. You use the left and right buttons to increase or decrease the minute value. Pressing the Enter button advances the program flow to modify the hour value.

//

// Use right / left / enter keys to adjust minute and hour

//

void setTimeBeforeStartingClock()
{

  nNxtButtonTask = -2;    // Tell NXT OS that your program will use the buttons



  // Display some help info on the LCD    display



  nxtDisplayCenteredTextLine(0,   "Left/Right to");// Text line 0 on LCD

  nxtDisplayCenteredTextLine(l,   "Set  Minute");      // Text line  1

  nxtDisplayCenteredTextLine(3,   "Enter sets hour");// Text line   2

  displayTime () ;

  while (true)      // Repeat a block of code many times
  {
    //

    // Loop until the 'enter' key is pushed.

    //

    if (nNxtButtonPressed == kLeftButton)


  {

    if (minute < 59)

      ++minute; // "++" will increment the minute variable by 'I'

    else

      minute =  0;

    displayTime();
  }

  else if (nNxtButtonPressed == kRightButton)

  {

    if (minute > 0)

      --minute; // decrease minute by one

    else

      minute = 59;

    displayTime();



  }

  waitlMsec(250)  ;

  if (nNxtButtonPressed ==     kEnterButton)

    break; // exit or "break out" of the loop
}
//

// Wait for the 'enter' key to be released.

//

while(nNxtButtonPressed   ==    kEnterButton)
{}

nxtDisplayCenteredTextLine(0,   "Left/Right to") ;

nxtDisplayCenteredTextLine(l,   "Set Hour") ;

nxtDisplayCenteredTextLine(3,   "Enter runs clock");

while (true)
{

  if (nNxtButtonPressed == kLeftButton)
  {

    if (hour < 11)

      ++hour ;

    else

      hour = 0 ;

    displayTime () ;
  }


    else   if (nNxtButtonPressed   == kRightButton)

    {

     if (hour > 0)

      - - hour ;

     else

       hour   = Ii ;

     displayTime    () ;

    }

    waitlMsec(250)    ;

    if (nNxtButtonPressed   ==  kEnterButton)

      break ;

  }

  while(nNxtButtonPressed   ==  kEnterButton)

  {}


  eraseDisplay()    ; // Clear   the LCD screen

}

There’s one thing to watch out for if you copy the preceding program. RobotC will generate an error message if you try to call a function before it is defined. So you have to rearrange the order of the source code to ensure that functions are defined before they are called.

The preceding program is included in the sample programs distributed with RobotC. The filename is NXT Simple Clock.c. You can open this file in RobotC with the Open Sample Program command.

This relatively simple program is more complex to write in NXT-G. Figure 7.1 shows a screenshot of partial implementation in NXT-G. This program updates the time for minutes and hours only (not for seconds) and fills the complete display.

Figure 7.1. Partial Implementation of Preceding Code, in NXT-G

We will use another example to clarify this concept and introduce other tips. Say your robot has been designed to follow a black line, detect small obstacles with a bumper, and remove them from its path by pushing the obstacles away with some kind of arm. As we explained earlier, it’s impossible to write a program without having a precise idea of how the robot is designed and what it is expected to do. For the example we are going to illustrate, we made the following assumptions about the robot and the environment:

Here is the initial code you should write:

int floor ;

int line;



task main()
{

  Initialize() ;

  Calibrate () ;

  Go_Straight () ;



  while(true)    // repeat the follow code block forever
  {

    Check_Bumper () ;

    Follow Line() ;
  }
}

The main level of your program is quite simple, because at this point you’re not concerned with what Go_Straight or the other functions mean in terms of actions. You’re only concerned with the logic that connects the different situations. You are deciding the rules that affect the general behavior of the robot and you don’t want to get into the details of how it can actually go straight. This result is achieved by encapsulating the instructions that make your robot go straight into a function, a small unit which “knows” what the robot requires in order to go straight. This approach has another important advantage:Your code will be more general because it doesn’t depend on the architecture of the robot. For example, for one specific robot, “go straight” will mean switching motors A and C on in the forward direction, whereas for another it might mean switching on motor B in the reverse direction. When you want to adapt the program to a different architecture, you simply change the implementation details contained in the low-level subroutines, without having to intervene on the logic flow.

Let’s come back to your main task to examine it in deeper detail. The first instruction is actually placed before the beginning of the task: It declares that you are going to use two variables, named floor and line and intended to contain integer numbers. A variable is like a box with a name written on it:You can place something inside; say, a specific number—that is, you can assign a value to the variable. Or you can watch what’s inside the box, reading the variable. At this stage, you are neither assigning nor reading the variables; you are simply declaring that you need two of them. In other words, you are asking RobotC to prepare two boxes with the names just mentioned.

When the user starts the program on the NXT, the main task begins. After it has completed initialization and calibration procedures, the program starts the robot in straight motion, and then enters an endless loop where the program continuously manages its two tasks: removing obstacles and following the line. The while(true) statement repeats all the instructions delimited by the open and close braces forever. In your case, it will execute the Check_Bumper subroutine, then Follow_line, then Check_Bumper again, in a continuous loop, that only the user can interrupt using the Exit button.

Everything is clear and simple, as it should be. Now let’s have a look at what happens at a lower level in our subroutines.

Any program will typically include an initialization section, where you set the motor power, configure the sensors, reset timers and counters, and initialize variables. This is not required when you use NXT code, because it automatically configures the input ports for you. RobotC, like the other textual environments, requires that you explicitly declare what kind of sensor you connect to each port:

void Initialize()
{

  SensorType[Sl]   = sensorTouch;

  SensorType[S2]   = sensorLightActive;
}

The word void is what tells RobotC that you are describing a subroutine, and it’s followed by the name you choose for it. The SensorType statements are used to configure input port SI for a touch sensor and input port S2 for a light sensor.

The calibration routine is designed to inform your robot of the actual light readings it should expect on its path. We discussed this topic briefly in Chapter 4, explaining that keeping your program independent from particular cases is a good general programming practice. In this example, it means you should not write the light sensor thresholds into the code, but rather give your robot the possibility to read them from the environment, and this is what you have declared the floor and line variables for.

void WaitBumperPress()
{

  PlaySound (soundBeepBeep) ;
  while (SensorValue[Sl] ==  0) ;  // wait for bumper press
  while (SensorValue[Sl] ==  i) ;  // wait for bumper release

}



void Calibrate()
{

  WaitBumperPress();
  floor = SensorValue[S2]  ;
  WaitBumperPress();
  line = SensorValue[S2]  ;


  WaitBumperPress ( ) ;
}

This code shows that in some situations you can recycle a sensor and use it for more than a single purpose: During the calibration process, the bumper is used as a trigger to tell the robot that it’s time to read a value. It also shows that subroutines can be nested. In other words, you can make a subroutine call another subroutine. In this particular case, WaitBumperPress is a small service subroutine that produces a beep and then waits until the bumper switch gets pressed and released.

When you run the program, the calibration procedure begins and informs you with a beep that it waits for the first reading. You place your robot with the light sensor on the floor, far from the line, and push the bumper. The program reads the light sensor and stores that value as a typical “floor” value in the floor variable. Then it beeps again while waiting to read the line. You place the robot with the sensor just over the line and push the bumper again, making it detect the “line” light value and store it in the line variable. The robot finally beeps again, meaning the calibration process has finished and that the next push on the bumper will put it in motion.

This sort of prerun phase is quite useful in many other situations, such as when you need to prepare the robot for operations by either reading some environment variable or resetting mechanisms that might have been left in an unknown state by previous executions.

The Check_Bumper procedure is in charge of testing whether the robot has hit an obstacle, and if so, how it should react:

void Check_Bumper ()
{

  if (SensorValue[Sl]   == I)
  {

    Stop () ;
    Remove Obstacle() ;
    Go_Straight () ;
  }
}

It checks the bumper, and, if found closed, stops the robot, calls the Remove_Obstade subroutine to clear the path, and then resumes motion. Testing the bumper is as simple as checking whether Si has become equal to 1, which means that the touch sensor connected to port 1 has been pressed. You notice that we apply here the same concepts used at the main level: encapsulating details into routines at a lower level.

The Follow_Line routine is what keeps your robot close to the line edge—let’s say the left edge. If the light sensor reads too much of the “floor” value, it turns right toward the line. If, on the contrary, it reads too much of the “line” value, it turns left, away from the line (see Chapter 4 for a discussion of this method).

void Follow_Line()
{

  const int SENSITIVITY = 5;



  if (SensorValue[S2]   <= (floor + SENSITIVITY))
    Turn_Right  () ;
  else if (SensorValue[S2]   >= (line - SENSITIVITY))
    Turn_Left() ;
  else
    Go_Straight () ;
}

The method used in this subroutine deserves some explanation. First of all, const int SENSITIVITY = 5; tells RobotC that the variable SENSITIVITY is a constant (const) value that cannot be modified. It is used together with the floor and line variables to decide what the robot should do. An example with actual numbers can make things clearer. Suppose the Calibrate routine placed the value 55 in the floor variable and the value 75 in the line variable. The program tests whether S1 is less than or equal to floor + SENSITIVITY, which results in 55 + 5 = 60, to decide whether the robot has to turn right toward the line. Similarly, it tests whether sensor S2 is greater than or equal to floor - SENSITIVITY, which corresponds to 75 - 5 = 70, and if this is the case, it makes the robot turn left, away from the line. While the readings remain greater than 60 and lower than 70, the robot goes straight. You can change the value of SENSITIVITY to make your robot more or less reactive to readings: An increase will narrow the range of values that allow the robot to go straight; thus, your robot will make more corrections in order to remain close to the edge of the line.

The code you wrote so far is rather general and could work for a broad class of robots. Now the time has come to write the part of the program that depends on the physical architecture of your robot.

The Go_Straight routine will be very straightforward in most cases. You know from the initial assumptions that the robot has two side wheels (or tracks) driven by two independent motors. In Chapter 9, we will explore this configuration, called differential drive, in greater detail. For the moment, let’s stick to the fact that if both motors go forward, the robot goes forward and straight. If one of the motors stops, the robot turns toward the side of the stationary wheel. This knowledge is enough to write the following routines, which control motion:

void Go Straight()

{

  motor[motorA]   =  50;    // Motor forward at 50% of full power
  motor[motorC]   =  50;    // Motor forward at 50% of full power

}

void Stop()
{

   motor  [motorA]  =   0;    // Turn  motor  off

   motor  [motorC]  =   0;    // Turn  motor  off
}


void Turn Left()
{

  motor[motorA]   =   0;    // Turn   motor  off
  motor[motorC]   =  50;     //  Motor  forward at 50% of full power
}


void Turn Right()
{

  motor[motorA]   =  50;     //  Motor  forward at 50% of full power
  motor[motorC]   =   0;    // Turn   motor  off
}

There’s one last routine left: Remove_Obstacle. Let’s say your robot features a very simple arm that works with a single motor and requires only a timed activation:

void Remove_Obstacle()
{
  motor[motorB]   =   50;   // Motor forward at 50% of full power
  waitlMsec(2000) ;         // Wait 2000 milliseconds or 2 seconds.
  motor[motorB]   =  -50;   // Negative value reverse motor at 50% of full power.
  waitlMsec (2000) ;
  motor [motorB] =    0 ;   // Turn motor off
}

The statement waitiMsec(2000) makes the program wait for 2,000 thousands of a second, or two seconds. This parameter depends on the time your mechanism needs to remove the obstacle, and it is once again related to the physical structure of the robot.

Your program is now finished and ready to be tested. We hope this example made you realize the benefits of modular and well-structured code. This program is included with the RobotC distribution as the sample program NXT FollowAndAvoid.c.