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.

HiTechnic Sensor Hack

In two previous articles (here and here) I had tried to come up with a way to use IR light to gauge distances.  It wasn’t very successful, but such is the risk of trying something new.  So last night, whilst sitting at my laptop, I wondered if there was a way to emulate a $10 device (a Sharp IR Sensor) with more than $100’s worth of NXT sensors.  It seems there is.  I repurposed a HiTechnic IR Link and IR Seeker (v2) and turned them into a very limited IR distance sensor.

So how does it work? Well, remember I mentioned a few articles back how you could turn an IR Link into a beacon by pulsing it at 1200Hz? Well, instead of using the IR Seeker’s direction register to determine where the beacon is, you could, instead, just query the forward pointing sensor (sensor number 2) for signal strength.  Now if you put the IR Link next to the IR Seeker and point them at an object some of the beacon signal from the IR Link is bound to bounce back and be detected by the IR Seeker.  Using the contraption on the left, I set out to take readings at various distances.  The results surprised me a little.

The first 3 points I expected to look that way, the surface was simply too close.  However, the linearity of the next couple of points really boggled me.  Did this actually work?  They are most likely highly inaccurate as the values bounced around a fair bit, even though the program was taking 10 readings and averaging them out before displaying them.  So there you go, a highly inaccurate, completely impractical IR distance sensor!  I think the EOPD is probably more suitable for this kind of thing but what would the fun be in that?

You can download the program here: [LINK].  Please note that you will need to use my driver suite, too.  You can pick that up here: [LINK].

Released: RobotC Driver Suite RC5

Some minor changes in this version and some bug fixes.

Changelog:

HTDIR-test1.c (0.2)

• Partial rewrite by Dick Swan, waits a little longer for sensor initialisation
• Nicer intro screen
• Less screen flickering, only updated if there’s been a change in data.

common.h: (0.3.2)

• makes use of the new alpha’s built-in clearI2CBus(). It is still defined for the older firmwares

MSLL-driver.h: (0.5)

• Bug in LLreadSteering() fixed

HTPB-driver.h: (0.7)

• Fixed a couple of function calls that had not been renamed.

TODO:

• Add UART (RCX) functionality to HiTechnic IR Link driver.

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