Optional Requests


Use case - request 3-5 robots (of possibly varying kinds) doing delivery where 3 is the minimum to run the service, and the latter just improve the service.

Current Resolution

  • Pending for now, but would like to tackle it sometime soon (maybe a January iteration).

Discussion Thread

Post-December 3

  • (Jack) I've been thinking about a different solution to this problem:

    • treat the Request.resources list as an ordered sequence

    • add a Request.min_resources field

    • the request will be granted when at least the first min_resources items are available. Any remaining resources will also be allocated, but only if they are available at that moment.

December 3

This ended up being very related to batched requests.

  • (Jack) Could add additional requests for the extras.

  • (Daniel) Run into a problem where two individual robots might get allocated before the essential batched request of 3 is allocated. If there aren't 5 robots, then the service is deadlocked and can't start, even if there are three robots because they are allocated 1-1-1.

  • In the batched request seems like the right place to put these.
  • (Piyush) Would need a flag of some sort to identify optional resources.

  • (Daniel) If we had priorities for each resource, a negative number could represent optionality, and the abs value of the priority the urgency of the priority.

Wiki: rocon_concert/Reviews/simple_scheduler API proposal_API_Review/Optional Requests (last edited 2013-12-03 17:47:54 by JackOQuin)