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
Currently, the domain bridge only supports topics, but it would be great to support services as well.
Analogous to how topics are bridged by creating a subscription/publisher pair, services could be bridged by creating a service/client pair that forwards calls from clients in one domain to services in another domain. For example, a service /add_two_ints could be bridged from domain ID 1 to domain ID 2 by
Waiting for a /add_two_ints service to be offered in domain ID 2
When the service is ready, create an equivalent a service in the bridge, but on domain ID 1
Also create a service client for domain ID 2
Whenever a request comes in on domain ID 1, forward it to domain ID 2 using the bridges service client
When a response comes back on domain ID 2, forward it to domain ID 1.
This requires the service and client created by the bridge to communicate within the same process (e.g. using a shared resource).
I don't think we should be concerned with supporting multiple services by the same name, since that isn't well supported in ROS itself.
One critical blocker for this feature may be type support. Unlike topic messages, services do not have equivalent APIs readily available for working with serialized data. This means we may find it difficult to forward requests/responses without knowing the service types at compile time.
The text was updated successfully, but these errors were encountered:
The only thing yet not supported is to configure the bridge dynamically from a yaml file, like we can do for topics.
For bridging services currently a custom executable setting the bridge correctly is needed.
Currently, the domain bridge only supports topics, but it would be great to support services as well.
Analogous to how topics are bridged by creating a subscription/publisher pair, services could be bridged by creating a service/client pair that forwards calls from clients in one domain to services in another domain. For example, a service
/add_two_ints
could be bridged from domain ID 1 to domain ID 2 by/add_two_ints
service to be offered in domain ID 2This requires the service and client created by the bridge to communicate within the same process (e.g. using a shared resource).
I don't think we should be concerned with supporting multiple services by the same name, since that isn't well supported in ROS itself.
One critical blocker for this feature may be type support. Unlike topic messages, services do not have equivalent APIs readily available for working with serialized data. This means we may find it difficult to forward requests/responses without knowing the service types at compile time.
The text was updated successfully, but these errors were encountered: