osrf / rmf_core

Provides the centralized functions of RMF: scheduling, etc.
Apache License 2.0
102 stars 41 forks source link

dispatching job to specify robot and get notification of job completion by robot #276

Closed imdalaf closed 3 years ago

imdalaf commented 3 years ago

i understand that when a delivery job is sent to RMF, we can indicate which group of robot (i.e.: fleet or fleet adapter) we want the job to be assigned to. There is a dispatching function in RMF that helps determine which robot within the assigned fleet to be selected to perform the delivery job. Is there any way which we can specify which specific robot to take up the delivery job?

Also, when the robot finished the tasks assigned to it, it there a way for the fleet manager which is outside the RMF to be informed about it?

mxgrey commented 3 years ago

Is there any way which we can specify which specific robot to take up the delivery job?

This is a tricky and controversial matter because of separation of responsibilities. Typically in a production environment, the intention is for individual robots to be completely interchangeable, meaning the "user" (person requesting a delivery) should never have a reason to care about which robot performs a task. Instead the user only cares about the task being done as quickly or efficiently as possible. For that reason, the task management utilities are designed to treat all the robots of a given fleet as equivalent, and the task planner decides which robot to send based on "cost" criteria.

However, we understand that for demo or research purposes it may be useful to specify an individual robot to perform a task, for the sake of reproducibility. Would that be your motive for wanting to specify an individual robot to perform a task, or is your use-case something that I'm not considering?

In the long-run, I think it would be good for RMF to have two operational modes:

  1. Automated task management
  2. Direct operator control

Mode (2) would override mode (1) and allow you to command robots to perform tasks in a way that preempts the automated task management.

Implementing the two modes will take some considerable time and effort, and I don't think it's near the top of our priority list yet, so in the meantime to unblock I might suggest making each robot its own fleet and specify which "fleet" you want to have perform a task. Would that work with the current task dispatching system @Yadunund @tanyouliang95 ?

youliangtan commented 3 years ago

Yes, currently the way around this is by having fleets with a single robot, and each with different traffic lane graph. The user will still submit the task to the dispatcher node. In this case, each fleet will only accept the task which the graph waypoint is valid. Indirectly you are able to select the desired robot to execute a task request.

Surely it will be handy to have an "operator control" mode to assign a task to a specific fleet/robot. We will consider having this feature request in the further future.

txlei commented 3 years ago

@tanyouliang95

different traffic lane graph

do you mean the nav graph? I have 2 fleets that are using the same nav_graph_file for the fleet_adapter launch node. using the rmf web panel, all tasks seem to get queued for only the tinyRobot fleet and not the other fleet I've added. Sending request_loop task using ros2 run to specify which fleet does not work anymore too. Please advice.

mxgrey commented 3 years ago

Fundamentally this is a problem related to "user roles". The final product of task management in RMF is targeted at end-users, not at researchers/developers. End-users generally don't want to specify which particular robot should perform a task, and instead want the system to make the optimal decision on that automatically. On the other hand, researchers/developers may have perfectly valid reasons for wanting to specify a particular robot to perform a task, maybe to test out a specific scenario.

But these two user roles are in conflict with each other. Creating a single API that accommodates both user roles may introduce unnecessary complexity, and should be done cautiously, if at all. We do have plans to support both use cases, but it will likely be done using an "operator override" system that works in parallel to the end-user task request system. That feature will take time to develop.

In the meantime, @tanyouliang95 is suggesting a possible workaround that would allow you to get what you want without needing any new features: You could create two nav graphs which are the same in every way, except the names of their waypoints are different. E.g. add _1 to all the waypoint names of the first nav graph and add _2 to all the waypoint names of the second nav graph. One fleet will use the _1 nav graph while the other fleet will use the _2 nav graph, and then you can specify which fleet should perform a task by using the waypoint names with _1 or _2 in it.

This is not how the system is meant to be used, and we would not consider this a good long-term approach to achieving what you're trying to do. But it should work right away without needing to wait for us to introduce any new features into RMF.

mxgrey commented 3 years ago

Also, the request_loop command has been deprecated in favor of dispatch_loop when using the full control robots. The dispatch_loop is using the new system that optimally selects the robot to perform a task.

mxgrey commented 3 years ago

I'm going to close this ticket as I believe the concerns here are covered under this feature request: https://github.com/open-rmf/rmf_ros2/issues/8