On 07/12/2010 04:26 PM, Jack O'Quin wrote:
> On Mon, Jul 12, 2010 at 2:35 PM, Eric Perko<wisesage5001@gmail.com>  wrote:
>    
>> It seems kinda odd to introduce another parameter for whether or not to
>> retry. Seems to me like retrying two or 3 times if the openCamera call fails
>> the first time would be desirable in all cases (as long as certain parameter
>> combinations don't actually damage the hardware). I'm just not sure what
>> reason we would have for not trying again if the first try fails...
>>      
> Mostly I'm just reluctant to make pervasive changes late in the test cycle.
>
> How about adding a "retries" parameter that defaults to zero (current
> behavior), but allows users to request one or more retries when an
> open fails, before giving up? There would need to be a reasonable
> upper limit to avoid hanging the driver node (maybe 3 or 7).
>
> Then, Kim could start the driver like this:
>
>   $ rosrun camera1394 camera1394_node _retries:=1
>
> Alternatively, we could make the default be one or two retries, but
> people could set it to zero if some device reacts badly. (I agree that
> seems unlikely, but you never know).
>
>    
>> On Mon, Jul 12, 2010 at 3:12 PM, Kim Houck<kim_houck@yahoo.com>  wrote:
>>      
>>> Dynamic Reconfigure would help, as it would eliminate the need to
>>> shutdown nodes and/or rerun the launch file or rosrun command, but it
>>> still would add an extra step on startup to make sure the cameras
>>> started correctly.  But then again, it would be less likely to cause
>>> problems with other camera hardware for an issue that sounds like it is
>>> relatively obscure(although it sounds like odd behavior from 1394
>>> cameras is not unheard of).
>>>        
> My experience with 1394 cameras is relatively limited. Just because I
> have not seen this happen does not necessarily make it "obscure".
>
> That's why we have alpha testers. :-)
>
> I understand the importance of starting the camera without requiring
> human intervention. I intend to fix this the problem once we converge
> on a good solution.
>
> Further thoughts, suggestions or ideas?
>    

I like the idea of a 'retries' parameter, either defaulted to 1 or 2 or 
to 0.