Bugs in AVRcam firmware

When I came across the AVR and CMU cameras and checked out the videos in their respective sites, I was convinced that building a line follower using a camera is more fun and less time consuming.

Since CMU camera is proprietary I decided to start working on building the AVRcamera.


But alas, I quite didnt realise that a camera being more sophisticated, the software required to filter out the useful data will be far more complicated and hence prone to bugs. When I got my AVRcam up and working, it was very very unstable. It was then I realised using a camera is not a piece of cake, but just the opposite :).


I will list out a few major problems I faced:

1. After taking one snapshot, the camera would not respond until it is power cycled.
2. If I somehow get it recognise an object, it would provide data for max 10 seconds and then hang.
3. The tracking data was only sometimes accurate and very noisy.

So hoping that this is not due to hardware problems , I sat down to go through the code.

Since at that time, I was not much familiar with either image processing nor AVR assembly (did not even know how many registers are there :) ), it was not an easy task. However, I just skimmed through the basics of both and went ahead with my work, reading as and when required.

I went mad the first 2 days.

On my third day, I had a brainwave... Application Binary Interface, very important if you are calling assembly routines from C. Cursing why I didnt think of this before started looking for errors from this perspective.

From then on, I found a series of bugs which I will now describe.

Bug1)
The ABI clearly states which registers are saved by the caller and which registers must be saved by the callee.
The assembly routines in AVRcam freely use the registers without conformance to the ABI spec and hence end up corrupting the frame pointer of the caller and a few other callee-saved registers. Adding a few push-pops was enough to get around this problem.

Now I was able to take continuous snapshots without the camera getting hung :). But still tracking was very problematic. Encouraged by the first bug I continued my work.

Bug2)
The usage of each resister in the assembly code is clearly documented, giving a name to each. There are also warnings at appropriate places cautioning which register names are not to be used simultaneously since they share the same register. But this warning is indirectly ignored when the register which stores color information is again used in an interrupt call without saving it first. Hence color was getting corrupted.

If you look at the code, the consequences of this mistake are so subtle its almost impossible to identify this bug if this was the only bug present. It certainly appears as if the camera is giving wrong information.

Well, there was no visible improvement in the camera and it was still hanging after giving tracking information for approx 5 seconds.

Bug3)
In the firmware, the T bit of the SREG register is used for a very critical purpose. It is set in an interrupt call and indicates the end of line that is currently read.(In this real-time image processing method, each line is read and the data is processed before reading the next line of the frame). But this bit is not being cleared. So if this flag is set before calling the routine which reads the line, the line will not be read and more importantly, an event indicating the end of line is not generated. Hence the camera hangs. Clering the T bit at the start of the routine solved the problem.

I am now able to get continuous tracking data. I wondered how other people have managed to use the AVRcam with all these bugs. I guess since these bugs are not consistently reproducible and also changing the optimization level somehow makes the code work a little better, the bugs were ignored.

After fixing these bugs, the camera became stable. But the changes in the assembly code has resulted in getting the camera and the controller out of sync.

In AVRcam, the clock of OV 6620 image sensor is used to clock the atmega8. Hence the pixel data is automatically synchronised.

Well not exactly, we need to carefully synchronize the start of data and again resync if processing is required. This is proving a little tricky since I cant really see the data.

As of now, I learnt a few tricks to help me do the sync'ing and I am hoping it will be done in a day or two!

Working with a camera is certainly more fun and informative than working with the traditional line following mechanisms.

Also, using a camera gives much wider scope for improvements and of course more challenging. Yup, price is a bit too high but not so if your budget is in tens of thousands and vision is critical in your Robot. Also I guess its just a matter of time before the prices fall.

By the way, if anyone in India wants to purchase the AVRcamera or want the fixed code (free :) ), do mail me at gjayanth8[at]gmail[dot]com.