After my slight diversion post of The Old, the New, the Data and a wonderful two weeks with my grandparents, I figured I should update you on my progress with my NXT venture, but before I begin, I would like to point towards a site called MarkPond, a bookmarking service that Alex Forey, a fellow pupil, created within two weeks and hosts the whole thing on two Raspberry Pis. To be honest, I have had one much longer than him, but I was too lazy to do anything with it as of yet. If you have any ideas, please let me know!
Ultrasonic Sensor
 |
| The ultrasonic rangefinder |
This was an interesting sensor to crack! From my experience working with ultrasonic range finders, I assumed that, as with the SRF05, one sends a pulse to one pin and then waits for the return pulse from another pin, with the delay between telling you how far away the object is. That was until I had a look at the LegoHardware Development Kit, detailing an I2C protocol for the sensor. I had heard of I2C before and knew that it was one of the standard ways one would chain multiple devices on two lines, the clock and data, SCL and SDA respectively.
Because I had no idea how to work with, or indeed wire up, I2C connections, I read up on the I2C protocol, and learned that one had to use pull-up resistors on the SCL and SDA lines. I also looked at the documentation Arduino had on it and found that Arduino's come with SCL and SDA lines, not requiring a digital or analog output, and a really handy library with which to communicate to devices on the lines. There was no need to learn about changing the clock speed or stuff like that.
But, alas, there was.
Lego, for some great reason, don't like to use standard I2C protocols, resulting in the SDA line needing a “wiggle”, as some described it, amongst other little annoying things, to make the sensor return data. My coding efforts were futile, but I found this helpful blog post, detailing how to correctly connect the sensor and providing the code. I even emailed the writer to ask for some more assistance.
 |
| The ultrasonic range finder breadboard wiring |
After some slight modifications and tests, I came to this setup. It works for most distances; however, one would occasionally get a “error reading distance” error, due to the fact that the 0V connection of the 9V battery was ‘hotwired’ into there, as I was using the 5V from the Arduino. Longer story. The sensor returns distances in centimetres.
 |
| Schematic of touch sensor hook-up. Image developed using Fritzing. |
 |
| Testing the sensor |
Sound Sensor
 |
| The sound sensor |
This was a really easy one to do! The Lego hardware development kit told me that this sensor was an analog sensor, like the lightsensor, with an open-collector transistor circuit. It was just a matter of hooking it up in a similar fashion to the light sensor and performing an analog read; however, I could not find anywhere on how to connect pins 5 and 6, so I looked at the schematic, but gained no valuable insight as to how to solve this dilemma.
 |
| Initial setup |
So, as any (aspiring) technician would do, I started, having failed at the methodical method, plugging them into random voltages, hoping against all hope that no blue smoke starts to emerge from the sensor. I managed to find a position giving me the most stable and wide-ranging readings, as seen in the schematic below. I have also included the code, although it is really, really simple, for documentation sake.
I was not sure whether pins 5 and 6 housed more advanced functions, such as precise sound data, but an analog value is good enough for me!
 |
| Schematic of touch sensor hook-up. Image developed using Fritzing. |
/*
This code reads the analog value of the Lego NXT sound sensor.
The schematic can be found on thecompblog.com
This code was written (badly) by Nicolas Weninger, auther of TheCompBlog.
THIS SOFTWARE COMES WITHOUT ANY WARRANTY, IMPLIED OR EXPLICIT, TO THE MAXIMUM EXTENT PERMISSIBLE BY LAW.
THIS INCLUDES WARRANTY AGAINST DAMAGE TO COMPUTER SYSTEMS, LOSS OF PROFIT, PERSONAL INJURY OR DEATH.
This code is in the public domain.
*/
const int mic = A5;
void setup()
{
Serial.begin(9600);
}
void loop()
{
Serial.println(analogRead(mic));
delay(10);
}
The Shield
 |
| The shield |
Well, this was an interesting story!
Having received great support in wiring my breadboard version of the ultrasonic rangefinder circuit, I decided to buy the shield to support the company as well as the fact that it would allow me and my school to do some interesting projects. The parts arrived on time and in good condition. I had previously persuaded my mother to let me buy a soldering station with solder, which was surprisingly not as difficult as I had expected! The parts were soldiered together with a few dodgy connections. Unfortunately, I did not have a multimeter on me and I was due to travel the next day, so I had no time to test the thing. It was only when I was at my grandparents place in Austria where I could test it.
The shield came with an L293DNE IC driver to power the two motors along with the complex external circuitry to read from the optical sensors inside the motor, so I would be able to control them with greater accuracy. It also came with the correct circuitry to connect the 9V supply to power the Ultrasonic rangefinder connection, allowing for more accurate readings and no more damn "error reading distance" errors.
A very good library was supplied, including many test programs. I uploaded these to my Arduino to test the functionalities of the shield and that they worked correctly. Everything was perfect, apart from one thing. One motor output would not drive the motor backwards.
I immediately presumed the worst and started re-soldering shoddy joints. Interestingly enough, my grandparents had a soldiering iron with electronic solder at home! So I soldered here and there, testing in between. The problem only got worse: the problematic port stopped working totally, then the good port started showing problems, then signals to the first port got sent to the second, until none of the ports were working!
I then assumed that the driver chip was bust. Before ordering a new one, I actually decided to properly troubleshoot the problem. After a bit of corrective soldering, I connected the pins of the chip to various voltages according to the schematic and observed the results. Both ports worked without problems. I then coded up a test program on my Arduino, manually controlling the pins connected to the driver. Both ports worked. Interestingly, when I tested I with the library, the initial problem came up again. I was baffled!
Using a few LEDs, I tested the outputs when using my manual code and the library. The only difference was that one LED would light dimly instead of brightly when using the library. Looking through the code in the library for some rogue PWM code, I was greeted with an insanely simple HIGH/LOW command for the enable pins of the driver.
Then, almost like a flash of light, it hit me. In my code, the pins had been defined as outputs.
The problem was that Arduino defaults all pins to inputs unless otherwise defined. Setting an input to HIGH turns on the internal 10K resistors, making my test LED shine dimly. In the library, that one pin was not defined as an output, resulting in the L293DNE not receiving a HIGH signal to provide power to the motors.
After a week of troubleshooting, the shield worked! I hope that I remember these lessons for my Systems and Control controlled assessment next year, where I will come across problems like these all the time!
 |
| Testing |
Using the library is pretty self-explanatory. There is really no need for me to post the code in this case! One can turn the motors a certain amount of degrees, at a variable speed, or both at the same time. It's not exactly precise: allow for a few degrees of freedom. If you are interested, go buy it and experiment yourself, or if you are friends with me, ask to borrow it. I would gladly lend it to you!
Next time, I should be finished with the color sensor. I have not started on it yet for a number of reasons, the most prominent being my geography homework, working with a document that has the most annoying and inconvenient formatting along with a mountain of data to sieve through, and that in the summer holidays. Also, they gave it to us 3 weeks late, after the time when I had a solid Internet connection to do what I like to call "research". Now, I have to do it within the few times I have a connection, elongating the pain of this futile exercise ten fold. "Enjoy the summer" they said. What a great joke coming from them.
(I like my Geography department! I don’t mean to be rude; just voicing an opinion. Don't give me a detention for that! Wait, if they do, wouldn't that be in violation of my freedom of speech right? DEBATE!)
