No option to start grabbing with a different strategy

[claudiofantacci]

The current implementation of the camera driver uses the following function call to start grabbing

void Pylon::CInstantCamera::StartGrabbing(EGrabStrategy strategy = GrabStrategy_OneByOne, EGrabLoop grabLoopType = GrabLoop_ProvidedByUser)

with default parameters, i.e. calling

Pylon::CInstantCamera::StartGrabbing()

in diffeernt part of the code, see for example pylon_camera/include/pylon_camera/internal/impl/pylon_camera_base.hpp.

However this implies that, for real-time applications, if a frame is not grabbed (e.g. a trigger fails) a queue with past frames is formed, resulting in an synchronized grabbed sequence of images. This may be desirable in some applications, but the dirver/ROS node should provide a way to choose the best strategy, which are

enum Pylon::EGrabStrategy

Enum	Description
GrabStrategy_OneByOne	The images are processed in the order of their arrival. This is the default grab strategy.
GrabStrategy_LatestImageOnly	Only the latest image is kept in the output queue, all other grabbed images are skipped. If no image is in the output queue when retrieving an image with CInstantCamera::RetrieveResult(), the processing waits for the upcoming image.
GrabStrategy_LatestImages	This strategy can be used to grab images while keeping only the latest images. If the application does not retrieve all images in time, all other grabbed images are skipped. The CInstantCamera::OutputQueueSize parameter can be used to control how many images can be queued in the output queue. When setting the output queue size to 1, this strategy is equivalent to GrabStrategy_LatestImageOnly grab strategy. When setting the output queue size to CInstantCamera::MaxNumBuffer, this strategy is equivalent to GrabStrategy_OneByOne.
GrabStrategy_UpcomingImage	The input buffer queue is kept empty. This prevents grabbing. However, when retrieving an image with a call to the CInstantCamera::RetrieveResult() method a buffer is queued into the input queue and then the call waits for the upcoming image. The buffer is removed from the queue on timeout. Hence after the call to the CInstantCamera::RetrieveResult() method the input buffer queue is empty again. The upcoming image grab strategy cannot be used together with USB camera devices.

[pablo-quilez]

Hi Claudio,

are you suggesting to do it configurable, as for example the fps we were discussing in the other issue? I think providing services for this would be a good idea, but maybe just changing to a LatestImageOnly strategy is a best option. What do you think?

[claudiofantacci]

It is probably good to have it configurable with GrabStrategy_LatestImageOnly as default.
Also, it may be worth investigating how these options behave with trigger mode On and Off.
I think, at least for us, we started noticing this after we moved to trigger mode On.

[m-binev]

Hi Pablo, hi Claudio,

as LatestImageOnly (1 buffer in the queue) is a version of LatesImages (one or more buffers, which is freely configurable in pylon), it may be a good idea to implement LatesImages.
I think, this strategy would best suit to ROS, because images are copied and published in the ROS space. As this operation may took longer, it may happen that you work with "older" images when using OneByOne under circumstances.
On the other side, if the use case requires all images to be kept, you would need OneByOne.
Thus, having OneByOne and LatestImages should cover most of the use cases.
@claudiofantacci , @pablo-quilez

[claudiofantacci]

Hi @m-binev, thanks for reaching out here 😄

I'm sorry, I'm not sure I got the point of your comment.
In general, as long as we have a way to

• use only the latest available image (LastImageOnly or LastImages with buffer 1)
• buffer up to N images (LastImages with buffer > 1)
• buffer all images (OneByOne)

we are covering most (or all?) use cases.

[m-binev]

Hi @claudiofantacci ,
I basically wanted to say that having OneByOne and LatestImages should cover all use cases with USB cameras (and most use cases with GigE).
For GigE cameras, having also "UpcomingImage" may make sense, but we may consider implementing that strategy in ROS only if we see real demand for that.

[claudiofantacci]

Ok, great. For the record, we use GigE cameras and for me UpcomingImage is some specific use case that I cannot really understand. Any example?

[m-binev]

Hi,
well, if I recall correctly, the users that were looking for such grab strategy wanted to make sure they do not deal with "older" images, which e.g. were still available in the queue.
In those cases they were running the cameras in free-run or continuous hardware trigger and used the grabbed images for a kind of preview to the end customer, e.g. in ophthalmology applications. While doing preview, they were also configuring different camera parameters controlling the brightness and the color to find the perfect settings. Once done, they wanted to switch off the preview and get a fresh new image with the last parameters.
I suppose, that something like that can also be reached while using e.g. SW trigger, but as we said before, with SW trigger you get lower maximum frame rate.
I hope that sheds some more light))

[claudiofantacci]

Interesting implementation! Thanks for the explanation!

[Neel1302]

To follow up: What is a temporary fix to get the FPS as high as Pylon Viewer? Is it by grab strategy modification or is by changing the trigger mode/timeout properties? I have no bandwidth limits (quad channel PCIE card from basler installed).

@claudiofantacci I understand you mentioned that "setting grab_timeout_ = and timeout = 2 * grab_timeout_ resulted in very stable performance" in #29 (comment). Have you figured out how to set the framerate based on the yaml file (i.e. using a variable rather than hardcoding it again?).

Thanks,
Neel

[m-binev]

@Neel1302 Hi, please check #21 and my comment from April, 16th, especially regarding the resulting frame rate in free-run/hardware trigger mode (both not supported under ROS yet), and software triggering. Hope that helps.

[Neel1302]

@m-binev @claudiofantacci Hi, Thanks. I did have a look at your comment and it seems that the software trigger mode set by the ros driver is driving down fps.

For anyone that wants to run in continuous acqisition mode refer to this fork that I wrote and tested for USB cameras (Users need to modify accordingly for GigE cameras). Test results show no drop in fps.

Thanks,
Neel