camera is off-center

[obeyken]

hi,

i just received and assembled the avr cam, and all seems to be working, except that the captured/tracked image data is considerably off-center.

if i manually line up the optical axis of the lens on an object, and perform a capture, the captured image is shifted quite a bit to the right. for example:



also, I found that while examining the tracking data of what should be a centered object, the reported x-values of the tracking box indicate a center of around 105-110 (decimal) whereas i assume it should be should be around 87 or 88. (while tracking an object at a distance of about 1 ft.)

moving an object across the vertical range yields a range of x-values from 0-175 (decimal), which seems to correctly correspond to the vertical resolution of the camera. it's as if the entire field of view is shifted to the left... maybe a problem w/ the camera module? the camera chip is mis-aligned?

also i was able to pop the camera module onto a CMUcam board, and saw the similar alignment problems via the cmucam pc software.

the horizontal centering seems to be ok.

firmware version is 1.4, board is 1.2.

i appreciate any thoughts on the matter!

ken.

[Guest]

Hi Ken,

I recall reading something about this issue with this camera module:

http://www.cs.cmu.edu/~cmucam/align/

This link goes into some of the details regarding the camera module itself. It sounds like the lens may be slightly off-centered in this case (from the pix you posted, it doesn't appear that it is as exaggerated as in the Acroname mis-alignment pix). Anyway, Acroname posted a fix for the issue, if you follow the above link. They do state that an offset of a few pixels is normal (which is what I have seen), but it sounds like your module may be more than a few pixels.

[obeyken]

That did it! i replaced the screws w/ really tiny machine screws so i was able to shift the optics housing enough to get things more or less centered.

Thanks!
Ken

[obeyken]

Hi again-

I'm noticing now that, while tracking, the range of x-axis values that are being sent in the tracking packets is between 0C and AF. Shouldn't the lowest value be 00? (I thought I had been previously getting the full range, but now I'm not so sure) I experimented some more w/ shifting the optics housing around a bit but that doesn't make a difference.

Thanks for any info...

Ken

[Guest]

Hi Ken,
Indeed you are correct. The minimum x-coordinate for tracking ends up being greater than zero. This actually has to do with the fact that when the first few pixels of each line are being spit out of the camera, the mega8 doing the processing is actually asleep. The HREF signal is used to "wake up" the mega8, and by the time it has executed its ISR to handle the interrupt and get back to begin processing the pixels some of them have passed.

Another person had pointed out to me that he had seen a similar situation regarding the minimum tracked x-position. I looked a little more closely at it and it seems that a minimum value of 0x0C seemed a little high to me (I believe I had calculated that maybe 4 or 8 pixels could be skipped). Another contributing factor here is that the AVRcam uses every-other set of pixels in each line; i.e., in a row containing 176 pixels, pixels x and x+1 are used, x+2 and x+3 are thrown away, x+4 and x+5 are used, x+6 and x+7 are thrown away, x+8 and x+9 are used, etc. Thus, there are maximally only 88 pixels that can be utilized in each row. Add to this the fact that there is some wake-up/ISR/returning from ISR time added in, I suppose the true possible resolution of each line is really closer to 76 or so.

Thanks for the heads up on this, and if you have any other questions regarding what is going on here don't hesitate to ask.

[Mr Potato Head]

Go straight through falkens maze....

[Guest]

Todd...is that you???

[Mr Patato Head]

Just a bit of humor there....How's it going John? This is a pretty cool web site...

I have been messing around with the Dallas DS80C400 TINI lately. It is a 75MHz 8051 with ethernet, JAVA and a web server. Pretty cool...

Todd