Skip to content
This repository has been archived by the owner on Jul 22, 2021. It is now read-only.

Commit

Permalink
Develop/dispatcher demo2 (#181)
Browse files Browse the repository at this point in the history 
* added battery related parameters

* Updated navgraph for office world

* Updated airport_terminal graph, shifted caddy spawn waypoint.

* Added holding points to clinic world

* Updated battery params with more accurate values

* Cleaned up launch files, rviz configs and added tasks.json files for scheduled tasks

* Added rmf_task_dispatcher to common.launch.xml

* Updated mock traffic light addapter launch file

* Develop/rmf demo panel: a react gui with flask server in place of current rmf panel (#176)

* create new rmf_demo_panel

* update panel server and bot battery capacity

* add react app to frontend

* add tabs for different worlds

* add config file in ts format and loop req form

* add delivery form

* add form validation

* remove dist index

* add dashboard config files and config services

* update instructions and setup.py

* add config changes

* add start time field to forms

* add loop and delivery post methods

* add props to forms for rerender on world change

* add evaluator field and update evaluator names

* add antd lib and progress ui

* shift evaluator field and make optional

* add antd css cdn

* add chip to task cards

* remove card overflow and increased height

* add error messages for input fields

* remove unused package and css loader config

* refactor and remove console messages

* add dist folder to setup and update msg srv

* minor ui changes

* update according to new taskdesciption.msg

* add react testing library and roles to components

* add basic tests for components

* add rostime clock component

* remove clean from office config and format quotes

* remove extra lines

* add test for rostime clock

* change typography variant

* edit readme

* add battery and dock icon to robot card

* add roles to forms

* uniform alignment in task card

* add typography to state labels

* add roboto font cdn

* fix start time

* fix dispenser and ingestor results

* add message box alert for status of request submissions

* add message alert box for scheduled tasks and remove unused console logs

* minor cleanups and edit dashboard configs

* fix pystyle

* fix style

* refactor submission of requests and add new tests for cleaning form

* refactor delivery form and add in tests

* uniform test names and adding tests for loop request form

* refactor start time and evaluator

* add test for scheduled task form and remove evaluators from delivery form

* refactor fetch call into services

* remove mock data and add tests for cards

* add cov to gitignore

* remove redundant test

* remove console.log

* change import lines to import used components only and reconfigure webpack

* add loading div

* remove example cards

* edit readme and remove comments/misspellings

* replace periodic fetch call with socket broadcast

* update readme and package xml to v1.0.0

* remove config loading from server, move delivery conversion to frontend

* change cleaning form header

* update socketio version

* remove unused code

* add cancel task functionality

* remove max height for task card and add cancel task button

* remove tasklist folder

* extract gui server block into common.launch.xml

* split web servers, cleanup launch, docs and repo

* update doc

* cleanup api server script

* move dashboard config files to rmf_dashboard_resources

* revert main.json and add cache for get_tasks in server

* revert main.json config, fix style

* refactor submission of delivery request through scheduled form

* stringify js object for post

Co-authored-by: youliang <tan_you_liang@hotmail.com>

* Updated README

* Fixed typos in README

* Added section on task dispatching to README

* add delayed task fix

* add hotel to rmf panel, minor updates on docs

* update ChangeLog

Co-authored-by: val <valeriebuilds@gmail.com>
Co-authored-by: youliang <tan_you_liang@hotmail.com>
Co-authored-by: vallq <vallq@outlook.com>
  • Loading branch information
@Yadunund @vallq @youliangtan
4 people committed Jan 14, 2021
1 parent ac91df7 commit fe3c82b
Show file tree
Hide file tree
Showing 90 changed files with 3,663 additions and 1,076 deletions.
187 changes: 31 additions & 156 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand All @@ -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

Expand All @@ -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)

Expand All @@ -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:

Expand Down Expand Up @@ -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.
17 changes: 15 additions & 2 deletions demos/launch/common.launch.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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)"/>
Expand Down Expand Up @@ -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>
23 changes: 23 additions & 0 deletions demos/launch/dashboard.launch.xml
View file
Original file line number Diff line number Diff line change
@@ -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>
20 changes: 20 additions & 0 deletions demos/launch/include/adapters/caddy_adapter.launch.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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>
25 changes: 25 additions & 0 deletions demos/launch/include/adapters/deliveryRobot_adapter.launch.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,31 @@

<!-- Whether it can perform deliveries -->
<arg name="perform_deliveries" value="true"/>
<!-- Whether it can perform loop -->
<arg name="perform_loop" value="true"/>
<!-- Whether it can perform cleaning -->
<arg name="perform_cleaning" value="false"/>

<!-- TODO Update these values with actual specs -->
<!-- Battery parameters -->
<arg name="battery_voltage" value="24.0"/>
<arg name="battery_capacity" value="40.0"/>
<arg name="battery_charging_current" value="8.8"/>

<!-- 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"/>

<!-- Battery level at which the robot ceases to operate -->
<arg name="recharge_threshold" value="0.1"/>

</include>
</group>
Expand Down
Loading

0 comments on commit fe3c82b

Please sign in to comment.