Thursday, August 31, 2006

Programming HiTechnic’s NXT Compass

As I explained before, HiTechnic, in close collaboration with LEGO, has announced the first sensor to be available on the market: a digital compass. HiTechnic sent it over to bNXT, so we put it on our test bench.

Before you start to play with the sensor, be sure you have upgraded your LEGO Firmware on the NXT Intelligent Brick to version 1.03 or higher. Back in June, I warned against doing that, but most problems appear now to be resolved. Version 1.01 has bugs related to the I2C communication, which means it has problems with some digital sensors like HiTechnic’s new compass. To upgrade your firmware, simply open NXT-G on your PC, choose Tools, and Update NXT Firmware. Version 1.03 ships with NXT-G, so you simply select and download it to your NXT Brick.

As a first test, I decided to replicate Jim’s Compass program, which does nothing but show the value of the sensor on the screen. Here’s what the core of the software looks like looks like (this part originally written by Jim):



You can download my code here. As you can see, I’m using it as an Ultrasonic sensor. That’s because the Ultrasonic sensor is the only digital sensor that comes with the LEGO MINDSTORMS NXT set. In the near future, HiTechnic will provide me with a custom NXT-G Compass Brick that exposes the full functionality. But for now, I’m just starting to explore the basic features of the sensor.

Having seen that the sensor works great, I wanted to make the most obvious demonstration: have the robot look at the same direction while the surface under the robot moves. Here’s a movie of my robot in action:



Since I used the TriBot, it should be easy to achieve the same behavior on your own robot. Here is the code for the robot in the movie. And here’s an image of the code:



Notice that in this code I first do the initialization, and then tell the other loops that they can now start the correcting behavior. But as I started to write up my experience with the sensor, something truly terrible happened: I noticed that Brian Davis has a much more elegant way to achieving the same thing. Here is the program he proposed (written by Brian):

Brian’s code


This is a truly beautiful piece of software. Here's how it looks in action:



One drawback of Brian’s code as published is that it never quite achieves zero. As soon as the power drops to below 8 or so, the robot no longer turns, but the motors are still trying to move. They just don’t overcome friction. This motor behavior prabably drains the batteries faster than the more complicated code I wrote. But it's a problem that is easy to remedy. Here is the code for Brian's approach.

Next up: A more useful application of the compass sensor.

Is it HiTechnic or Lego?

To paraphrase the Belgian Surrealist René Magritte: Ceci n’est pas une brique LEGO! (this is not a LEGO brick).

It is the new compass sensor by HiTechnic, that I obtained from them for testing. I’ll be writing about that in my next posts. But take a good look at these pictures. It looks like a Lego brick, the plastic feels like a Lego brick. I have tested the sensor, and I can confirm it works like a Lego brick. And it will sell via Lego@Home. Can you find the difference between a HiTechnic and a LEGO brick?



Deep Collaboration

As you can see from the images, LEGO and HiTechnic are doing something unique here: HiTechnic selects the NXT sensor/multiplexer/... bricks they feel the set is missing the most. They do all of the research and development to prototype the selected NXT brick. Up to this point, things are very similar to the way they were in the past, and still are with some other suppliers. But then something unique happens: LEGO provides HiTechnic with NXT plastic parts, it certifies the HiTechnic brick, and then helps HiTechnic to sell the brick.

So LEGO actually supplies the housing, the connectors, etceteras, to HiTechnic. HiTechnic "only" needs to produce the parts that are unique to their sensor. In the case of the compass, this is the black cap on the front, and off course the electronics inside. When I say "only", remember that the parts must match the LEGO system exactly, and that HiTechnic needs to mold the plastic to the high (child-friendly) standards of LEGO. Since molding high-quality plastic is only financially efficient when making few ten thousand or more units, this must represent a large investment on HiTechnic's side. And off course the electronics must behave just like the user would naturally assume they work, it must be electrically safe, etceteras. So the R&D needs to be well-done before before releasing parts. So that's a very relative "only".

But from an operational point of view, HiTechnic has effectively become a part of LEGO: they get components from LEGO and internal resources, assemble them, and return them to LEGO for sale at Lego@Home (you can also buy them worldwide from HiTechnic's website).

HiTechnic anticipates that it will be releasing new sensors (or other NXT electronics parts) every couple of months, and every new sensor will be jointly launched by LEGO and HiTechnic.

Color Coding

The compass in the pictures is a production model, exactly they way you'll be able to buy it soon. For this compass sensors, HiTechnic needed to produce custom end caps. Since the compass sensor does not have external parts, a closed cap does the trick.

HiTechnic plans more sensors without external parts. If they all looked the same, you would have a hard time finding the right sensor in your sensor collection. To avoid this problem, HiTechnic has said they will color-code the sensors: different sensors will have different end cap colors, when the end caps are the same for various sensors.

Everyone wins

The new HiTecnic Lego brick adds value to my NXT set, and I believe sensors like these will bring more people to buy the LEGO MINDSTORMS NXT set. Users will have a wider range of sensors to build robots with. So everyone wins.

Tuesday, August 29, 2006

Welcome to The Mindstorms NXT Review, update RSS locations

Welcome to Jacool and The Mindstorms NXT Review.

I added Jacool's blog to the bNXT's Aggregated News Feed.

By the way, I also radically simplified the locations of the feed files. Here is the list of feed files currently available:

http://bNXT.com/blog/atom.xml

http://bNXT.com/news/EN/atom.xml
http://bNXT.com/news/EN/feed.rss
http://bNXT.com/news/ES/atom.xml
http://bNXT.com/news/ES/feed.rss
http://bNXT.com/news/DE/atom.xml
http://bNXT.com/news/DE/feed.rss
http://bNXT.com/news/PT/atom.xml
http://bNXT.com/news/PT/feed.rss
http://bNXT.com/news/NL/atom.xml
http://bNXT.com/news/NL/feed.rss

Please update the feeds you are using accordingly.

Monday, August 28, 2006

Japanese & Chinese Help Wanted

I came across NXT articles in Japanese and Chinese. At least, I think they are NXT articles. It will come as no surprise that I didn't have the faintest idea what the text was saying, except for words like “Lego”, “Mindstorms” and “NXT”. Nevertheless, these languages are important when it comes to the robotics user base.

I'd like to provide aggregate feeds in Japanese and Chinese, in much the same way as I currently provide them for English, Dutch, German, Portuguese and Spanish. But I need the help of native speakers in Japanese and Chinese, to help me collect these links. I just need some info on the content of the blogs, and on how to translate a few English words to the respective languages. Chinese or Japanese NXT enthusiasts willing to help, please contact me at filip@bnxt.com. Thanks.

If there are any NXT blogs in still other languages, let me know!

HiTechnic Becomes Official Lego Supplier

LEGO announced they have been working this year with HiTechnic to pilot a new 3rd party developer program where HiTechnic will produce a range of LEGO certified sensors for the NXT. Our colleagues from NXTasy captured a video of the announcement.

Lego has set up an official Certification Program to ensure the sensors meet their high standards. As a result, parents, teachers, researchers and every user can be sure that these components will work just as you expect them to (something that is usually harder to do than it would appear).

Getting these components anywhere in the world will be easy too: Lego’s online shop will sell the third party components, and HiTechnic also ships them directly from their own site. The production versions of HiTechnic’s sensors really look and feel like ordinary Lego, which I think is a great plus.

HiTechnic will supply custom brick software to add the sensor blocks to the NXT-G graphical programming environment that comes with the Lego Mindstorms NXT set. So you’ll be able to select their sensor from the sensor palette in you graphical environment, and use its properties directly. In addition, the sensors work well with NBC and RobotC.

The new third-party robot sensors look the same, they act the same, and you buy them in the same place. That's as close to real Lego as you can get. HiTechnic has effectively become a officially supplier for Lego, but instead of working to meet Lego's demands, they get to decide for themselves what to build when. It is only natural that Lego wants to certify that the parts meet their quality standards. A big "thumbs up" for Lego, who's really doing something unique and without precedent here.

Clearly, doing that takes a large investment from companies like HiTechnic (not in the least to mold plastic for their own Lego bricks). They are making a big bet, and congratualations for doing so! I can’t imagine that they go through all that effort to provide just one or two components. Expect a continuous flow of new and improved sensors as time goes by. Robot builders may soon have a wide range of sensors and other components to choose from.

Because of the ease of building robots from Lego Technic bricks, and the amount and diversity of robot parts available, I believe Lego will be(come) the best platform to learn and explore new robot designs. That’s why I believe academic and industrial users will also start to use Lego as their platform to test their research. I hope a lot of them will choose the (re)publish their papers on bNXT, for all of us to use.

Friday, August 25, 2006

Brickfest 2006

Brickfest 2006 starts today in Washington D.C. It runs all the way till Sunday evening.

This is the first Brickfest since the launch of NXT. I expect some announcements will be made about the NXT future. Admission fees to Brickfest are very low, but you have to get in washington D.C.

This year, I won't be able to make it, so I need your help. If you intend to go, keep me posted on the latest announcements and I will put your information online. If anybody has a MP3 recorder with him, and the recording is of reasonable quality, I'd be happy to host the recording of the keynote on Saturday morning, as well as recordings of other interesting NXT-related stuff.

Have fun at Brickfest!

Friday, August 18, 2006

Call for Papers, Jeff Owrey joins bNXT

Jeff has agreed to publish his papers on bNXT. In the menu above this page, you'll find the first papers, in the section "Learn NXT".

Papers are a great way to exchange research, and to publish work. Papers provide more in-depth information than blog articles. They also refer to prior work whenever possible. Papers are well known in the academic world, and we want to invite everyone in the academic community who does research using NXT, to (re)publish their papers here.

However, every good paper will be allowed. No academic degrees are required, only the quality of the paper matters.

By publishing these papers on bNXT, I hope they'll be easier to discover, and easier to keep them available for the future.

You are hereby formally invited to submit papers!

UPDATE: Both students and teachers are encouraged to submit papers.

The Start of the Start

Finally! I've managed to publish the new bNXT website. The main work has been done behind the scenes. The old bNXT site was static (really!), but now it is completely dynamic. This should make it easier to add content.

The objective of bNXT is to move beyond the blog, and provide all sorts of information,, downloads and other stuff that helps you get the most out of your Lego Mindstorms NXT set.

There may still be issues with the website. If you find any, it would be great if you could add them in the comments here. Also, any ideas for the development are welcome.

Thursday, August 03, 2006

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:


Q1: When will RobotC be commercially available?
RobotC will be commercially available in August 2006.
Q2: What is the price for RobotC?

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.

Q3: What platforms does RobotC support?

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.

Q4: What market does RobotC target?

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.

Q5: What is your position on LEGO making the NXT firmware open source? Is that an advantage or disadvantage to you?

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.

Q6: What are the advantages of RobotC compared to the standard NXT programming system? And compared to the emerging freeware programming solutions?

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.
Q7: 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.

Q8: How does RobotC facilitate programming by introductory programmers?

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.

Q9: Is there any Bluetooth (BT) support planned for RobotC for NXT?

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.

Q10: How about internal NXT sensors (like battery)?

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

Q11: Are there any differences in the RobotC firmware when compared to the standard or open source firmware?

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 3rd 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.

Q12: How will RobotC support 3rd party sensors?

RobotC has absolutely the best support for 3rd 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.

Q13: And finally, what is the Robotics Academy and Carnegie-Mellon University and how did you get involved in the effort?

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.

Getting Started with NXT Byte Code (NBC) Programming

NXT Byte Code (NBC) is an “assembly” language that allows to write software directly on the NXT brick. It works with the standard Lego firmware that comes with your NXT set. This means that you can develop some of your programs using the NXT-G graphical environment, and some with NBC. Both software be uploaded independently from each other. However, it isn’t possible (yet?) to include NBC within the NXT-G environment (or vice versa).

NBC is really simple, but documentation on it is still rather scarce. That’s why I decided to write a short tutorial on how to get started with NXT Byte Code programming.

Hello World

Let's start with looking at the first program for any programming language: putting "Hello world" on the screen. In this case, on the screen of the NXT brick. Here's the complete Hello world program:

#include "NXTDefs.h"
// Always include the above

// Segments declare variables or types
dseg segment
  // Variables are always global.
  // Define variable dtArgs of type TDrawText
  dtArgs TDrawText /* see Syscall DrawText docs */
dseg ends

// Code is organized in threads
thread main
  // Set is to store scalar constants
  // For instance, set X location to 1
  // X is a member of the TDrawText struct
  set dtArgs.Location.X, 1
  set dtArgs.Location.Y, 1
  set dtArgs.Options, 1 /* erase previous text */
  // Mov is to copy more complex data
  mov dtArgs.Text, 'Hello World'

  // Write to the screen
  // by calling the Lego firmware

  syscall DrawText, dtArgs

  // Wait forever so the user sees the screen
Endless:
  jmp Endless
endt

So how do we execute this program? The simplest way is to use the Bricx Command Center together with the NXT Byte Code compiler.

BricxCC and NBC Installation

The Bricx Command Center supports Lego Mindstorms NXT, and NBC, and provides an easy to use editor for it. If you prefer to install only NBC, then skip to the “NBC Only Installation” section. If you are using Apple or Linux, then you also need the “NBC only” installation.

First, we need to download the BricxCC software from http://bricxcc.sourceforge.net/test_release.zip. You may want to check http://bricxcc.sourceforge.net for later versions. Download the zip by selecting the “Open” option (or save first, and open it locally). Double click on “BricxCC.exe”. Windows will provide the options “Extract all”, “Run”, or “Cancel”. Choose “Extract all”. Follow the wizard, and choose a directory to install. For this introduction, I’ll use the directory “C:\Program Files \BricxCC”. Notice that the wizard allows you to create new directories as needed. After selecting a directory, the wizard will install BricxCC. When installation is complete, you can close the archive you opened.

Next, download the NBC software from http://bricxcc.sourceforge.net/nbc/. In this introduction, I’ll be using version 0.1.4 b4, dated June 15, 2006/July 26, 2006. Select that beta version, and next select the Win32 version. You can save it locally, and then open it, or open it directly. Double-click on “nbc.exe”. Again, select “Extract all” and use the wizard. Make sure to install NBC in the same directory as BricxCC. So within the wizard, select the “C:\Program Files \BricxCC” directory to install in. At the end, the wizard shows you the content of the BricxCC directory.

You may want to create a shortcut to BricxCC by dragging the BricxCC.exe file to the start menu, and to the location where you want it. For instance, in the Start > Program Files > LEGO MINDSTORMS NXT directory. Feel free to rename the shortcut.

Start BricxCC (any starting options). Define the location of the compiler by selecting “Edit”, “Preferences”, “Compiler”, “NBC”. Set the EXE Path to “C:\Program Files\BricxCC”.

This completes the installation. To run the Hello World program, turn on the NXT and connect it to the PC. Then start the BricxCC software. This time, make sure to select “usb”, “NXT” and “Standard” as starting options. It takes a while for BricxCC to start up due to connection time-outs. Create a new document, and copy following Hello World code in it. Save it. Then press the Run, or select Run from the compilation menu. Now look at the screen of the NXT... You can terminate the program with the grey cancel key on the NXT brick.

NBC Only Installation (command line)

If you prefer not to use BricxCC, then here’s how to install NBC without installing BricxCC. To use NBC later on, you will need to be able to use the command line. If you are working with a Windows PC, and have no experience with DOS commands and the command line, then choose the BricxCC installation option. There is no BricxCC for Apple or Linux, so those users need to install NBC only. I do not own an Apple or use Linux, so I cannot provide installation instructions for those platforms, sorry.

Let’s first download the software from http://bricxcc.sourceforge.net/nbc/. In this introduction, I’ll be using version 0.1.4 b4, dated June 15, 2006/July 26, 2006. Select that beta version, and next you’ll need to select the operating system that you are currently using. I used the Win32 version for this introduction. You can save it locally, and then open it, or open it directly.

After opening the zip, you should see three files: "history.txt", "nbc.exe" and "NXTDefs.h". Double click on "nbc.exe". Then choose the Windows option "Extract all". Next, the NBC "Extraction Wizard" pops up. Click next and choose a directory. The wizard gives you the option to create directories as needed. For this introduction, I’ll use "C:\Program Files\NBC". After selecting a directory, click "Next" again.

Next, you’ll want to add the directory you have just created to the command path. Assuming you are working with Windows XP, go to the "Control Panel" (via "Start"). If you are in classic view, then choose "System". Otherwise, choose "Performance and Maintenance" and then choose "System". Go to the "Advanced" tab, and click the "Environment Variables" button. In the bottom window, scroll and select the "Path" variable. Select "Edit". At the end of the existing variable value, add the text ";C:\Program Files\NBC" (without the quotes – or the directory where you have installed NBC. Don't forget the leading semi-column). Click OK three times and close the control panel.

Your manual installation is now complete.

To run the Hello World program, save it to a file, for instance "bNXT_HelloWorld.nbc". Then, within the directory where you saved the file, start the following command at the command prompt:

“c:\program files\nbc\nbc” –S=usb –d bNXT_HelloWorld.nbc

Make sure that the include file is in the same directory, or that you specify the include directory.

Wednesday, August 02, 2006

Program NXT Robots Using NI LabVIEW

National Instruments has announced that it will soon have a LabVIEW Toolkit for LEGO MINDSTORMS available for download. It is unclear whether this toolkit is the same as the Driver SDK (fantomSDK1.0.2f0.zip 2.21MB) that Lego has just released.

According to NI:

The LabVIEW Toolkit for LEGO MINDSTORMS gives existing LabVIEW users the ability to create and download VIs to operate and control their LEGO robotics systems. The toolkit also makes it possible for third-party software and hardware developers to create native blocks for MINDSTORMS NXT software. The LabVIEW Toolkit for LEGO MINDSTORMS will soon be available for download. Stay up-to-date by joining the LabVIEW Fans of LEGO Community.


All this is off course only an option if you already have LabView. Purchasing LabView just to use it with Lego is likely out of everyone's price range.

Filip

Inside the Lego Mindstorms NXT SDK

I've taken a look at what is inside the current NXT'TREME information (Lego's Open Source page).

Within the Software Development Kit (SDK), the "Executable File and Bytecode Reference" is a great source of information, and the perfect companion to the NXT Byte Code (NBC) compiler. This is great stuff for "power users" of the NXT. Has anybody tried to communicate over Bluetooth using NBC?

You can also interface with the driver on the PC/Mac. I haven't really looked deeply into this. It contains a number of .VI (LabView) files, and a number of header files. If someone has more information on the proper use of this SDK information, please comment.

The Hardware Developer Kit (HDK) is full of insightful information. The amount of disclosure here is perfect, it looks absolutely complete. Some insights drawn from the HDK:

  • The output ports use PWM signalling to the servo motors. This is a standard communication method for servo's, and it implies that other servo motors could be connected when properly wired.
  • The sensor ports have a pin for analog input. This input is digitized once every 3 milliseconds. The value is converted into a 10-bit value (range 0 - 1023).
  • Each sensor port can also communicate using the I2C communication protocol (only as master). The Ultrasonic sensor is currently the only standard Lego sensor using this capability. HiTechnic's and MindSensor's sensors use this capability too.
  • Analog sensing faster than every 3 milliseconds is possible using the NXT hardware, but currently not supported by the firmware.
  • The NXT has a RS485 serial port hidden behind sensor port 4. This enables extremely high data rate communication (theoretically up to 35 Mbs), or over longer distances (theoretically up to 1.2 kilometer/ 0.75 miles). The RS232 serial port we all know so well connects one device with one appliance. However, the RS485 was designed to connect up to 32 devices to a single serial port. In other words, there is a lot of opportunity to tap sensor port 4 for future applications. In the future, Lego considers using P-Net to connect multiple devices. Right now, this is not supported by the firmware.

Clearly, the amount of information Lego has released on the Lego Mindstorms NXT set is nothing short of amazing. They want to support the NXT community as much as possible. I almost feel guilty for still being left with this one question: are they going to open source the actual firmware source code too? I believe it would make a lot of sense to do so.

Filip