Mindsensors was kind of enough to send me one of their prototype sensors, the Power Meter, to play with.  It’s a sensor that allows you to measure, among other things, the current and voltage of anything you care to connect to it (within limits, of course). 

The first thing that came to mind was building something that would log the incoming data to an Excel sheet using the NXT HID, but then Andy M scooped me on that so I had to come up with something else (damn you, Andy!).  Then it hit me!  Why not make an oscilloscope? So without further ado I started programming. This is what I came up with.

The result is quite nice, I must say.  Right now it takes a sample every couple of milliseconds and refreshes the screen every 20 milliseconds.  There are five scales for each unit (amps and volts), to cover the full range of the sensor (up to 13V5 and up to 3A).  You can switch between ranges using the arrow keys and between units using the enter key.  This program, together with the driver will be available with the next release of the 3rd Party Driver Suite.

Things I’d like to implement at some point is data recording, zooming and manual scrolling of the screen.  I had the manual scrolling implemented at one point but ditched it for the cardiogram-look instead.

Another cool project using the Power Meter sensor can be found here: [LINK].

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

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!

Having read the countless articles, websites and hearing about it from friends, I’ve decided to jump on the Arduino bandwagon.  I bought one of the new ArduinoMega boards with a very nice shield and some other things.

The ArduinoMega is an Arduino compatible board with an ATmega1280 controller that has 128KB flash, 8KB SRAM and 4KB EEPROM.  It has 54 digital IO pins (of which 14 can provide PWM output), 16 10bit analogue inputs, I2C and a bunch of other ones.

The idea is to use the ArduinoMega as a (very) smart sensor/I2C slave for the NXT.  I am not sure what I’ll do with it, yet.  I have a Wiznet WIZ810MJ Ethernet module in a drawer somewhere, perhaps I can use that.  So far I have managed to upload a “blink” program and it works.  The only bad thing about the Arduino programming environment is that it is very, very slow on my Windows 7 64bit laptop.  I have it running on a Vista 64bit VM without any issues, though.  Perhaps they have fixed this in the upcoming 0017 release.  For now I will just use the VM-based solution.

I ordered the stuff from an online shop in Germany called Watterrot.  I was really impressed with how quickly my order was processed and shipped.  I ordered it on Wednesday lunch time, it shipped out on Thursday afternoon and by Friday afternoon I had all my items.  Their packages are traceable, so you can hit F5 (refresh) in your browser until the lettering wears off.  They also stock a very wide variety of SparkFun items (117 of them @ 25/07/09), which is great.  To top it all off, they have very good prices and only charge €10 euro for shipping and handling for orders within the EU!  That’s less than a 1/3 than what some of the shops in the Netherlands charge for a similar order.  I will definitely order from them the next time.

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

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.

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

What is nicer than attaching a Sharp IR sensor to your NXT?  Attaching 8 of them, of course. That is what my friend Helmut wanted to do with his NXT.  Unfortunately, as good a programmer as he might be, messing around with electronics just wasn’t his “Tasse Tee” (that is cup of tea for you non-German speaking folks).

8 Sharp IR sensors consume a lot of power, much more than the NXT could ever hope to supply without frying.  A single sensor can easily draw up to 40mA, so 8 of them is 320mA, almost 4 times as much as the all the sensor ports can supply, put together!  An external power supply would be necessary.  A way to enable and disable sensors on an individual bases would be very useful, too.

Thus was born “MightyBoard”.  At the heart of the board are 2 ICs, the MAX127, an 8 channel 12bit ADC, and an MCP23008, an 8 channel IO chip.  Both these chips can talk I2C and are therefore ideal to connect to the NXT.  The ULN2803A merely acts as a buffer for the MCP23008. I added some green LEDs so that it was easy to see when a channel was enabled.

I prototyped the whole thing on 3 breadboards but to cut down on the wires and mess, I only made it work for 4 channels.  It was for proving a concept, rather than duplicating the whole thing.  Below is a short video of one of the first tests.

Next was the hard part, making a permanent copy of the whole thing.  I chose to use copper strip board, the 3 hole per strip kind.  They’re fairly easy to use and you almost never have to manually cut any of the strips.  I used a cut up conducting flat strip of Lego as a connecting point for the Lego battery holder. I soldered some pins into the back of it and then super glued it to the board to stop it from ever moving again.  The small dual DIP switch is to allow the pull-up resistors to be disabled.  This is necessary if the second sensor looped through is a Lego sensor.  They have the pull-ups already built in.

To prevent the mess of wires from being ripped off, I used a whole bunch of hot glue and the plastic from a DVD cover box.  It really did the trick and made the board rather “professional” looking, even if I do say so myself.  I used a box cutting knife to trim the blobs off the side.

Below is the video of the first test I did with the final version of the MightyBoard.  As you can see, it worked rather well.

MAX127 8 channel 12 bit ADC with I2C interface
ULN2803A Darlington transistor array
MCP23008 8-Bit I/O Expander with I2C interface
C1..C8 0.1 uF capacitor
R1..R8 1kOhm resistor
D1..D8 green 3mm LED
CON0..CON8 3 pin connector
C9 0.01 uF capacitor
C10 4.7 uF capacitor
J1, J2 NXT connector           
R1..R8 1kOhm resistor 
R9, R10 82kOhm resistor   
SW1  double DIP switch

You can download the latest version of the RobotC drivers for this board here: [LINK].

Have fun and remember, if you blow it up, don’t blame me!

I got a Mindsensors NXTCam2 for my birthday last year but hadn’t had much time to play with it yet.  That is, until today. 

The NXTCam2 detects objects by matching them to one of 8 user-programmable colour ranges.  The objects and their colour can then be retrieved via a few trivial I2C commands.

You would think that this would mean that a ball shaped object would appear ball shaped on the camera when dangled in front of it.  You would be wrong.  Objects are rarely uniformly coloured and a patch of reflected light might make the object appear very differently to the camera, resulting in something resembling the picture to the right. 

This can make processing processing the information quite hard and daunting if all you really want is to know whether there’s a red ball in front of your robot.  I thought it would be nice if there was some way to combine all the shapes that were overlapping or touching into something that was was contiguous and square.  One type of software that does a lot of checking whether two objects are touching is game software.  After a little Googe’ing I came across this great tutorial that explains collision detection very nicely: Collision Detection and Response.

After a little fiddling and programming, I turned the above jumble of boxes into just two big squares. This makes dealing with the shapes a lot simpler.  It gives a much more accurate representation of what’s in front of the camera than the original, assuming you’re not trying to detect pringles with your NXTCam2, that is.

The program below is a modified version of cam_display written by Gordon Wyeth.  I’ve also included the nxtcamlib file with the program.

File: cam_display_mk2.zip

I’ve been quite busy the last few days with various performance testing.  A friend of mine is keen to develop a robo-football platform.  Due to the nature of the game, very fast sensor updates and processing is required to track the ball and the opponents.  I’ve offered to work on an extension for the NXT allowing him to hook up to 8 Sharp IR sensors, which will be dotted around the robot’s body.  That made me curious, how fast *can* the NXT go when it comes to I2C?

I wrote a program that made use of two drivers I created earlier.  One for the MAX127 and another for the HiTechnic ProtoBoard (HTPB).  Running both sensors in standard mode, I noticed that I was able to get about 140 readings per second on both.  However, after a conversation with Steve from HiTechnic, I confirmed a suspicion that I had before, that it is possible, with a single request, to query ALL of the ADC channels of the HTPB at once.  I had no function for that so I extended the current driver with a new function:

void HTPBReadAllADC(tSensors _link, tBuffer &_oBuffer, byte _width)

Reads all the analogue channels on the Protoboard at once.

This really pushed up the number of readings I could get per second, going as high as 330.  Mind you, this is not the number of I2C requests made per second, that would be 330/5 or 66. 

After speaking with Dick Swan, one of the principal developers of RobotC, the Faster and FastSkipStates for the 9V sensor types were added to both the firmware and the compiler as they only existed for the standard sensor types prior to this.  Officially the HTPB is not supported at these speeds, at least not yet.  It does, however, seem to work without any problems.  At the Faster speed, the MAX127 can be pushed to 330 reads per second, using the HTPBReadAllADC() call, the HTPB can crank out a very respectable 833 readings per second.  For ludicrous speed, the FastSkipStates will allow you to go as fast as 500 reads per second on the MAX127 and 886 on the HTPB.

To make sure that the readings were not erroneous, extensive testing was done with the HTPB.  A program was written to write a sequentially increased number to a specific register and read it back a predetermined number of times at various speeds.  If a different value was read back than was written, an error had occurred.  I did 250,000 individual reads at each speed and found no errors.  HiTechnic are currently doing their own tests to confirm this. 

You can download the test programs here: [LINK].