Loaned messages for permanent (re)use and continous publishing

asked 2020-02-20 10:01:23 -0500

gdebrecz
55 ●6 ●7 ●13

updated 2020-02-20 10:28:14 -0500

Hello !

Problem setup:

I have a camera (ROS2 EE, C++) node and another node processing the camera image. The camera driver (handled by the first node) is able to receive a memory pointer - at configuration time - where it will put / store the last N captured image frame (in ring-buffer configuration). I'd like to send this buffer as a (iceoryx) loaned message with zero copy to the other node for further processing, without always loaning and releasing a distinct message for every frame.

So what I'd like to do is the following:

1.) Define a custom fixed size message for image frame 2.) Borrow a loaned message from ixeoryx that is able to contain N of this custom message 3.) Pass the memory pointer of the loaned message data field to the camera driver at initialisation time. 4.) Start capturing 5.) While capturing, after each frame publish this loaned message to the other node (without releasing it, so the camera remains able to use it)

This was we were able to save 2 memory copy for each frame.

In the examples I haven't found any pattern how to do this. The "fixed_size_image_demo" borrows and releases a loaned message at every frame and uses memcpy to put data into that memory area - which I'm not sure is efficient.

Is it possible to do what I'd like ? thanks for any help or pointer, Cheers, gdebrecz

answered 2020-02-24 15:55:26 -0500

Karsten
643 ●9 ●18 ●23

Just to make sure we are on the same page here, loaning and releasing does not correspond to new/delete and memory allocations. It's really just a signal to the middleware to gain and release ownership over a junk of memory (previously) allocated by the middleware.

Can I ask why do you think borrowing and releasing a loaned message is not desired? Off the top of my head I don't see any other possibility to send a message via zero-copy transport without explicitly releasing the pointer back to the middleware. By not doing so, how could one secure the integrity of the message on the subscription side? That is, not modifying the message data after a call to publish.

The idiom with loaned messages is that the middleware, opposed to the user application, is handling all memory allocations. In the case of Iceoryx, that would essentially be its managed shared memory. I think what you are trying to do is some sort of DMA where the user application provides access to externally located memory. This is not possible with the current API design for loaned messages. You still would have to loan an appropriately sized message from the middleware and copy your camera ringbuffer into the loaned message. However, there wouldn't be any other copy involved as the message which arrives at the subscription side is not copied but also just loaned. So in your case there is really just one copy from your camera to the message, but no second one.

edit flag offensive delete link

Comments

Hi Karsten !

Thanks a lot for the answer ! I havent written that borrowing or releasing the message is not desired, I've wrote that one could save the extra memcpy if it were possible to create / produce data (for example by the camera) right in the borrowed memory area. (This is possible to do once at the very first frame, but when the message is published the camera looses access to it - of course.)

But from your answer I understood that - as of now - this is not possible. So in all cases first I have to move the data into the borrowed memory area then publish that. This way we save "only" one memcpy instead of two but its already a great achievemnt....and in fact it works nicely.

Another solution would be /could be to reconfigure the camera after each frame and tell it to use another memory area ...(more)

gdebrecz ( 2020-02-24 16:16:18 -0500 )edit

Still I think my use-case is quite common: lot of camera producing lot of data that I wouldn't like to copy. If there is any workaround for the above mentioned scenario or future feature development, that would be extremely useful.....

What I dream about is something that the 1.) middleware allocates N frame of data 2.) the application borrows this memory area 3.) tells the camera to put the frames into this area after each other in a ring buffer configuration 4.) the frames that are not currently used/written by the camera can be published (read only?) to other nodes 5.) when those nodes releasing the messages (published frames) the camera can re-use the same memory area for writing.

This way integrity can be handled and memcpy saved. Of course in practice it is not so easy....

gdebrecz ( 2020-02-24 16:24:52 -0500 )edit

add a comment

Loaned messages for permanent (re)use and continous publishing

1 Answer

Comments

Question Tools

Stats

Related questions

Loaned messages for permanent (re)use and continous publishing edit

1 Answer

Comments

Question Tools

Stats

Related questions

Loaned messages for permanent (re)use and continous publishing