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:

Please update the feeds you are using accordingly.

Monday, August 28, 2006

NXT Education Set Received in Canada

YEAH!!! After a cross border foul up I finally received the Education NXT set.

I am supposedly getting my NXT-ed from the 2nd ship load to Spectrum of Canada. However an additional battery pack is still on Back Order.

This kit is going to be my travel NXT for showing off to others - It looks to be lots of fun (but I miss the Hassen Pins... PLEASE offer these bulk!)

It’s great with a roomy storage container (the pieces all fit with room to spare) and of course the rechargeable battery (which is why I am typing while it charges instead of playing).

The software (separate) is 2 discs and comes with a user guide (more on that later).

The Legacy cables were a pleasant surprise because I got 9 instead of the usual 3. (Shh! Don’t tell Lego!) So I have enough for all my sensor ports...

I also got a legacy temperature sensor. I can now imagine building a robot with a ring of RIS Touch Sensors and a temperature (or light) sensor in the middle. The cool part is that instead of making an elaborate touching bumper, I can just put more of my oh so common RIS sensors around the bot. Use those to have the robot know when it crashes. But even cooler, if I hook up RIS sensors, I can use a programming trick that says if you get a value that is MAXed out, then the sensor should be a touch sensor. If you get a value greater than 0 but not maximum then it is the other sensor. 2 sensor types in one slot, and multiple touch sensors as well. OK, so this is an old trick, but we have new users - so spread the old wisdom... It’s education after all.

Now I am off to go create a deluxe remote control and car set up. I'm hoping it'll be a smart car that won’t let me hit walls (without trying) and will allow me to either pick up a ball or shoot something - not quite sure which. I am also hoping to include a 9v motor set up with an on off servo switch for added power. I just hope the pulsing at low speeds is not too bad.


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 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!

Thursday, August 24, 2006

To spin or not to spin? - That is the question.

I'm excitedly expecting my education set (last I heard it was on a boat but my imagination has not really accepted how far away that boat is in time/space/reality).

To that end I am exploring rovers that can both be independant and great little BT remotes. I want to have speed for the remote but also have it drive itself at similarly high speeds. To that end I am abandoning the tank style dual drive motor turning system for a rack and pinion (or may be just rotation) based steering.

Tank style driving is nice because you can have your sensors all point forward and simly sit and spin to get an idea of whats going on. Even thought NXT makes this style of driving alot smoother, the car style of driving I think can go faster - especially if higher speed motors are used.

Car driving allows a forward view or a head bobbing view that follows the direction of the turning wheels.

I am, however, exploring a concept where a minor turning of the wheels causes a large movement in the UltraSonic sensor head so that while in motion it can wiggle the wheels to sweep and decide to go left, right or random and how severe a turn to make.

Does anyone know how an Ultra Sonic sensor reacts to a perpendicular plane near its source of radiation? In short can you put blinders on it so that it ignores "low" obsticals - or would it simply continually detect the shelf. Also I am curious how it reacts to driving with the US near a wall or floor?

So what are everyones comments and preferences when it comes to Car, Tank or other steering styles...

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.

Saturday, August 05, 2006

NXT shootable accessories from Bionicle & Exo-Force

The New Bionicle Line-up has like always some really good robotic decorations. Light up swords, masks that can be used as catapult spoons and the usual basic of neat feat.
Now add to that list expandable Ammo Clips for ZamoSphere Launchers. if you dont want to mess with large beam intensive trays angled everso slightly and an jamming ever so often (see DAZLR on the MDP page of Mindstorms) - Try the Toa Inika's new stackable and expandable ammo clip.

A side shot in the magazine shows that they use a spine thats bent at a hole ending in axels. So this mounts right to the launcher and can be expanded until the bend makes gravity a problem. THey look like technic angle connectors number 3 which finish the 90 degrees after 4 pieces and they hold 3 shots plus the loaded shot (13 shots).

Also check out Exoforces's Mini Disk shooter along with the adustable technic beams and body panels.

The Disk shooter is on the rear side of the gattling gun and the adjustable angle beams are on the under carraidge.

This also has the disk shooters and a bunch of construction buckets.

Let us know if you've tried these shooting elements. Whats there range, mechanism and reload rate like.

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
  jmp Endless

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 You may want to check 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 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 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 ( 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.


Ultrasonic Radar Improvements?

Jeff has once again shown us how some detailed math can do really cool things. He has even sparked my dread of math into a desire to use the math knowledge I have for things other than Math Tests...

He has written an article that describes how to use the NXT display to take range data and convert it into a radar screen style display. He's even provided false readings in a data file so you can try out this coolness without even having a US hooked up. He also discusses converting hte program to read from the US and not the data file.

This got me thinking (always a hazard with all these ideas flying).
Does the US need a certain amount of time on station to send and recieve each signal? I know from experience that it can recived data on the move but how good is it. I also know that each send/recieve cycle takes a finite amount of time (cant seem to relocate that data right now - commnet it if you have it)
Thus should a radar set studder from angle to angle allow 3 returns (incase you catch one durring hte shift).

So I tried to do some web research and looked at the Lego description.

It showed this diagram which labels one of the eyes as a reciever and the other a sender. If this is accurate then perhaps there is also a perfered direction of rotation. If you spin right (assuming the sender is right as in the diagram) then the reciever will be comming into the path of the signal. if you went the other way it might turn far enough away (if you try to do fast scans) that the return broad sides the reciever fairly weakly.

Just curious but has any one tried disabling (plugging up or unhooking) the sender and reciever from different sensors and see what happens when the sender and reciever are seperated but allowed to communicate. (RIS experiment?) It might be interesting especially if you interact with other robots to be able to play marko polo.

Lots of neat stuff emerging - Have fun every one

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.


FLL Freak Tutorial updated!

This was emailed to me (I asked for update notification)
It looks like its a new BT video and file (not a huge revamp - more like another chapter in a serial novel). Its fairly basic if you've already had success and have tried your BT but if you haven't "there is nothing like a walk through". This video talks about set up of the NXT-G program connection via BT - not any robot to device communication. Maybe another time.
- Drew


I finished the latest tutorial on Bluetooth. It is available at:

I am now working on a tutorial on how to reclaim memory to squeeze more programs into your NXT.
Hope to finish that early next week.


Tuesday, August 01, 2006

Theoretical BT Data Traffic control and solutions to its limits

This started out with the intention of being a comment tacked onto the ARTag article
But ended up being a much more robust monologue that I really wanted to become a dialogue with its own comments section. It can get complex in places so I thought I might try to summarize at the beginning and let you venture in if you need more. Now I dont yet have my 2nd NXT. But even if I did this type of research would require more than 3 I think. I leave a few unanswered questions such as how long does a BT transmission burst take - so if you have the resources please comment and fill in blanks.

BT Mail Box Limits and solutions:
NXT Bluetooth Mail Box system is limited to 10 pieces of information. By using math you can further "tag" pieces of information by making them of a unique Size. For example if you want to use only 1 mailbox to recieve both direction and range information. You could set a variable switch which puts values of 1-360 into direction and values over 1000 send to Distance. The sending bot would have added 360 (optional if <360>Traffic Control:
BT can only transmit to or recieve from 1 source at a time. Transmitting continual streams of data (like fluctuating US returns) is thus only possible when 1 bot is giving and the other recieving. If more bots are involved they need to know how to wait (I am not sure if this is done in the firmware programming - send until recieve).
You can have them synchronize watches and communicate in assigned windows of time.
They can use "Shhh... and let me talk" comands to clear the airwaves.
Reduce the number of transmissions by having the sender decide if the value change is signifigant enough to warant an update.
Daisey Chain - Since only a few connections can be made their is a finite limit to how many NXT's an NXT can talk to. So if you tell each NXT to talk to only two others (bot 2 talks to 1&3) then they can use that daisey chain to pass along information from themselves and others. Since #1 is talking to #9 and #2 and #9 is talking to #8 etc data can be sent like passing notes. Notes could be set up to go to all bots awareness or just be passed along untill they reach the target.

Primary Discussion (fodder)
Now I've been chewing this over more, and if we can give the NXT native programing this information (I speak of the mailbox system).
Assuming your dont use an active query system (hard to program - the bot asks for what it thinks it needs from a netword of NXT's or a PC/PDA) and instead use a broadcast system (all the data you want or need is being updated as it changes). This mind you nesecitates a BT traffic control system. If your bots are generating continually changing values like light or US readings then they woudl continually broadcast those. But only one connection can be maintained. So you might need to either A) reduce sends by creating a "value changes by X amount" trigger, which then sends until a "I have recieved" signal is recieved.
B) if you can find out how long each data burst would last you could have one NXT give a timer signal comand (could even be a MAX sound that they all recieve simotaneously by you yelling or ringing a bell) so that Bot1 would be free to transmit in the first 1 second, bot 2 in the 2nd and on the n+1th second where n = # of bots the timers would reset and start the que line-up all over.C) Daisey chain. Bot 1 tells bot2 what bot 1 and bot 3 are up to. Bot 2 tells 3 what 1&2 are doing then 3 tells 1 what 2 & 3 are doing. That would need to be like a VHF/CB radio Recieve a "let me talk" and a "I'm done" signal (or another timer) but only 2 bots are involved. This is much more expandable than B) since B is limited by the number of connections. C) has only 2 connections per bot. Its 2 assigned buddies. But since the buddies are all different you get a kind of robotic game of telephone. Make sure they move slow because unlike the game telephone the info will be accurate but it could be a few seconds old.There could be other systems - Comment to add more

Now with 10 mail boxes you could have 10 pieces of information. So if you ID'ed slots (mail boxes) 1&2 to refer to Bot A then you could have heading and range info stored their. That means 5 bots could be tracked by any 1 NXT.BUT! if you multiply range values to some value that all readings will be above 360 then use a compare switch to grab the values and sort them out so that heading values which are within a known range will be placed into a variable suitcase (thus freeing up the mailbox) so that the next piece of incoming info could go towards the same mailbox. If its a range reading it will be an inflated value (maiking below 360 unlikely) and sorted by the switch into a seperate variable suitcase for that bots range info.
Thus with a little math and switching your number of reception data entries are only limited by the NXT's max program size and the speed at which it can recieve info.
You could even distinguish robots by going: (Value+n)x nxA where n is the desigation of the robot and A is the designation of the value. At really small Values the +n gives the nxA something to enlarge (which is what your variables will sense). Alternatively for huges amounts of data (which is really the only reason you'd use this) it might be easier to send a BT message preffacing the next message so that the BT is expecting a certain value to arrive and it can use a switching tree to determine what variable recieves the second data based on what the first message says. But then THIS requires that all bots wait for the 2nd message before trying to but in. Otherwise bot 1 might send "Heres Direction" and bot 3 might but in and insert "Range" into Bot1's direction variable.

Now all of this muck and bother is only really required by builders with MANY nxt's and probably only if your Swarming. An exception would be with an external Augmented Reality sensor which could provide HUGE amounts of Data.


BLUETOOTH add on "coming soon"

I checked out the Developer kits - A very exciting time for NXT. But that's not all that's happening. I checked the Lego Bluetooth Page and it changed since last I checked:

"Coming Soon!Remote control your NXT Robot from from the palm of your hand with the LEGO MINDSTORMS NXT Mobile Phone Application. A Getting Started tutorial and programming ideas are included. "
I was starting to get annoyed with the "Line is busy" when using BT with other non-NXT things. I was about to call and complain - I mean they even show a picture on the box. Now I know the phone is not included but the functionality if shown should be doable from whats in the box or freely avalaible and within the realm of an average user (not a super hacker). But now I am much happier.

AND they included Lego tested BT apps (I assume these were tested by the MDPs)

The table below list a number of devices with Bluetooth enabled wireless technology that has been tested by LEGO and our partners.MINDSTORMS NXT
  • Abe UB22S - Compatible
  • Belkin F8T003 ver. 2 (short range) - Compatible
  • BlueFRITZ! AVM BT adapter, BlueFRITZ! USB v2.0 - Compatible
  • Cables Unlimited USB-1520 - Compatible
  • Dell TrueMobile Bluetooth Module - Compatible
  • Dell Wireless 350 Bluetooth Internal Card - NOT COMPATIBLE
  • Dlink DBT-120 - Compatible
  • MSI Btoes - Compatible
  • MSI StartKey 3X-faster - Compatible
  • TDK GoBlue - Compatible
  • Qtrek, Bluetooth USB Adapter v2.0 - Compatible

On the site they are ranked on compatability. Only the Dell internal BT was poorly rated. I just got a laptop (partly to support mobile NXT work) and was having a tough time deciding between getting onboard BT or not (from Dell). Instinct told me to stay away. Yeah!

I wonder if this is all part of a larger republishing of the Lego Mindstorms site. Anyone else notice changes (I think software may have a different picture layout, but I am not sure).