Dnae adas/generic subscriber and publisher#1077
Conversation
|
@Karsten1987 I did not create a spezialzation of Publisher for SerializedMessages as I disklike copying so much redudant code. I redesigned it so the changes to the Publisher are reduced. I hope it does not break to much with the current api. (But I have also a version with a spezialized publisher in backup) |
|
depends on #1076 |
|
A few questions before reviewing, I'm probably missing some context from #973 discussion:
Thanks! |
| create_generic_publisher( | ||
| NodeT & node, | ||
| const std::string & topic_name, | ||
| const rosidl_message_type_support_t & type_support, |
There was a problem hiding this comment.
Why both MessageT template parameter and the type_support argument are needed?
There was a problem hiding this comment.
Naming should also be more clear.
Maybe, just an override of create_publisher?
There was a problem hiding this comment.
I think MessageT is used for the allocator
| if (RCL_RET_OK != status) { | ||
| rclcpp::exceptions::throw_from_rcl_error(status, "failed to publish message"); | ||
| } | ||
| generic_publisher::do_inter_process_publish(publisher_handle_, msg); |
There was a problem hiding this comment.
I don't understand why the two new free functions are needed, and why a "normal" Publisher is calling the functions in generic_publisher namespace.
@DensoADAS can you expain?
There was a problem hiding this comment.
for the SerializedMessage the original "do_inter_process_publish" will fail as it's no ROS message
There was a problem hiding this comment.
can we just are an override for a serialized message in the Publisher class?
Karsten1987
left a comment
There was a problem hiding this comment.
Given that there is no generic publisher type, I would think it makes sense best to not mention this and keep the notation to publisher.
The "generic" publisher/subscriber allows communication without knowing the message type to compile time. Therefore a serialized message can bei published or received and the endpoint has to handle the content itself. This is used for example in rosbag2. This implementation supports now intraprocess communication when using the C++ version of serialized messages which make the memory handling more safe. |
e0fb512 to
b5bce53
Compare
Ah ok. So in those cases, you use |
* implemented interface to deserialize a given serialized message to ros message Signed-off-by: Joshua Hampp <[email protected]>
* serialized publisher uses correct method to forward content to subscriber * non-serialized publisher can serialize message for serialized subscriber Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
…cess_message Signed-off-by: Joshua Hampp <[email protected]>
…y needed for the next PR) Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Dirk Thomas <[email protected]>
* Reflect changes in rclcpp API Signed-off-by: Prajakta Gokhale <[email protected]> * Revert earlier fix made in rclcpp Signed-off-by: Prajakta Gokhale <[email protected]>
* added constructor with typesupport * added more generic do_inter_process_publish Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
…d subscribers Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
b5bce53 to
aeb69bf
Compare
|
Switching back to create_generic_... would solve this. Do you have another suggestion? |
|
@Karsten1987 I lost a little bit the track of the conversation. What's the current status? |
|
In my opinion, #1076 (comment) this is where we stand. I think the intraprocess manager should be sorted out before pushing forward with this change. |
* removed specialization to rclcpp::Serialization Signed-off-by: Joshua Hampp <[email protected]>
* allocate message * getter for serialization * provide untyped message Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
* two extra subscription/publisher pairs (for serialized ones) * added methods for (de)serialization * added methods for messages without known allocator * splitted up publishing with same type and not matching message type Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
Signed-off-by: Joshua Hampp <[email protected]>
|
Thanks @DensoADAS for iterating over this PR. Unfortunately, we've passed API freeze for Foxy and after talking with @jacobperron (the Foxy lead), we've decided to table this for G-Turtle. |
|
Is a generic subscriber available in Foxy? I don't think I can use ROS2 until it is in. :/ |
Not in rclcpp. Unless something like this PR can be done in an ABI compatible way, I don't think we can expect it to land in Foxy. As mentioned on ROS Answers, you can do this in Python and/or copy the C++ implementation from rosbag2 for your application. |
using SerializedMessage and support in intraprocess manager to create a generic subscriber / publisher without previously known message type