bNXT Blog

Everything about RobotC

I'm super excited about RobotC. It is a commercial product, but it is reasonably priced and the product creators seem driven to solve every issue reported on this and other blogs so far (and much more). Great features include real debugging tools showing the robot internal runtime status on the PC screen while the software runs (a first for the NXT!), faster running code, more efficient memory usage, better access to internal sensors like the battery level, better multi-tasking, and much more. Find out everything there is to know about RobotC in this Q&A with Dick Swan:

RobotC will be commercially available in August 2006.

Pricing is currently being finalized. Price for a single user license for NXT will be in the $20 to $30 range.

RobotC works on many platforms. There may be some minor pricing differences between the different platforms and between the educational vs. hobbyist packages. Some platforms also require programming cables/adaptors that increase the price.

A 30-day full-featured trial version will be available for "try before you buy" use.

RobotC is a cross-platform solution. It currently supports five different robotics controllers including the RCX and NXT from Lego and the VEX controller from Innovation First. Support for additional popular robotics controllers is planned.

RobotC operates on a Microsoft Windows XP platform. Support for Apple platforms is planned for the future.

The primary market focus is the educational market. RobotC was designed as a teaching tool suitable for both new and skilled programmers. It includes a high level of educational support functionality. RobotC will be particularly appealing to teachers that are using multiple platforms to teach robotics because their students, new programmers, will be able to use the same programming environment as they progress over time from one robotic system to another.

However, the capabilities of RobotC fit not only introductory users but also more advanced users. So RobotC also targets the retail / consumer segment that is primarily interested in a text based programming system rather than a graphical interface.

There are non-overlapping market segments that fit both the open source and commercial solutions. RobotC targets a completely different demographic with the educational segment. This market needs a large surrounding infrastructure – educational and curriculum tools – that is not traditional available in open source solutions.

RobotC also targets the consumer/retail market where it will eventually compete with emerging open source alternatives. RobotC can only succeed in this market if it delivers superior value and features at an attractive price so that it can favorably "compete" with the freeware options.

Some of the key differentiators of RobotC include:

A strong customer support infrastructure including.

• Dedicated full-time support staff.
• An eMail based "help" desk available to all users. Phone line support is planned for premium educational users.
• FAQ
• Web-based trouble reporting and resolution system.

Interactive PC based real-time debugging via standard BT or USB connection. Hardware JTAG capability is not required for the debugger! The debugging capability has features comparable to professional grade development systems. This includes user defined breakpoints, execution start/stop/suspend/resume, execution trace, single step operation, 'watch' windows to monitor user defined variables, ASSERT macros, etc. The availability of the debugger dramatically reduces program debug times.

A nearly complete C implementation. This includes many of the C capabilities traditionally missing from classical "Tiny C" implementations; includes support for standard C functions like:

• struct support. [In next release]
• typedefs – for both enum and user defined variable types.
• function overloads and prototypes.
• short, long and float variables. Char / byte variables are in development for next release.
• Pointers are not currently supported. This is probably the biggest differentiator from standard C.

A large existing and growing base of supporting material developed by the Robotics Academy at Carnegie-Mellon University.

• Tutorials. Step-by-step walkthroughs.
• How-to videos.
• Large and expanding base of educational curriculum materials.
• A growing base of sample programs.
• College in the high school accredited programming course

A large segment of the RobotC users may be "beginners" and programming neophytes. RobotC has several features designed with this audience in mind. Including:

• Compiler will optionally accept variables that only differ in letter case. For example, if a variable is declared as "Sensor", then compiler will generate a warning, but accept the typing of "sensor". Of course, if you have two variables declared "Sensor" and "sensor" this feature will only accept accurate spelling.
• Compiler has stronger type checking functionality than found in standard C. Many of the built-in variable are declared via "enum" typedefs so obvious errors can be caught at compile time. For example, the statement "SensorMode[sensor1] = sensorLight;" will generate an error message because "sensorLight" is an enum of type "TSensorTypes" whereas the built-in variable "SensorMode" is an enum of type "TSensorModes".
• Powerful code completion and code template capabilities.

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.

The mission of Carnegie Mellon’s Robotics Academy is to use the motivational factors of robotics to excite children about math and science. Robots are engaging to both young and old. New programmers are able to quickly realize the fruits of their work by seeing their robot move; this is far more exciting to kids than seeing the text "hello world". Robotics also is able to teach fundamental math concepts that are at the foundation of all technology. I guess I’m trying to say "robots make programming fun!"

RobotC is an interpretative VM solution. The advantages of this have been explained in the above question.

End user feedback has indicated that one of the most complicated items in writing programs for a robot is properly configuring the motors and sensors; especially when there are multiple types and modes to setup. The new motors are just as complicated – the NXT firmware has five different software registers per motor that are used to accumulate counts from the integrated encoder. The two graphical programming systems for the Mindstorms (NXT-G and Robolab) both "solve" this problem by deducing the configuration from the graphical programming blocks and then internally generating the appropriate setup commands for the motors and sensors. RobotC has recognized this issue and has an optional configuration wizard that provides a PC-based graphical setup (fill in a series of forms) for the motor and sensor configuration.

RobotC has powerful and intuitive debugging facilities to trace and monitor the execution flow of a user program. These are especially powerful when coupled with BT messaging as you can completely monitor, and alter, program flow and execution on an un-tethered NXT robot. This dramatically reduces program debugging time.

There are several information LCD screens built-in into the RobotC firmware to monitor the motor and sensor status of an operating robot. These are invoked through the NXT’s left and right buttons during program execution. The value is that these are built-in capabilities; you don’t have to write custom programming to get this information. It even includes a real-graph of recent items added to the datalogging capability.

RobotC has comprehensive code completion and code template functionality.

BT is currently supported for downloading programs and used by the RobotC debugger.

BT messaging for NXT to NXT communications is planned for release later this summer.

RobotC has two existing built-in variables for monitoring the immediate and smoothed battery voltages. The ‘smoothed’ voltage level is the average of several recent battery voltage samples and is designed to eliminate the wild variations (0.5V or more) that occur from interrogating voltage during transient power drains (like the surge from turning on a motor or transmitting a BT message).

RobotC has several other nifty features related to battery voltage.

It detect when the robot controller (RCX or NXT) is operating from an AC adaptor. There is a boolean configuration variable that user can set to prevent the controller from ‘sleeping’ when running on AC adaptor. When operating on battery power, the standard sleep timeout mechanism will be used. This feature is fully tested on the RCX. Obviously, it’s waiting for availability of the NXT rechargeable battery and AC adaptor option before it can be tested on the NXT.

The NXT can perform unpredictably, especially when writing to flash, at low voltage levels that are just above the standard threshold for shutdown. At startup, the RobotC IDE will check the battery level and warn if battery voltage is too low.

On the RCX, the low voltage level used to trigger "forced" sleep is a user programmable field rather than a hard-coded constant. This feature has not yet been implemented for the NXT but is "coming soon".

The starting point for the RobotC firmware was the same standard Lego source code that will be open-sourced. During development of enhanced RobotC capabilities it became necessary to enhance and improve several firmware modules. Some of these subtle advantages are described below.

Standard firmware only supports integer arithmetic. RobotC supports integer and float variables. Automatic type conversion is performed during code generation for mixed mode expressions.

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).

RobotC firmware supports a superset capability of the sound capabilities found in the standard firmware. Expanded features include:

• Firmware supports playback of compressed sound (RSO or "WAV") files. Standard firmware only plays uncompressed files. Compression can significantly reduce the size of sound files stored in the NXT. RobotC supports playback of compressed sound (RSO) files. The large size of sound files is one of the most common concerns about the standard file system. The RobotC IDE can convert a raw uncompressed sound file into a compressed version. Industry standard compression algorithms are used.
• Standard firmware can only play a single sound at a time without any queuing; starting a new sound will abort the current sound. RobotC can queue up to 10 sound "items" for sequential playback. The advantage of RobotC’s implementation is that user programming of sounds is significantly simplified.
• You don’t have to check if the current sound is finished. [For advanced users, RobotC also has built-in variables to check the state of the queue. I’m not sure if sound busy/idle state can be easily checked in the NXT-G system].
• The workaround for NXT-G is an inline program delay to ensure a sound has finished. This can significantly degrade the performance of a robot since, without a complicated multi-threaded program, sensors and motors will not be updated during this delay.

Standard firmware uses a polling mechanism on a hardware register to calculate the system clock. RobotC timing is interrupt based. This has two advantages:

• It improved RobotC real-time performance by over 10%. Standard firmware polls the system clock after every interpreted opcode to determine whether current time slice has expired. This ‘check’ is interrupt based in RobotC.
• Standard firmware is susceptible to dropped timer ticks. RobotC is not. Timer ticks can be dropped when the file system writes to flash memory and the CPU is stalled for the several millisecond duration that this takes. Counts may also be dropped when the internal hardware timer (a partial word value) overflows and wraps around.

RobotC firmware has deterministic delays. Standard firmware performs periodic garbage collection. The delay for garbage collection is of an unknown duration?

RobotC is an optimizing compiler. It eliminates dead code, collapses common code, optimizes branches, eliminates run-time constant expression evaluations, etc.

RobotC is extremely efficient for ‘switch’ implementation with a single opcode for the switch calculation. Classical "Tiny C" implementations either fail to support ‘switch’ statements (e.g. InteractiveC) or implement them as a series of nested ‘if..then..else..’ clauses.

RobotC has an enhanced device driver for sending I2C messages to new 3^rd party developed digital sensors. The Lego SONAR sensor is a digital sensor that communicates over industry standard I2C bus. There are many new 3rd party sensors announced from a variety of vendors. The standard firmware I2C device driver works well (perfectly) with the SONAR sensor. However, many of the newer sensors will utilize multi-byte byte (vs. single for the SONAR) messages operating at a faster rate. RobotC performs I2C messaging two to five times faster than standard firmware.

Standard firmware (currently) does not have a ‘wait’ function. The "work around" is to use a code loop that checks to see if elapsed timer has reached the desired value. In a multi-threading program this is extremely wasteful of CPU real time. RobotC has a "wait" function that will suspend running task/thread until timer has expired and not consume CPU cycles.

The RobotC firmware has more comprehensive error detection and recovery function. It checks for over 50 different run-time exception conditions (stack overflow, array bounds checks, etc).

RobotC firmware tends to have more functionality native in the firmware rather than implemented as sequences of interpreted opcodes. For example:

• When changing the configuration of a sensor it can take 10 to 100s of milliseconds before the sensor stabilizes and its value can be read. Firmware maintains a flag that end user programs should check to determine if the sensor values are valid. This checking is integrated into RobotC firswmare.

All threads in standard firmware have a single priority. RobotC implements configurable priority per thread/task for the advanced user.

A comprehensive real-time data logging capability is available now on RobotC. Datalogging is not a feature of the current standard firmware.

RobotC has multiple built-in LCD screens available to an running program to display the current sensor and motor values and status. You can provide similar capabilities with the NXT-G system, but it would have to be a fairly long user written programs.

RobotC has absolutely the best support for 3^rd party sensors. Support for new sensors/motors and for multiplexers were day one design requirements for RobotC. Testing of a variety of commercial sensors with RobotC has been ongoing over the last six months.

A "how to easily implement new sensors" SDK is planned for release soon.

The faster performance of RobotC’s I2C messaging is important for new sensors that have more complicated messaging than the sonar sensor. Minimize delays is important for squeezing the best performance from a user program/robot.

RobotC has native support for sensor and motor multiplexers.

• Sensor values and motor power settings are accessed in RobotC through the arrays "Sensor[index] and Motor[index]. Normally the sizes of these arrays are four (sensors) and three (motors). However, RobotC has support for "virtual" devices outside of these bounds. Consider the case of a four-port motor multiplexer.
• Array elements 0..2 of the ‘Motor’ array are for the NXT’s internal three motor ports.
• Array elements 3..6 can be assigned to the ports on the motor multiplexer.
• Within a user program, he can refer to any of the seven motors via the ‘Motor’ array. It is transparent to the program whether motor is one of the internal motors or connected via the MUX.

Of course, this requires a device driver for the motor MUX. This can be easily written as a separate RobotC task stored in a "#include" file that is embedded in the user’s program when motor MUX functionality is required. The existing MUX driver file is currently about 200 lines of heavily commented code generating under 500 bytes of compiled code.

• A similar approach is implemented for sensor MUXes.
• Sample driver files for popular MUXes are planned in upcoming RobotC release.

This same technique is used to easily implement drivers for new 3rd party sensors. The sensor vendor can provide a small device driver program that is easily included in an end user program. The driver is written in RobotC code and could be customized by end user if he wishes. The device can then be seamlessly integrated.

Currently these driver files are manually "#included" in an end user program. A future enhancement is planned that will automatically include them as required when a user program uses one of the 3rd party devices; the basic infrastructure – support for "#include" files and conditional compilation – are already fully operational and this enhancement is a small incremental step.

Carnegie Mellon University’s Robotics Institute is arguably the largest robotics research organization in the world. In 1999, the Robotics Institute started an outreach named the Robotics Academy which quickly became known for the robotics educational support materials they produced for both traditional and nontraditional education.

As mentioned before, the Robotics Academy’s mission is to use the motivational affects of robots to excite children about math and science. When I was approached to be part of this exciting education project I was excited about making a contribution to education doing what I love to do, which is program.

posted by Filip @ Thursday, August 03, 2006