lots of questions

[frank26080115]

first, is there a maximum or minimum? also does the space in between the values = 0x20? is there a space between the SM and the first number? and are there leading zeros? does the values have to be specific values identical to the way your software lets me set it?

does anybody have example code for uploading a colour map? i'd appreciate that a lot.

[johno]

A maximum or minimum what?

Assuming you mean for the color map (?), there is a space between the "SM" and each number in the map. Each number is represented as an ASCII value.

If you want to see what a properly formatted color map setting command looks like, you can turn on more verbose debugging in AVRcamVIEW to actually see all the commands sent from AVRcamVIEW to the AVRcam. This should provide sufficient example of how to interact with the system.

[frank26080115]

I checked out the log, i think i know what is going on, that method is ridiculous...

so the first set of numbers represent 0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 240 for red, then another 16 numbers for green, then blue

each of the 8 bits of the bytes represented by those 16 numbers represent if each "colour" matches the values represented in my previous paragraph?

and then all of that has to be turned into ASCII with spaces in between?

why can't you just make it 34 bytes, "SM", then a minimum and maximum for each shade, and not ASCII?

if chip memory is a problem, then I'd be more than happy to pay an extra $5 for some improvements.

so for now I'll upload a default map from my windows desktop computer
are the camera registers stored in RAM or EEPROM?

oh and by minimum and maximum i mean like the shade brightness thresholds a pixel must match in order for it to become a part of an object

[johno]

I'm sorry if you think the color map method is ridiculous...I suppose it would have been possible to formulate the structure of the user-provided color map in a more sane manner (while performing the internal mapping to the needed color map structure as it is currently represented).

That is the beauty of open-source though: it is a fairly simple exercise to review the source code, and make changes where needed. Would you be willing to suggest and implement an updated color map command interface for the system?

[frank26080115]

I'm still reading through the ov6620 datasheet and your source
personally i'd prefer a colour ratio based tracking

im having trouble understanding how to interface the camera. it seems your source grabs the data then sends the data repeatedly, i'd like to get them all in one go and store them in an array variable. if you can provide me with example code to get that done

I can try using edge detection to find objects, and use a average shade to determine if that is what the user is after. or ratios between colours so brightness or darkness is not a problem

uploading settings will use a command byte, just a single byte, an address byte, then the value you want to put into that address

and instead of tracking packets, the user request values of a specific register, so if i wanted to know the x, i ask for x, first by sending a request command, then the register number for x, then the avrcam outputs a single byte telling me where x is.

i'd also forget about the ACK except for pinging

frame rate is going to suck after all that but, i would make it so that the user requests a specific info, and even if the frame hasn't been updated, the user can still find out what he wants super fast

I've programmed my own minesweeper game before, and also a image differencing program, i can probably do it if i knew how to use the camera

[frank26080115]

if i can calculate the RGB values for each pixel using the microcontroller, i will take the red for each pixel, and if it is significantly different from any of the adjacent pixels, it is tagged as an edge. do the same again for green and blue.

after all the edge pixels are found, i'd pretend it was minesweeper, scan the image for the first non-edge pixel, remember it's position as the top edge depending on my scanning order, and remember i've already gone through that pixel. i'd then check the adjacent pixels to see if the solid mass connects, if it doesn't it is ignored for now because it belongs to another edge, if it does connect it is marked as already scanned, the last one scanned will be marked as the bottom. Then quickly scan the vertical colums from the left and find the left edge at the first encountered "already been counted" pixel, do the same from the right.

now you have the position of that object, now turn 4 bit shade value into 2 bits and add them all up, now you will have a rough average, which then you either report to the user, or process that even further by getting the ratios between the colours, if red is significantly more by percentage, then the object is red, etc

now that area has been marked old, mark them all again as edge and repeat the above algorithum

resolution can be reduced in order to increase processing speed and more useful data
all any body wants to know is where it is, how big is it, and what colour, all roughly, it's already a low resolution

[davedave]

The mega8 doesn't have the memory for a full screen dump, neither does a mega128 for that matter.
Getting the colour in YUV instead of RGB is possible but much harder to utilise - the screen shots from the Java half look weirdfor starters.

The various oddities in the code (correct me if I'm wrong) are largely there to get around the limitations of an 8 bit micro controller with 8k of ram. After pouring over it for 2 months straight a couple of years ago I still haven't thought up a way to measurably improve it, other than YUV config which I'm too busy to play with right now. I'm sure we (or John) could port the code to a 32bit controller with 8MB cache but then it wouldn't be a simple, neat and cheap system.