Interface Mechanisms

Topic

Should the interface be an actionlib client/server? Or should it be some other kind of goal oriented approach? Concurrency?

Current Resolution

A mix of pubs/subs with action style request feedback but allows parallel requests.

The ROCON scheduler subscribes to an allocation topic. Any ROCON service or application sending messages to that topic is called a requester. Each requester assigns itself a Universally Unique Identifier (UUID) and subscribes to a feedback topic suffixed by its hexadecimal string representation, as shown below. The scheduler will provide status feedback on that topic.

• default scheduler_msgs/SchedulerRequests topic names:

  • allocation: /rocon_scheduler

  • feedback: /rocon_scheduler_0123456789abcdef0123456789abcdef

Discussion

• (Jack) Does actionlib actually allow multiple concurrent requests?

  • (Jack) Apparently not. New requests preempt old ones. We'll need to work out a different solution.

  • (Daniel) For quite some time I've wanted to write a similar module for queued, even parallelised jobs rather than pre-emptible jobs.

  • (Jack) A more-general actionlib implementation is worth doing, but ambitious for this one project. Have you a pointer to some work Marcus already did in that direction?

    • (Daniel) I'm not aware that Marcus has already done something here - will ask and return here with information if he has.

  • (Jack) The way this design is evolving will likely require C++ and Python class interfaces to manage the state transitions for both requesters and schedulers. It is not yet clear whether that mechanism can be generalized to handle other applications.

  • (Daniel) Ok, sounds reasonable.

• (Jack) Since actionlib is not going to work and we need to keep moving forward, I'm proceeding with a topic-based approach. The basic idea is that the scheduler subscribes to a /rocon_scheduler topic of type scheduler_msgs/SchedulerRequests. Each requester assigns itself a Universally Unique Identifier and subscribes to a topic using the string representation of its unique ID, in the form /rocon_scheduler_01234567-89ab-cdef-0123-456789abcdef. The scheduler will provide status feedback on that topic via scheduler_msgs/SchedulerRequests messages. The details are still to be determined, see this overview

  • (Jack) ROS complains that '-' is not a valid character in a topic name. It actually runs, but we should avoid it and remove the dashes, leaving /rocon_scheduler_0123456789abcdef0123456789abcdef.

• (Daniel) While thinking of satisfying a simple orchestration that we are looking at, I can't find anything missing here - I'd tentatively stamp this as the way to go for a first iteration.

• (Jack) I made an initial guess at the various states of each resource request based on the actionlib goal states. They will likely change until there is a prototype implementation available.

  • (Daniel) As above, it looks like a reasonable plan for a first iteration so we can evaluate its appropriateness.