search

open-rmf / rmf_ros2

Internal ROS infrastructure for RMF
Apache License 2.0
71 stars 57 forks source link

[Bug]: Mutex group is accquired by other robot when first robot has already accquired it and performing action #375

Open techmanjeet opened 1 month ago

techmanjeet commented 1 month ago

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

OS and version

Ubuntu 24.04

Open-RMF installation type

Source build

Other Open-RMF installation methods

No response

Open-RMF version or commit hash

latest on jazzy

ROS distribution

Rolling

ROS installation type

Binaries

Other ROS installation methods

jazzy ros2

Package or library, if applicable

No response

Description of the bug

i am having ros2 jazzy on ubuntu 24.04. i installed the ros in binary and open rmf as source build. My requirement is that on a waypoint where i am performing an action like conveyor dock and transfer, i dont want another robot to go to that place and kept waiting before certain waypoint.

I tried to simulate this using office demo launch file and assigned the task to perform teleop action on coe waypoint. i gave command two bot ronot to go there.

I applied the mutex group to the waypoints going to the coe end.

What i faced is that upon reaching suppose tinyRobot1 to coe, after certain seconds the tinyRobot 2 is also accquiring the same spot and robot goes in deadlock scenario.

i am attaching the building.yaml files office.building.zip

Steps to reproduce the bug

1.Launch Rmf using ros2 launch rmf_demos_gz office.launch.xml 2.ros2 run rmf_demos_tasks dispatch_action -F tinyRobot -R tinyRobot1 -a teleop -s coe --use_sim_time 3.ros2 run rmf_demos_tasks dispatch_action -F tinyRobot -R tinyRobot2 -a teleop -s coe --use_sim_time

Expected behavior

One robot should wait till the other finished the teleop operation and has mutex lock acquired. i want to use this as a transfer use case via conveyor or any medium. need a custom action to dock and than finish request.

And i also found that after giving task request rmf takes a while to start task, some times one minute and sometimes give api response but dont start Screencast from 2024-07-13 12-35-15.webm

Actual behavior

how can i achieve this use case in rmf framework. i tried using mutes, let me know how can i achieve this, its a good project where i can use this.

Additional information or screenshots

No response

luca-della-vedova commented 1 month ago

I'm not too familiar with the details of the mutex implementation but have you tried doing a composed task made of a simple goto place (for the coe waypoint) followed by a perform action (for the teleop)?

Generally, during the "perform_action" mode, RMF has minimal interactions with the robot and I wouldn't be surprised if that also means it won't lock any mutexes. By contrast, doing normal dispatch patrols should.