The HiTechnic Sensor Multiplexer (SMUX) is a complex sensor that requires a fair amount of intimate knowledge of its operation in order to use it.  The tutorial has both ROBOTC and NXC examples.  Please note that error checking for all the I2C calls is outside the scope of this tutorial.  This was done so as to not clutter the code and take away from the essence; to show how the SMUX works.

Table of contents:

• The HiTechnic Sensor Multiplexer
  • Introduction
  • Operational states
• Multiplexer Operation
  • How does it do what it does?
  • Programming examples
  • Putting it all together
  • Advanced operations
  • Dealing with the unexpected
• 3rd Party ROBOTC Driver Suite
• Appendix A Register Layout + Function
• Appendix B: SMUX Status
• Appendix C: Channel Mode
• Appendix D: Channel Type
• Appendix E: Supported Sensors

I hope you enjoy reading it and learning from it as much I enjoyed writing it.

You can download the tutorial here: [LINK].

Edited: 23-11-2009, updated tutorial to v1.0
Edited: 25-11-2009, updated tutorial to v1.0.1

On my continuing mission to take apart HiTechnic sensors and show you guys their guts, I present to you: The Gyro.  The little yellow/gold component on the right of the PCB is the actual gyro chip, the rest of the components most likely to deal with power conditioning.  There’s not a whole lot to tell about this board since there’s not a lot to it.  The other side of this board is completely bare apart from some writing, a couple of vias and the connector, of course.

For Lego World 2009 in the Netherlands I wanted to make a remote controlled version of the Crane Truck (8258).  It seemed pretty easy, after all, it’s a pretty big truck, right?  Well, I had underestimated the amount of space the gears and all the bevels take up. 

In addition to the 4 powered functions in the original model, I wanted to be able to drive and steer the truck.  That meant a total of 6 PF motors; 5 small ones and one large one for the rear wheels. 

I ripped out all of the intricate gears and gear boxes that were housed in the middle.  The original model really is a work of art, truly worthy of being the 2009 flagship.  I felt a little bad for undoing such a wonderful complex design but it had to be done, I guess.  I took some pictures while building it and some afterwards (I just removed some pieces to show the inside). Click on them for a larger version.

I’ve also made a video of the whole thing so you can see it move.  If you click on the video, it’ll open it in YouTube and you can watch the HQ/HD version.  Enjoy!

ROBOTC 2.0 is out!  After many months of development, testing and bug fixing, the folks at Robotics Academy have given birth to a 27MB baby.  This latest release is a major improvement over ROBOTC 1.x. 

I was lucky enough to be part of the debugging and testing of the internal builds as Dick and Tim hacked away to squash the evil bugs.  It makes you appreciate the amount of work required to make a new major release (i.e. going from 1.x to 2.x) a little more.

Anyway, the list of improvements and fixes is HUGE.  A lot of nice features were added to make ROBOTC more attractive to not just the beginner and intermediate but also the more experienced programmers.  Many of the requested features on the forums have now become part of the latest release:

• A tabbed interface; you can now have multiple files open and work on them simultaneously.
• More configurable interface, it has more of a Visual Studio 2005 look now.
• Better Motor and Sensor Setup Wizard with more options.
• The documentation has undergone a major metamorphosis; it includes sample code and much better explanations. 
• A live start page with regularly updated news about the ROBOTC community.  I mention it because it also features a link to my 3rd Party ROBOTC Driver Suite

There are many other improvements, of course.  For all the details, I suggest you head over to Robotics Academy, where you can find list of changes here: [LINK]. You can download 2.00 for the NXT right here: [LINK]. 

Get your copy today!

For the Lego World 2009 in the Netherlands I built an omniwheeled robot.  It’s been done thousands of times before and the Internet is full of great (and not so great) examples.  I wondered why I hadn’t jumped on that bandwagon so I got cracking. 

This was the first prototype I made back in August.  I was on a Lego expo together with Martijn and Daniel (and their respective better halves).  I wanted to see if it were possible to build an omniwheeled robot using just the NXT 2.0 kit pieces.  This is what I came up with.

It didn’t perform well at all, especially when it needed to do anything but spin around.  It got me thinking, though, how could I build an omniwheeled robot that would perform well.  Lucky for me, Martijn was more than happy to donate a couple of wheels to the cause.  It was a little more than a couple, I guess he was expecting me to build a 6 wheeled robot or something.  It came to about 200 wheels in all, 86 small ones and about 115 bigger ones.

I went through quite a number of wheel designs over the next couple of weeks.  Some were ridiculous cart wheels shaped monstrosities that measured more than 20cms in diameter.  Others simply defied explanation.  The design I eventually settled on is shown below.  It is loosely based on the omniwheel design that Steve Hassenplug made with some of my own modifications.

The wheel is actually made up of two wheels next to each other.  They’re quite resilient.  During Lego World I demoed the robot quite a bit and only 2 of the small wheels fell off during that whole time (5 days).  Not bad.

Before I got my current design, the actual robot went through a number of prototypes over the course of about 2 months or so. I took pictures of some of them.

The first one is quite simple but it had quite a bit of flex in the axles attaching the wheels to the motors, so the outer wheels never actually touched the ground.  The one in the middle had one half of the wheel on each side of a frame holding the motor.  This one actually had suspended arms holding the frame housing the motors.  It looked super cool but the whole thing flexed like crazy when you took a turn, it was terrible.  The 3rd model was one I build during our camping trip.  It was much improved, less flexing but I wasn’t happy with how little contact the outer wheels made with the ground.  This caused a huge amount of  bouncing around.  I think in all there were about 10 prototypes.  The final and current incarnation of the I present to you below.

The first picture was taken before Lego World, the other two were taken after.  A couple of nice bumpers were added, a HiTechnic Touch MUX, a HiTechnic Compass and finally a HiTechnic IR Receiver to make the whole thing remote controlled.  Here’s a little video I put together of it in action.

So there you have it.  I’ll post some pictures of my remote controlled crane truck later this week.

I2C is a very popular communication bus for connecting low speed peripherals to embedded systems.  It will come to no surprise that the NXT is also capable of communicating via I2C to digital sensors.  Out of the box, the NXT is capable of talking to up 4 sensors at once.  However, I2C can do much more than that.  This howto is not going to very deeply into the protocol specifications, those details can be found in more than one spot on the Internet.  Instead it will focus on how make the NXT play nice with all manners of I2C capable sensors and peripherals. This installment will introduce the basic calls and variables needed to make I2C calls.  The next installment will focus on error handling and other fun things!

Please note that I am using hexadecimal notation (0x..) for messages sent through I2C.  This is a convention you’ll find used throughout most of the world of microcontrollers.  I suggest you practise a little with it, it will come in very handy as you progress.  You can easily convert between decimal and hexadecimal using the built-in Windows calculator (calc.exe).

What you’ll need:

• An NXT brick with the ROBOTC firmware installed on it.
• A copy of ROBOTC on your PC, I recommend 2.00 preview or whatever comes after that.  You can download that here: [LINK].
• A digital sensor, I’m using HiTechnic Colour Sensor in this example but you can use something else, like a Mindsensors ACCL-NX, it doesn’t matter.

Step 1: Let’s get started

Open a new source file in ROBOTC and create a standard main task with the following:

This configures port S1 as a low speed I2C sensor.  This is a speed that should work with any I2C sensor as it uses the standard Lego clock speed (9600 Hz).  The program doesn’t do a whole lot yet.  It mainly just loops around until the cows come home or the batteries run out, whichever comes first.

Step 2: Declaring an array

I2C works by sending messages.  To be able to send a message, we’ll need something to hold the message. An array of bytes will do the trick very nicely (line 5).

Step 3: Addressing the slave

Each device on the I2C bus has a unique address.  If you want to talk to a slave, it needs to know you’re talking to it and not one of the other possible 126 slaves on the bus. This is done by setting the address of the slave as the first byte you send  (line 11). 

Why am I setting the 2nd byte in the array as the I2C address (0×02) and not the first?  We’ll get to that later, rest assured that it’s supposed to be that way.

Step 4: Selecting the read register

Most sensors made for the NXT use a standard register layout.  “What, pray tell, is a register?” you might ask yourself.  Well, think of registers as memory locations or drawers, if you will, where information is stored.  In order to get the right information, you need to know what register you want to read from.  Lucky for us, you don’t usually have to guess where the information is kept.  The register, or address, that holds the latest sensor reading is almost always 0×42 in the case of NXT sensors.  We’ll use that as the 2nd byte we’re sending to the slave (line 14).

Step 5: Specifying message size

We’re almost ready to send our message to the slave but first we need to do one last thing; specifying the message size.  Remember I said I would get back the first byte in the array later?  Well, that time has come.  In order for ROBOTC to know how much data to send to the slave, you need to specify the size of the message.  In this case, our message is only two bytes long; the slave address (0×02) and the register we want to read (0×42), so let’s put that in our program (line 17).

Step 6: Getting the message across

We’re good to go now.  The ROBOTC call to send a message via I2C is sendI2CMsg(nPort, sendMsg, nReplySize).  The first argument, nPort, is S1, S2, S3 or S4.  The second argument, sendMsg, is a pointer to the the array containing the message.  The third and last argument, nReplySize, specifies the number of bytes we want to read back from the sensor in response to our request.  We’ll tell ROBOTC that we want to read back a single byte (line 22).

Step 7: Handling the slave response

The code in step 6 isn’t all that useful considering we’re not actually doing anything with the slave’s response.  To retrieve the response from the slave, you must use readI2CReply(nPort, replyBytes, nBytesToRead).  Once again, nPort is the port specifier, S1 to S4, replyBytes holds the slave’s response and nBytesToRead tells ROBOTC how many bytes we’re expecting from the slave.  We’ll print the response to the screen, so we can see (lines 28, 29).

Compile the program and upload it to your NXT brick.  Run it and look at the the number on the screen.  If you have the HiTechnic Colour Sensor connected, observe how the number changes when you hold differently coloured objects in front of the sensor.  If you’re using the Mindsensors ACCL-NX, you’ll notice the number changes as you change the orientation of the sensor.

The sensor updates the contents of register 0×42 every couple of milliseconds (ms).  What you are seeing are constantly updated values as returned by the sensor.  Congratulations on writing your first I2C driver for the NXT!

Final words

The code for this program can be downloaded here: [LINK].  In the next installment I will go over error handling and how to deal with more than one byte in a response.

Taken from XKCD.

In an earlier article I wrote, I tested how fast I could push the HiTechnic ProtoBoard and the MAX127 ADC under ROBOTC.  In a recent discussion with Deepak from Mindsensors, I2C speeds in ROBOTC on the NXT came up.  The questions arose about the most efficient read size for the NXT and if there was a ceiling or a cut-off point.

So, rather than taking a guess, I wrote a quick ROBOTC program to test the time taken to repeatedly do requests for an ever increasing number of bytes.  The program would do a 1000 reads of 1 byte, time the results, then repeat the same 1000 requests for 2 bytes, all the way up to 16 bytes.  The results were quite interesting and not nearly as linear as you’d expect.  I made use of the new I2C calls “clearI2CStatistics()” and “getI2CDriverStatistics()”.  They allow you to gather information on internal I2C statistics, such as failed pull-up tests, number of retransmits and other things.  You can find more information about them in the "I2CIntrinsics.h" header file included with the latest release of ROBOTC (2.00 preview at the time of writing this article). 

So without further ado, here are the results:

Number of bytes read per second.	Average time per I2C transaction.  This includes the time required to send the request and for the reply to be received and read.	Number of transactions per second.

So what conclusions can we draw from this?  If it’s sheer bandwidth you need then reading 16 bytes at a time is the way to go.  However, it does reduce the number of total transactions per second to about 166.  If you need to poll a sensor very frequently, it is paramount to keep the number of bytes requested down. 

Tests were done using two sensors, a Mindsensors Accel-NX and the HiTechnic Colour Sensor (V1).  The results were identical (with a deviation of perhaps 4-6 ms).  The sensor was configured as a custom I2C sensor using the fastest possible clock speed.  Please note that a lot of sensors are not guaranteed to work flawlessly at these speeds.  However, neither sensor produced any errors during the test runs.  ROBOTC version 2.00 preview was used, the program was compiled with the “release” setting and without a connection to the debugger.  Runs with the debugger connected and with the “debug” setting enabled showed no difference in performance.

Remember, there are three kinds of lies: lies, damned lies, and statistics..  Use the above data with caution!

You can download the source for the program here: [LINK].

A new version (1.1) of the ROBOTC driver suite awaits your download from the usual source.
Not as many changes in this release as with the previous one. Changes include:

• Added support for the Mindsensors Servo controller, up to 8 servos per controller.
• Added a new function to get the raw uncalibrated AD values from the sensors in the Mindsensors LineLeader sensor.
• Added support for the new HiTechnic IR Receiver, control your robots with a Power Functions remote.
• Minor documentation changes.

The drivers’ website is here: [LINK].
The documentation can be found here: [LINK].
You can download the software from the Source Forge page here: [LINK].

After a long time between releases, I am proud to present to you the latest version of the ROBOTC Driver Suite. The biggest new addition to this version is support for the new HiTechnic SMUX sensor. Adding support for this new sensor involved modifying almost every single driver for the HiTechnic sensors to add the ability to poll the sensors through the SMUX. I’ve tried very hard to make it as easy to use and transparent as possible.

For example, to use the HiTechnic Colour Sensor V2, you’d use the following code:

#pragma config(Sensor, S1,     HTCS2,               sensorI2CCustomStd)
#include "drivers/common.h"
#include "drivers/HTCS2-driver.h"
task main () {
  int _color = 0;
  eraseDisplay();
  while (true) {
    //eraseDisplay();
    _color = HTCS2readColor(HTCS2);
  }
}

To use the same sensor via the SMUX, you’d use the following:

#pragma config(Sensor, S1,     HTSMUX,               sensorI2CCustomStd)
#include "drivers/common.h"
#include "drivers/HTCS2-driver.h"
task main () {
  int _color = 0;
  HTSMUXinit();
  HTSMUXscanPorts(HTSMUX);
  eraseDisplay();
  while (true) {
    //eraseDisplay();
    _color = HTCS2readColor(msensor_S1_1);
  }
}

As you can see, there’s not a whole lot of difference. msensor_S1_1 means the SMUX is attached to sensor port S1 and the Colour Sensor is attached to port 1 of the SMUX. To connect to port 4 of the same SMUX, you’d use msensor_S1_4. All the sensor calls that are supported through the SMUX can be found in the drivers. I recommend you check out the documentation for more information.

A quick overview of some of the changes in this version:

• Added support for the new HiTechnic SMUX and created functions for all supported sensors to allow access via the SMUX.
• Added support for the new HiTechnic Colour Sensor
• Added support for the new HiTechnic Sensor MUX
• Added support for the Mindsensors RCX MUX
• Added support for the Mindsensors PF Mate
• Added support for the latest alpha release of ROBOTC and its ability to distinguish between signed and unsigned.

You can download V1.0 here: [LINK].
The drivers’ website is here: [LINK].
The documentation can be found here: [LINK].
You can download the software from the Source Forge page here: [LINK].