Camera Starving Watchdog

[daltore]

Last night we noticed that the lights on our Jaguars randomly flicker every once in a while (we still have our electronics mounted on plywood away from the robot so it's more convenient to test things on both platforms). A couple of details on our system first:

- We're controlling a string of Jaguars through CAN, bridged through a black Jag. We currently have 5 active.
- We've added code to the default FRC 2010 project that comes up on LabView. We have changed Begin.vi and Teleop.vi, and nothing else.
- We're using a modified version of the camera tracking code found in the case statement in Teleop.vi which moves the camera on a servo (for now, again, electronics separate from drive train).
- Drive system is mecanum, driven off of the Holonomic Drive VI that's been modified twice (first for scaling, second to convert to CAN from PPM).


Anyway, this morning I narrowed down the blinking to a watchdog error (noticed the blinks corresponding with a very brief DS "Watchdog Not Fed" message), and a bit later, I found that after disabling most of our custom code and trying the default CAN project (which worked fine), that unplugging the camera ethernet cable stopped the watchdog problems, and plugging it back in started them again. I lowered the resolution from 320x240 to 160x120, and it's been fine so far, but camera tracking is less reliable up close.

The difference between the working CAN project and the FRC project is that the CAN project opens the camera and gives it a reference number, whereas the FRC project opens the camera, sets the brightness, exposure, color threshold, compression, resolution, etc...

Does anyone know what particularly is going "wrong", if anything? I would imagine this is no where near the limit of the processing power of the cRIO, I've seen them do way more on FRC demo videos (remember the OCR demo 2 years ago?). If at all possible, I would like to lower the color depth instead of the resolution, because in all honesty, 32-bit color depth doesn't add much over 16-bit when you're dealing with a webcam. First of all, there's an entire byte that's being processed for an alpha channel that doesn't exist, and by flattening the colors to thousands from millions, I think the camera software might have a bit easier time recognizing shaded surfaces as contiguous.

Opinions or suggestions?