Sunday, April 13, 2008

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.

Friday, April 11, 2008

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.

Monday, April 7, 2008

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