Giter Club home page Giter Club logo

rmf_demos's Introduction

RMF Demos

The Open Robotics Middleware Framework (Open-RMF) enables interoperability among heterogeneous robot fleets while managing robot traffic that share resources such as space, building infrastructure systems (lifts, doors, etc) and other automation systems within the same facility. Open-RMF also handles task allocation and conflict resolution among its participants (de-conflicting traffic lanes and other resources). These capabilities are provided by various libraries in Open-RMF. For more details about Open RMF, refer to the comprehensive documentation provided here.

This repository contains demonstrations of the above mentioned capabilities of RMF. It serves as a starting point for working and integrating with Open-RMF.

Robotics Middleware Framework

(Click to watch video)

System Requirements

These demos were built and tested on

Note: RMF is fully supported on ROS 2 Foxy as well

Installation

Instructions can be found here.

FAQ

Answers to frequently asked questions can be found here.

Roadmap

A near-term roadmap of the Open-RMF project can be found in the user manual here.

RMF-Web

Full web application of Open-RMF: rmf-web.

In order to interact with the default configuration of the web application, the server_uri launch parameter will need to be changed to ws://localhost:8000/_internal, for example,

ros2 launch rmf_demos_gz office.launch.xml server_uri:="ws://localhost:8000/_internal"

By specifying server_uri, the fleetadapter will update rmf-web api-server with the latest task and robot states. User can then monitor on-going states and initiate rmf task with an interactive web dashboard.

Demo Worlds

Note: When running the demos on Ubuntu 18.04 (not officially supported), you are required to explicitly supply gazebo_version launch argument. Eg: ros2 launch rmf_demos_gz_classic office.launch.xml gazebo_version:=9

To run the demos using Ignition instead of Gazebo, change the commands from ros2 launch rmf_demos_gz_classic [...] to ros2 launch rmf_demos_gz [...]

RMF Panel

Click this link: https://open-rmf.github.io/rmf-panel-js/

For a full-proof web application of Open-RMF, please refer to rmf-web.

The RMF panel is a web based dashboard for interacting with rmf_demos. It allows users to send task requests to RMF and monitor the status of robots and submitted tasks. For more details.

There are two main modes of submitting tasks to Open-RMF via the Panel:

  1. Submit a Task: Used to submit a single task.
  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_demos_panel/task_lists.

LATEST UPDATE: Display Task States

task_state_uptates are now published via websocket. To display task states on rmf-panel, specify server_uri:="ws://localhost:7878" during ros2 launch. Example:

ros2 launch rmf_demos_gz_classic office.launch.xml server_uri:="ws://localhost:7878"

This will let Open-RMF (websocket clients) to publish their states to port 7878. In this case, rmf-panel's api_simple_server is the websocket server.


Hotel World

This hotel world consists of a lobby and 2 guest levels. The hotel has two lifts, multiple doors and 3 robot fleets (4 robots). This demonstrates an integration of multiple fleets of robots with varying capabilities working together in a multi-level building.

Demo Scenario

To launch the world and the schedule visualizer,

source ~/rmf_ws/install/setup.bash
ros2 launch rmf_demos_gz_classic hotel.launch.xml

# Or, run with ignition simulator
ros2 launch rmf_demos_gz hotel.launch.xml

Here, we will showcase 2 types of Tasks: Loop and Clean

Open RMF Panel to submit clean or loop requests. To submit a loop task, select Loop from the Select a request type dropdown list. Choose desired start and end locations and click submit. Similarly for Clean task, select Clean, then choose the desired cleaning zone from the dropdown list.

Or, dispatch robot via CLI

ros2 run rmf_demos_tasks dispatch_clean -cs clean_lobby --use_sim_time
ros2 run rmf_demos_tasks dispatch_patrol -p restaurant  L3_master_suite -n 1 --use_sim_time

Robots running Clean and Loop Task:

To submit a list of scheduled tasks via rmf web panel, load hotel_tasks.json, or paste the json list to the Submit a List of Tasks section. Next, click on submit.

Tip: To speedup simulation on gazebo, user can run gz physics -s 0.01 on a separate terminal after launching the world. Use with care!


Office World

An indoor office environment for robots to navigate around. It includes a beverage dispensing station, controllable doors and laneways which are integrated into RMF.

source ~/rmf_demos_ws/install/setup.bash
ros2 launch rmf_demos_gz_classic office.launch.xml

# Or, run with ignition simulator
ros2 launch rmf_demos_gz office.launch.xml

Now we will showcase 2 types of Tasks: Delivery and Loop

To send task requests, open rmf_demos web panel: https://open-rmf.github.io/rmf-panel-js/

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.

Or, submit a task via CLI:

ros2 run rmf_demos_tasks dispatch_patrol -p coe lounge -n 3 --use_sim_time
ros2 run rmf_demos_tasks dispatch_delivery -p pantry -ph coke_dispenser -d hardware_2 -dh coke_ingestor --use_sim_time

To submit a loop task, 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_demos_panel/task_lists 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.

The office demo can be run in secure mode using ROS 2 DDS-Security integration. Click here to learn more.


Airport Terminal World

This demo world shows robot interaction on a much larger map, with a lot more lanes, destinations, robots and possible interactions between robots from different fleets, robots and infrastructure, as well as robots and users. In the illustrations below, from top to bottom we have how the world looks like in traffic_editor, the schedule visualizer in rviz, and the full simulation in gazebo,

Demo Scenario

In the airport world, we introduce a new task type to rmf: Clean. To launch the world:

source ~/rmf_ws/install/setup.bash
ros2 launch rmf_demos_gz_classic airport_terminal.launch.xml

Open RMF Panel. Load the airport_terminal_tasks.json list and click submit to begin a collection of loop, delivery and cleaning tasks.

Or, submit loop, delivery or clean task via CLI:

ros2 run rmf_demos_tasks dispatch_patrol -p s07 n12 -n 3 --use_sim_time
ros2 run rmf_demos_tasks dispatch_delivery -p mopcart_pickup -ph mopcart_dispenser -d spill -dh mopcart_collector --use_sim_time
ros2 run rmf_demos_tasks dispatch_clean -cs zone_3 --use_sim_time

To see crowd simulation in action, enable crowd sim by:

ros2 launch rmf_demos_gz_classic airport_terminal.launch.xml use_crowdsim:=1

Non-autonomous vehicles can also be integrated with Open-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 Open-RMF nomenclature, this vehicle is classified as a read_only type, ie, Open-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 Open-RMF schedule.

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.

Run teleop_twist_keyboard to control the caddy with your keyboard:

# Default launch with gazebo
ros2 run teleop_twist_keyboard teleop_twist_keyboard

# if launched with the Ignition simulator
ros2 launch rmf_demos_gz airport_terminal_caddy.launch.xml

Tip: To speedup simulation on gazebo, user can run gz physics -ps 0.01 on a separate terminal after launching the world. Use with care!


Clinic World

This is a clinic world with two levels and two lifts for the robots. Two different robot fleets with different roles navigate across two levels by lifts. In the illustrations below, we have the view of level 1 in traffic_editor (top left), the schedule visualizer in rviz (right), and the full simulation in gazebo (bottom left).

Demo Scenario

To launch the world and the schedule visualizer,

source ~/rmf_ws/install/setup.bash
ros2 launch rmf_demos_gz_classic clinic.launch.xml

Open RMF Panel. Load the clinic_tasks.json list and click submit to begin a collection of loop and delivery tasks.

Or, submit a task via CLI:

ros2 run rmf_demos_tasks dispatch_patrol -p L1_left_nurse_center L2_right_nurse_center -n 5 --use_sim_time
ros2 run rmf_demos_tasks dispatch_patrol -p L2_north_counter L1_right_nurse_center -n 5 --use_sim_time

Robots taking lift:

Multi-fleet demo:


Campus World

This is a larger scale "Campus" World. In this world, there are multiple delivery robots that operate. The world is designed and traffic lanes are annotated at the planet scale, using GPS WGS84 coordinates. Each robot is also streaming its location in WGS84 coordinates, which are processed by its fleet adapter. This demo intends to show the potential of Open-RMF on a large scale map.

Demo Scenario

To launch the world and the schedule visualizer,

source ~/rmf_ws/install/setup.bash
ros2 launch rmf_demos_gz campus.launch.xml

ros2 run rmf_demos_tasks  dispatch_patrol -p room_5 campus_4 -n 10 --use_sim_time
ros2 run rmf_demos_tasks  dispatch_patrol -p campus_5 room_3 -n 10 --use_sim_time
ros2 run rmf_demos_tasks  dispatch_patrol -p room_2 dead_end -n 10 --use_sim_time

RobotManager Integration

fleet_robotmanager_mqtt_bridge (see rmf_demos_bridges) can be used to publish robot locations, battery percentage and state to a /robot/status/ROBOT-ID websocket endpoint. An instance of RobotManager can be configured to subscribe to this server to receive json messages, which will in turn visualize the robots on RobotManager.

# Install the prerequisites
sudo apt install mosquitto mosquitto-clients

# Start the bridge
ros2 run rmf_demos_bridges fleet_robotmanager_mqtt_bridge -y 31500 -x 22000

The json messages for the first robot can be echoed using the following example command,

mosquitto_sub -t /robot/status/00000000-0000-0000-0000-000000000001

Manufacturing & Logistics World

An Open-RMF simulation demonstration created by ROS-Industrial Asia Pacific showcasing workcell (conveyor and fixed manipulator), multiple AMR fleets and infrastructure interoperability using the Open Robotics Middleeware Framework (Open-RMF).

[![Alt text](https://img.youtube.com/vi/oSVQrjx_4w4/0.jpg)](https://www.youtube.com/watch?v=oSVQrjx_4w4)

Other Tools and Features Demos

Traffic Light Robot Demos

Open-RMF can also manage fleets whose API or fleet managers only offer pause and resume commands to control their robots. Such fleets are classified as traffic_light. To integrate a traffic_light fleet, users are expected to implement a traffic_light fleet adapter based on this API. The rmf_demos repository contains demonstrations of traffic_light fleets in various scenarios. A simplistic mock_traffic_light adapter is used in these demonstrations.

Triple-H scenario:

$ ros2 launch rmf_demos_gz_classic triple_H.launch.xml
(new terminal) $ ros2 launch rmf_demos the_pedigree.launch.xml

Battle Royale Scenario:

$ ros2 launch rmf_demos_gz_classic battle_royale.launch.xml
(new terminal) $ ros2 launch rmf_demos battle_go.launch.xml

Office Scenario:

Note that tinyRobot1 is a standard "full control" robot, while tinyRobot2 "traffic light" robot.

$ ros2 launch rmf_demos_gz_classic office_mock_traffic_light.launch.xml
(new terminal) $ ros2 launch rmf_demos office_traffic_light_test.launch.xml

Additional Features

  • Flexible Tasks Scripts For more details.

  • lift watchdog

    • The robot can query an external lift_watchdog_server for the permission to enter the lift cabin during the LiftSession Phase.
    • Command lines:
    # run hotel world with lift_watch_dog enabled
    ros2 launch rmf_demos_gz_classic hotel.launch.xml enable_experimental_lift_watchdog:=1
    
    ## On a separate terminal, set lift as crowded
    ros2 launch rmf_demos experimental_crowded_lift.launch.xml
    
    # Dispatch robot from level1 to level3, robot will wait in front of the lift cabin
    ros2 run rmf_demos_tasks dispatch_patrol -p L3_room1  L3_room1 -n 1 --use_sim_time
    
    # Lift is cleared. Give robot the permission to enter the lift
    ros2 launch rmf_demos experimental_clear_lift.launch.xml
  • Custom Docking Sequence

    • Fleet adapter will notify the robot (via dock() api/ModeRequest) to execute its custom dock sequence when the robot reaches a "dock" waypoint.
    • Implementation is similar to Clean task, refer to docs here
  • Emergency Alarm

    • All robots will get directed to the nearest parking spot when the emergency alarm is triggered.
    • Command lines:
    # toggle alarm ON
    ros2 topic pub -1 /fire_alarm_trigger std_msgs/Bool '{data: true}'
    
    # toggle alarm OFF
    ros2 topic pub -1 /fire_alarm_trigger std_msgs/Bool '{data: false}'

Task Dispatching in Open-RMF

In Open-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.

rmf_demos's People

Contributors

aaronchongth avatar akash-roboticist avatar arjo129 avatar chapulina avatar chianfern avatar cnboonhan avatar codebot avatar cwrx777 avatar ddengster avatar gbiggs avatar kevinskwk avatar koonpeng avatar landeru avatar luca-della-vedova avatar marcoag avatar matiasbavera avatar mattbooker avatar mdfesto avatar mrushyendra avatar mxgrey avatar ngwk1 avatar nicholas-gs avatar orensbruli avatar suchetanrs avatar vallq avatar xiyuoh avatar yadunund avatar youliangtan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rmf_demos's Issues

rmf_demos_panel: Download of webpack to location with no permissions

Bug report

Required information:

  • Operating system and version:
    • Ubuntu Focal
  • OpenRMF installation type:
    • binaries
  • OpenRMF version or commit hash
    • 1.3.0
  • ROS distribution and version:
    • galactic
  • ROS installation type:
    • binaries
  • Package or library, if applicable:
    • rmf_demos_panel

Description of the bug

When trying to run a demo on an installed version of Open-RMF rmf_demos_panel uses this function to try to download the webpack to a location that is relative to the installation of the package:

when using binary packages the user does not have permissions on the installation directory, therefore this fails:

[gui_server-13] Check path  /opt/ros/galactic/lib/python3.8/site-packages/rmf_demos_panel/static/dist/app.bundle.js
[gui_server-13] BundleJS File does not exist, Download it from https://open-rmf.github.io/rmf_demos/v1.0.0/app.bundle.js
[gui_server-13] Traceback (most recent call last):
[gui_server-13]   File "/opt/ros/galactic/lib/rmf_demos_panel/gui_server", line 11, in <module>
[gui_server-13]     load_entry_point('rmf-demos-panel==0.0.0', 'console_scripts', 'gui_server')()
[gui_server-13]   File "/opt/ros/galactic/lib/python3.8/site-packages/rmf_demos_panel/gui_server.py", line 77, in main
[gui_server-13]     download_webpack()
[gui_server-13]   File "/opt/ros/galactic/lib/python3.8/site-packages/rmf_demos_panel/gui_server.py", line 51, in download_webpack
[gui_server-13]     open(bundle_path, 'wb').write(response.content)
[gui_server-13] PermissionError: [Errno 13] Permission denied: '/opt/ros/galactic/lib/python3.8/site-packages/rmf_demos_panel/static/dist/app.bundle.js'

Alternative solutions to the problem

  • Install the webpack somewhere in some config directory in the user's home directory.
  • Find alternative ways to distribute the webpack. can this be installed through system packages? any other way?

Steps to reproduce the bug

  1. On a new Ubuntu focal machine install ros-galactic-rmf-demos-gz.
  2. Run one of the demos, i.e. ros2 launch rmf_demos_gz office.launch.xml.

Expected behavior

The demo run as per normal and the dashboard panel should be accessible through a web browser at http://localhost:5000

Actual behavior

The dashboard panel is not found in the browser.

rmf_demos do not run on Galactic

Bug report

Required information:

  • Operating system and version:
    • Ubuntu 20.04
  • OpenRMF installation type:
    • source
  • OpenRMF version or commit hash
    • master
  • ROS distribution and version:
    • Galactic
  • ROS installation type:
    • Binaries, ROS2 Control and gazebo_ros2_control built from source
  • Package or library, if applicable:
    • rmf_demos

Description of the bug

running office demo. Demo launches, Riz and Gazebo run. Two tiny robots are present in the environment, but they do not move. slotcar plugin appears to be functioning correctly, except the joint interface to Gazebo is not functioning properly. If I manually modify source code and either hard code joint velocities or multiply those computed in code, the obots eventaull tumble, but never move correctly.

Steps to reproduce the bug

mock_docker dropping robot_state callbacks due to callback queue being 1

Bug report

Required information:

  • Operating system and version:
    • Ubuntu 20.04
  • OpenRMF installation type:
    • Source
  • OpenRMF version or commit hash
    • main
  • ROS distribution and version:
    • Foxy
  • ROS installation type:
    • Binaries
  • Package or library, if applicable:
    • rmf_demos_tasks

Description of the bug

mock_docker.py script drops robot_state messages when there are multiple robots in the world due to callback queue being size of 1. This works perfectly when there is only 1 robot, but not when there are more than 1.

Steps to reproduce the bug

  1. Insert a print-out for robot name in the robot_state callback function
  2. Launch a world with multiple robots
  3. Start a task that would require the mock docker, notice how it only works with a single robot most of the time, while occasionally deals with the second or third robot.

server_uri changed failed

Bug report

Required information:

  • Operating system and version:
    • Ubuntu 20.04
  • Open-RMF installation type:
  • Open-RMF version or commit hash
    • 21.09
  • ROS distribution and version:
    • Galactic
  • ROS installation type:
    • From source

Description of the bug

When I run 'ros2 launch rmf_demos_gz leju.launch.xml headless:=1 server_uri:="ws://localhost:8000/_internal"', but server_uri did not change. Nothing show on the web.

Steps to reproduce the bug

  1. install ROS2
  2. install RMF
  3. run rmf-web
  4. run 'ros2 launch rmf_demos_gz leju.launch.xml headless:=1 server_uri:="ws://localhost:8000/_internal"'

Expected behavior

Actual behavior

Screenshots

image
image

Additional information

[simple_api_server-12] TypeError: emit() got an unexpected keyword argument 'broadcast'
[simple_api_server-12] Set Server IP to: 0.0.0.0
[simple_api_server-12] Set Server port to: 0.0.0.0:8083
[simple_api_server-12] Set RMF Websocket port to: localhost:7878
[simple_api_server-12] Starting Websocket Server
[simple_api_server-12] Starting RMF_Demos API Server: 0.0.0.0:8083, with ws://localhost:7878
[simple_api_server-12] * Serving Flask app 'rmf_demos_panel.simple_api_server'
[simple_api_server-12] * Debug mode: off
[fleet_adapter-14] [INFO] [1683603250.463764784] [tinyRobot_fleet_adapter]: Parameter [discovery_timeout] set to: 60.000000
...
...
...
[fleet_adapter-14] [WARN] [1683603985.000418458] [tinyRobot_fleet_adapter]: BroadcastClient unable to connect to [ws://localhost:8080/_internal]. Please make sure server is running. Error msg: invalid state
[fleet_adapter-14] [WARN] [1683603987.000823219] [tinyRobot_fleet_adapter]: BroadcastClient unable to connect to [ws://localhost:8080/_internal]. Please make sure server is running. Error msg: invalid state
c[fleet_adapter-14] [WARN] [1683603989.001271996] [tinyRobot_fleet_adapter]: BroadcastClient unable to connect to [ws://localhost:8080/_internal]. Please make sure server is running. Error msg: invalid state
[fleet_adapter-14] [WARN] [1683603991.001612044] [tinyRobot_fleet_adapter]: BroadcastClient unable to connect to [ws://localhost:8080/_internal]. Please make sure server is running. Error msg: invalid state

mock_docker might drop robot from `self.watching` even though it is still in `Docking`

Bug report

Required information:

  • Operating system and version:
    • Ubuntu 20.04
  • OpenRMF installation type:
    • Source
  • OpenRMF version or commit hash
    • main
  • ROS distribution and version:
    • Foxy
  • ROS installation type:
    • Binaries
  • Package or library, if applicable:
    • rmf_demos_tasks

Description of the bug

mock_docker.py script sends the Pause mode request hardcoded 5 times to switch away from Docking, and immediately drops the robot from self.watching. If all messages get dropped by the robot, it will get stuck in Docking mode.

office demo delivery task

In the example office, I try to run the 'delivery' task. The robot stops at the pickup waypoint. What command should I send to make it run to the dropoff point,thanks!

[Other issue]: Problem with de files .rviz

Before proceeding, is there an existing issue or discussion for this?

Description

Based on the demonstrations I'm trying to create my own map, spawn some of the TinyRobots and make them do things.

Observing and analyzing the different demos I saw (using as example the office demo) that all the juice is in the office.launch.xml that calls three other launchers the simulation.launch.xml, fleet_adapter.launch.xml and the common.launch.xml.

My problem is with the common.launch.xml. Because we have to filled up with 3 arg names
-the file .building.yaml
-the file .rviz
-the file dashboard_config.json

Thanks to this document https://osrf.github.io/ros2multirobotbook/simulation.html I was able to create the map using traffic-editor and then save it a from the .building.yaml create the .world

However I don't know how are the .rviz and the dashboard_config.json files created. The .rviz is for the configuration of RVIZ so without it i can't launch anything. And the dashboard_config.json file is for the program cumunicate with the rmf-panel so without it I can not send any goal to the robots and also the launcher won't work

So, do someone know how can I create those files. Because if I copy paste them to my new map at the time of launch it appears with the configuration of the office. So it doesn't work.

Thanks for your time and best regards :)

Colcon build failed

Before proceeding, is there an existing issue or discussion for this?

OS and version

Ubuntu 22.04

Open-RMF installation type

Source build

Other Open-RMF installation methods

No response

Open-RMF version or commit hash

rmf.repos

ROS distribution

Humble

ROS installation type

Source build

Other ROS installation methods

No response

Package or library, if applicable

No response

Description of the bug

rmf_visualization_obstacles CMake Error at CMakeLists.txt:13

Could not find a package configuration file provided by "vision_msgs" with any of the following names:
vision_msgsConfig.cmake
vision_msgs-config.cmake

Steps to reproduce the bug

Followed instructions per building from source

Expected behavior

packages finished

Actual behavior

1 package fialed (rmf_visualization_obstacles)
multiple packages aborted and stderr output

Additional information or screenshots

No response

Dispatcher Node Unavailable

Hi, I was facing issue with Dispatcher Node being unavailable, despite reinstalling RMF demo from source or binary.
image

I had managed to figure out a partial solution and I would like to share this with the community. I am using a laptop which had its network security improved recently, and this was the problem. ufw was enabled and this firewall was blocking the communication for the Dispatcher node. After disabling ufw by using the command "sudo ufw disable", I was able to get the demo's running perfectly again.

However, in the rmf_demo_panel/simple_api_server that states that the default port used was 8083, even after enabling 8083 in ufw settings, I was still unable to get the Dispatcher Node running. If anyone knows what I did wrong here please correct me. In any case, disabling ufw fixed this problem for now.

image

README: inline videos are missing

The previous repo osrf/rmf_demos had inline videos in the README for drive-by "is this cool" type of bling. After the migration, those are no longer here (probably to make the repo smaller?). "it would be great" to host those videos somewhere else (Google Drive?) so they show up when GitHub renders the README.

rmf_demos_maps in rolling fails to build on rhel targets

The package rmf_demos_maps in rolling has been detected as not building on all platforms in the buildfile rhel. The release manager for rolling will consider disabling this build if it continues to fail to build.

  • jenkins_urls:
    • rhel 8 x86_64
      This is being filed because this package is about to be blacklisted. If this ticket is resolved please review whether it can be removed from the blacklist that should cross reference here.

Excerpt from the most recent build log:

DEBUG: [ 34%] Generating maps/airport_terminal/nav_graphs/phony
DEBUG: ros2 run rmf_building_map_tools building_map_generator nav /builddir/build/BUILD/ros-rolling-rmf-demos-maps-1.3.1/maps/airport_terminal/airport_terminal.building.yaml /builddir/build/BUILD/ros-rolling-rmf-demos-maps-1.3.1/obj-x86_64-redhat-linux-gnu/maps/airport_terminal/nav_graphs/
DEBUG: Traceback (most recent call last):
DEBUG:   File "/opt/ros/rolling/lib/rmf_building_map_tools/building_map_generator", line 11, in <module>
DEBUG:     load_entry_point('rmf-building-map-tools==0.0.0', 'console_scripts', 'building_map_generator')()
DEBUG:   File "/opt/ros/rolling/lib/python3.6/site-packages/building_map_generator/building_map_generator.py", line 32, in main
DEBUG:     g.generate_nav(args.INPUT, args.OUTPUT_DIR)
DEBUG:   File "/opt/ros/rolling/lib/python3.6/site-packages/building_map/generator.py", line 79, in generate_nav
DEBUG:     building = self.parse_editor_yaml(input_filename)
DEBUG:   File "/opt/ros/rolling/lib/python3.6/site-packages/building_map/generator.py", line 17, in parse_editor_yaml
DEBUG:     y = yaml.safe_load(f)
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/__init__.py", line 94, in safe_load
DEBUG:     return load(stream, SafeLoader)
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/__init__.py", line 72, in load
DEBUG:     return loader.get_single_data()
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/constructor.py", line 35, in get_single_data
DEBUG:     node = self.get_single_node()
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/composer.py", line 36, in get_single_node
DEBUG:     document = self.compose_document()
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/composer.py", line 55, in compose_document
DEBUG:     node = self.compose_node(None, None)
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/composer.py", line 84, in compose_node
DEBUG:     node = self.compose_mapping_node(anchor)
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/composer.py", line 133, in compose_mapping_node
DEBUG:     item_value = self.compose_node(node, item_key)
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/composer.py", line 84, in compose_node
DEBUG:     node = self.compose_mapping_node(anchor)
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/composer.py", line 133, in compose_mapping_node
DEBUG:     item_value = self.compose_node(node, item_key)
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/composer.py", line 82, in compose_node
DEBUG:     node = self.compose_sequence_node(anchor)
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/composer.py", line 110, in compose_sequence_node
DEBUG:     while not self.check_event(SequenceEndEvent):
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/parser.py", line 98, in check_event
DEBUG:     self.current_event = self.state()
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/parser.py", line 379, in parse_block_sequence_first_entry
DEBUG:     return self.parse_block_sequence_entry()
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/parser.py", line 384, in parse_block_sequence_entry
DEBUG:     if not self.check_token(BlockEntryToken, BlockEndToken):
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/scanner.py", line 116, in check_token
DEBUG:     self.fetch_more_tokens()
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/scanner.py", line 252, in fetch_more_tokens
DEBUG:     return self.fetch_plain()
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/scanner.py", line 676, in fetch_plain
DEBUG:     self.tokens.append(self.scan_plain())
DEBUG:   File "/usr/lib64/python3.6/site-packages/yaml/scanner.py", line 1299, in scan_plain
DEBUG:     "Please check http://pyyaml.org/wiki/YAMLColonInFlowContext for details.")
DEBUG: yaml.scanner.ScannerError: while scanning a plain scalar
DEBUG:   in "/builddir/build/BUILD/ros-rolling-rmf-demos-maps-1.3.1/maps/airport_terminal/airport_terminal.building.yaml", line 29, column 87
DEBUG: found unexpected ':'
DEBUG:   in "/builddir/build/BUILD/ros-rolling-rmf-demos-maps-1.3.1/maps/airport_terminal/airport_terminal.building.yaml", line 29, column 92
DEBUG: Please check http://pyyaml.org/wiki/YAMLColonInFlowContext for details.
DEBUG: Traceback (most recent call last):
DEBUG:   File "/opt/ros/rolling/bin/ros2", line 11, in <module>
DEBUG:     load_entry_point('ros2cli==0.16.1', 'console_scripts', 'ros2')()
DEBUG:   File "/opt/ros/rolling/lib/python3.6/site-packages/ros2cli/cli.py", line 89, in main
DEBUG:     rc = extension.main(parser=parser, args=args)
DEBUG:   File "/opt/ros/rolling/lib/python3.6/site-packages/ros2run/command/run.py", line 70, in main
DEBUG:     return run_executable(path=path, argv=args.argv, prefix=prefix)
DEBUG:   File "/opt/ros/rolling/lib/python3.6/site-packages/ros2run/api/__init__.py", line 73, in run_executable
DEBUG:     if -process.returncode in signal.valid_signals() and os.name == 'posix':
DEBUG: AttributeError: module 'signal' has no attribute 'valid_signals'
DEBUG: make[2]: Leaving directory '/builddir/build/BUILD/ros-rolling-rmf-demos-maps-1.3.1/obj-x86_64-redhat-linux-gnu'
DEBUG: make[1]: Leaving directory '/builddir/build/BUILD/ros-rolling-rmf-demos-maps-1.3.1/obj-x86_64-redhat-linux-gnu'

[Humble, simple-api-server] Websockets 9.1 from ubuntu offical ppa doesn't seem to work

Bug report

When launching office world, the simple API server is not able to update the task states from the websocket server, resulting in the js-panel not able to display the tasks states. (the #166 (comment) by Grey prompt us to investigate the version difference, although the fastapi is not giving us any issue at this point)

We switched to using the latest version (10.4), through building from source. It seems to work.

It seems that the default Ubuntu PPA's python3-websockets version 9.1-1 is somehow buggy.

Robot occasionally get stuck in clinic world

Once a while, the deliveryRobot will get stuck in front of a door in clinic.world. This might due to some waypoint estimation in slotcar. This is not highly reproducible in every test. Create this issue ticket for tracking.

ezgif-3-214bd3ea4ec9

Unable to install from apt

I'm following these instructions to install RMF and demo: https://github.com/open-rmf/rmf#rmf-demos

Upon running sudo apt install ros-humble-rmf-demos-gz, it's unable to locate the package and throws an error:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package ros-humble-rmf-demos-gz

Installation: Build Error

Bug report

Required information:

Using Ubuntu 20.04, ROS2 Galactic, Installing from Source.

Description of the bug

Hi building from source works smoothly in my other computers but for my current desktop I'm facing this error:

--- stderr: rmf_battery
/usr/bin/ld: /home/msi/workspace/trl_ws/install/rmf_traffic/lib/librmf_traffic.so: undefined reference to `pthread_rwlock_unlock'
/usr/bin/ld: /home/msi/workspace/trl_ws/install/rmf_traffic/lib/librmf_traffic.so: undefined reference to `pthread_rwlock_trywrlock'
/usr/bin/ld: /home/msi/workspace/trl_ws/install/rmf_traffic/lib/librmf_traffic.so: undefined reference to `pthread_rwlock_tryrdlock'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/test_rmf_battery.dir/build.make:147: test_rmf_battery] Error 1
make[1]: *** [CMakeFiles/Makefile2:80: CMakeFiles/test_rmf_battery.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
---

I tried searching online to find for solutions but couldn't find any. Would appreciate any help!

open-rmf and rmf difference

What is the difference between this repository and the rmf-demos in osrf๏ผŸ
The readme.md documentation does not seem to be complete and the installation guide ("Instructions can be found here.") cannot be opened.

Models with space in names are not downloaded

Bug report

Required information:

  • Operating system and version: Ubuntu 20.04
  • OpenRMF installation type: Source build
  • OpenRMF version or commit hash: main-->
  • ROS distribution and version: Foxy
  • ROS installation type: binaries

Description of the bug

When launching the airport_terminal world, ros2 launch rmf_demos airport_terminal.launch.xml, these models were listed as missing,

[gzserver-14] Error Code 12 Msg: Unable to find uri[model://Pine Tree]
[gzserver-14] Error Code 12 Msg: Unable to find uri[model://Standing person]
[gzserver-14] Error Code 12 Msg: Unable to find uri[model://Cafe table]
[gzserver-14] Error Code 12 Msg: Unable to find uri[model://Lamp Post]
[gzserver-14] Error Code 12 Msg: Unable to find uri[model://Construction Cone]
[gzserver-14] Error Code 12 Msg: Unable to find uri[model://Oak tree]

Steps to reproduce the bug

  1. Remove all the artifacts except sun and ground_plane in ~/.gazebo/models/
  2. Remove pit crew artifacts for a clean build, rm -rf ~/.pit_crew
  3. Build a new workspace up till rmf_demos, colcon build --packages-up-to rmf_demos
  4. Launch airport terminal simulation, ros2 launch rmf_demos airport_terminal.launch.xml

Additional information

Possibly related to https://github.com/open-rmf/rmf_traffic_editor/pull/359/files

python3-websockets dependency not resolved for RHEL

Package rmf_demos_panel depends on python3-websockets and it's not defined what package should resolve this dependence:

Could not resolve rosdep key 'python3-websockets' for distro '8':
No definition of [python3-websockets] for OS [rhel]
	rosdep key : python3-websockets
	OS name    : rhel
	OS version : 8
	Data:
arch:
		- python-websockets
		debian:
		- python3-websockets
		fedora:
		- python-websockets
		gentoo:
		- dev-python/websockets
		nixos:
		- python3Packages.websockets
		openembedded:
		- python3-websockets@meta-python
		ubuntu:
		- python3-websockets
		
Failed to resolve python3-websockets on rhel:8 with: Error running generator: Failed to resolve rosdep key 'python3-websockets', aborting.
python3-websockets is depended on by these packages: ['rmf_demos_panel']
<== Failed

I need to make further investigation about if this package is distributed or not in fedora and rhel.

Error in rmf_traffic_schedule_node

Hi there. I have tried launching a demo launch file and apparently there is a dispatcher node error which results to failure in launching. I have not edited any of the files from provided by RMF demos and core. May I know what could be the cause of these errors?

[INFO] [launch]: All log files can be found below /home/rosuser/.ros/log/2021-04-08-11-23-22-099046-rosuser-4672
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [rmf_traffic_schedule-1]: process started with pid [4674]
[INFO] [rmf_traffic_blockade-2]: process started with pid [4676]
[INFO] [door_supervisor-3]: process started with pid [4678]
[INFO] [lift_supervisor-4]: process started with pid [4680]
[INFO] [rmf_task_dispatcher-5]: process started with pid [4682]
[rmf_task_dispatcher-5] ~Initializing Dispatcher Node~
[rmf_task_dispatcher-5] [INFO] [1617852202.374765163] [rmf_dispatcher_node]:  Declared Time Window Param as: 2.000000 secs
[rmf_task_dispatcher-5] [INFO] [1617852202.374846947] [rmf_dispatcher_node]:  Declared Terminated Tasks Max Size Param as: 100
[rmf_task_dispatcher-5] [INFO] [1617852202.381721003] [rmf_dispatcher_node]: Starting task dispatcher node
[rmf_traffic_blockade-2] [INFO] [1617852202.383422101] [rmf_traffic_blockade_node]: Beginning traffic blockade node
[rmf_traffic_schedule-1] [FATAL] [1617852202.495543207] [rmf_traffic_schedule_node]: Failed to correctly load participant registry: yaml-cpp: error at line 915, column 11: bad conversion
[rmf_traffic_schedule-1] 
[rmf_traffic_schedule-1] terminate called after throwing an instance of 'std::runtime_error'
[rmf_traffic_schedule-1]   what():  yaml-cpp: error at line 915, column 11: bad conversion
[ERROR] [rmf_traffic_schedule-1]: process has died [pid 4674, exit code -6, cmd '/home/rosuser/rmf_ws/install/rmf_traffic_ros2/lib/rmf_traffic_ros2/rmf_traffic_schedule --ros-args --params-file /tmp/launch_params_lzwgc264'].

ODE assertion fails in Ignition when TinyRobot is in scenario

Bug report

Required information:

Running Ignition Edifice, Ubuntu 20.04 and ROS2 Foxy

Description of the bug

When TinyRobot is present in the world, pausing and resuming the simulation will cause the physics engine solver to fail with the following error:

ODE INTERNAL ERROR 1: assertion "!bSafeNormalize4Fault" failed in dxNormalize4() [odemath.h:53]

Specifically, the full backtrace is:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7a5f859 in __GI_abort () at abort.c:79
#2  0x00007fffcebb6c58 in dDebug () from /lib/x86_64-linux-gnu/libode.so.8
#3  0x00007fffcebce7fd in ?? () from /lib/x86_64-linux-gnu/libode.so.8
#4  0x00007fffcebcec3f in dBodySetQuaternion () from /lib/x86_64-linux-gnu/libode.so.8
#5  0x00007fffd40fbbc6 in dart::collision::OdeCollisionObject::updateEngineData() ()
   from /lib/x86_64-linux-gnu/libdart-collision-ode.so.6
#6  0x00007fffcfe68e51 in dart::collision::CollisionGroup::updateEngineData() () from /lib/x86_64-linux-gnu/libdart.so.6
#7  0x00007fffd40f9b36 in dart::collision::OdeCollisionDetector::collide(dart::collision::CollisionGroup*, dart::collision::CollisionOption const&, dart::collision::CollisionResult*) () from /lib/x86_64-linux-gnu/libdart-collision-ode.so.6
#8  0x00007fffcfea127e in dart::constraint::ConstraintSolver::updateConstraints() () from /lib/x86_64-linux-gnu/libdart.so.6
#9  0x00007fffcfea27b6 in dart::constraint::ConstraintSolver::solve() () from /lib/x86_64-linux-gnu/libdart.so.6
#10 0x00007fffcfebdd21 in dart::simulation::World::step(bool) () from /lib/x86_64-linux-gnu/libdart.so.6
#11 0x00007fffd42c809e in ignition::physics::dartsim::SimulationFeatures::WorldForwardStep (this=<optimized out>, _worldID=..., 
    _h=..., _u=...) at /home/luca/ws_edifice/src/ign-physics/dartsim/src/SimulationFeatures.cc:61
#12 0x00007fffe464674d in ignition::physics::ForwardStep::World<ignition::physics::FeaturePolicy<double, 3ul>, ignition::gazebo::v5::systems::PhysicsPrivate::MinimumFeatureList>::Step (_u=..., _x=..., _h=..., this=<optimized out>)
    at /usr/include/c++/9/ext/new_allocator.h:89
#13 ignition::gazebo::v5::systems::PhysicsPrivate::Step (this=<optimized out>, _dt=...)
    at /home/luca/ws_edifice/src/ign-gazebo/src/systems/physics/Physics.cc:2074
#14 0x00007fffe46588d6 in ignition::gazebo::v5::systems::Physics::Update (this=0x5555573cfd10, _info=..., _ecm=...)
    at /home/luca/ws_edifice/src/ign-gazebo/src/systems/physics/Physics.cc:738
#15 0x00007ffff2febe82 in ignition::gazebo::v5::SimulationRunner::UpdateSystems (this=this@entry=0x5555559e2130)
    at /home/luca/ws_edifice/src/ign-gazebo/src/SimulationRunner.cc:570
#16 0x00007ffff2ff30eb in ignition::gazebo::v5::SimulationRunner::Step (this=this@entry=0x5555559e2130, _info=...)
    at /home/luca/ws_edifice/src/ign-gazebo/src/SimulationRunner.cc:819
#17 0x00007ffff2ff38db in ignition::gazebo::v5::SimulationRunner::Run (this=0x5555559e2130, _iterations=<optimized out>)
    at /home/luca/ws_edifice/src/ign-gazebo/src/SimulationRunner.cc:784
#18 0x00007ffff2fe6614 in ignition::gazebo::v5::ServerPrivate::Run (this=0x55555596f060, _iterations=<optimized out>, 
    _iterations@entry=0, _cond=...) at /usr/include/c++/9/bits/unique_ptr.h:360
#19 0x00007ffff2fdd87c in ignition::gazebo::v5::Server::Run (this=this@entry=0x7fffffffad70, _blocking=_blocking@entry=true, 
    _iterations=_iterations@entry=0, _paused=_paused@entry=true) at /usr/include/c++/9/optional:690
--Type <RET> for more, q to quit, c to continue without paging--
#20 0x00007ffff340b4af in runServer (
    _sdfString=0x555555dacf00 "<sdf version=\"1.7\">\n\t<world name=\"sim_world\">\n\t\t<physics name=\"10ms\" type=\"ode\">\n\t\t\t<max_step_size>0.001</max_step_size>\n\t\t\t<real_time_factor>1.0</real_time_factor>\n\t\t</physics>\n\t\t<plugin filename=\"li"..., _iterations=0, _run=0, _hz=-1, _levels=0, _networkRole=0x555555953248 "", _networkSecondaries=0, _record=0, 
    _recordPath=0x555555953220 "", _recordResources=0, _logOverwrite=0, _logCompress=0, _playback=0x5555559531d0 "", 
    _physicsEngine=0x555555953108 "", _renderEngineServer=0x0, _renderEngineGui=0x0, 
    _file=0x5555558a13d0 "/home/luca/demos_ws/install/dp3_maps/share/dp3_maps/maps/ranger_station_ign/ranger_station.world", 
    _recordTopics=0x555555984f50 "") at /home/luca/ws_edifice/src/ign-gazebo/src/ign.cc:351
#21 0x00007ffff3465ff5 in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
#22 0x00007ffff346540a in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
#23 0x00007ffff34bb8fc in ?? () from /usr/lib/x86_64-linux-gnu/ruby/2.7.0/fiddle.so
#24 0x00007ffff7e0d6da in rb_nogvl () from /lib/x86_64-linux-gnu/libruby-2.7.so.2.7
#25 0x00007ffff34bb715 in ?? () from /usr/lib/x86_64-linux-gnu/ruby/2.7.0/fiddle.so
#26 0x00007ffff7e3c026 in ?? () from /lib/x86_64-linux-gnu/libruby-2.7.so.2.7
#27 0x00007ffff7e48dab in ?? () from /lib/x86_64-linux-gnu/libruby-2.7.so.2.7
#28 0x00007ffff7e2f406 in ?? () from /lib/x86_64-linux-gnu/libruby-2.7.so.2.7
#29 0x00007ffff7e40131 in ?? () from /lib/x86_64-linux-gnu/libruby-2.7.so.2.7
#30 0x00007ffff7e46870 in rb_vm_exec () from /lib/x86_64-linux-gnu/libruby-2.7.so.2.7
#31 0x00007ffff7cd7491 in ?? () from /lib/x86_64-linux-gnu/libruby-2.7.so.2.7
#32 0x00007ffff7cdc2ee in ruby_run_node () from /lib/x86_64-linux-gnu/libruby-2.7.so.2.7
#33 0x000055555555517f in ?? ()
#34 0x00007ffff7a610b3 in __libc_start_main (main=0x555555555120, argc=5, argv=0x7fffffffb8e8, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffb8d8) at ../csu/libc-start.c:308
#35 0x00005555555551ce in _start ()

Steps to reproduce the bug

Run a world with TinyRobot, then pause and resume the simulation.

Additional information

Commenting the slotcar plugin seems to remove the crash, so this is probably more related to rmf_simulation

Restore "reversible" parameter in demo launch files?

I was wondering if it would be a good idea to explicitly list the reversible parameter in the the full control adapters here. It does seem to result in odd behaviors for non-reversible robots, where the robot "spins unnecessarily" at each intermediate waypoint. It's may not be obvious that its a parameter setting in RMF rather than a robot navstack issue.

Building fails because building_map_model_downloader downloads to home directory

Bug report

Required information:

This is the exact error on the buildfarm:

https://build.ros2.org/view/Rbin_uF64/job/Rbin_uF64__rmf_demos_maps__ubuntu_focal_amd64__binary/1/console

Description of the bug

building_map_model_downloader tries to download files to the user's home directory:

COMMAND ros2 run rmf_building_map_tools building_map_model_downloader ${map_path} -f -e ~/.gazebo/models

While installing to the user's home directory works when building from source, it does not when we try to create a package out of that source.

Steps to reproduce the bug

Build a package.

Expected behavior

Successfully builds.

Additional information

A refactoring of this behavior is needed to install those files in a package relative location so that all required files can be packaged and installed adequately (suggestions to this approach are more than welcomed).

TypeError: Server.emit() got an unexpected keyword argument 'broadcast'

Bug report

TypeError: Server.emit() got an unexpected keyword argument 'broadcast'

Required information:

  • Operating system and version: Ubuntu 22
  • OpenRMF installation type:
    debians
  • OpenRMF version or commit hash
    debians
  • ROS distribution and version:
    humble
  • ROS installation type:
    by debians

Description of the bug

When launching the any example that launches the rmf comons, gives this error:

TypeError: Server.emit() got an unexpected keyword argument 'broadcast'

This makes the web interface not work.

I tracked the error until here:

simple_api_server.py

Is there a version that I'm not aware of?

How to reproduce

execute:

ros2 launch rmf_demos_gz_classic hotel.launch.xml | grep "Server.emit"

You should see that error.

Expected behavior

I would imagine that following this tutorial of installation, there shouldn't be any errors:
open-rmf/rmf#267

Screenshots

Screenshot from 2023-04-04 18-12-41

Additional information

I will try to do the same but installing rmf from source but I really don't understand why this could be happening. Hve I done something wrong in the installation?

UPDATE: Did the source installation with the exact same results
UPDATE2: Tried to update the Websockets, like so ISSUE, same result.

Fleet Adapter throws exception sometimes after office_loop.launch.xml

Bug report

Required information:

  • Operating system and version:
    • Ubuntu 20.04
  • OpenRMF installation type:
    • Source
  • OpenRMF version or commit hash:
    • main
  • ROS distribution and version:
    • galactic
  • ROS installation type:
    • binaries
  • Package or library, if applicable:
    • rmf_fleet_adapter

Description of the bug

Full control fleet adapter throws an exception sometimes in office.launch.xml after office_loop.launch.xml is called. Exception is

[full_control-13] terminate called after throwing an instance of 'std::invalid_argument'
[full_control-13]   what():  Battery State of Charge needs to be between 0.0 and 1.0.

Gist: here

Steps to reproduce the bug

ros2 launch rmf_demos_gz office.launch.xml

# in another terminal
ros2 launch rmf_demos office_loop.launch.xml

Screenshots

Additional information

  • this does not happen all the time, probably some race conditions happening somewhere?
  • I am also using an underpowered laptop, this might not occur on beefier machines

Caddy model fails when increase step size to 0.02 in gz

Bug report

Description of the bug

Caddy fails when increases the step size to 0.02 in gazebo. Notice that the model will spawn back to the origin

caddy_spawn_error.mp4

(not sure why the video is not viewable on firefox ๐Ÿ˜ž , try chrome)

Steps to reproduce the bug

  1. ros2 launch rmf_demos airport_terminal.launch.xml
  2. Run this when launch is completed: gz physics -s 0.02

Observe the caddy robot.

Occasionally will get this error when repeat the above steps:

[gzclient-14] gzclient: /build/ogre-1.9-kiU5_5/ogre-1.9-1.9.0+dfsg1/OgreMain/include/OgreAxisAlignedBox.h:251: void Ogre::AxisAlignedBox::setExtents(const Ogre::Vector3&, const Ogre::Vector3&): Assertion `(min.x <= max.x && min.y <= max.y && min.z <= max.z) && "The minimum corner of the box must be less than or equal to maximum corner"' failed.
[ERROR] [gzclient-14]: process has died [pid 5

Note that this will not happen when using stepsize 0.01 in gazebo. On ignition, it works perfectly fine.

I tried to remove the readonly plugin in the rmf_demos_assets/models/Caddy's model.sdf and spawn caddy at other location. But this issue still happens. Will require a further look into the model to debug on this.

Task rejected by legacy AcceptTaskRequest callback

Bug report

[rmf_task_dispatcher-13] [WARN] [1684473786.013756728] [rmf_dispatcher_node]: Dispatcher Bidding Result: task [delivery.dispatch-1] has no submissions during bidding. Dispatching failed, and the task will not be performed.
[rmf_task_dispatcher-13] [ERROR] [1684473786.013822443] [rmf_dispatcher_node]: No submission error[1]: Task rejected by legacy AcceptTaskRequest callback
[rmf_task_dispatcher-13] [ERROR] [1684473786.013836414] [rmf_dispatcher_node]: No submission error[2]: Task rejected by legacy AcceptTaskRequest callback

Does anyone know why this could be happening? I'm performing a delivery like always using the web interface

Any insight?

Multiple symbol lookup error

Bug report

Required information:

  • Operating system and version:
    • Ubuntu 20.04
  • OpenRMF installation type:
  • OpenRMF version or commit hash
  • ROS distribution and version:
    • galactic
  • ROS installation type:
    • binaries

Description of the bug

[rmf_traffic_schedule-1] [INFO] [1654989904.529860681] [rmf_traffic_schedule_primary]: Successfully loaded logfile .rmf_schedule_node.yaml 
[rmf_traffic_schedule-1] [INFO] [1654989904.544024806] [rmf_traffic_schedule_primary]: Set up heartbeat on /rmf_traffic/heartbeat with liveliness lease duration of 1000 ms and deadline of 1000 ms
[rmf_traffic_schedule-1] /opt/ros/galactic/lib/rmf_traffic_ros2/rmf_traffic_schedule: symbol lookup error: /opt/ros/galactic/lib/librmf_traffic_ros2.so: undefined symbol: _ZN22rosidl_typesupport_cpp31get_message_type_support_handleIN16rmf_traffic_msgs3msg15ItineraryErase_ISaIvEEEEEPK29rosidl_message_type_support_tv
[rmf_traffic_schedule_monitor-2] [INFO] [1654989904.479796887] [rmf_traffic_schedule_backup]: Set up heartbeat listener on /rmf_traffic/heartbeat with liveliness lease duration of 1000 ms
[rmf_traffic_blockade-3] [INFO] [1654989904.517519371] [rmf_traffic_blockade_node]: Beginning traffic blockade node
[rmf_task_dispatcher-11] ~Initializing Dispatcher Node~
[rmf_task_dispatcher-11] [INFO] [1654989905.046314166] [rmf_dispatcher_node]:  Declared Time Window Param as: 2.000000 secs
[rmf_task_dispatcher-11] [INFO] [1654989905.047427995] [rmf_dispatcher_node]:  Declared Terminated Tasks Max Size Param as: 100
[rmf_task_dispatcher-11] [INFO] [1654989905.047499026] [rmf_dispatcher_node]:  Declared publish_active_tasks_period as: 0.000000 secs
[rmf_task_dispatcher-11] /opt/ros/galactic/lib/rmf_task_ros2/rmf_task_dispatcher: symbol lookup error: /opt/ros/galactic/lib/librmf_task_ros2.so: undefined symbol: _ZN22rosidl_typesupport_cpp31get_service_type_support_handleIN13rmf_task_msgs3srv11GetTaskListEEEPK29rosidl_service_type_support_tv
[ERROR] [rmf_task_dispatcher-11]: process has died [pid 981056, exit code 127, cmd '/opt/ros/galactic/lib/rmf_task_ros2/rmf_task_dispatcher --ros-args --params-file /tmp/launch_params_s2czitzc --params-file /tmp/launch_params_83db9h68'].
[full_control-13] [INFO] [1654989905.434408136] [tinyRobot_fleet_adapter]: Parameter [discovery_timeout] set to: 60.000000
[full_control-13] /opt/ros/galactic/lib/rmf_fleet_adapter/full_control: symbol lookup error: /opt/ros/galactic/lib/librmf_traffic_ros2.so: undefined symbol: _ZN22rosidl_typesupport_cpp31get_message_type_support_handleIN16rmf_traffic_msgs3msg15ItineraryErase_ISaIvEEEEEPK29rosidl_message_type_support_tv

Steps to reproduce the bug

ros2 launch rmf_demos_ign office.launch.xml server_uri:="ws://localhost:8000/_internal"

rmf demos connection error

Bug report

Required information:

  • Operating system and version:
    • ubuntu 22.04
  • OpenRMF installation type:
    • source install
  • OpenRMF version or commit hash
    • we installed it following the instructions on the instructions, current commit hash: 2687cbc59ceb39ff0e3c42c9dc8cb15a80a0ce4b
  • ROS distribution and version:
    • we are using ROS humble
  • ROS installation type:
    • Installed ROS humble from binary

Description of the bug

When we run any of the rmf demos launch file like ros2 launch rmf_demos_gz_classic hotel.launch.xml or ros2 launch rmf_demos_gz_classic office.launch.xml, we manage to launch the gazebo world, and we can see rviz. However, the problem is that we arn't able to see the robot on rviz, and we seem to be getting a connection error as seen from the screenshot below.

Steps to reproduce the bug

  1. Install ubuntu 22.04
  2. Install ROS humble
  3. install rmf with source
  4. run rmf demos (office world, hotel world, etc)

Expected behavior

Expected behaviour is that we should be able to see yellow dots on rviz which represents the robot and we should not be getting any errors on our terminal.

Actual behavior

you can see from the screenshot what is error that we got.

Screenshots

Screenshot from 2023-02-22 11-28-40

Unable to update or reinstall rmf_demos

For a couple of months, our research team has been working with an old version of rmf_demos.

In order to advance our testing and work with the new features, we have decided to upgrade, but we are unable to compile the new version of rmf_demos.

Our Set-Up (workstation):

  • Ubuntu 20.04.
  • Ros2 Foxy.
  • Ros1 Noetic.

We have followed the steps, as marked in the demos, but modifying the project folder (workspace). Here the steps :

cd new_rmf_ws/
wget https://raw.githubusercontent.com/open-rmf/rmf/main/rmf.repos
vcs import src < rmf.repos
mkdir src
vcs import src < rmf.repos
 rosdep install --from-paths src --ignore-src --rosdistro foxy -yr
rosdep updapte
sudo apt-get update
rosdep install --from-paths src --ignore-src --rosdistro foxy -yr
source /opt/ros/foxy/setup.bash
colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release

Here the error during compilation:

Finished <<< menge_vendor [23.4s]
Finished <<< rmf_charger_msgs [23.5s]                                                                               
Finished <<< rmf_dispenser_msgs [23.8s]                                                                             
Starting >>> rmf_ingestor_msgs
Starting >>> rmf_task_msgs
Finished <<< rmf_door_msgs [23.8s]
Finished <<< rmf_workcell_msgs [26.6s]                                                                               
Finished <<< rmf_utils [27.8s]                                                                                       
Starting >>> rmf_traffic
Finished <<< rmf_building_map_msgs [29.8s]                                                                                                              
Starting >>> rmf_building_map_tools
Starting >>> rmf_building_sim_common
Starting >>> rmf_visualization_building_systems
Finished <<< rmf_visualization_building_systems [0.89s]                                                                                                
Finished <<< rmf_building_map_tools [0.98s]
Starting >>> rmf_demos_maps
Starting >>> rmf_traffic_editor_test_maps
--- stderr: rmf_traffic_editor_test_maps                                                                                                               
BUILDING WORLDFILE WITH COMMAND: ros2 run rmf_building_map_tools building_map_generator gazebo /home/cluster1/new_rmf_ws/src/rmf/rmf_traffic_editor/rmf_traffic_editor_test_maps/maps/door_madness/door_madness.building.yaml /home/cluster1/new_rmf_ws/build/rmf_traffic_editor_test_maps/maps/door_madness/door_madness.world /home/cluster1/new_rmf_ws/build/rmf_traffic_editor_test_maps/maps/door_madness/models
DOWNLOADING MODELS WITH COMMAND: ros2 run rmf_building_map_tools building_map_model_downloader /home/cluster1/new_rmf_ws/src/rmf/rmf_traffic_editor/rmf_traffic_editor_test_maps/maps/door_madness/door_madness.building.yaml
Traceback (most recent call last):
  File "/home/cluster1/new_rmf_ws/install/rmf_building_map_tools/lib/rmf_building_map_tools/building_map_generator", line 11, in <module>
    load_entry_point('rmf-building-map-tools==0.0.0', 'console_scripts', 'building_map_generator')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 490, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2854, in load_entry_point
    return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2445, in load
    return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2451, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/home/cluster1/new_rmf_ws/install/rmf_building_map_tools/lib/python3.8/site-packages/building_map_generator/building_map_generator.py", line 3, in <module>
    from building_map.generator import Generator
  File "/home/cluster1/new_rmf_ws/install/rmf_building_map_tools/lib/python3.8/site-packages/building_map/generator.py", line 4, in <module>
    from .building import Building
  File "/home/cluster1/new_rmf_ws/install/rmf_building_map_tools/lib/python3.8/site-packages/building_map/building.py", line 1, in <module>
    import fiona
ModuleNotFoundError: No module named 'fiona'
make[2]: *** [CMakeFiles/generate_door_madness.dir/build.make:61: maps/door_madness/door_madness.world] Error 1
make[1]: *** [CMakeFiles/Makefile2:78: CMakeFiles/generate_door_madness.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
---
Failed   <<< rmf_traffic_editor_test_maps [1.95s, exited with code 2]
Aborted  <<< rmf_demos_maps [2.26s]                                                                                        
Aborted  <<< rmf_ingestor_msgs [10.9s]                                                                                     
Aborted  <<< rmf_fleet_msgs [37.6s]                                                                                         
Aborted  <<< rmf_building_sim_common [12.3s]                                                                                   
Aborted  <<< rmf_task_msgs [30.6s]                                                                                             
Aborted  <<< rmf_traffic_editor [59.3s]                                                                                         
Aborted  <<< rmf_traffic_msgs [1min 9s]                                                                                      
Aborted  <<< rmf_traffic [1min 36s]                                          

Summary: 16 packages finished [2min 6s]
  1 package failed: rmf_traffic_editor_test_maps
  8 packages aborted: rmf_building_sim_common rmf_demos_maps rmf_fleet_msgs rmf_ingestor_msgs rmf_task_msgs rmf_traffic rmf_traffic_editor rmf_traffic_msgs
  4 packages had stderr output: menge_vendor rmf_building_sim_common rmf_demos_maps rmf_traffic_editor_test_maps
  20 packages not processed

Thanks in advance

Clean up demos README

Feature request

Description

With more fancy gifs and media added onto the README, it is starting to get cluttered and making it difficult to parse information. I would suggest leaving the media and gifs on the main README, with links to more directed information about each demo in docs

Unable to Visualize map & navgraphs in RViz

Bug report

Required information:

  • Operating system and version: Ubuntu 20.04
  • OpenRMF installation type: From source, binaries
  • OpenRMF version or commit hash: foxy
  • ROS installation type: binaries
  • Package or library, if applicable: N/A

Description of the bug

When we are trying to run the RMF office demo. We are not able to visualize the map and navgraph in the RViZ window that opens up.
Where as when we try to run the RMF office demo along with the gazebo. We are able to visualize the map and navgraph in RViZ window.
Sometimes the map and navgraph is visible when we reboot our system, and then run the RMF. After that when we try to run the RMF file, It doesn't shows the map and navgraph.

Steps to reproduce the bug

  1. Launch RMF using ros2 launch rmf_demos office_demo.launch.xml
  2. After that, when the RViZ Window open's up we can't visualize the map.
  3. Launch RMF using ros2 launch rmf_demos_gz office_demo.launch.xml
  4. We can visualize the map and navgraph in RViZ

Expected behavior

When we launch the RMF demo file. It open ups a RViZ window in order to show the
map as well as the Navgraph for particular robots.

Screenshot from 2021-11-25 11-46-58

Actual behavior

What actually is happening is that, When ever we try to run the RMF demo file. It open ups the RViZ
window but is not showing the map and the Navgraph for the robots. Whereas just keeps on displaying a black screen in the RViZ window. Without anything to display.

Screenshot from 2021-11-25 11-58-50

[Other issue]: Roadmap for integrating VDA5050 with the OpenRMF

Before proceeding, is there an existing issue or discussion for this?

Description

Hello,

My project focuses on implementing VDA5050 protocol on AGVs in physical world. However, before going forward with this implementation on physical AGVs, I am planning to demonstrate it in virtual world. So, I am planning to integrate VDA5050 with OpenRMF demos.
It would help with a roadmap or set of instructions on how to integrate these both in either rmf demos or user-defined tasks.
Thanks in advance.

Non-unique names detected for links in `airport_terminal.world`

Bug report

Required information:

  • Operating system and version: Ubuntu 20.04
  • OpenRMF installation type: Source build
  • OpenRMF version or commit hash: main-->
  • ROS distribution and version: Foxy
  • ROS installation type: binaries

Description of the bug

During the launch of airport_terminal.launch.xml, this error message occurs, specifically targeting the Table model, https://app.ignitionrobotics.org/OpenRobotics/fuel/models/Table

It does not affect the simulation, other than the error message showing up. This might be due to some behavior changes in nested SDF models.

[gzserver-14] [Msg] Loading world file [/home/aaron/workspaces/rmf/install/rmf_demos_maps/share/rmf_demos_maps/maps/airport_terminal/airport_terminal.world]
[gzserver-14] Error: Non-unique names detected in <link name='link'>
[gzserver-14]   <collision name='surface'>
[gzserver-14]     <pose>0 0 1 0 -0 0</pose>
[gzserver-14]     <geometry>
[gzserver-14]       <box>
[gzserver-14]         <size>1.5 0.8 0.03</size>
[gzserver-14]       </box>
[gzserver-14]     </geometry>
[gzserver-14]     <surface>
[gzserver-14]       <friction>
[gzserver-14]         <ode>
[gzserver-14]           <mu>0.6</mu>
[gzserver-14]           <mu2>0.6</mu2>
[gzserver-14]         </ode>
[gzserver-14]       </friction>
[gzserver-14]     </surface>
...

Steps to reproduce the bug

ros2 launch rmf_demos airport_terminal.launch.xml

Fatal error for rmf_traffic_schedule-1

Bug report

Required information:

  • Operating system and version: Ubuntu 20.04
  • OpenRMF installation type: From source, following install in https://github.com/open-rmf/rmf for galactic
  • OpenRMF version or commit hash: latest commit, 92972bffbdb3c4e8e4bfb8b1238047d876c07f38
  • ROS distribution and version: galactic
  • ROS installation type: from binary
  • Package or library, if applicablle: N/A

Description of the bug

get error [rmf_traffic_schedule-1] [FATAL] [1660195044.439489807] [rmf_traffic_schedule_primary]: Failed to correctly load participant registry: yaml-cpp: error at line 9, column 16: bad conversion in terminal

No map displayed in rviz, but the lift and doors are present

Steps to reproduce the bug

  1. Launch RMF using ros2 launch rmf_demos office_demo.launch
  2. See the error displayed in rviz panel and error message in terminal

[Other issue]: How do I run rmf_demos?

I just installed rmf and rmf_demos.
I am trying to run Office World demo and it seems like robots are not moving
But I am getting
TypeError: Server.emit() got an unexpected keyword argument 'broadcast'
By searching the webs I could learn maybe I have installed wrong version.
So what python-socketio version do I have to install?

Is there any other packageI should setup before running the demos?
Thanks!

Common export directory for downloaded models

Feature request

Description

Related to open-rmf/rmf_traffic_editor#386.

  • Current split of MAP_NAME and MAP_NAME_ign directories makes install directory of rmf_demos_maps a little cluttered, with duplicated efforts.

  • We should have downloaded models as well as any common generated map yaml files be exported to a common MAP_NAME directory.

  • Both simulations from rmf_demos_gz and rmf_demos_ign should add this common directory to path for simulation needs.

Implementation considerations

  • We should try to minimize the built package size in order for the binaries to be efficient.

  • Consider using a common model directory for all maps, to avoid exporting duplicated models throughout. See #89 (comment)

python3-flask-socketio not resolved for RHEL

Package rmf_demos_bridges depends on python3-flask-socketio and it's not defined what package should resolve this dependence:

Could not resolve rosdep key 'python3-flask-socketio' for distro '8':
No definition of [python3-flask-socketio] for OS [rhel]
	rosdep key : python3-flask-socketio
	OS name    : rhel
	OS version : 8
	Data:
debian:
		- python3-flask-socketio
		ubuntu:
		- python3-flask-socketio
		
Failed to resolve python3-flask-socketio on rhel:8 with: Error running generator: Failed to resolve rosdep key 'python3-flask-socketio', aborting.
python3-flask-socketio is depended on by these packages: ['rmf_demos_bridges']

I need to make further investigation about if this package is distributed or not in fedora and rhel.

[Bug]: Map Server not starting

Before proceeding, is there an existing issue or discussion for this?

OS and version

Ubuntu 22.04

Open-RMF installation type

Binaries

Other Open-RMF installation methods

No response

Open-RMF version or commit hash

2.3

ROS distribution

Humble

ROS installation type

Binaries

Other ROS installation methods

No response

Package or library, if applicable

No response

Description of the bug

When trying to run the simulation i get the follwoing errors
[gzserver-17] [ERROR] [1690367439.546164527] [slotcar_tinyRobot1]: Unable to determine the current level_name for robot [tinyRobot1]. Kindly ensure the building_map_server is running. The RobotState message forthis robot will not be published.

this is for each robot , do i need to start a map server somehow or should it start automatically ?

Thanks

Steps to reproduce the bug

Simply run the example as instructed on gitub

Expected behavior

No response

Actual behavior

No response

Additional information or screenshots

No response

mock_docker crashes when fleet_name missing in config

Bug report

Required information:

  • Operating system and version:
    • Ubuntu 20.04
  • OpenRMF installation type:
    • Source
  • OpenRMF version or commit hash
    • Latest master
  • ROS distribution and version:
    • Roxy
  • ROS installation type:
    • Binary
  • Package or library, if applicable:
    • rmf_demos_tasks

Description of the bug

The mock_docker.py script is prone to crashing when the callback function mode_request_cb is triggered for a robot who parameters are not configured in the docking yaml file. The crash is attributed to this line . We should split the two .get() function calls as the first one may return a None.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.