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.


At September 01, 2006 2:27 AM , Blogger Brian Davis said...

Thank you for the very kind words! More than anything else, I think this points out one important point about the NXT-G language: we're all just beginning to learn how to use it most effectively. It's not like the languages I've worked in before, and some times an elegant solution just jumps out at you. And believe me, my posted code was certainly not me first version either!

As to battery life, I'm not sure how battery-draining my solution is - that's a very good point. Often I end up braking the motors, waiting a short time, and then floating them, just to save on batteries. But I'm not sure it makes any practical difference in most cases.

Brian Davis

At September 01, 2006 12:33 PM , Anonymous Filip said...

You'r right, I'm still learning how to better use NXT-G, and I've been in for a few surprises. It can do more than I originally thought.

Off course, as a longtime user of Microsoft Visual Studio, I have experienced my share of frustrations with NXT-G as well.

By the way, do you know of a definition of the .rbt format? I'd be interested in writing an .rbt to .xml converter (and back). Or using one that someone else wrote :-).

At September 01, 2006 1:58 PM , Blogger Jason said...

Are there any intereferce from the motors?

At September 01, 2006 2:56 PM , Blogger Brian Davis said...

I suspect I will be learning the details of NXT-G for some time to come. The thought of a NXT-G programming challenge, where people submit code solutions to a specified problem, might be a very good way to help folks figure this out. Should we have a cooperative contest "sponsored" by theNXTstep and bnxt?

As to the format of a .rbt file, I do not know... but since John Hansen has done so much with the stadard bytecodes, (including disassembly), I suspect he does.

Jason, the motors (or the batteries) can change the heading reported by the sensor. It's not too hard to keep the sensor far enough away from such hazards, and I believe there is some on-board calibration on the compass sensor (forthcoming) that can at least partially compensate for this problem. HiTechnic has such a calibration on their RCX-based compass sensor, and I think it's on this one as well (but it needs to be "exposed" by a custom block in NXT-G).

Brian Davis

At September 01, 2006 6:08 PM , Anonymous Filip said...


I'm sure my sensor is still too close to the motors, and there are times where you see the robot do strange things. But it usually quickly recovers, and so I'd say I don't have an issue with interference for the robot I'm using.

Jim actually published a great article on the interference on TheNXTStep.



Same here about still learning about NXT-G. I'm open to any programming challenge we can come up with. Let's discuss this offline,my email is



Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home