Waiting time between two stations for the delivery robot

[cihattalat]

Hello. When a task message is sent in the Open RMF system, I want a robot that first goes to point a and then to point b to wait for a while after reaching point a, and especially for this robot that comes to point a, to go specifically to point b. The reason for this is that the product loaded on the robot arriving at point a must go from point a to point b. Which task message should I use to achieve this? The robot going to point A must wait for a while to load the load before the robot goes to point B. How can I perform this hold?

[xiyuoh]

Hello! For this use case, you can take advantage of RMF's custom task feature to get your robot to move to the intended waypoints, then wait there indefinitely until it receives a signal to move off. We have a similar implementation available on rmf_demos, specifically the teleop PerformAction. In this example, we signal the move off by subscribing to the action_execution_notice topic, then call execution.finished() to let RMF know that the robot is done with its custom action and is ready to work on the next phase of the task (if any).

This is a 2-step implementation. For example, if you name your custom action wait_until:

1. Write the logic for your wait_until action inside the fleet adapter's execute_action callback.

From this callback, upon checking that the category passed is indeed your custom action wait_until, you may choose to do nothing (if your robot is simply waiting there) or trigger some custom logic as necessary. It is recommended to store the execution object (like here) so that it can be accessed from anywhere within the class as we will need this object to mark the end of the waiting action.

There are a couple of ways to end the action.

• If this signal to move off is received from an external source, e.g. you subscribe to a certain topic that publishes a message whenever the loading is complete, then in the subscription callback you'll want to call self.execution.finished() to end the action.
• If you'd like your waiting action to be time-based, e.g. move off after waiting for 10 minutes, you can do that within the fleet adapter. For example, check how much time has passed in the update callback, or any other method you may prefer. If the time has exceed a configured waiting time, call self.execution.finished() to end the action. You may want to configure this waiting time in your task JSON, using the description field.
• You may even do both, if you'd like to signal the move off from an external source but also have a default timeout so that the robot won't be stuck at Point A for too long if no one published the move off signal.

2. Design a task that contains the following phases:

• GoToPlace to Point A
• PerformAction wait_until
• GoToPlace to Point B

You are definitely welcome to rearrange these phases as you like.
You may take the teleop task script as a starting point. Here we have a GoToPlace phase followed by a teleop action.

Hope this helps, let me know if you have further questions.

[cihattalat]

I tried that too. But even after the time_out period I gave with wait until expired, the robot did not become active again. I tried publishing the following command to activate it.

ros2 topic pub /action_execution_notice rmf_fleet_msgs/msg/ModeRequest '{fleet_name: 'tinyRobot', robot_name: 'tinyRobot1', mode: {mode: 0}}'

But when I did this, even though I entered the robot name correctly, all the passive and waiting robots became active at the same time. Specifically, the robot whose name I entered and published should have been active, but all of them became active. How can I solve this problem?

[aaronchongth]

Apologies I am finding it a little hard to follow the steps you have taken. Can you provide logs in gist.github.com, and also each of the commands you tried in sequence?

With the composed task with wait_until, there should be nothing related to robot mode that is required, with everything running normally, just the task itself should be suffice.

[cihattalat]

{
  "type": "dispatch_task_request",
  "request": {
    "unix_millis_earliest_start_time": 0,
    "category": "compose",
    "description": {
      "category": "teleop",
      "phases": [
        {
          "activity": {
            "category": "sequence",
            "description": {
              "activities": [
                {
                  "category": "go_to_place",
                  "description": "way_1"
                }
              ]
            }
          }
        },
        {
          "activity": {
            "category": "sequence",
            "description": {
              "activities": [
                {
                  "category": "perform_action",
                  "description": {
                    "unix_millis_action_duration_estimate": 60000,
                    "category": "wait_until",
                    "description": {
                      "timeout": 10,
                      "location": "way_1"
                    }
                  }
                }
              ]
            }
          }
        },
        {
          "activity": {
            "category": "sequence",
            "description": {
              "activities": [
                {
                  "category": "go_to_place",
                  "description": "ent_1"
                }
              ]
            }
          }
        }
      ]
    }
  }
}

Sorry, I'll explain it in more detail.
I am trying this command. With this command, it first goes to way_1 point. Then perform_action becomes active and the robot goes into waiting state. In other words, if I need to explain it via rviz, the yellow light is removed from the robot. As far as I understood later, the yellow light should come back after 10 seconds and the robot should go to ent_1 point, but this never happens. It stays in perform action all the time.

To solve this problem, I published the action_execution_notice topic that I mentioned above. However, as I explained above, this causes all robots to be active (i.e. the yellow light comes on rviz) even though I enter the name of the robot. How can I solve this problem?

[aaronchongth]

There should be no need for the action execution notice as well, but I believe it is due to your compose task category as teleop, can you just use https://gist.github.com/aaronchongth/d8bf7ba0d0cc6692f65f2cc11a03ce7b that I shared instead? It could be arbitrary as long as it is not teleop. With this gist that I just shared I was able to have the desired behavior in simulation

[cihattalat]

I did exactly as you said. But it still got stuck indefinitely and did not go to the 2nd point. I am sending you the version I tried below. I just changed the waypoint names.

{
  "type": "dispatch_task_request",
  "request": {
    "unix_millis_earliest_start_time": 0,
    "category": "compose",
    "description": {
      "category": "rmf_milkrun_delivery",
      "phases": [
        {
          "activity": {
            "category": "sequence",
            "description": {
              "activities": [
                {
                  "category": "go_to_place",
                  "description": "way_1"
                }
              ]
            }
          }
        },
        {
          "activity": {
            "category": "sequence",
            "description": {
              "activities": [
                {
                  "category": "perform_action",
                  "description": {
                    "unix_millis_action_duration_estimate": 60000,
                    "category": "wait_until",
                    "description": {
                      "timeout": 30,
                      "location": "way_1"
                    }
                  }
                }
              ]
            }
          }
        },
        {
          "activity": {
            "category": "sequence",
            "description": {
              "activities": [
                {
                  "category": "go_to_place",
                  "description": "way_2"
                }
              ]
            }
          }
        }
      ]
    }
  }
}

Why might this problem occur? Although it does not give any error, it is not forwarded to the 2nd point and remains as in the photo below.

We are using the main branch of all RMF packages. Here we are using the full_control adapter in rmf_ros2. We are communicating with Free Fleet.