Is the Station task type handled?

[rcywongaa]

It seems the Station message type is not yet implemented

[mxgrey]

That's correct, it is not implemented.

One blocker for this to be done is a bit of a philosophical question: After the robot arrives at the specified place, should it simply sit there doing nothing until it receives a new command, or should it be willing to yield and move out of the way of other robots that might want to pass through its parking spot?

I think part of the difficulty in making this decision is that "stationing" is not a clearly defined task concept. What would be the real-world use case of requesting that some robot perform a task where it simply goes to a location and does nothing else? It has clear usage for demo purposes, but I don't know what the point would be in deployment. I think this blurs the line between "task request" and "manual human intervention" without being very useful for either of those categories.

If anyone has thoughts on the usefulness or recommended design of the "Station" task request, please do share.

[rcywongaa]

I was under the impression that the Station task acts as a low level general task type for workflows that don't strictly fit into a Delivery task or a Loop task.

For example, in our case, the user is supposed to manually load the AGV and then input the destination for dropoff. Since the dropoff location is not known before hand, a single delivery task cannot be used.

Instead, what I had in mind was to use a Station task to bring the AGV to the user loading station first, and then after receiving user input, create the full Delivery task (with a dummy pickup, since pickup is already completed by the user) to send the AGV to the destination.

Food for thought, I wonder if a Station msg of the type

rmf_dispenser_msgs/DispenserRequestItem[] items
string place_name
string dispenser
Behavior behavior

be more generalizable than the current Delivery task. In essence, a Delivery task would just be a pair of Station tasks, and MultiDelivery would just be a sequence of these.

[mxgrey]

I think this kind of logic belongs at a command level instead of a task request level. The goal of the task request interfaces is to provide a description of a goal that needs to be accomplished, preferably without details of how it should be done. Then it should be up to the lower level systems to determine how to achieve the task requirements by issuing commands.

So I think it's fine to have this as a command interface rather than a task interface. Although I still think my original question about what the robot's behavior should be after it arrives at the destination is up in the air.

[rcywongaa]

To make sure I understood you correctly, you're saying that RMF should function at the task level interface and that the Station message along with my use-case of it belongs on the command level that should be transparent to RMF?

If that's the case, how would the system handle situations where commands need to be sent (e.g. AGV should go to the user-loading station) based on incomplete task information (the delivery location is not yet known yet).

I think it would still make sense to expose a Station2* type message in the task level as it represents a general enough task type (go here do this) compared to the current Delivery type (go here do this - go there do that pair).

For your question regarding the robot behavior after it arrives, I think based on the principle of least astonishment, the AGV should stay at it's commanded location. Of course, later on, it may make sense to make this user-configurable (e.g. if dispense hasn't started yet / has completed, AGV may move out of the way). But for the first cut solution, it would likely make more sense and cause less surprises if AGV stayed at the position it was commanded.

* By Station2 type I mean my suggested modified Station type

rmf_dispenser_msgs/DispenserRequestItem[] items
string place_name
string dispenser
Behavior behavior

[mxgrey]

the Station message along with my use-case of it belongs on the command level that should be transparent to RMF?

"Transparent" is a funny word that can either mean "You can see inside of this thing and know exactly how it works" or it can mean "This thing is completely invisible to you". I assume you're going with the second definition.

If so, I don't really have a strong opinion. We could have an optional "command" layer in RMF that lies somewhere below the "task request" layer. I wouldn't have any problem with that, as long as it's considered an optional interface. I also wouldn't have any problem with leaving that out entirely.

how would the system handle situations where commands need to be sent (e.g. AGV should go to the user-loading station) based on incomplete task information (the delivery location is not yet known yet).

If we expect use-cases where we know a robot will need to perform a delivery "soon" and we know where the pickup area is, but we don't know any further details about the delivery, then that sounds like a pretty compelling use-case to motivate a "station" task request.

the AGV should stay at it's commanded location

In that case, I think there should be some kind of rule (maybe or maybe not explicitly enforced at some level of RMF) that these Station requests can only target "places" that are designated as parking spots. Otherwise they could end up being roadblocks for other vehicles.

By Station2 type I mean my suggested modified Station type

I think I would call this a Pickup task request instead of a Station2 request.

[rcywongaa]

In that case, I think there should be some kind of rule (maybe or maybe not explicitly enforced at some level of RMF) that these Station requests can only target "places" that are designated as parking spots. Otherwise they could end up being roadblocks for other vehicles.

Is this rule also enforced for Delivery tasks? If not, I don't see why it should exclusively apply to Station type tasks. If we do end up replacing the Station task with the Station2 task (calling it Station2 for now until a better name comes along. Since it is nothing more than a location-action pair, not necessarily picking up or dropping off), a delivery is really just a sequence of 2 Station2 tasks.

[mxgrey]

Is this rule also enforced for Delivery tasks?

Yes and no. Allow me to elaborate.

The general rule (which isn't explicitly enforced yet, but the system will not work correctly if this isn't followed) is that every robot must either:

1. Be reporting a reasonable estimate of its whole itinerary to the traffic schedule, or
2. Be parked at a designated location that no other robot will want to use or occupy

Delivery tasks fall under (1). When a robot is interacting with a dispenser, it can have a reasonable estimate of how long it will sit there waiting for the item to dispense, and it can report that estimate (as well as estimates for every step of the transportation and drop-off) to the traffic schedule. Ideally the delivery pickup and dropoff locations should be set up so that robots don't generally have a reason to pass through them unless they need to pick something up or drop something off (e.g. they should be leaf nodes on the navigation graph), but that's not strictly required because we can get reasonable estimates for the pickup and dropoff actions (e.g. we can predict that a certain pickup operation will take 30 seconds, so if waiting 30 seconds to pass through that point is the most efficient itinerary for another robot, then it's allowed to choose that strategy).

What makes the Station2 proposal different is that we have incomplete information if we don't know how long the robot will need to wait at the requested location. Without knowing how long the robot will need to wait at that spot, we can't put a reasonable estimate on the schedule. Because of that, if the robot is "stationed" in a spot that other robots want to pass through, there won't be a reasonable way for them to negotiate use of the passage. The "stationed" robot will declare that it wants to sit there indefinitely, and so other robots won't know if they should:

1. wait for the stationed robot to move,
2. demand that the stationed robot move aside so that they can get through, or
3. use a different path entirely to avoid the stationed robot

If enough robots are stationed in inconvenient locations, then option (3) will no longer be viable. If the robot has no estimate for how long it needs to be stationed, then option (1) doesn't make sense. We're left with only option (2), which is why I asked earlier whether a stationed robot should be able to move aside for other robots. If we decide that stationed robots should simply sit in place and not move out of the way of other robots, then all we can do to avoid conflicts is have a rule that robots can only be stationed at designated parking spots that are out of the way of any other traffic.

[mxgrey]

Since it is nothing more than a location-action pair, not necessarily picking up or dropping off)

I don't believe using the same message definition for pickup and dropoff has a reasonable use-case. If a drop-off is performed, then I imagine the robot should return to some kind of parking spot. It shouldn't sit around at the dispenser (effectively blocking others from using the dispenser) once its payload is released. At the very least, the robot should go somewhere to move out of the way of others. Its task would be finished by that point. Because of that, I think there's a strong semantic difference between picking up and dropping off, so I would split those into two separate tasks: Pickup and Dropoff where a Delivery might simply have a Pickup field and a Dropoff field.

[mxgrey]

I think the combination of this PR #308 and this feature request capture the needs of this issue report, so I'll be closing this issue as part of the migration over to the new organization.