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.