pylon-ros-camera icon indicating copy to clipboard operation
pylon-ros-camera copied to clipboard

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

Open alireza-moayyedi opened this issue 10 months ago • 4 comments

Hello,

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

  • Image acquisition: 5ms (Exposure time set by myself)
  • Image data readout: ~50ms
  • ROS communications and my other software overheads: ~ 5ms

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:

  • As far as I can see this feature (Camera Events) is not implemented in this repo, is that correct?
  • Are there any upcoming updates/planning to implement it?

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

Thanks in advance.

alireza-moayyedi avatar Apr 08 '24 08:04 alireza-moayyedi

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?

FrancoisPicardDTI avatar Apr 18 '24 11:04 FrancoisPicardDTI

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:

  • Send an action request for grabbing one image.
  • forward the goal handle of the request to the event handler (maybe with a lambda function or something)
  • Upon finishing exposure, publish a feedback for the action request indicating exposure was finished.
  • Upon finishing readout, return the result.

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.

alireza-moayyedi avatar Apr 26 '24 09:04 alireza-moayyedi

@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

m-binev avatar Apr 30 '24 09:04 m-binev

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

galou avatar May 16 '24 12:05 galou