Problems with updating speed on the actual field

[sarangmittal]

At Peachtree Regional, we had some problems concerning the camera and a PID loop for the shooter. If we ran the camera during a match, the PID feedback would stop working and we would have no control over RPM. However, the second we disabled the camera in the FRC PC Dashboard, the PID loop would resume function.

I personally thought that it was a problem with bandwidth for the FMS. Any suggestions on how to fix this from a code standpoint? Our camera is running at 320x240 , 30 fps, and 30% compression although we did mess with the Exposure, Brightness, and Contrast in order to see the reflective targets.

Also, my assessment may be completely wrong. I'd like to hear other ideas related to the cause of this issue.

Also, just ask if anymore clarification is needed or you want me to post code.

Thanks.

[engunneer]

Try 15fps.

Is your vision system doing any math? or looping? is other control laggy?

[Alan Anderson]

I can't think of anything involving the FMS or network bandwidth that would prevent a PID control loop from functioning. I'd need to look at your code before I could make a good guess about what might be going on.

[Bongle]

Could be a CPU issue - if the image-analysis task is taking too many CPU cycles, it could starve the PID or at least make the PID unpredictable.

Could be a starvation issue: We had a bug once where we had a tight sensor-checking loop on one thread that never yielded, which caused the robot to be undriveable. But when we put a printf in, things worked - this is because internally, the printf call yields execution to other threads. The correct solution was to put a short wait() statement in so that other threads could get a turn on the CPU. Your camera code could be similar - if there's never a wait() call in it, then it could completely monopolize the CPU.