My Omnipotent Omniwheel

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.

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.

XKCD

Taken from XKCD.

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

Public Service Announcement

Be sure to let your grand parents know about this.

Thanks.

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.