|
Re: TrackTwoColors execution time
I fooled with this a little more tonight. I changed the image size to 160x120 and reduced the frame rate to 5Hz. Using the spy utility I can see that camera-related activities are consuming nearly 50% of the CPU bandwidth.
It looks like there are some memory problems with this code under certain conditions. The demo runs with the FRC_Robot and FRC_Camera tasks at the same priority. In our code, we run the camera demo stuff in its own task. If you lower the priority of the FRC_Camera task (raising the number in VxWorks) relative to the demo code (in whatever task context) you will get occasional memPartAlloc errors that eventually kill the robot. So there are some possible mutual exclusion issues with the FRC_Camera task and the demo code.
It looks like my comments about the waste of getting 2 images might be wrong. They change the image while looking for each color. But it may still be more efficient to copy (and there is a method for this) the camera image than run GetImage again.
|