ROS 2 supports several message types and users can also create custom message definitions. The [common_interfaces](https://github.com/ros2/common_interfaces) includes several ROS 2 packages which encapsulate the most commonly used message definitions.
Problem
When creating a publisher, the user should be able to select what type of message will be published to a specific topic. For example, if the user wants to publish string messages, the user would want to select the String message definition from the std_msgs package.
from std_msgs.msg import String
ros_node.create_publisher(String, 'ros_topic')
Similarly, when creating a subscriber. The user selects the message definition for a given topic.
One solution could be to create a block for each message definition, but this would not scale nicely and it would not be possible to support custom messages.
A better solution is to have a single block with two drop-down menus.
The first menu would be for the user to select the ROS 2 package where the message definition is located (std_msgs, geometry_msgs, nav_msgs, etc.)
And the second menu would be populated based on the selection from the first menu. It should list all of the message definitions included in the given package.
Challenges:
How to populate the second drop-down menu (which selects the message definition) so that it is conditional on the first menu (the message package containing multiple definitions)
Context
ROS 2 supports several message types and users can also create custom message definitions. The
[common_interfaces](https://github.com/ros2/common_interfaces)includes several ROS 2 packages which encapsulate the most commonly used message definitions.Problem
When creating a publisher, the user should be able to select what type of message will be published to a specific topic. For example, if the user wants to publish string messages, the user would want to select the
Stringmessage definition from thestd_msgspackage.Similarly, when creating a subscriber. The user selects the message definition for a given topic.
Proposed Solution
One solution could be to create a block for each message definition, but this would not scale nicely and it would not be possible to support custom messages.
A better solution is to have a single block with two drop-down menus.
std_msgs,geometry_msgs,nav_msgs, etc.)Challenges:
References
From SyncLinear.com | BLO-90