You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Presently, the names for various internal ROS 2 topics are defined in StandardNames.hpp files in multiple packages such as rmf_fleet_adapter, rmf_traffic_ros2, rmf_task_ros2.
Downstream packages need to depend on these packages to include this header file to retrieve topic names even though they do not need any other artifacts. But even so, the correct DDS QoS settings for the topic is not apparent.
Proposal:
We define a separate package, rmf_internal_interfaces (or something relevant)
Then inside a single header file, say RMFInternalInterfaces.hpp:
For each internal interface, say FleetStates that is meant to provide information to publish and subscribe to a topic carrying rmf_fleet_msgs::msg::FleetState message, we have
Presently, the names for various internal ROS 2 topics are defined in
StandardNames.hpp
files in multiple packages such asrmf_fleet_adapter
,rmf_traffic_ros2
,rmf_task_ros2
.Downstream packages need to depend on these packages to include this header file to retrieve topic names even though they do not need any other artifacts. But even so, the correct
DDS QoS
settings for the topic is not apparent.Proposal:
We define a separate package,
rmf_internal_interfaces
(or something relevant)Then inside a single header file, say
RMFInternalInterfaces.hpp
:For each internal interface, say
FleetStates
that is meant to provide information to publish and subscribe to a topic carryingrmf_fleet_msgs::msg::FleetState
message, we havesuch that downstream applications can
Instead of namespaces we could also define
structs
.For stricter API control, we could also have a pure abstract base class
which can be implemented
But the latter would require users to instantiate objects of these classes first.
The text was updated successfully, but these errors were encountered: