You spin me right round, baby, right round

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.

ROBOTC I2C Howto (Part I)

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.

I Feel The Need, The Need For Speed…

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:

Read size (B)	Time Taken (ms)	Bytes/s	Transaction time (ms)	Transaction/s
1	1995	501	2.00	501
2	2000	1000	2.00	500
3	2000	1500	2.00	500
4	2994	1336	2.99	334
5	3000	1667	3.00	333
6	3000	2000	3.00	333
7	3989	1755	3.99	251
8	4000	2000	4.00	250
9	4000	2250	4.00	250
10	4549	2198	4.55	220
11	5000	2200	5.00	200
12	5000	2400	5.00	200
13	5347	2431	5.35	187
14	6000	2333	6.00	167
15	6000	2500	6.00	167
16	6011	2662	6.01	166

 

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

Released: ROBOTC Driver Suite V1.1

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

Released: ROBOTC Driver Suite V1.0

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

Connecting the NXT to an ArduinoMega

I’ve had my ArduinoMega for almost 2 weeks now and until today I had no luck getting it to work as an I2C slave with the NXT.  The NXT is a finicky beast when it comes to I2C.  It’s really not all that standard and requires very high pull-ups (82K) for the NXT to be able to pull the lines down properly.

After testing the ArduinoMega’s ability to play I2C master to a number of ICs I had lying around, an MCP23008 and a DS1631, I was pretty sure the I2C lines were working properly.  I tried in vain to make the ArduinoMega work as a slave with the NXT using the AVRlib I2C library, the one provided by the Atmel AVR311 Appnote (source code) and the Arduino Wire library.  Having tested it with 3 libraries, I was pretty sure it was probably not a software issue but some stupid electrical problem.  Little did I know how stupid it turned out to be.

Lacking the proper equipment to further diagnose the problem, namely a scope and a logic analyser, I employed the help of my friend Joep.  We hooked up the ArduinoMega to his PC based I2C master board and all tests completed successfully.  The board responded as it should so that definitely ruled out the software as a source of our problems.  So what could it be?  We connected the ArduinoMega to the NXT using a small breadboard and two 82K pull-ups.  With the scope hooked up to SCL the problem became pretty obvious; the NXT wasn’t pulling down the line enough.  That made no sense, since the internal pull-ups of the ATmega1280 were explicitly disabled in our program.  Joep re-examined the PDF with the circuit diagram and discovered that the SDA and SCL lines had in fact 10K pull-ups!  They were not drawn near the chip itself, but way, way off in the top right corner where you could easily miss them.  With the 10K pull-ups in parallel to the 82K ones, the resulting pull-up resistance had been reduced to a mere 8K9.  After a little brain surgery, the two evil pull-ups from Hell, were removed and subsequent testing resulted in a successful NXT to ArduinoMega I2C transaction! 

If you plan to use your ArduinoMega with an NXT, you will need to remove R2 and R3, which you can find below.  Click on the left picture for a larger version. 

Before brain surgery	After

Be very careful when removing these two resistor, of course.  You don’t want to end up damaging your board.  Joep is quite experienced in soldering very small components and has a very fine tipped soldering iron.  The end result was very nice.  Click on the picture on the right to see a bigger version. 

So why had no one else bumped into this problem with Arduino’s before?  Well, it turns out that the Arduino Duemilanove, for example, does NOT have these pull-ups.  The SCL/SDA lines are shared with the ADC channels.  You can’t very well put a pull-up on an ADC channel.  I am not sure why they would put the pull-ups on the SDA/SCL lines on the ArduinoMega when they weren’t there on the normal Arduino. 

Thank you, Joep, you saved the day!

Released: ROBOTC Driver Suite RC6

Another release with some changes and additions:
HTAC-driver.h:

• Fixed bad registers
• Added HTACreadAllAxes(tSensors link, int &x, int &y, int &z)
• Removed HTACreadAllAxes(tSensors link, tIntArray &data)
• Changed HTACreadX, Y, Z to use by reference instead of as return value

HTIRS-driver.h:

• Fixed wrong registers

HTEOPD-driver.h:

• Added HTEOPDsetShortRangeNW and HTEOPDsetLongRangeNW, these don’t wait 10ms
• Changed the underlying sensor types for ROBOTC 1.57A and higher.

New Drivers:

• Added support for MSDIST-nx Sharp IR sensor
• Added support for MSAC Acceleration sensor
• Added support for MSHID Human Interface Device sensor

This is a quick interim release to address a couple of issues and to syncronise with the version that will be hosted on the HiTechnic website. Stay tuned for many changes in the next month or so. New drivers will include:

• The new HiTechnic colour sensor
• Mindsensors RCX sensor MUX
• Mindsensors PFMate
• Mindsensors Servo controller
• and maybe even a few you’ve never even heard of…

I’ve also been working on making most functions pass by reference, rather than making use of structs of arrays. All of these things will be in the next release.

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

Exclusive: New HiTechnic Colour Sensor Bares All!

A new version of the colour sensor has been brought out by HiTechnic.  It features a number of new abilities:

• Increased sensitivity; the sensor can determine a large object’s colour from up to 20 cm away.
• No longer needs an RGB LED but uses a bright white LED instead.  The RGB values are determined by the very sensitive colour sensor.
• The LED can be switched off to determine the RGB values of ambient light or a light source directed at the sensor.  Now you can really tell the difference between a fluorescent light and an incandescent light bulb.

Rather than sending me a fully assembled sensor, HiTechnic sent it to me in discrete parts, namely the PCB (Printed Circuit Board) with all the components, the grey body, the white cover and the black cap with holes.  This would allow me to take some pictures of its innards to share with you before closing it all up.

So without further ado, I present to you the new colour sensor in all its naked, exposed glory:

 

I didn’t take pictures of the underside of the PCB since there really wasn’t much there. The domed component on top of the colour sensor is a very bright LED. The colour sensor is the cylindrical shaped clear doodad at the bottom with the flat front.  When viewed from the front you can see there is a rather large square sensing area.  I took a macro picture of the colour sensor itself, which you can see here on the left.  If you look very closely, you’ll notice that the light is reflected at a 90 degree angle onto the sensor which is actually mounted on the PCB.  This is done by the black block which you can see in the above right, notice how it has that surface at a 45 degree angle?  I realised this when I saw the small vias (connections between the different PCB layers) next to the sensor area which could only be on the PCB itself.

A ROBOTC driver for this sensor and some of its new functionality will be available very shortly as part of the ROBOTC Driver Suite.  Until then you can safely use the sensor with the drivers for the older model, you just won’t have access to some of its advanced features.

TwitterTattle: Big Brother Is Watching You

I love our dogs more than anything.  Even more than my NXTs.  I can hear you all gasp and mutter “blasphemer!”.  Now before you throw me on the fire, you must understand that I was a dog person before I was a robot person.

Anyway, as I was saying, as much as I love my dogs, they have a tendency to bark.  When we’re home, we can (and do) tell them to shut up, sometimes combined with the (in)appropriate expletives, depending on volume and time duration of said barking spree. However, when we’re not there, we obviously can’t keep an eye and ear on them.  Luck would have it that Mindsensors have a new sensor, the NXTHID.  It’s a sensor that can act as a Human Interface Device (HID), like a keyboard.  Using I2C commands, you can, for example, send data to a program on your computer via a USB cable as if *you* were typing it.  You can also make it start a program using the “run command” by sending the “Windows Key” modifier and the letter “r” and entering the command line in the text box followed by an newline and return carriage. 

That gave me an idea. How cool would it be to know how much the dogs had barked and for how long?  Everyone (and their dog) is using Twitter nowadays, so why not my NXT as well?  I did some Google’ing for a command line Twitter client for Windows and bumped into a very handy little script that uses wget to send a message.  It’s really very simple.  Put the batch file and wget program in a directory in your PATH (like C:\Windows or another directory you added to the PATH variable yourself).  Make sure you edit the twitter.bat file to set the username and password of your Twitter account. 

I created a small program that uses a test release of the NXTHID driver I made.  It will be part of the next release of the ROBOTC Driver Suite.  You can download the zip file with the program and all the necessary drivers here: [LINK].  The program is quite simple.  First we check if the dog is barking, this is done by checking if the sound sensor is registering a loud noise.  Usually our house is pretty quiet, so if the sensor reads “100”, we can be pretty sure that it’s a bark.  If we’re not already running a total bark time timer, we reset it now and start counting.  Another timer to check how long it’s been since the last bark is also reset.  If there hasn’t been any barking for 30 seconds and our total barking time has been less than 90 seconds (that’s 60 seconds of barking time + the 30 seconds since the last bark), we’ll ignore it.  However, if the total barking time is more than 90 seconds, we’ll start up the twitter script to alert us.  After the tweet is sent, the whole process starts anew.

It is important to set your NXT to not switch itself off after 10 minutes or you’ll never know how bad your dog has been.  You can view my NXT’s Twitter page here: [LINK].

Release your inner evil scientist

Are you a budding evil scientist but lack the electronics skills to build your own sharks with laser beams?  Well, you no longer need to outsource your plans for world domination to second rate henchmen.  Now you can learn the skills needed to do this kind of thing yourself. HiTechnic have brought out the Experimenter’s Kit A, which consists of the solderless version of the Protoboard, a solderless breadboard, a whole bunch of electronic components, jumper wires and, of course, a handbook with quite a number of experiments.  Sample programs in NXT-G, LabView, NXC and RobotC (written by yours truly) are available for each experiment.  They’re easy to modify and expand on so the only limit is your imagination.

The kit allows you learn how to interface your NXT with more than just the pre-made sensors that are available on the market.  It includes push buttons, a temperature sensor, a magnetic sensor (plus magnet) and much more.  You can even build your own ambient cancelling light sensor!  That’ll give you a good idea of how the EOPD sensor works.  The handbook has plenty of drawings, photos and diagram, so you won’t be left in any doubt as to which components to place where.

When you’re done with the experiments in this kit, you’ll be well acquainted with interfacing non-Lego electronics with your brick and programming it to access their data.  How to make your own NXT controlled Death Star will be covered in the second edition of the handbook.