TrackTwoColors execution time

[Tom Bottiglieri]

It seems (at least in our tests) that the TrackTwoColors function from the example two color tracking code is bogging down the cRIO to an almost unusable point. Has anyone else had this issue?

Symptoms are as follows:
1) When function is called in sequence with motor control code, execution of the main loop is slowed to a few Hz, lagging operator control.
2) Code runs relatively quick when there are no HSL color matches in view. As soon as a pink or green target appears, regardless of orientation, the process slows down immensely. This makes sense, but the lag seems very big for the amount of code that is running.

To fix #1, we split the object matching code out into a separate thread, which fixed the motor update lag. Unfortunately, our servos now overshoot the target by quite a bit before the "target found" flag is raised.

We tried to characterize the execution time of the code block, and came up with the attached graph. I don't have the source on hand, but it looked something like this:

/*This runs in a seperate thread, so I have no idea how the other threads effect execution time.*/
Timer timer;
float start,finish,delta;
timer.Start();
while(1){
   start = timer.Get();
   TrackTwoColors(params here);
   finish = timer.Get();
   delta = finish - start;
   cout << start << "," << delta << endl ;
}

A graph generated from the stdout is attached. The low points happen when the camera is panning with no target, and the peaks occur when the target is upside down. The high holds occur when the target is oriented the correct way.

Is there any kind of hidden debug stuff going on? I have turned down all the do-debug flags in target.h, but I don't see a difference. I don't want to re-write a signal processor, and want to make sure I'm not alone before I start any such work.

Link to graph: http://i43.tinypic.com/119w6k9.png