Merge branch 'master' of https://github.com/osrf/rmf_demos into featu…

…re/add_multilevel_crowdsim
osrf · tianenchong · Oct 16, 2020 · Oct 16, 2020 · Oct 19, 2020 · Oct 21, 2020
commit 4ca6cbd4e19cc36bdc3b37abc04b0018b6631b8b
diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -0,0 +1,46 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+<!--
+This form is strictly to report bugs.
+For technical help or general questions, please use the Discussions tab on https://github.com/osrf/rmf_demos
+-->
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**Workspace information:**
+ - Operating system and version:
+ - ROS distribution:
+ - ROS installation method: [from binary packages or from source]
+ - RMF installation method: [from binary packages or from source]
+ - RMF binaries version, if installed from binaries:
+ - RMF source versions, if installed from source:
+   - `rmf_demos` branch or commit hash: 
+   - `rmf_core` branch or commit hash: 
+   - `rmf_schedule_visualizaer` branch or commit hash: 
+   - `traffic_editor` branch or commit hash: 
+
+**Steps to Reproduce**
+1. 
+2. 
+3. ```
+
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Actual behavior**
+A description of what actually happens.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Additional context**
+Add any other context about the problem here.
diff --git a/.gitignore b/.gitignore
@@ -0,0 +1,5 @@
+*.pyc
+rmf_dashboard_resources/clinic/main.json
+rmf_dashboard_resources/hotel/main.json
+rmf_dashboard_resources/airport_terminal/main.json
+rmf_dashboard_resources/office/main.json
diff --git a/README.md b/README.md
@@ -27,6 +27,18 @@ Instructions can be found [here](docs/installation.md).
 ## FAQ
 Answers to frequently asked questions can be found [here](docs/faq.md).
 
+## RMF Panel
+![](docs/media/RMF_Panel.png)
+
+The RMF panel is a web based dashboard for interacting with RMF. It allows users to send task requests to RMF and monitor the status of robots and submitted tasks.
+There are two main modes of submitting tasks to RMF via the Panel:
+
+1. Submit a Task: Used to submit a single task. The user is required to first select a request type from the drop down menu. Depending on the type selected, additional fields specify to the type will need to be populated. The user can then specify the `start time` for the task before clicking `Submit Request`. 
+2. Submit a List of Tasks: Used to submit a batch of tasks. A `.json` file containing a list of tasks may be loaded via the `Choose file` button. Some example files are found in `rmf_demo_tasks/rmf_demo_tasks`. Once loaded, clicking the `Submit Task List` button will automatically assign the various tasks to available robots.
+
+Users may switch between different tabs on the top-left corner of the Panel when running the relevant demo world. More information on configuring the panel can be found [here](rmf_demo_panel/README.md)
+
+
 ## Demo Worlds
 
 * [Office World](#Office-World)
@@ -47,136 +59,21 @@ source ~/rmf_demos_ws/install/setup.bash
 ros2 launch demos office.launch.xml
 ```
 
-To simulate a delivery
-
-Select `pantry` and `hardware_2` as `Start` and `End` waypoints. Ensure `Pickup` and `Dropoff` dispensers are set to `coke_dispenser` and `coke_ingestor` respectively. Finally, click the `Send Delivery Request` button in the RViz `RMF Panel`.
-
-Alternatively, a launch file is configured to achieve the same result.
-
+To send task requests, open RMF Panel from a browser
 ```bash
-source ~/rmf_demos_ws/install/setup.bash
-ros2 launch demos office_delivery.launch.xml
+firefox localhost:5000
 ```
 
-![](docs/media/delivery_request.gif)
+To submit a delivery task, select `Delivery` from the `Select a request type` dropdown list. Next, select `coke` from the `Select delivery task` list. Choose an desired start time for task and click submit.
 
-To request each of the TinyRobot to loop between two points,
-Select desired `Start` and `End` waypoints using the `RMF Panel` and click the `Send Loop Request` button. Alternatively,
+![](docs/media/delivery_request.gif)
 
-```bash
-source ~/rmf_demos_ws/install/setup.bash
-ros2 launch demos office_loop.launch.xml
-```
+To send loop requests, select `Loop` from the `Select a request type` dropdown list. Choose desired start and end locations and click submit.
+To run a scenario with multiple task requests, load `office_tasks.json` from `rmf_demo_tasks/rmf_demos_tasks` in the `Submit a list of tasks` section. This should populate the preview window with a list of tasks. Click submit and watch the demonstration unfold.
 
 ![](docs/media/loop_request.gif)
 
-#### Secure ROS 2 Office Demo
-
-The office demo can be run in secure mode using the [ROS 2 DDS-Security integration](https://design.ros2.org/articles/ros2_dds_security.html) (SROS2) capabilities. This security features will provide encryption, authentication and access control to the whole ROS2 setup of RMF.
-
-Because of the heavy development undergoing RMF, changes happen in a very fast manner. Therefore, the ROS 2 Access Control Policies declared in the `office.policy.xml` file are only guaranteed to work with the RMF release 1.1.X, so please set all the git repos of your RMF workspace to point to the tag `1.1.0`. Alternatively you could update the policies yourself to any later version of RMF (PRs are welcome if you do so :smirk:).
-
-There is a `tmux` based script that automates pane splitting and the execution of all the required commands to run the office demo. In order to run it this way just open a tmux terminal and run the script.
-
-```
-bash ./install/demos/share/demos/sros2/office_deploy.bash
-```
-
-Alongside, the following steps can be used to run all required commands individually.
-
-To use ROS 2 to secure the office demo a few environmental variables need to be set. Adding them to a script would make it easier to source them in any shell where we need to run ROS 2 secured nodes.
-
-```bash
-echo 'export ROS_SECURITY_KEYSTORE=~/rmf_demos_ws/keystore
-export ROS_SECURITY_ENABLE=true
-export ROS_SECURITY_STRATEGY=Enforce
-export ROS_DOMAIN_ID=42' > sros2_environment.sh
-```
-
-A few security artifacts like signed permission files, identity certificates and Certificate Authorities (CA) are needed to enable the DDS Security. They can be generated using the security tools from the ROS2 cli. Because of [#242](https://github.com/ros2/sros2/issues/242) and until its solution [#238](https://github.com/ros2/sros2/pull/238) is released it is recommended to generate the security artifacts before switching to `cyclone_dds`.
-
-```
-source sros2_environment.sh
-mkdir keystore
-ros2 security generate_artifacts -k keystore -p ./install/demos/share/demos/sros2/policies/office.policy.xml
-```
-
-It is recommended to use `cyclone dds` with the secure version of the demo, make sure it is properly installed, with security support and selected through the correspondent environment variable ([here](https://index.ros.org/doc/ros2/Installation/DDS-Implementations/Working-with-Eclipse-CycloneDDS/) you can find instructions on how to do it). Adding this to the environment script makes it easier to source in any terminal that might need it,
-
-```bash
-echo 'export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp' >> sros2_environment.sh
-```
-
-Because SROS2 does not support `ros2 launch` yet all the different nodes will have to be launched individually. A `yaml` file with the parameters of all the nodes is provided. One terminal per execution is recommended for an easier debug of the system. Make sure you `source ~/rmf_demos_ws/install/setup.bash` in each of them before executing the different commands.
-
-```bash
-source sros2_environment.sh
-ros2 run rmf_traffic_ros2 rmf_traffic_schedule --ros-args --params-file ./install/demos/share/demos/sros2/office.params.yaml --enclave /office/rmf_traffic_schedule_node
-```
-
-```bash
-source sros2_environment.sh
-ros2 run building_map_tools building_map_server ./install/rmf_demo_maps/share/rmf_demo_maps/office/office.building.yaml --ros-args --enclave /office/building_map_server
-```
-
-```bash
-source sros2_environment.sh
-ros2 run rmf_schedule_visualizer rviz2 -r 10 -m L1 --ros-args --params-file ./install/demos/share/demos/sros2/office.params.yaml --enclave /office/rviz2_node
-```
-
-```bash
-source sros2_environment.sh
-ros2 run building_systems_visualizer building_systems_visualizer -m L1 --ros-args --params-file ./install/demos/share/demos/sros2/office.params.yaml --enclave /office/building_systems_visualizer
-```
-
-```bash
-source sros2_environment.sh
-ros2 run fleet_state_visualizer fleet_state_visualizer -m L1 --ros-args --params-file ./install/demos/share/demos/sros2/office.params.yaml --enclave /office/fleet_state_visualizer
-```
-
-```bash
-source sros2_environment.sh
-rviz2 -d ./install/demos/share/demos/include/office/office.rviz --ros-args --enclave /office/rviz2
-```
-
-```bash
-source sros2_environment.sh
-ros2 run rmf_fleet_adapter door_supervisor --ros-args --enclave /office/door_supervisor
-```
-
-Gazebo needs the environment variables to locate files, and set up communications between the server and clients. They can be added to a script for an easier re-use.
-
-```bash
-echo 'export GAZEBO_MODEL_PATH=~/rmf_demos_ws/install/rmf_demo_maps/share/rmf_demo_maps/maps/office/models:~/rmf_demos_ws/install/rmf_demo_assets/share/rmf_demo_assets/models:/usr/share/gazebo-11/models
-export GAZEBO_RESOURCE_PATH=~/rmf_demos_ws/install/rmf_demo_assets/share/rmf_demo_assets:/usr/share/gazebo-11
-export GAZEBO_PLUGIN_PATH=~/rmf_demos_ws/install/rmf_gazebo_plugins/lib:~/rmf_demos_ws/install/building_gazebo_plugins/lib/
-export GAZEBO_MODEL_DATABASE_URI=""' > gazebo_environment.sh
-```
-
-```bash
-source sros2_environment.sh
-source gazebo_environment.sh
-gzserver --verbose -s libgazebo_ros_factory.so -s libgazebo_ros_init.so ./install/rmf_demo_maps/share/rmf_demo_maps/maps/office/office.world --ros-args --enclave /office/gzserver
-```
-
-Because of [#151](https://github.com/osrf/rmf_demos/issues/151), the ros node created by plugins run on gzclient will be left out of the secured network. This should only affect the `toggle_floors` plugin that runs on gzclient and is intended for multilevel demos.
-
-```bash
-source gazebo_environment.sh
-gzclient --verbose ./install/rmf_demo_maps/share/rmf_demo_maps/maps/office/office.world
-```
-
-```bash
-source sros2_environment.sh
-ros2 run rmf_fleet_adapter full_control --ros-args -r __node:=tinyRobot_fleet_adapter --params-file ./install/demos/share/demos/sros2/office.params.yaml --enclave /office/tinyRobot_fleet_adapter
-```
-
-```bash
-source sros2_environment.sh
-ros2 run rmf_fleet_adapter robot_state_aggregator --ros-args -r __node:=tinyRobot_state_aggregator --params-file ./install/demos/share/demos/sros2/office.params.yaml --enclave /office/tinyRobot_state_aggregator
-```
-
-The system is now ready to attend simulated delivery requests as per usual but with all the guarantees of [DDS-security](https://www.omg.org/spec/DDS-SECURITY/1.1/PDF)!
+The office demo can be run in secure mode using ROS 2 DDS-Security integration. Click [here](docs/secure_office_world.md) to learn more.
 
 ### Airport Terminal World
 
@@ -193,35 +90,11 @@ source ~/rmf_demos_ws/install/setup.bash
 ros2 launch demos airport_terminal.launch.xml
 ```
 
-To spawn robots into the world and issue tasks to the same,
-
-```bash
-source ~/rmf_demos_ws/install/setup.bash
-ros2 run demos airport_terminal_scenario.sh
-```
-This command spawns two DeliveryRobots and four TinyRobots in the map. Out of these one DeliveryRobot and two TinyRobots are issued loop request tasks. The other robots are idle and can be issued loop or delivery request tasks via the `RMF Panel`.
-
-Alternatively, to spawn all the robots without issuing any task orders,
-
-```bash
-source ~/rmf_demos_ws/install/setup.bash
-ros2 run demos airport_terminal_spawn_robots.sh
-```
-
-An delivery request may also be submitted via a launch file,
-```bash
-source ~/rmf_demos_ws/install/setup.bash
-ros2 launch demos airport_terminal_delivery.launch.xml
-```
-
-Non-autonomous vehicles can also be integrated with RMF provided their positions can be localized in the world. This may be of value at facilities where space is shared by autonomous robots as well as manually operated vechiles such as forklifts or transporters. In this demo, we can introduce a vehicle (caddy) which can be driven around through keyboard/joystick teleop. In RMF nomenclature, this vehicle is classified as a `read_only` type, ie, RMF can only infer its position in the world but does not have control over its motion. Here, the goal is to have other controllable robots avoid this vechile's path by replanning their routes if needed. The model is fitted with a plugin which generates a prediction of the vehicle's path based on its current heading. It is configured to occupy the same lanes as the `tinyRobot` robots. Here, a `read_only_fleet_adapter` submits the prediction from the plugin to the RMF schedule.
+Select the `airport` tab on RMF Panel. Load the `airport_terminal_tasks.json` list and click submit to begin a collection of loop, delivery and cleaning tasks.
 
-To spawn the caddy into the world,
+Non-autonomous vehicles can also be integrated with RMF provided their positions can be localized in the world. This may be of value at facilities where space is shared by autonomous robots as well as manually operated vehicles such as forklifts or transporters. In this demo, we can introduce a vehicle (caddy) which can be driven around through keyboard/joystick teleop. In RMF nomenclature, this vehicle is classified as a `read_only` type, ie, RMF can only infer its position in the world but does not have control over its motion. Here, the goal is to have other controllable robots avoid this vehicle's path by replanning their routes if needed. The model is fitted with a plugin which generates a prediction of the vehicle's path based on its current heading. It is configured to occupy the same lanes as the `tinyRobot` robots. Here, a `read_only_fleet_adapter` submits the prediction from the plugin to the RMF schedule.
 
-```bash
-source ~/rmf_demos_ws/install/setup.bash
-ros2 launch demos airport_terminal_caddy.launch.xml
-```
+In the airport terminal map, a `Caddy` is spawned in the far right corner and can be controlled with `geometry_msgs/Twist` messages published over the `cmd_vel` topic. 
 
 ![](docs/media/caddy.gif)
 
@@ -239,12 +112,7 @@ source ~/rmf_demos_ws/install/setup.bash
 ros2 launch demos clinic.launch.xml
 ```
 
-To request different robots perform loop requests, a launch file has been configured,
-
-```bash
-source ~/rmf_demo_ws/install/setup.bash
-ros2 launch demos clinic_loop.launch.xml
-```
+Select the `clinic` tab on RMF Panel. Load the `clinic_tasks.json` list and click submit to begin a collection of loop and delivery tasks.
 
 Robots taking lift:
 
@@ -277,8 +145,15 @@ source ~/rmf_demos_ws/install/setup.bash
 ros2 launch demos hotel.launch.xml
 ```
 
-To simulate a loop request, select desired robot fleet, `Start` and `End` waypoints using the `RMF Panel` and click the `Send Loop Request` button.
+Select the `hotel` tab on RMF Panel. Loop requests can be submitted via "Submit a Task" form.
 
 Robot taking lift:
 
 ![](docs/media/robot_taking_lift_hotel.gif)
+
+## Task Dispatching in RMF
+![](docs/media/RMF_Bidding.png)
+
+In RMF version `21.04` and above, tasks are awarded to robot fleets based on the outcome of a bidding process that is orchestrated by a Dispatcher node, `rmf_dispatcher_node`. When the Dispatcher receives a new task request from a UI, it sends out a `rmf_task_msgs/BidNotice` message to all the fleet adapters. If a fleet adapter is able to process that request, it submits a `rmf_task_msgs/BidProposal` message back to the Dispatcher with a cost to accommodate the task. An instance of `rmf_task::agv::TaskPlanner` is used by the fleet adapters to determine how best to accommodate the new request. The Dispatcher compares all the `BidProposals` received and then submits a `rmf_task_msgs/DispatchRequest` message with the fleet name of the robot that the bid is awarded to. There are a couple different ways the Dispatcher evaluates the proposals such as fastest to finish, lowest cost, etc which can be configured.
+
+Battery recharging is tightly integrated with the new task planner. `ChargeBattery` tasks are optimally injected into a robot's schedule when the robot has insufficient charge to fulfill a series of tasks. Currently we assume each robot in the map has a dedicated charging location as annotated with the `is_charger` option in the traffic editor map.
diff --git a/demos/CHANGELOG.rst b/demos/CHANGELOG.rst
@@ -2,8 +2,8 @@
 Changelog for package demos
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Forthcoming
------------
+1.2.0 (2021-01-06)
+------------------
 * Secured Ros2 office demo. [#135](https://github.com/osrf/rmf_demos/pull/135)
 * Traffic Light Scenarios. [#168](https://github.com/osrf/rmf_demos/pull/168)
 

diff --git a/demos/launch/common.launch.xml b/demos/launch/common.launch.xml
@@ -5,8 +5,9 @@
   <arg name="use_sim_time" default="false" description="Use the /clock topic for time to sync with simulation"/>
   <arg name="viz_config_file" default="$(find-pkg-share rmf_schedule_visualizer)/config/rmf.rviz"/>
   <arg name="config_file" description="Building description file required by building_map_tools"/>
-  <arg name="headless" description="do not launch rviz; launch gazebo in headless mode" default="false" />
-
+  <arg name="headless" description="do not launch rviz; launch gazebo in headless mode" default="false"/>
+  <arg name="bidding_time_window" description="Time window in seconds for task bidding process" default="2.0"/>
+
   <!-- Traffic Schedule  -->
   <node pkg="rmf_traffic_ros2" exec="rmf_traffic_schedule" output="both">
     <param name="use_sim_time" value="$(var use_sim_time)"/>
@@ -42,4 +43,16 @@
     <node pkg="rmf_fleet_adapter" exec="lift_supervisor"/>
   </group>
 
+  <!-- Dispatcher Node -->
+  <group>
+    <node pkg="rmf_task_ros2" exec="rmf_task_dispatcher"  output="screen">
+      <param name="use_sim_time" value="$(var use_sim_time)"/>
+      <param name="bidding_time_window" value="$(var bidding_time_window)"/>
+    </node>
+  </group>
+
+  <include file="$(find-pkg-share demos)/dashboard.launch.xml">
+    <arg name="use_sim_time" value="true"/>
+  </include>
+
 </launch>
diff --git a/demos/launch/dashboard.launch.xml b/demos/launch/dashboard.launch.xml
@@ -0,0 +1,23 @@
+<?xml version='1.0' ?>
+<!-- Launch file to run dispatcher node and dispatcher api and gui server -->
+
+<launch>
+  <arg name="use_sim_time" default="true" description="Use the /clock topic for time to sync with simulation"/>
+  <arg name="server_ip" default="0.0.0.0" description="GUI IP address"/>
+
+  <!-- Dispatcher API Server -->
+  <group>
+    <node pkg="rmf_demo_panel" exec="api_server"  output="screen">
+      <param name="use_sim_time" value="$(var use_sim_time)"/>
+      <env name="WEB_SERVER_IP_ADDRESS" value="$(var server_ip)" />
+    </node>
+  </group>
+
+  <!-- Dashboard GUI Server -->
+  <group>
+    <node pkg="rmf_demo_panel" exec="gui_server"  output="screen">
+      <env name="WEB_SERVER_IP_ADDRESS" value="$(var server_ip)" />
+    </node>
+  </group>
+
+</launch>
diff --git a/demos/launch/include/adapters/caddy_adapter.launch.xml b/demos/launch/include/adapters/caddy_adapter.launch.xml
@@ -26,6 +26,26 @@
 
       <arg name="delay_threshold" value="1.0"/>
 
+      <!-- TODO Update these values with actual specs -->
+      <!-- Battery parameters -->
+      <arg name="battery_voltage" value="24.0"/>
+      <arg name="battery_capacity" value="2.0"/>
+      <arg name="battery_charging_current" value="24.0"/>
+
+      <!-- Physical parameters -->
+      <arg name="mass" value="70.0"/>
+      <arg name="inertia" value="40.0"/>
+      <arg name="friction_coefficient" value="0.22"/>
+
+      <!-- Power systems -->
+      <arg name="ambient_power_drain" value="20.0"/>
+      <arg name="tool_power_drain" value="0.0"/>
+
+      <!-- Whether to consider battery drain for task planning -->
+      <arg name="drain_battery" value="true"/>
+
+      <arg name="recharge_threshold" value="0.2"/>
+
     </include>
   </group>
 </launch>