Negative flash delay not possible to set #39

rbrth · 2016-04-06T12:46:04Z

I am trying to set the flash delay to a negative value. According to the documentation this should be possible from -1000000us to 1000000us

However, in the RQT GUI setting negative values is not possible.

Best,
Ruud

anqixu · 2016-04-06T13:08:04Z

According to the cfg code, flash_delay should be able to accept negative values.

Here's 2 caveats from the actual source code:
1 - when setting to free-run mode, the flash delay/duration are hard-coded to 0/1000, to facilitate default compatibility with externally triggered slave cameras. Let me know if this is the cause of your issue, in which case we can find a better solution.

2 - when setting flash parameters, the requested delay/duration values are first saturated within the camera's min/max values. If your camera does not support negative flash delay, then rqt_reconfigure will automatically update to the capped value (=0).

rbrth · 2016-04-06T13:19:03Z

Thank you for the quick reply! :)

1 - We do not run the camera in free-run mode. It is software triggered.

2 - Our camera ( https://en.ids-imaging.com/store/ui-5250re-poe.html ) should support negative flash delay. We have tested this under the IDS camera manager under Windows.

What do you mean with "the requested delay/duration values are first saturated within the camera's min/max values." ?

Thanks!
Ruud

anqixu · 2016-04-06T13:21:57Z

Before setting a user-requested flash delay value, the code first retrieves the camera's minimum and maximum delay values, and then checks+updates the requested delay value to be within the min-max range.

rbrth · 2016-04-06T13:49:15Z

Clear. Thanks.

I will double check if our camera supports negative flash delay and what the minimum and maximum delay values are.

rbrth · 2016-04-06T13:54:42Z

My colleague updated me on your first point:

1- when setting to free-run mode, the flash delay/duration are hard-coded to 0/1000, to facilitate default compatibility with externally triggered slave cameras. Let me know if this is the cause of your issue, in which case we can find a better solution.

We are running the camera in free-run mode! :-)

anqixu · 2016-04-06T14:01:30Z

In that case, the solution might be as easy as commenting out this line. Essentially, instead of manually forcing the flash parameters to hard-coded values each time entering free-run, we hope that the user chose sensible values, or used default dyncfg values of delay=0 and duration=1000.

If commenting out that one line causes other issues, then you might have to comment out that whole block, meant to generate a pulse signal on flash output pin.

Please test this fix out thoroughly, as I unfortunately don't have the cycles to address this till at least next week. Let me know if/which fix works, so I can make the change permanent.

rbrth · 2016-04-07T14:09:31Z

Thank you for the help.

I commented out the line, recompiled it with catkin_make and changed the flash parameter to a negative value.

However, when running and checking rostopic echo /ueye_gripper_cam_nodelet/parameter_updates , the flash_delay is set to 1.

I will further look into the code next week to see if I can force the delay in there somewhere :-)

Best,
Ruud

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Negative flash delay not possible to set #39

Negative flash delay not possible to set #39

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Negative flash delay not possible to set #39

Negative flash delay not possible to set #39

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!