Skip to content

add ZMQ interface#19

Open
LorenzoFerriniCodes wants to merge 11 commits intobrow1633:mainfrom
LorenzoFerriniCodes:zmq
Open

add ZMQ interface#19
LorenzoFerriniCodes wants to merge 11 commits intobrow1633:mainfrom
LorenzoFerriniCodes:zmq

Conversation

@LorenzoFerriniCodes
Copy link
Copy Markdown

Hi, thanks for the cool project!

I've been recently working on implementing the ZMQ interface, via zmqpp. Here is a first, working version. I have tested it both locally and over an office network, succesfully. You can test it using the dedicated configuration files. I will add README information about it over the next days. Feedbacks are absolutely welcome :)

@brow1633
Copy link
Copy Markdown
Owner

Sweet! Readme would be great, and would also appreciate adding a ZMQ test (similar to TCP/UDP tests) to run with CI.

I'll make some time to take a look. Thanks!

@LorenzoFerriniCodes
Copy link
Copy Markdown
Author

Hi @brow1633, thanks for the quick response! I have included the tests (which are passing locally) and a dedicated demo launch file. I have also updated the README.

@brow1633
Copy link
Copy Markdown
Owner

'ament_target_dependencies' is deprecated, please use 'target_link_libraries' instead. Looks like CI has become more flaky, I'll make another PR at some point to address. Otherwise looks good!

@brow1633
Copy link
Copy Markdown
Owner

Just curious, do you have a use case for Push/Pull specifically? I think this adds something potentially useful in that multiple pushers can go to one puller (many robots to 1 monitor). Or 1 command center to many available worker robots.

However, this does not seem to handle the case of one publisher to many subscribers (1+ robot/s to 1+ monitors).

Would it be easy to add configurable Pub/Sub to support this behavior with a configurable topic name?

I think it might be worth adding some of these considerations to the selecting a protocol section of README.

This adds some really cool functionality! Thank you!

@LorenzoFerriniCodes
Copy link
Copy Markdown
Author

I agree with you that probably PUSH/PULL is not the best default setup given the round robin polling behaviour. I can see multiple nodes subscribing, for instance, to the camera stream. In this case the PUSH/PULL behaviour does not meet the ROS requirements in terms of message delivery.

I think that in some cases, where developers are sure there's going to be a 1-to-1 publishing/subscription behaviour, still having the PUSH/PULL pattern available can be useful. However, PUB/SUB should be the default one.

I was thinking to define a pattern parameter (default value pub_sub) to define the type of message exchange pattern. What do you think about it?

@brow1633
Copy link
Copy Markdown
Owner

brow1633 commented Apr 23, 2026 via email

Lorenzo Ferrini added 2 commits May 4, 2026 15:55
- Defined parameter to select the message forwarding/receiving
  pattern
- Adapted socket connection and binding to use the specified
  pattern
@LorenzoFerriniCodes
Copy link
Copy Markdown
Author

Hi @brow1633, sorry for disappearing over the last couple of weeks. I have pushed the changes regarding the pattern for ZMQ message handling. I will try to fix the issue with the deprecation of ament_target_dependencies tomorrow, I am having some troubles building the project locally for kilted.

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

Successfully merging this pull request may close these issues.

2 participants