| ROS Resources: ROS Homepage | Media and Trademarks | Documentation | ROS Index | How to Get Help | Q&A Help Site | Discussion Forum | Service Status |
Posted by @jamietjx:
I ran the task command: ros2 run rmf_demos_tasks dispatch_loop -s L1_left_nurse_center -f L2_south_counter -n 1 --use_sim_time on the clinic demo, however the robot failed to request for the lift due to the lift being busy. But after awhile the robot managed to get into the lift.
Posted by @mxgrey:
I’m not sure if this is what you experienced, but there are some known issues at the moment for the clinic demo where a robot might exit a lift without endings its session with the lift, and as a result the lift ends up “occupied” by a robot that is no longer using it, which effectively blocks any other robot from using the lift.
We have a plan for fixing this in the long term, which will be based on a “reservation system” that’s currently in development. The idea is to have a robust distributed system for robots to reserve the right to use things like lifts and parking spots. The system is fairly complex, so it’ll take some time to develop, but there are a couple simpler solutions that could be implemented if this issue is an urgent concern for you:
That being said, in your description you’ve only mentioned issuing one loop command. If your simulation only ever had one robot active, then the issue that I described above wouldn’t apply. Could you clarify on whether your issue occurred when only one task was issued for your entire simulation, or if there were multiple tasks issued with multiple robots moving?
Edited by @mxgrey at 2021-04-30T03:42:50Z
Posted by @jamietjx:
The issue occurred when there was only one task performed for the entire simulation in the clinic demo. I also tried it on a simulation that i have created, and it also has the same issue. On the simulation that i have created, i only implemented one robot and only perform one task at a time.
Posted by @mxgrey:
Ah, I see. If you’re not seeing any delays or misbehavior in the lift, then this message can be safely ignored. It’s really just indicating that the lift is busy carrying out a task to move to a new floor, and it’s not accepting any other tasks in the meantime.
We can tweak or remove this output to avoid needlessly alarming users. I’ll open an issue ticket for that.
Edited by @mxgrey at 2021-04-30T05:58:08Z
Posted by @jamietjx:
Okay great! Thank you for your assistance.
Posted by @luca-della-vedova:
Hi @jamietjx.
Long overdue but this small PR should only print to the terminal if there is indeed an issue (i.e. if the lift was requested to go somewhere else than it is currently going). In case everything is working normally and the new request perfectly matches the previous one the warning is not printed.
