C++ Vision Camera Problems

[SnarkyNinja]

Hey there, programming geniuses at Chief Delphi!

We're having a bit of trouble with our vision camera, and I'm hoping you can help. To summarize, when we try to use the camera, our robot completely crashes. This problem came out of nowhere one day; the camera went from working perfectly to not working at all, and there were no changes to the robot or the code in the meantime. I've attached all the errors and messages associated with the problem.

This happens when the camera is plugged in to the cRIO and the code tries to create a camera object. We get one or two frames of video, then robot communication dies on the driver station. If either the camera is unplugged, or the code doesn't try to start the camera, there are no other problems. It happens with our team code, and the unmodified 2010 Vision Example code. We have all the latest updates applied to WPILib/WindRiver (C++ Team Update 4.3/Workbench Version: 3.0.1) and the driver station (update 1.1), and the latest version of the cRIO image (v20).

We've tried: different cRIOs, different programming laptops, reinstalling WindRiver, reimaging the cRIO, reinstalling the driver station, restoring camera to factory settings (we put the FRC/FRC user account back on afterwards), and deploying code that creates the camera object only. The one thing we haven't tried is using a different camera, as we don't have another one available.

The camera works properly (if laggy) in both LabView and Java. It also is fully accessible and streams properly from the web interface. It's only when we use C++ that this problem occurs. From the cRIO console, the camera is pingable at 192.168.0.90. We're using the newer Axis M1011 camera. Any ideas?

[davidalln]

I'm not sure if this helps you, but we got the same error (S_errno_ETIMEDOUT) whenever our camera was correctly plugged in and then somehow unplugged (such as violent turbulence from the robot causing the cord to become unplugged, as I unfortunately learned during a match at championships). From my understanding, the code is initializing the camera correctly but is unable to read any images coming from it. For whatever reason, WPIlib doesn't appear to have any exception handling if the camera doesn't return anything and causes the code to crash.

If I had to point to any potential problem, the new Axis camera might not be compatible with the C++ library. This is just speculation.

[PatrickS]

It may actually be an incomparability with the new camera. The errors you are receiving seem memory allocation errors. The only strange circumstance is that this issue randomly started occurring. Can you post any more debugging information?

[Alan Anderson]

There's a Camera Configuration document linked from the Kit of Parts web page. Is the camera properly set up with the correct users? I don't have the code handy to look at, but it's possible that the LabVIEW and Java libraries are trying a name/password combination that the C++ library isn't.

[jhersh]

Originally Posted by SnarkyNinja

Hey there, programming geniuses at Chief Delphi!

We're having a bit of trouble with our vision camera, and I'm hoping you can help. To summarize, when we try to use the camera, our robot completely crashes. This problem came out of nowhere one day; the camera went from working perfectly to not working at all, and there were no changes to the robot or the code in the meantime. I've attached all the errors and messages associated with the problem.

This happens when the camera is plugged in to the cRIO and the code tries to create a camera object. We get one or two frames of video, then robot communication dies on the driver station. If either the camera is unplugged, or the code doesn't try to start the camera, there are no other problems. It happens with our team code, and the unmodified 2010 Vision Example code. We have all the latest updates applied to WPILib/WindRiver (C++ Team Update 4.3/Workbench Version: 3.0.1) and the driver station (update 1.1), and the latest version of the cRIO image (v20).

We've tried: different cRIOs, different programming laptops, reinstalling WindRiver, reimaging the cRIO, reinstalling the driver station, restoring camera to factory settings (we put the FRC/FRC user account back on afterwards), and deploying code that creates the camera object only. The one thing we haven't tried is using a different camera, as we don't have another one available.

The camera works properly (if laggy) in both LabView and Java. It also is fully accessible and streams properly from the web interface. It's only when we use C++ that this problem occurs. From the cRIO console, the camera is pingable at 192.168.0.90. We're using the newer Axis M1011 camera. Any ideas?

Can you try again with the released 2011 source? I guessing that it will still fail. Even if you get those errors accessing the camera (S_errno_ETIMEDOUT or S_errno_ECONNREFUSED), you should not crash your program. My guess is that there are at least 2 bugs here... the one that makes it not work here when it works in Java and LabVIEW, and the one where it crashed with a data access violation when the first condition is true.

-Joe

[masoug]

Seems like socket problems to me...

[James Tonthat]

(I'm not the programming mentor so I'm not fully informed.)

We made a new electronics board with different cRio we had, and had installed 2011 and the newest versions of everything (including the DS update) on a laptop with a fresh install of Windows 7 and we received the same errors.

I'll see if the errors are different than the ones we had gotten with the 2010 software.

Thanks for the input, we'll try some different things and document it at tomorrow's meeting and post back on Chief.

Edit: Could you elaborate on the 'socket problem' comment? Thanks.

[masoug]

When Joe referred to the "S_errno_ETIMEDOUT or S_errno_ECONNREFUSED" errors this means that the socket cannot connect successfully and transfer data safely. The TIMEOUT error means that there is contact with the server, BUT the server is not responding to the client. CONNREFUSED means that the server actively rejected the request from the client. So my suspicions may be the misconfiguration of the camera OR that the current camera code does not handle the camera instance properly. Did other teams get their camera to run successfully under the same conditions?