open-rmf / rmf_demos Goto Github PK

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

Migrated from osrf/rmf_demos#149

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

• I have done a search for similar issues and discussions.

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

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

(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.

Bug report

Required information:

• Operating system and version:
  • Ubuntu 20.04
• OpenRMF installation type:
  • This repo checked out at aef1752
  • And open-rmf/rmf_internal_msgs@c0b929d
  • build both from source. Everything else was installed as needed.
• OpenRMF version or commit hash
  • aef1752
• 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"

The current way of having a binary priority input (0 low and 1: high) will work for now. For future support of a "non-binary" priority input, it will be ideal to use this kind of input format.

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

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.

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

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

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

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.

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.

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.

osrf/rmf_demos#159

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!

Bug report

Required information:

• Operating system and version:
  • Ubuntu 20.04
• Open-RMF installation type:
  • https://git.lejurobot.com/rmf/rmf-all.git
• 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

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

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:

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).

Presently, there is an implicit requirement of having a _start waypoint right before the location of cleaning. For example, if the robot need to clean zone_1, then a zone_1_start waypoint is required.

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.

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

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.

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.

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!

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

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'].

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.

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)

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?

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.

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.

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

• I have done a search for similar issues and discussions.

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 :)

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

• I have done a search for similar issues and discussions.

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

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.

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.

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

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

test_ackman scenario imports Ambulance as a model, instead of being spawned through traffic map annotation. Consequently, it seems the wrong model ( without slotcar plugin ) is used.

Vaguely related to open-rmf/rmf_traffic_editor#386 involving some issues with the model download pipeline from fuel.

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

osrf/rmf_demos#151

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.

I encounter an issue on certain distributions of python3-yaml ( such as the binary on rhel8 ) where this line is parsed weirdly:

https://github.com/open-rmf/rmf_demos/blob/main/rmf_demos_maps/maps/airport_terminal/airport_terminal.building.yaml#L29

Specifically, the colon in model: is confused as a key-value delimiter. Manually quoting the value seems to fix this.

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!

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'

Some doors in the clinic world do not seem to have plugins assigned. For example:

https://github.com/open-rmf/rmf_demos/blob/main/rmf_demos_maps/maps/clinic/clinic.building.yaml#L21

Is this intentional? It results in a rather odd visual on rmf-web, where the doors are listed but cannot be controlled.

As mentioned in this review there appear to be some updates still needed for the simple_api_server.

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.

Feature request

Description

See open-rmf/rmf-web#518. This is a reminder to synchronize the progress of that feature request.

Implementation considerations

Alternatives

Additional information

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

• I have done a search for similar issues and discussions.

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.

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.

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

We could perhaps add a disclaimer not to mix source / binary installs, to prevent accidental build 🔥 .

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