Monday, September 25, 2017
Home » How To's » Programming Solutions for the LEGO Mindstorms NXT – Which approach is best for you? (Part 2)

Programming Solutions for the LEGO Mindstorms NXT – Which approach is best for you? (Part 2)

<p >Programming Solutions for the LEGO Mindstorms NXT <p >Which approach is best for you?

Page two
<< Back   1 | 2


It often takes longer to debug a program, i.e., to find and correct errors, than it initially took to write it. ROBOTC and NXC are the only solutions that have an interactive, PC-based, real-time debugger which dramatically reduces the debugging time.

ROBOTC debugger in action. Single stepping of a program is under way and is about to execute line 132 in the source file. The Program Debug window contains the commands to step through the program. The NXT Remote Screen is similar to Windows remote desktop. It remotes the NXT LCD onto a PC window and allows you to simulate key presses with the PC mouse. And it works great over the Bluetooth wireless network.

Traditionally it is difficult to debug (i.e. find and correct errors) programs for an embedded system. The development process is a repeated cycle of:

  1. Modify program source code on the PC.
  2. Compile and link your program on the PC.
  3. Download the linked or executable version of your program to the embedded system (i.e. the NXT).
  4. Run or execute your program and hope it works.
  5. Upon failure, determine what went wrong and return to step 1.

Its difficult to examine the state of your program as it is executing because theres little or no visibility from the PC into the operation of the NXT CPU which is executing millions of instructions per second.

In an enterprise environment you would typically utilize an add-on hardware debugger that attaches between the NXTs circuit board and your PC. This hardware debugger provides low-level control and access over the CPU and memory. A typical device is shown in the picture to the right.

The average hobbyist will not use a hardware debugger! They wont want to cut open the plastic case of the NXT and solder the connector for the hardware debugger to the circuit board. Nor will they purchase the hardware debugger which, in the above diagram, is an industry standard JTAG debugger from IAR systems.

So, for basic debugging, the hobbyist must resort to simple techniques.

  • To determine if your program is executing the intended logic you insert code in your program to play different tones/sounds as different sections of code are executed. You listen to the sounds that are played to give you some indication of what parts of your program are being executed.
  • Alternatively, you modify your program to display progress and debugging information on the NXT LCD screen and watch the output to determine how your program is executing. However, watching the LCD screen can be challenging if your robot is moving position as it is running.
  • If you guess wrong on where to modify your program then you have redo to examine different sections of your program code.
  • When complete, you then remove the modifications for debugging.

The development systems for the NXT generate instructions for an intermediate virtual machine (VM) rather than direct instructions for the NXT CPU. When you run a program on the NXT, a VM interpreter application within the NXT firmware begins interpreting the intermediate instructions of your program. Adding some extra capabilities in the VM “ e.g. suspend and resume the interpretation “ can provide debugging functionality without the need for an external hardware module. Each programming solution for the NXT has different definition of its VM. ROBOTC is the only solution that has debugging functionality fully integrated into the VM interpreter.

The NXC programming environment also has a software based debugger. It uses a different implementation approach. Debugging functionality is not integrated into the VM. Instead the NXC compiler, transparently to the end user, generates additional debug related instructions for each line of source code. Programs execute slower with the debugger active.

The ROBOTC solution is full featured and provides capabilities comparable to the professional hardware debuggers.  An integrated debugger eliminates the need to manually add code for debugging to your program. A debugger provides better functionality to the techniques discussed above without modifying your source code!

An effective PC-based real-time debugging capability has the potential to significantly reduce the time it takes to find and correct errors in your programs. With a good debugger for the NXT you can:

  • Use either USB or Bluetooth (BT) for communications with the NXT. The wireless BT link is preferred because it can be pretty tough to test in real-time a moving robot if it is tethered to the PC via a USB cable!
  • Start and stop your robots program execution from the PC.
  • Suspend and resume execution in the middle of your program execution.
  • Single step through your program executing one line of code at a time and examining the results (i.e. the values of variables) and the flow of execution.
  • Define breakpoints in your code that will cause program execution to be suspended when they are reached during program execution
  • Read and write the values any of the variables defined in your program
  • Read and write the values of motors and sensors.
  • Be in-obtrusive. The debugger should not impact the performance (i.e. speed of execution) of your program

The following picture illustrates some of the ROBOTC debugging windows during an interactive debugging session.

Note: To minimize the size of the picture, the two debugger windows in the above picture were positioned on top of the main ROBOTC window. This is not a requirement. They can be positioned anywhere on the PC desktop.

Four debugger capabilities are shown in the above picture. Each of these is highlighted in the following picture.

Debugger Controls This is the main debugger window for controlling user program execution
Current Execution Point The yellow left arrow indicates the next line of source code to be executed in the program. Yellow is used to indicate that program execution is currently suspended. Green is used when the program is free running.
User Defined Breakpoint The red stop sign indicates a user defined break point. Program execution will be suspended if this line of code is reached during program execution. Breakpoints are easily defined by left-clicking in the gray column corresponding to the desired breakpoint.
Variable Display This is a display of all the variables that are defined in your program. The values are periodically retrieved from your robot and displayed here. If desired you can select a variable and rewrite its value.

Debugger Controls

This is the main debugger window for controlling user program execution. The buttons on this window allow you to start/stop, suspend/resume program execution. Other buttons allow you to control the rate at which information from your robot is refreshed.

The names of the buttons change based on the state of your program execution. For example Start is shown if no program is running and Stop is displayed when a program is executing.

Each of the buttons is described in the following table.

Start / Stop Starts or stops the execution of a program
Suspend / Resume Temporarily suspends (or resumes) the execution of your program.
Step Causes a suspended program to execute the next line of code in your program. Note: Some complicated lines of code, especially code lines that cause a break in sequential program execution like a for or while clause may only be partially executed by a single Step command.
Once Will trigger a single refresh of the debugger windows. It also stops continuous refresh of the debugger windows.
Continuous / Stop Starts or stops continuous refresh of the debugger windows.

User Defined Breakpoints

Break points are locations in your source code where program execution can be interrupted for manual intervention.

The red stop sign indicates a user defined break point. Program execution will be suspended if this line of code is reached during program execution. Breakpoints are easily defined by left-clicking in the gray column on the source code line corresponding to the desired breakpoint.

ROBOTC breakpoints do not impact the speed with which your program executes. The breakpoint capability is built-into the ROBOTC firmware and does not require insertion of extra instructions in your compiled code.

You can define (virtually) unlimited breakpoints within your program. There are no restrictions on the number of breakpoints within a single function or task.

Changing Flow of Program Execution

Sometime during debugging you may want to alter the normal flow of program execution. If you right-click instead of left-clicking with the mouse a pop-up menu appears. One of the commands is Set Next Instruction which allows you to change the currently executing point of your program to this selected line! The pop-up menu is shown in the picture below.

This picture shows the Debugger Windows available for the NXT platform in ROBOTC.

Debugger Displays
There are several different debugger windows that can be used when the ROBOTC debugger is operational. These windows give access to user program and built-in variables. Some of the windows are infrequently used but can be useful when needed. Debugging windows can be opened from the sub-menu shown in the following picture.
Other robot platforms may have a different list of windows customized to the robot controller hardware. The number of available windows is also impacted by the Menu Level setting found on the Window sub-menu. In the basic mode, some of the more advanced and less-frequently used windows are not available.
Several of these windows are shown below.

This window contains a table of all the variables declared in your program along with their current values. If needed, you can select and change the value of any variables.

ROBOTC has several built-in variables that customize the performance of your robot. The System Parameters window provides PC access to these variables. This example is for the NXT robot controller.
This debugging window is only available on the NXT robot platform.The remote screen allows you to control your NXT from your PC. It provides an image of the NXT LCD screen. A mouse press over one of the four buttons will simulate a key press; or you can use one of the four arrow keys on your PC keyboard.  

Of course, all of these variables, above-right, are directly accessible within your program code.
Although not usually needed, the advanced user may find a few of these fields particularly interesting. For example:
avgBackgroundTime is the overhead time spent in the device driver code. The remaining CPU time is available for user program execution. This example shows background overhead at 13%.
bNoPowerDownOnACAdaptor is a neat variable to prevent the NXT from automatically powering down if a rechargeable battery is being used and it is connected to AC power.
This is the devices debugging window for the NXT robot controller platform. Different versions of the screen are available for other platforms supported by ROBOTC.

The above-right screen provides access to current values for the motors and sensors on the NXT.

The More button expands the window to provide controls that enable you to write to the sensors and motors to setup their initial configuration.
There are no restrictions on the number of debugger windows that can be simultaneously opened. However, each window does require the PC to message with the robot controller to refresh its data. The more windows that are open the more data transmission required for the refreshing activity.
ROBOTC has been optimized to minimize refresh times. Typically only one or two messages are required to refresh each window; this is valuable on the robot controllers that have a slow communications channel between the robot and the PC.
For example, Bluetooth messaging on the NXT platform is slow, taking about 25 milliseconds per message. Out of the box, NXT Bluetooth messages are restricted to 58 bytes of data and 13 messages are required to refresh the 800 byte NXT LCD image. The ROBOTC enhanced firmware performs only requires a single message.
Three key capabilities differentiate ROBOTCs debugger. Single step mode is built into the firmware and does not require the extra CPU cycles required of solutions that use extra instructions automatically inserted by the compiler to implement single stepping. A debugger requires high bandwidth on the PC-NXT link to provide fast user response; ROBOTCs debugger is integrated with the IDE so that any or all debugging screens can be open at one time.
NXT-G is likely a good choice for a graphical programming solution. ROBOTC is a good, text-based programming solution. If you dont need the full power of ROBOTC or want an open source solution and already have programming experience, NXC is another choice for you. pbLua and NXJ show promise but are not currently mature enough or sufficiently full-featured for most users.
Author Dick Swan is an avid LEGO robotics fan. He is also one of the principal developers of the ROBOTC system and co-developer of the ROBOLAB extensions for the NXT.
LEGO Mindstorms retail,
LEGO Education, 
National Instruments NXT-G Programming,
NXJ JAVA for the NXT,
NXC Programming Language,
pbLUA for the NXT,
ROBOLAB graphical programming, or pagename=robolab
Robotics Academy ROBOTC,

Back   1 | 2

Words by Dick Swan