Rockhopper wins expert division and 2nd place in hide and seek!

I am happy to say that Rockhopper v1.5 has repeated Rockhopper v1.0's win at Trinity! On my first run I got the perfect run of putting out both candles, found the baby, and went up and down the ramp to the second floor. This was something I was unable to do last year and I believe the first time this has been accomplished by any robot at this competition.

Things however went downhill from there. On my second run I hit the button to start and...... nothing. So this run was a bust. I took the robot back to my table and began to debug. It took some digging but I found it was just a bad connector. I was able to replace the bad wire and I _thought_ all was well.

I didn't have much time between when I thought I had fixed it and my next run. So, on my third run when I hit the button it _did_ move however very erratically as soon as I saw this I knew what the problem was. In the process of trying to figure out what was wrong I had disconnected my A/D connector so essentially the robot was completely blind. Worse actually because with the cable disconnected I just got random signals in place of my range sensors. So this run was a bust as well.

However my robot being the only one to accomplish any tasks was still by far the winner in the Expert divsison.

On to hide and seek.

Last year the expert divison was not eligible for the "Hide and Seek" competition. I just noticed in the rules about a week ago that this year it was open to all robots in the competition. The challenge in "Hide and Seek" is to find a baby in the maze. The baby is the same as in the expert division where they have a 15 watt light bulb painted black to simulate the body heat of the baby. The robot simply must find the baby and signify it has done so by either turning on an indicator light or (for a bonus) have an audible voice that it uses to say it has found the baby. I could not do the voice but the rest is the same thing as the robot already knows how to do from the expert division.

The robot gets 3 runs for this competition also. On my first run it found the baby but it signified that it found it outside of the 30cm limit so it didn't count. On my 2nd and 3rd run it found the baby both times but on the 3rd run it took quit a while so I didn't get a great score. Still, I figure 3rd place in an event I had not planned to do and never had any time to write special code for is pretty good.

So now, over the next week or so I plan on getting my thoughts down on paper with new ideas and such. I am also going to investigate what went wrong to try to avoid it next year.

Greetings from Hartford

We just got to Hartford. The competition starts tomorrow! Well, technically tomorrow (Saturday) is for registration, practice and qualifying for the actual competition on Sunday but honestly Saturday is when all the fun is since that is when you meet other builders and see what they have done. On Sunday everyone is more concerned with the competition itself so there is less socializing.

I think I am in pretty good shape. Since my last post I have worked on improving the candle seeking and also added some code to re-find the candle when it looses sight of it. I also have it finding the "baby" fairly well however it is really sensitive as to the hight of the light bulb they use to simulate body heat. They do not specify how high off the ground it is but they do have a picture which I used to estimate it. Hopefully I can practice with the real thing some tomorrow.

I worked on it every evening this week also except last night (didn't get home from work until after 9:00). Most of this week has been working on some reliability code for recognizing when it is stuck. Last year I used wheel rpm to determine if the robot is stuck but this year I have tried a new method of watching the distance sensors. If it doesn't see enough variability in the distance sensors it assumes it is stuck and backs up a bit. From experimenting this seems to work well.

I also worked on some "intelligent" navigation code. OK, it isn't all that intelligent but should be an improvement over what I had last year. Last year it simply followed one wall for a while, then switched to the other wall. I found that it often picked a very inopportune time to switch so I have improved this a bit. First it only switches which wall to follow when in a hall. I realized last year that if it switches when in a room it is just going to go out the same way it came in and retrace the same steps. The other change is instead of switching after a specified amount of time it is watching the wheel distance sensors. If one wheel has turned considerably more distance than the other it thinks it might be in a loop. I set the threshold on this so it actually goes through the loop just over 2 times before it does this so it shouldn't do it too soon. I may tweak this setting some tomorrow as I experiment in the real maze.

The maze we get to practice in will not be the same layout as the competition but it should allow me to see how my code changes should work out in general. I plan on having Jane shoot some video as I run it through some simulated runs. I just realized I forgot my firewire cable so I won't be able to upload video until I get home but I do plan on posting some video of it on youtube or some place like that.

Final full build day

The final full day I have taken a vacation day for is here. The competition is this weekend. I think I am pretty close to "done". Of course projects like this are only really done when you are out of time, there is always something that could be improved upon.

The general navigation is working well, better actually than the original Rockhopper from last year. The advantages v1.5 has is it is a few centimeters narrower and also the fact that the PWM control for the motors is running on the AVR which is more dedicated to the task which gives me finer grained control than running it on the ARM (Rockhopper v1.0 updated the PWM in the kernel timer interrupt at 100hz, the AVR updates it at 2khz).

I did run into a couple of major snags. I bought a couple of USB-i2c adapters and planned on using them to talk to the AVR board. It turns out the AVR i2c implementation has some latency issues and the USB-i2c adapter has a short timeout. The end result was the i2c adapter would time out before the AVR would respond. This seems odd considering the AVR implements this in hardware but the i2c adapter really needs a way to set the timeout. Unfortunately the adapters are not open source so I can't do anything about them. Sounds like I need to design my own open sourced USB-i2c adapters next year.

The fallback plan there was to use the serial ports on the ARM and AVR for communication. The fastest I seem to be able to communicate is 19200 baud. Any faster than that and I get too much error to be useful. Considering I am not sending a large amount of data between the 2 boards I expected this to be fine however this led to my next big issue... not throughput but latency.

The latency is so high (I don't have specific numbers but I wrote a test program to demonstrate it) that the robot becomes uncontrollable. The situation is this: AVR grabs sensor data (such as from the ir range sensors), ARM reads that value over the serial port, ARM decides it is too close to the wall and writes a new speed to the motors over the serial port... by the time all this happens we are even closer to the wall so on the next iteration it needs to turn even more abruptly... then suddenly we are poiting directly away from the wall and need to over compensate toward the wall.... The end result is it wildly veers toward and away from any obstacle and makes very little forward progress.

The fix for this was to implement all of the time critical stuff directly on the AVR. Programming the AVR is simple enough but it is much harder to debug than running on under linux on the ARM. However, most of these algorithms are essentially the same as I have used on several robots in the past so I wasn't starting from scratch. I ran into various snags on stupid little bugs that took considerable time but it is all working well now.

So, with less than a week to go where to I stand? Navigation (in the follow a wall and don't run into anything sense) is working well. It finds the candle fairly well but not as well as I would like (that is the highest priority for today). Once I get finding and blowing out the candle working well the next plan is to work on reliability. The thing that won the competition for me last year was the reliability, it simply _never_ got stuck. If it can continue to explore the maze it should just by dumb luck eventually find the candle.

Lowest priority just as last year is finding the baby and dropping the beeper (see rules for what I mean). I hope to be able to get this working as this is the one task that Rockhopper never quite did successfully last year and I really would like to get a perfect score on at least one of my competition runs.

Now, back to work....

Rockhopper v1.5

As usual I have been bad about updating my blog. I have started on a new version of Rockhopper for this years Trinity College Fire Fighting contest. I certainly can't take 8 weeks off like I did last year but honestly the majority of that time was spent figuring out how to do things so by taking what I learned from that I should be able to do this one much more quickly. There won't be any major new ground broken with this one (which is why I call it v1.5 instead of v2.0) but it will be a "refined" version of last years design. Much of the code will be re-used from last year with some updates. I am using the same linux kernel as before also so that is a lot of time saved not having to re-do that.

The highlights:

It is smaller. Rockhopper was just barely within the maximum allowed size of 30cm (in all dimensions). Rockhopper 1.5 is about 22cm wide and long. This should make it able to maneuver past obstacles more easily.

Cleaner wiring. Since much of how I am doing things is the same as last year I know ahead of time what is going in. The problem with Rockhopper is I was a lot of it was designed as I went.

New ARM board. Ok, mostly this is because I accidently fried a not-so cheap piece of hardware :( but it gave me a good reason to update to an TS7400 board from www.embeddedarm.com. Nice features of this are that it is smaller and has an SD slot so I can easily have 2G of flash space. I also can boot from the SD card so I can have a full linux distro installed. I am using debian right now since an ARM image of debian was already available. I am normally a Fedora user and I hear some people are working on an ARM port of Fedora so I might go with that later on.

New Flame sensors!!! This is something I have been planning on designing for a long time and should make things much cleaner and more reliable. The picture here isn't so good. I will see about uploading a better pic later on. This is a small board with an i2c A/D converter on it and 4 IR phototransistors. I have used the phototransistors on my last few robots and they are simply _by_far_ the best way I have found to find the candle. Perhaps I am giving away one of my competitive advantages but I believe in sharing of info :)

The IR phototransistors can be bought from digikey for something like $0.75 each and are part number op599a. You don't need a fancy board like I designed. Use a 47k pull up resistor on one side and put the other side to ground. Connect one of your microcontroller's A/D ports between the resistor and the phototransistor. Works perfectly. It can be fooled a little by incandescent light bulbs or bright sunlight but if it is shaded from above I have found that isn't a problem. Also, does not get fooled at all by florescent lights or the sodum vapor lights used in the gym at Trinity.

I am considering starting a small (very small) home business and selling these boards. Probably not for any real profit but hopefully enough to offset my robot building costs. If people have an interest please post a comment here. I am guessing I could sell them in kit form for probably $25 each. However since the chip is a surface mount I imagine that would scare off many hobbyists. I might sell assembled boards for probably $45 each (need to figure out how much it is worth to me to solder a bunch of these myself).

For those of you going to the contest at Trinity come check them out and we can all see how well they really work.

Back home again

After 30 hours door to door I am back home again. Who knew Australia was so far away :)

For those of you who saw my presentation at LCA my slides are now up on the web page. There are a couple of slides I didn't bother showing during the talk which has references to software and hardware I used on Rockhopper. It can be found on the LCA page at: http://linux.conf.au/programme/thursday

I had a wonderful time at LCA and honestly it was worth the long trip. I spent a couple of days more in Melbourne. Of course this meant I was there for the superbowl which I was a bit concerned that I would miss it. I wasn't sure I could find anywhere showing it in Australia. Boy was I surprised! I checked a couple of sports bars but none said they would be open that early (since the game was shown live it was on at 10 am there). I was told the best bet would be the crown casino. I expected to find just a few American's there begging the bartender to turn it on to "that american football game". What I found was a large sports bar with probably 200 very excited football fans. While there met some really fun Australian fans and of course a few Americans spending some time abroad. So, I want to give a special G'day to Gary (aka Gazz), Rod, and Jamie from down under and Melody (from the US) and of course "guy from California" who I am ashamed I cannot remember your name.

Even though the Pats lost it was a hell of a game and I had more fun watching it than any superbowl I can remember.

So, now that I am back home I am already starting to think about possibly building a new bot for this year's contest at Trinity College. I have just about 2 months to work on it and this year I certainly won't be able to take a bunch of time off like last year. Still undecided but I am considering it.

Greetings from down under!

Yes, I am a horrible blogger. I have not updated the blog since the contest and yes I am quite ashamed of myself.

So certainly time for an update. I am writing this update from a hotel in Melbourne Australia where I am attending Linux Conf Australia. My manager urged me to submit a proposal to do a talk about Rockhopper to LCA a few months ago which got accepted. It is pretty cool that HP sent me here to talk about something that was not HP related (although I did talk about a lot of HP specific stuff with various people during the week).

The talk itself went very well and was voted one of the best in the conference. I was asked to do an encore of the talk today during what they call "Open Day" where members of the public can attend. I didn't think today's talk went quite as well as the first one but still not bad. The best part of the talk was the demo of the robot itself. I was not able to bring the robot itself but what I did do was set up a webcam in my workshop and run live streaming video. When I came up with that plan I gave it a 50/50 chance of actually working (it is from the other side of the world after all) but it worked perfectly. Special thanks to Paul for helping out on the New Hampshire end. He powered up the robot and lit the candles and most importantly he was there in case I ran into network issues (luckily there were none).

I plan on posting my slides and code for the robot online soon (yes, should have done that months ago). Hopefully that will happen in a week or so. I am staying a couple more days in Melbourne to do the tourist thing (have not done anything but the conference since I got here).

The video of my talk can be found on the LCA web site.