| ROS Resources: ROS Homepage | Media and Trademarks | Documentation | ROS Index | How to Get Help | Q&A Help Site | Discussion Forum | Service Status |
Posted by @cwrx777:
Hi,
Consider a fleet of food delivery robot in a multi storey hotel. When food is being loaded into the robot (robot A), users on another floor may request for a to collect empty cart (on-demand/adhoc) how to prevent the empty cart collection cart task to be assigned to robot A ?
Posted by @Yadunund:
Your question is lacking several details on your specific use case. Please be more descriptive in the future in explaining the setup. For example
Depending on your answers above, there are multiple ways to address the problem.
Posted by @cwrx777:
Hi @Yadunund ,
The robot probably looks like this.
Posted by @Yadunund:
The problem is that you have the robot idle while loading items but expect Open-RMF to somehow know that it is actually being utilised. This is not a good way to execute your task with Open-RMF.
There are a couple ways to fulfil your task in a safe manner:
Option 1: use the existing Delivery task. This task will guide a robot to a pickup location (if the robot is already at this location, it will skip this step), wait for conformation that items have been loaded (via rmf_dispenser_msgs), go to a dropoff location, and wait for confirmation that items have been unloaded (via rmf_ingestor_msgs). If a human is loading the items, you can implement a interface somewhere on the robot or a dashbaord for them to confirm the loading/unloading which will then publish the suitable confirmation messages. While the robot is executing any of these steps including waiting, it will not be assigned a different task.
if your delivery task is more complicated, eg you have multiple pickup and multiple dropoff locations, you can still create such a task by defining a custom Compose task with a list of pickup and dropoff events. See option 2 below for more information.
Option 2: An alternative to not publishing ROS 2 messages for confirmation.
Create a compose task using our flexible task framework (See our documentation here.) that is a sequence of activities like
GoToPlace->PerformAction->GoToPlace->PerformAction
The PerformAction is a really powerful activity whose execution you can totally customize. You’ll need to define an action_executor for the robot which will decide what the robot should do when this event is triggered. In your case, you can simply wait for confirmation from the human before calling finished(). All this is within your fleet adapter so you can have your adapter integrate with any other system you have to receive the human confirmation.
Edited by @Yadunund at 2022-08-23T04:28:16Z
Posted by @Yadunund:
I would not say they are related.
Yes technically with that feature, you can set a robot as unable to bypass any tasks from being assigned. But like I explained in detail above, you can achieve what your want to do with existing task frameworks in Open-RMF. You can designate a robot as “busy” while it is being loaded.
Posted by @cwrx777:
Hi @Yadunund ,
What is /rmf_traffic/unregister_participant service? In what scenario is this used?
Assuming the robot has been added (using fleet_handle.add_robot) and unregister participant is called against that robot, will calling ‘/rmf_traffic/register participant’ for the robot put things back to normal (before unregister participant is called) ?
Posted by @mxgrey:
/rmf_traffic/unregister_participant clears the participant’s itinerary in the traffic schedule. When it was first implemented, it used to remove the participant from the schedule entirely so that no new itinerary could be scheduled for a traffic participant until /rmf_traffic/register_participant is called for it again, but after some real-world experience we found that for the sake of robust fail-over it’s better to leave participants registered in the schedule permanently. Therefore “unregister” just clears the participant’s itinerary, but you can resume scheduling itineraries for that participant at any time.
As mentioned in this discussion you can use /rmf_traffic/register_participant to change the properties of a participant, but otherwise there is no value to calling it multiple times, even if /rmf_traffic/unregister_participant has been called.
Posted by @cwrx777:
Hi @mxgrey ,
/rmf_traffic/unregister_participantclears the participant’s itinerary in the traffic schedule
By itinerary, do you mean the intended robot trajectories as mentioned here? and by calling /rmf_traffic/unregister_participant, it will clear all planned trajectories?
Therefore “unregister” just clears the participant’s itinerary, but you can resume scheduling itineraries for that participant at any time.
What do you mean by ‘resume scheduling itineraries’? does ‘unregister’ pause anything?
Posted by @mxgrey:
By itinerary, do you mean the intended robot trajectories as mentioned here?
Correct.
and by calling /rmf_traffic/unregister_participant, it will clear all planned trajectories?
It will clear planned trajectories only for the robot that you request to unregister. The planned trajectories for all other robots will be unaffected.
What do you mean by ‘resume scheduling itineraries’?
The fleet adapter will automatically schedule itineraries for the robots as they get commanded to perform tasks. That will continue to happen even after you manually unregister the robot.
does ‘unregister’ pause anything?
No, it does not pause anything. The name of the service is admittedly confusing, because it originally did completely remove the robot from the schedule such that it could not appear again in the traffic schedule until it gets re-registered, but that design proved problematic when it came to supporting robust fail-over. The new (current) behavior allows participants to shut down, restart, and resume operating correctly with no disruption to the overall system.
Posted by @mxgrey:
@cwrx777 After thinking over the questions you’ve been asking, it’s become clear to me that RMF needs a built-in way to take robots temporarily offline and make it clear to the task planning system that they are not available to perform new tasks.
To that end, I’ve opened this PR which allows you to “decommission” your robots. When a robot is decommissioned it will no longer accept new tasks.
RMF does not currently have a builtin way to reassign tasks from one robot to another. We want to develop that feature but do not currently have funding to do so. Therefore decommissioning will not affect the robot’s current task queue. After you’ve decommissioned a robot, it will continue to perform any tasks that it was already assigned.
If you need the robot to stop what it’s doing immediately, you will need to use the task interrupt, cancel, or kill APIs that are described in the pull request that I linked.
We intend to do a code freeze for the next release on 16 September (Friday), so if you can test out that PR for your use case and give us some feedback that would be very helpful. We have very limited time for testing before the code freeze, so I can’t promise that the feature will be merged for the release without your feedback.
Posted by @cwrx777:
Hi @mxgrey ,
The is_commissioned flag seems not respected when assigning a task directly to a robot.
I confirmed that the robot’s is_commissioned flag was False before sending the following task.
I used the following to send a task to a robot.
ros2 run rmf_demos_tasks dispatch_patrol -p wp1 wp2 -R DeliveryRobot_1 -F DeliveryRobot
Edited by @cwrx777 at 2022-09-21T09:09:05Z
Posted by @mxgrey:
That raises an interesting question…
If a robot is decommissioned but a task is directly assigned to it, should it ignore that task? Report an error? Queue the task until the robot is re-commissioned?
The decommissioning feature was specifically designed to prevent the RMF dispatching system from assigning tasks to robots that shouldn’t be receiving any tasks, because otherwise you as the system integrator cannot prevent the dispatching system from assigning tasks to them.
When it comes to direct tasks, you as the system integrator do have complete control over which robots those tasks are given to. So if you as the system integrator are telling RMF “Give this task to Robot A right now” should RMF block that or should RMF believe that you know what you’re doing?
The direct request pipeline was created specifically because system integrators were asking for a way to issue commands to robots without interference from RMF. I think a healthy debate could be had over where the line is between “interference” versus “correct behavior”. Feel free to share your own thoughts on what the correct behavior is.
Posted by @cwrx777:
I think the expected behavior of a ‘decommissioned’ robot needs to be defined and it needs to be consistent regardless if a robot is to be assigned direct or indirect task request.
I’m not sure if this is related, if due to some reason, e.g. building owner policy, a robot needs to be turned off, e.g. during weekends/long public holidays, etc, how can this be made known to rmf? coz if it is not handled properly, we’ll see lots of errors in getting the latest robot status.
Posted by @mdfesto:
@mxgrey I believe this request is resolved with the latest release on Jazzy?
@cwrx777 FYI