On 07/12/2010 09:06 AM, Jack O'Quin wrote:
> On Sat, Jul 10, 2010 at 11:32 PM, Kim Houck<kim_houck@yahoo.com> wrote:
>
>> I was wondering if anyone else has seen issues with camera1394 throwing
>> an exception after failing to start the camera. I have been dealing
>> with an older firewire camera(dc1394 A) that often fails to start on the
>> first try(this also occurs using the camera with opencv or the dc1394
>> interface directly).
>>
> What make and model of camera do you have?
>
Sony DFW-x710
> Which version of ROS and camera1394 are you running?
>
cturtle Alpha 3 and Alpha 4
> With the cturtle version of the camera1394 driver, the expected
> behavior when the camera open fails is to print an exception message,
> but the driver node should continue running. The intent is to give
> users the opportunity to change camera parameters with dynamic
> reconfigure. When a parameter changes, the driver will attempt to open
> the camera again (using the new values).
>
>
>> hen the camera fails to start properly the camera1394 node needs to be
>> restarted to get get the camera to work, which isn't a problem for a
>> stand alone node but gets aggravating when using launch files. I made a
>> change to openCamera in camera1394.cpp to have it try again to open the
>> camera if it fails the first time and only give up and throw an
>> exception if it fails twice. I was wondering if anyone else has
>> encountered this problem and if so if have they found a better solution
>> for it?
>>
> Did the driver keep running after the open failed?
>
Unfortunately, it keeps running so the node simply cannot be
respawned, though I see the value in doing for cases where changing the
parameters will solve the problem(probably more common than this situation).
> So, you are saying that this device fails to open on the first try,
> but succeeds on a second attempt using the same parameters?
>
Yes, I just run the same rosrun command or launch file again and it
works. These cameras have behaved similarly with opencv and pure dc1394
code as well.
>> I'm not sure if this constitutes a bug/change request for camera1394,
>> since it may be limited to a very small subset of hardware and I'm not
>> sure if fixing this would cause problems for other camera hardware.
>>
> I have not personally seen any cameras that behave as you describe,
> but the range of behavior exhibited by IIDC cameras never ceases to
> amaze. I am very curious exactly what device this is.
>
(text/plain)