search

utexas-bwi / concert_scheduling

Scheduler support packages for the Robotics in Concert project
http://wiki.ros.org/concert_scheduling
1 stars 4 forks source link

scheduler_node : resource status via the requester feedback #24

Open stonier opened 10 years ago

stonier commented 10 years ago

Some background information can also be found in #23.

A requester currently has to track resource status (i.e. MISSING or not) in the resource_pool topic. While this is eminently doable, it would be convenient to have this information show up in the requester feedback function which is where a requester (I think) typically does alot of it's decision making.

The variable that gets passed back in the requester feedback function is the RequestSet which has resource information embedded in scheduler_msgs.Resouorce which would feel like a more natural place to get resource status feedback.

Note: this doesn't have to be done since we have a way of getting it already. What are your thoughts on it though Jack?

jack-oquin commented 10 years ago

We certainly want to make it as convenient as possible for requesters to handle both temporary and permanent outages.

I do like the modularity of the separate concert_resource_pool and concert_scheduler_requests packages. They are almost completely independent, except that pool resources may be "owned" by an ActiveRequest object, which keeps a list of its currently allocated resources. None of that necessarily prevents doing a good job of reporting information in a form that requesters can handle cleanly.

One idea I have considered, but not worked out in any detail, is providing a concert_resource_pool interface for requesters similar to what already exists on the scheduler side. It would handle the ROS messages and track the association of known resources with the current request set. That way, the requester could do most of its processing in the request feedback callback based on helpful links between each ResourceRequest object and its associated pool resources.