2010 FRC camera vision tracking delay, image processing lag

[pspeer]

We are running modified code based on the 2010 FRC Vision Sample Code (released 2/3/2010). Our live video feed is almost real-time as it is displayed on the classmate. To achieve this, we are using the latest driver station console but have removed the linear sliders located above the gyroscope gauge. This solved initial lag problems associated with the camera stream.

Now in our code, we notice the targeting function takes 167 ms to execute, where approximately 50 ms is used converting an HSL image to grayscale and the remaining 117 ms is used for “target image processing” where colored arcs are drawn around potential targets.

Have other teams noticed this “target image processing” lag?

When called, the targeting function blocks execution, the processor is busy comparing pixels to find the target and code in the main OperatorControl loop is halted. Since code in the main loop executes every .167ms (5-6 times per second), the delayed reading of joystick values causes a jerky motion and the robot feels unresponsive. This is not acceptable since we would like to use the targeting function to process data continuously during the match.

Our solution:

We want the targeting function to run outside the OperatorControl loop. We are considering the creation of a new “task” for the vision code to run independently in its own “thread” similar to the compressor class. However, since multi-threaded applications are complicated and hard to debug, we wanted to post this on the forum first.

Could Brad Miller comment on a good solution to the problem? (Is there something obvious we are overlooking)

Have any other teams implemented a tracking "thread" for independent vision tracking?

Will you post sample code on this forum?