On Mon, Jul 12, 2010 at 2:35 PM, Eric Perko 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 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? --  joq