SWTrigger Service doesn't return error codes

[bennilson]

I'm using the software trigger service to get data, and I'm successfully able to data. However, when I introduce an error condition (such as no camera connected) and trigger the SWTrigger service, I get the response status as 0(OK). I would expect that I get an error code for being unable to talk to the camera. I'm not sure if this is an issue with the ROS part or with the library. Can someone confirm that I should be getting an error code from the software trigger service for cases such as no camera at IP address?
Thanks

[tpanzarella]

You will not get an error code in the way you are expecting. The software triggering is asynchronous -- "success" indicates that your request to trigger was successfully completed (i.e., processed by the underlying libo3d3xx).

Lot's of other lower-level technical issues at hand here.... From a practical perspective, you can determine an "error" (like, no camera connected) in that your next call to WaitForFrame() on the FrameGrabber will time out, or in the case of ROS, no message getting published to the topic you are subscribing to.

....at the driver level, libo3d3xx is running a boost::asio event loop. If the camera is not connected, no TCP connection to the PCIC server on the camera can be made. At which point the main FrameGrabber thread will stop as the asio event loop will stop running. So, when you ask to s/w trigger, the event is posted to the ASIO io_service, but since the event loop is not running, it is basically like sending it to /dev/null (metaphorically speaking).

I hope that helps.

[bennilson]

Ok, so the s/w trigger request for a frame is queued with the FrameGrabber, but in that case never executed.

And there is nothing at the ROS level that can catch or handle any exception being raised as part of the FrameGrabber failing to establish a TCP connection to the PCIP server, correct?

And the only thing that could recover from that situation would be the FrameGrabberreset as a result of timeout_tolerance_secs for not receiving a frame?
Thanks

[tpanzarella]

Right. The auto-resetting of the FrameGrabber (i.e., literally calling .reset() on the std::shared_ptr) reconstructs a new FrameGrabber which will re-attempt to establish the TCP connection with the camera. When running in "free run mode" you can literally watch this in action (via rviz) by plugging and unplugging your ethernet cable between the camera and your computer. The idea here was to make the node robust to exactly this situation ... losing the connection to the camera.