basler / pylon-ros-camera

The official pylon ROS driver for Basler GigE Vision and USB3 Vision cameras:
http://www.baslerweb.com
Other
144 stars 143 forks source link

[Humble] Don't waste time on blocking image data readout #208

Open alireza-moayyedi opened 5 months ago

alireza-moayyedi commented 5 months ago

Hello,

I have noticed that for every image on my camera, I am spending more or less 60 ms with the following compositions:

Looking at the lowest level grab function (https://github.com/basler/pylon-ros-camera/blob/humble/pylon_ros2_camera_component/include/internal/impl/pylon_ros2_camera_base.hpp#L501) I see that it waits for the full result before it returns. However I can see that there are APIs to handle this via Camera Events (https://docs.baslerweb.com/pylonapi/cpp/pylon_advanced_topics#handling-camera-events) where we can have callbacks for Exposure End events for instance. I thought taking advantage of this functionality, it would be possible to save some time by doing other stuff parallely while not being blocked for the data readout.

I am raising this issue to know:

I just want to make sure I would not be reinventing the wheel here.

Thanks in advance.

FrancoisPicardDTI commented 4 months ago

Hello @alireza-moayyedi To answer you, no, this feature is not implemented in this repository. Either because at the time, the API was not allowing it, or because it has been deemed not suitable for the current implementation. And no, it is not planned for now. It can become a priority if several users are asking for it. Are you planning to work on this feature?

alireza-moayyedi commented 4 months ago

Hello @FrancoisPicardDTI,

I can see why it might not be a high priority as in any case one could do an asynchronous action request to take images which ineherently is non blocking. In my specific case, the camera position moves continuously which is why I need to make sure the exposure is finished before moving furthur. But well that can also be done (my current solution) with a simple waiting for some safety time (~7us) after sending the action request.

But personally for me a clean solution would be getting a callback on when the exposure is finished to know the exact times. I have thought about it and it is not that simple because the event handlers are registered for all the grab events (low level implementation) whereas it needs to be intertwined with the action request to react on a specifc request. I thought about a solution like this:

This going up and down all the way from ROS interface to camera implementation and back, can be a bit tricky. I would like to work on it of course but at the moment my resources are limited. If I get some free time I will look at it.

m-binev commented 4 months ago

@alireza-moayyedi Hi, yes, your thoughts are generally right & yes, the pylon C++ API does support both (1) working with timeouts (while the pylon engine is polling on the queue); and (2) using callbacks (registering for events). The latter is not implemented on ROS yet and despite I'm not the best ROS expert I'm not sure it would bring the same benefits as it does in the pure pylon C++ implementation. What I'm trying to say is that you are all free to give it a try if you've got the time and believe your use case will gain advantages of that. Cheers

galou commented 3 months ago

I'm also interested in this feature but our application is not that time-critical so that the current implementation is OK for us.