Generate low-level action typesupport API

[hidmic]

Feature request

Feature description

In order to bundle reusable logic bits within rcl to support actions, basic access to action ID information on a per message basis is a prerequisite. And since rcl cannot treat client library specific messages as anything but pointers void of any type, some low-level C access to that information has to be generated and exposed.

Implementation considerations

A potential solution (as suggested initially by @jacobperron) would be to generate conversion functions for the relevant message types. Elaborating on this idea, I believe we could introduce getters and setters in rosidl_action_type_support_t to help rcl interact with type erased messages. Generated function count totalizes 10 functions, including:

1. GoalInfo getters from:
   1. action goal request messages, for the action server to use.
   2. action goal response messages, for the action client to return.
   3. action result request messages, for the action server to use.
   4. action result response messages, for the action client to return
   5. action feedback messages, for the action client to filter and return.
2. GoalInfo setters into:
   1. action goal request messages, for the action client to set and track.
   2. action goal response messages, for the action server to set.
   3. action result request messages, for the action client to set.
   4. action result response messages, for the action server to set.
   5. action feedback messages, for the action server to set.

To this, we add 6 more functions to deal with cancellation and status updates (that use the same types for all actions):

1. GoalInfo setter into action cancel request messages, for the action client to use.
2. GoalInfo getter from action cancel request messages, for the action client to set.
3. GoalInfoArray setter into action cancel response messages, for the action server to set.
4. GoalInfoArray getter from action cancel response messages, for the action client to track.
5. GoalStatusArray setter into action status messages, for the action server to use.
6. GoalStatusArray getter from action status messages, for the action client to filter and track.

Allocation mechanism for these messages in a type agnostic manner may also be necessary.

This scheme allows us to push most if not all action client and server logic inside rcl, avoiding duplication in client libraries, while making use of client library specific types to ease introspection and further tinkering. We may also strip some of them and delegate on the client library, tolerating duplication to an extent.

[dirk-thomas]

@hidmic @jacobperron Can this be closed?

[hidmic]

IIRC this has not been implemented. This issue is about changing typesupport packages to provide API that can help rcl interact with action-specific fields in type erased action goals, results, and such. Instead, we ended up making most of rcl's action API just forward type erased messages to the proper pub/sub or service/client API, and re-implemented quite a bit of action server and client functionality in client libraries.

Having said that, I don't know how relevant / likely this is at this point.

[jacobperron]

Although I think it's a nice idea, I don't foresee us doing this refactor any time soon. I think it's okay to add the "backlog" label or close altogether if you prefer (I don't have a preference).