[yoyodyne]

Greg,

Thanks for the response and help. We think we have a deterministic 15fps solution for 160x60 pixel images. We don't need much vertical FOV because our camera is mounted toward the top of our robot on the shooter turret so we can throw away part of the image.

To get around the problem with the thresholding not taking different input and output files we read a 160x120 image from the camera, crop it to 160x60 and then copy it. We use the first image for color1 and the second for color 2 that way we know that we are not using different frames for color 1 and color 2. We break the processing up as follows:


If a new frame is ready:
Threshold for color 1 (about 10ms)
Set state to threshold for color 2
Else return and test for new frame ready the next periodic cycle (20ms later)

If state == threshold for color 2
Threshold for color 2 using the image copy (about 10 ms)
Set state for particle processing
Endif

If state == particle processing
Do all the processing for both colors that is in the dual color example code (about 14ms)
Return results to tracking code
Endif

Because our frame rate is 15fps 66.6666 ms period we get a result every 3,3,4 frames.

To us, the advantage of this approach is that we can insure that everything we will ever do in either teleop or auto mode will be complete in less than 20ms so the system operation is predictable. When I was a young engineer one of my first supervisors drilled into me that "Synchronousness is next to Godliness". If you take the approach that you are going to run the image processing in a separate thread at the same or higher/lower priority then it becomes much more difficult to prove that other processes like the traction control loops for instance will always execute as intended.

Anyway, that is our solution and so far it looks like it will work.

Greg