prosilica intrinsincs parameters failed to load

edit

OK, that's interesting. The driver does try to optimize the packet size; the relevant code is in Camera::setup() in src/libprosilica/prosilica.cpp:

// adjust packet size according to the current network capacity
tPvUint32 maxPacketSize = 8228;
PvCaptureAdjustPacketSize(handle_, maxPacketSize);

8228 is a Jumbo Frame size, and the camera default on power up. PvCaptureAdjustPacketSize is supposed to determine the maximum packet size supported by the system, and configure the camera to use that value or maxPacketSize, whichever is lower.

It sounds like there's something kooky about your network card or system that's causing it to report an incorrect max packet size.

Can you try changing maxPacketSize to 1500, recompile prosilica_camera, and see if that works?

For reference, SampleViewer instead does:

tPvUint32 lMaxSize = 8228;

// get the last packet size set on the camera
PvAttrUint32Get(lHandle,"PacketSize",&lMaxSize);
// adjust the packet size according to the current network capacity
PvCaptureAdjustPacketSize(lHandle,lMaxSize);

Which seems a bit odd. That code will never increase the packet size, only decrease it.

Have you tried manually setting the StreamBytesPerSecond configuration in the Prosilica program? and restarting in Linux to run ROS? It seems like a failure because of the fast ethernet (switching back to default gigabit because of unset value).

Adjusting the MTU only works if your entire network setup supports this, otherwise a router or NIC might chop them up again in smaller frames.

We've seen this sort of thing before, e.g. #ros-pkg4481. Usually it's because of too many dropped packets between the camera and computer. Can you please post the diagnostics - before starting the Prosilica, do:

rosrun runtime_monitor monitor

Then start the Prosilica driver with streaming.launch (prosilica.launch starts the camera in polled mode, so it won't automatically stream images). Look at the Packet Statistics component in the runtime monitor. On a properly configured GigE network there shouldn't be any dropped packets. On Fast Ethernet some (warning level) lost packets are expected, but things should still work.

If the error always happens on the very first diagnostics collection, we'll have to try something else. But hopefully that's not the case.

Did you run the camera calibration on this camera? After the camera calibration ran successfully the camera calibration matrices are stored in the internal eeprom of the camera and loaded each time the node starts.