Hardware please give us a break

So, Hardware hasn't been nice to us. After our voice recognition circuit failed, we had to start working on a plan C while we are waiting for the PCB to arrive. We decided to try to add image feeding to our project. The idea is that the car would have a camera, that would take pictures. These pictures would be sent to the user controlling the car via the xBee connected to the car mBed. The xBee of the user would then get the picture data, send it to the mBed of the user, which would create an image file that the user would be able to see.

We managed to run a simple program to take a picture, and save it on a file. Of course, we had to give you a picture of ... Jefta Jawi, who loves being in front of the camera.

From Camera

Yes, he was posing for the camera.

But, at first we didn't go very past that. We had to find a way to send the image via the xBee, and then things started failing on us. Even our xBees that once worked fine, stopped working for awhile #don'tAskMeWhy.

New day, new trial, we got the xBees to transmit data once again. Yeah, I know. This just put us back where we were in the start, but it makes us happy to know that our xBees are not broken #hardwareFinallyGaveUsABreak.

Those of us who believe that late night coding is the best coding, you are RIGHT! Our program was tired of failing and we finally cut a break. We managed to have the mBed take a picture, save it on its local memory. Then, the file was open and copied to a second file. The proof is here:

Original Image

Image Copy

Yes, I know that this is just my lamp, but believe me: you don't want to see me on camera right now.

Now that we managed to open an image already taken and copy it into another file, we are ready to try to send the file via the xBee and writing it into the second mBed. Basically, most of our problems about writing into the file is that previously we were trying to hack the code to take the image, and send the file at the same time that it was being written #ABadIdea. So now open the file after it has being written seems to be a better option, since we will know the size of the packages that we are sending via the xBee.

Those who believe that late night coding is the best coding, should also believe that one needs to get some rest. Therefore, the xBee sending of the image will be left for tomorrow. If you are trying to take pictures with the mBed and the LS Y201 camera, here are some tips that really helped us:

Whenever there is a file being written to the file system of the mBed, it will disconnect from your computer. Whenever the mBed is done writing the program, meaning that a fclose is reached, it will reconnect to your computer automatically. If you don't see it come back, then move to bullet two.

If there are any bugs on your code and fclose is never executed, you will not be able to see the mBed again. Yes, I thought I burned the microcontroller #scary. In order to be able to see the mBed again, disconnect it from your computer, press the reset button and KEEP IT PRESSED. Then compile a new program that you know that works and connect your mBed to your computer. You will see the mBed again. Don't move your finger quite yet. Download the program into the mBed and then stop pressing the reset button. And voila, you can see it again. Make sure that you then debug your code to see why the file was not closed before putting it again into your mBed.

If you had a bug on your code, it is very likely that you opened it on the wrong mode (i.e. you opened as a read, and tried to write to it). Well, at least I did that many times.

The fact that the mBed keeps disconnecting is really annoying. Therefore, it was easier to create a txt file and print there everything that I would have printed if I had a print statement. Then, after the mBed is done (or after it fails), you can open the log file to see what happened.

If you are using the code showed in the example at the mBed page, you might not ever see your mBed connection again, since there is an infinite loop there. To be fair enough, we saw print statements on the terminal a couple times, but when we ran the code other times, we didn't see anything ebcause the mbed was disconnecting. I would recommend you breaking out of the while loop after you've taken a good number of pics, and then going back to your log file and seeing what happend.

mBed cookbook is your friend. And we are too! If there is something that you can't find there, reach out to us and we will try to help you if you can.

Voice Recognition (Attempt #2)

Guess what? Turns out the breadboard was fried! We rewired the whole circuit on a completely different board and voila! The LED turns on! But that's about it. The LED is supposed to turn off when a key is pressed and it is not doing so. Since we are realizing that this voice recognition circuit is going to give us trouble, we have already reached out to other blogs and other groups that have used it in the past and that could maybe offer some assistance.

Some of those links are listed here:

1. http://letsmakerobots.com/node/26178
2. http://www.projectbloc.com/seniorproject/
3. http://www.the4cs.com/~corin/cse477/toaster/FinalReport.html

Unfortunately, some of these blogs are about ten years old and although we have contacted them, the information about the circuit is limited. Additionally, a lot of the projects that use the HM2007, actually used the preassembled PCB board, and therefore aren't very helpful. On the most part, the advice people suggest is to just double and triple check the wiring and that eventually it should work, unless the chips are faulty (which is a real possibility).

After the half-way demo, our professor suggested we go ahead and buy the PCB as a back-up plan and meanwhile continue trying to make our wired circuit work.

Since we want to have a complete project by the time of the actual demo, Jefta has started working on another Plan B. This consists of building our own remote control that we would integrate with the XBees and mBed that we already have working. Hopefully we won't have to come to that but better safe than sorry!

Now to the umpteenth rewiring attempt....

Voice Recognition (Attempt #1)

Our voice recognition chip arrived! Together with an 8KB SRAM and microphone. We wired the circuit according to the schematic on the website (link: http://www.imagesco.com/speech/sr07schematic.JPG), but unfortunately, nothing seemed to be happening!

There is an LED connected directly to one of the pins on the voice recognition chip (HM2007) that is supposed to light up indicating that the chip is ready for interfacing. This LED was completely unresponsive.

From Voice Recognition

This is a picture of this circuit with the HM2007, the SRAM, a latch, and two 7-segment display decoders.

Remote Controlled Car

Having figured out how the XBees worked, we integrated them, the mBed and the ping sensor with the car. This video shows the accomplished PC controlled car.





Now that we have a remote controlled car, time to move on to the meat of our project....VOICE RECOGNITION! (fingers crossed)

Playing with XBees

When our XBees arrived, we immediately began by trying to understand how they work and implemented some sample code found online in the mBed forums in which one XBee is connected to the mBed which reads input from the PC and another XBee is connected to the USB Breakout board which prints out the letters it receives wirelessly.

Since the XBees don't have pins that can fit onto the breadboard, and since we weren't aware of that fact, we had to improvise and mount the XBee onto individual pin sockets in order to allow us to connect to the pins needed and for it to stay stable on the board. A picture of this can be seen below.

At first, we couldn't see any of the the letters being printed on the terminal. We tried using a Mac terminal and the Hyperterminal on the Detkin Lab computers but to no avail. We then found out that the XBee has a baud rate of 9600 and that the mBed doesn't necessarily have that specification. After a bit of research, we quickly found out that the mBed configuration could be easily changed using the *.baud() command. After doing this and setting the terminal configurations with the same baud rate, we finally saw the letters being printed.

For some reason, we cannot seem to print the letters from the XBee to the Mac, but it seems to work fine on all other OS's.

Wheels + Ping Sensor

After much thought, we decided that we would only use mBeds in our project as opposed to one mBed and one HCS12. Originally, we thought it would be better to use the HCS12 in the car to control the motors since we already learned a lot about PWM in class, but since we need to interface it with the XBees anyway, we decided that it would be best to stick to one platform and learn it well in order to accomplish more with our time. Learning how PWM works in the mBed wasn't too much trouble since a lot of help was provided in the forums.

Moving on, phase two of our project was to add the Ping Sensor to our circuit. The idea is that if there is an object in front of the car, the car will stop even if the user tells it to do otherwise.

The coding wasn't too difficult, but we had a lot of hardware problems. First, we were powering the Ping sensor with an external source and we didn't connect the grounds of the external source and the mBed together. This mistake took us a couple of hours to figure out. Another problem was that for some reason, the USB port of the Mac computer that we were using wouldn't work to power the mBed when we had both the Ping Sensor and the motor working together. Simply changing the connection to a Windows computer solved the problem. We are not sure of why this happened, so maybe Apple can answer that for us.

Next Steps? We will now work on integrating the Xbees with the circuit, so that we have a remote controlled car.

RC Car Tear Down

The first day efforts consisted in tearing down the car to understand how it works. On the bottom, the car has the battery holder. After removing it, we could have access to the IC that controls the car. There are two sets of wires that come out of this IC: one for the motor that controls the front wheels and another for the motor that controls the right wheels.

The back wheels only move forward and backwards. The front wheels only have controls to set their direction as straight, right or left. Apparently, they move with the impulse generated by the back wheels. On the pictures above, one can see the set of gears that controls the direction of the front wheels.
We didn't try to understand the IC that composes the board, since we are constructing our own circuit.

After the tear down, we used the HCS12 to control the wheels, which was our first accomplished milestone with this project.