CMUCam 3 second startup Delay?
 

I think I read somewhere that it takes 3 seconds for the CMUcam to either initialize or send packets. Does anyone know for sure which one is taking the 3 seconds?

We noticed today that from the time you power up the robot until about 3 seconds later, we would finally get some sort of life out of the robot, like responding to the joysticks.....

It seems very evident that during this 3 second camera power up the CPU is still holding up the scan (program pointer) and nothing else will work.

Is there any work around for this? I see this a problem in autonomous mode mostly, unless the camera is initialize on power up, we walk off the field, and it's ready before the master computer throws the big switch to go fully auto...

So we need to Start the camera as well, BEFORE autonomous mode?

I guess it would help to know where the 3 second delay is happening. In the initialize function? In the start function? In the capture data function?

Maybe we are too paranoid... ;-)

Re: CMUCam 3 second startup Delay?
 

It does take time (less than) 3 seconds for the camera to initialize. There isn't really any way around this, but it isn't really a problem either. You can initialize your robot while it is on the field, long before any autonomous period begins. In easyC, the delay should only happen when you call an initialize camera block. Just call that in the initialize section, give the robot a few seconds before autonomous, and you should be all set.

Re: CMUCam 3 second startup Delay?
 

You are not paranoid to want to know what's happening inside your robot!

When the robot starts (power on -when you first turn it on) a clock starts running. The camera won't start initializing until after 2 seconds and the gyros won't initialize until after 1 second. The reason is to make sure that the robot has settled down and the camera has completed its initialization. In competition this should not be a problem since you put the robot on the field, turn it on, and usually several minutes pass before the match starts.

So the thing to do is initialize the camera and gyros in the Initialize() function, then start them either in Initialize() or Autonomous() or OperatorControl(). Our robot has both, and they are started during the Initialize() function just to be sure they're running. That way if the robot is restarted for some reason in the middle of the operator control period, the devices are guaranteed to be initialized - since autonomous will be skipped in this case.

Re: CMUCam 3 second startup Delay?
 

OK, you guys - try this and let us know what happens.

There is a new version of WPILib that has better error handling for the CMUCam. It will now fail more quickly if the camera is not detected and there is a function to get the status from the camera after initialization.

You can get it at the usual place.

Please post something with your results. I have tested it on a 2006 controller with the camera disconnected from the serial adapter and also with the serial adapter disconnected from the robot and both seem to work.

Be sure to save the old version this close to shipping in case you don't like the results.

Re: CMUCam 3 second startup Delay?
 

Good point, I think we will leave it as is, it's working ok for us right now. We might try a the new library off season sometime. Thank for all you have done.




-