Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
alireza-moayyedi opened this issue Apr 8, 2024 · 4 comments
Open

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

alireza-moayyedi opened this issue Apr 8, 2024 · 4 comments

Comments

@alireza-moayyedi
Copy link
Contributor

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.

@FrancoisPicardDTI
Copy link
Collaborator

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
Copy link
Contributor Author

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.

@m-binev
Copy link

m-binev commented Apr 30, 2024

@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 m-binev assigned m-binev and unassigned m-binev May 8, 2024
@galou
Copy link

galou commented May 16, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants