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