We’re working with C++; not sure if this is relevant, or even if it’s a programming issue, but about five seconds after our camera starts sending images, it freezes, sometimes coming back on a few minutes later (if so, it generally works from that point on). We’re not really doing anything with the camera in our current version of the code, just letting it get sent to the Camera Image window in the driver station. The relevant code is as follows:
The images from the camera are read on port 2 and written on port 1, requiring a task or thread to do the transfer. If your program loads up the cRIO sufficiently, it may be that the task is starved and doesn’t send the images. I suppose another symptom of this would be that when it comes back, it will be lagged by several seconds.
This year, the rules and electronics allow for the camera to be directly connected to the external switch, and to allow the images to be read directly from the dashboard. You may want to investigate as it frees up some amount of cRIO CPU and should have less lag.
We are having a similar problem with the Axis 1011 camera. We have tried using only the minimum camera code, resetting the camera and reimaging the cRio. We can run the axis 206 camera just fine, but as soon as we switch cameras the problem continues. We don’t have a spare Axis 206 so we wanted to have one of our cameras as a spare. We do anticipate processing images so connecting directly to the D-Link would not be an option. Would appreciate any help. We are using C++.
It does have the FRC account. Haven’t tried it with NI Vision Assistant, but the camera will send images to a laptop if connected directly to the laptop. When connected through the cRio, as the initial post mentioned, we get about 5 seconds of video on the driver station and then the cRio crashes. We were thinking there might be some problem with exceeding a buffer or something, but don’t know where to begin with that. Another, possibly unrelated issue, is that we can’t seem to reset the image size through C++. The Axis 206 sends a smaller image than the axis 1011 according to information on the driver station, but attempts to change that in software have failed.
Based on some other threads in the forum, we have tried a few other ideas to get the axis 1011 camera to work. We went into the camera and set the resolution to the lowest possible value, removed compression, and lowered the frame rate. None of those settings had any impact on the problem. We still get a few seconds of feed to the dashboard and the cRio crashes. Forgot to get a screen capture on the error, but will try to do that tomorrow. Someone in the forum suggested that the WPILib code for the camera doesn’t work for the axis 1011. Is there any confirmation of that, or should be continue to troubleshoot. We are just about out of ideas.
We are not having this problem, so sorry for breaking in, but this option sounds quite interesting. I have not heard anything of connecting the camera to the switch. Could you explain or point me to any resources of how to do this correctly? (Or do you just plug it into the switch, no more changes required?)
You plug it in and use the IP range reserved for cameras. In other words, change the camera IP to be 10.te.am.xx. I believe xx is above 10, but look for the official doc.
You can probably figure out how to get images from the camera, but I expect example code for how to do this to go up soon.
We are having a similar problem using java. When the robot is tethered, there are no problems. But when using the wireless the camera freezes a few seconds after we enable the robot. I would think that this is a communication error, but then why does it freeze only when we hit the enable button?
We have found that it freezes when the battery gets low and you put a lot of load on it (driving around). The camera reboots and comes back on about a minute later if there’s not too much load. Might explain why it works when tethered, but freezes when not tethered (more likely to be moving around).
Well, I’ve been running the camera off of a power supply when developing my vision code, and it’s done this to me once. I guess it’s just a glitch, as the cam doesn’t actually reboot or anything.