Hey, we’ve been working on our code to track the targets for a while, and, when we are able to actually grab a picture off the camera and use it, our calculations work. Our problem is that the camera is continually rebooting in the middle of use:mad:.When that happens, the code stops talking to it and we can’t get any more pictures until we restart the robot. We have been doing everything we can to make this stop happening, but we think the problem may be inside the camera. Earlier today our team had a driving practice, and I’m told that the camera rebooted in the middle and the entire robot froze up. It shut down to the point where we were unable to re-upload code:eek: , so now we think that we may have to reimage the cRio.
Is anyone else having trouble with the camera itself, not with the image processing? If so, please help!
Well, first thing you want to do is create “Plan Bs” (read: threads) in your code to make sure the cRio doesn’t crash when the camera goes out on you during a competition. Or, just a try/catch block to contain that code in case it breaks.
Second, you should not need to re-image the cRio unless the camera code is ran continuously in the init section of the robot. It won’t hurt, but I don’t see how it might help.
Third, any ideas on why the camera is rebooting in the middle of a match? Never had that happen before.
Zip tie/ tape the black power cable to the camera to make sure that it is receiving a constant supply of power. I don’t know if loss of power will cause the symptoms you are seeing, but it wouldn’t hurt anything to try this.
Same goes for the CAT 5 cable that runs from the camera to the bridge.
Without more info, I (nor any more qualified people) can truly help. It would be nice if you posted some of the specifics of the system that you are using. Error codes (if any) and “external events”, like the robot being bumped, are also nice to have.
Patrick, First, we already have all the camera code in a try-catch and an if statement checking if (null!=image) where image is the new image.
–Second, we may not have to reimage, I wasn’t at the practice and that’s what everyone who was there said.
–Third, I don’t know, that’s part of our problem.
Garrett, the code isn’t outputting any error messages when this happens, we put in a check for camera.freshImage() which seems to return false once or twice, and then return true the rest of the time, bypassing the rest of the camera code. As for the zip-tie and tape, we have alreadey tried holding the power cord in with a rubberband around the entire camera, but that doesn’t seem to be the problem because we are getting live feed the the SmartDashboard the whole time except for extreme cases. The camera is getting jostled around a bit, and is attached to the top of the shooter mechanism so the image goes blurry when we shoot, could that have loosend some of internal parts?
Ruffles, thanks for the idea, I’ll suggest that to the team.
I don’t know what camera you are using, so this may or may not apply.
Some electronics are vibration sensitive. IE, out of the box, they will freak out if they are submitted to intense vibrations. The KOP camera is rugged and therefor resistant to vibrations, though most webcams that I have messed with can freak out if they are shaken up a little too much. If this is your problem, then all data from the camera would be useless while there is major vibration (aka, camera code doesn’t work and the dashboard doesn’t work).
From what you have said, this is not the case. Even when your code quits working, your live feed continues to function. Check to make sure that your camera is compatible with everything that you are using.
I don’t know much about coding for cameras, so dismiss this if it is not possible. Would two different programs (dashboard and image processing) have a conflict if they both tried to read the same piece of data at the same time? Theoretically, the dashboard program is really robust and therefor isn’t severely affected by this hiccup, but your code might just crash because of it.
A way to test for this is to figure out how to ensure that there are dedicated “image processing” frames, and dedicated “live feed” frames.
Disclaimer: I have never coded for a FIRST robot, what I wrote above is based on experience with Arduino and various other java base languages. It may or may not be applicable to this application. Check with someone who knows more about these things.
Thanks for the idea, we tried turning off the camera widget on the Dashboard, but it didn’t help. We did another test and discovered that the problem is caused by the jostling of the robot. We managed to get 8 pictures in a row by driving no faster than 1/4 full speed, but the camera stopped working when we went faster.
I’ve had the camera reset on us from the plug vibrating, and losing contact. Hot glue is a must IMO.
Another suggest is to ensure your camera mount doesn’t accidentally touch the reset button on the back of the camera. A lot of people just bolt the camera to a vertical 1" square tube, which would hover right over the camera’s reset button.
I didn’t see it mentioned, but you should also insure that the camera and cRIO are electrically isolated. Especially if one is taking down the other, this sounds like something may be shorting to the frame and affecting the other electronics.
