camera - console error messages

[oddjob]

Still not got the camera to send a single frame to the Dashboard. In the Task..console we see these messages:

[CameraToDashboardExample.cpp:RobotMain@0046] DEBUG Waiting for camera to initialize
[CameraToDashboardExample.cpp:RobotMain@0050] DEBUG Starting image server
[CameraToDashboardExample.cpp:RobotMain@0052] DEBUG Image server Running
task 0x1eb0240 ((FRC_PCVideo) deleted: errno=0 (0) status=0 (0)

Should the FRC_PCVideo task be getting deleted?

After about one minute, the Image server stops and then the console fills with this line, repeated quickly and forever:

bind: S_errno_EADDRINUSE

The Driver Station classmate is at 10.xx.yy.5, with Remote Dashboard set to 10.xx.yy.6. The PC at 10.xx.yy.6 is running the Dashboard and is also the Windriver platform. It is the newest Dashboard with the compass in the lower right. The cRIO has C++ v19 loaded. The camera has the FRC/FRC and root/admin accounts, IP 192.168.0.90. We get camera images to the web page when we connect the camera direct to a PC. After the camera boots, its led's go green. We use the orange crossover cable from camera to cRIO port 2.

Anyone got some suggestions what could be wrong? We've been tinkering with the camera code now for 2 weeks.

EDIT - the Windriver PC is running Windows 7. Anyone successfully running C++ camera code to dashboard with Windows 7?

[gvarndell]

Originally Posted by oddjob

After about one minute, the Image server stops and then the console fills with this line, repeated quickly and forever:

bind: S_errno_EADDRINUSE

I'm sorry I can't be more help here but I think this indicates a bug in the code.
The bug I suspect is not the cause of the problem you're asking about.
Rather, it is a bug that would only manifest when there are networking problems.
Perhaps this will be of help some.

That error indicates that software (on the robot) has tried to create a socket.
This initial attempt takes a while to fail.
My guess it that there's a loop that then repeatedly attempts to retry the failed operation but can't because the first attempt has left a lingering half connection that could take many minutes to clear itself up.

I don't have the source code to look at so I can't conjecture any further.
But you definitely have basic network connectivity issues.

Try pinging the cRio from each of the other PCs -- I'm guessing you cannot.

[TimDavis]

We were able to get the camera code running under C++ with no changes from the sample. I have not tried the remote dashboard, however. I have configured our development laptop at the 10.xx.yy.5 address, installed the driver station application, and not used the Classmate driver station since initial benchtesting.

The bind: S_errno_EADDRINUSE error leads me to think you're having an initialization problem, perhaps the PCVideoServer is already streaming to the driver station IP and not to the laptop dashboard.

Are you able to download the sample application from your .6 development workstation, reboot the cRio, and then disconnect the laptop and just use the driver station instead of the remote dashboard?

Also, if you have modified the camera setup code, plase post your source code for a quick lookover.

Tim

[oddjob]

First thing this morning I checked everything, and the Driver Station reported cRIO image V19.

Just for laughs, reformatted and reimaged the cRIO to C++ v19. Loaded the same camera code that hasn't been working, and bingo, an image on the Dashboard. That is with the Driver Station and Dashboard on the same PC @ 10.xx.yy.5. Does the cRIO calculate and verify a checksum of the loaded image? It seems totally odd that the Dashboard would report the image version but yet there was something corrupt in the cRIO.

Next we loaded 2010ImageDemo and it ran first time. Images to the Dashboard and drawn in circles when toggling the joystick trigger and looking at the target. We couldn't successfully find a target but our bullseyes are hand drawn and the code appears to be very sensitive to the accuracy of the circle. Still, it's huge progress from yesterday. We were ready to throw the camera into the river.

[Radical Pi]

Originally Posted by oddjob

We couldn't successfully find a target but our bullseyes are hand drawn and the code appears to be very sensitive to the accuracy of the circle.

Are you really close to your target by any chance? If the circle is over a certain size the image tracker rejects it. Also, we chopped up the default targeting code for our bot and it seemed very flexible about the circles (a little over sensitive IMO). Make sure there is nothing in the way of your target. If anything interrupts the edge of the circle then the tracker fails