Posted by @Achllle:
What are the steps to debug a fleet adapter not submitting a bid to complete a task? I have an idle robot that has taken up tasks in the past but sometimes fails with the following message:
[rmf_dispatcher_node]: Dispatcher Bidding Result: task [Loop0] has no submissions during bidding, Task Failed
I also noticed that robots want to move to a vertex on the graph on initialization. It also doesn’t update which vertex to navigate if the robot moves by itself. Is there a way to change this behavior?
Posted by @mxgrey:
It also doesn’t update which vertex to navigate if the robot moves by itself. Is there a way to change this behavior?
These are features that need to be developed in free fleet, but free fleet development has been on the back burner as most of our critical work right now has been at the automatic traffic and task management level, and not so much at human operator level.
Posted by @Yadunund:
What are the steps to debug a fleet adapter not submitting a bid to complete a task? I have an idle robot that has taken up tasks in the past but sometimes fails with the following message
Could you elaborate on how the task was submitted (GUI, CLI, etc) and the details of the task (task type, parameters, etc)? Are you using the provided full_control fleet adapter or using a custom one?
There are a few scenarios where the dispatcher will not receive any bids from a fleet adapter:
- The fleet adapter is not configured to accept the submitted task type as determined by this function. If you’re using the
full_control implementation, you should indicate which task types are doable using these parameters in your launch file. Else, the fleet adapter will simply not bid for the submitted task. A message should be published in the terminal indicating this: [full_control-15] [INFO] [1617245135.071996222] [tinyRobot_fleet_adapter]: Fleet [tinyRobot] is configured to not accept task [Clean0]. If you’re using a custom fleet adapter, make sure you’re calling FleetUpdateHandle::accept_task_requests().
- The fleet adapter is unable to process the request due to invalid fields in the request. If for example a
loop request is submitted with start or finish waypoints that do not exist on the robot’s nav graph, a bid will not be submitted. An explanatory message will be printed in the terminal such as [full_control-15] [INFO] [1617245206.473805336] [tinyRobot_fleet_adapter]: Fleet [tinyRobot] does not have a named waypoint [bad_waypoint] configured in its nav graph. Rejecting BidNotice with task_id:[Loop1]
- The duration for which the dispatcher accepts bids is smaller than the time taken by the fleet adapters to compute and submit a bid. The duration parameter is specified here. If this is the case, you should still see some printouts in the terminal highlighting that a bid was computed and submitted by the fleet adapter
[full_control-15] [INFO] [1617245621.881432804] [tinyRobot_fleet_adapter]: Planning for [2] robot(s) and [1] request(s)
[full_control-15] [INFO] [1617245621.886230967] [tinyRobot_fleet_adapter]: Submitted BidProposal to accommodate task [Loop2] by robot [tinyRobot2] with new cost [45.222308]```
Posted by @Achllle:
Thanks for your reply. I’m using the vanilla full_control fleet adapter alongside a free_fleet implementation on real robots. I’ll try to recreate the scenario soon and add more details.
I didn’t mention that:
- the robot has performed the same task in the past and the path is clear
- a different robot from the same fleet was awarded the task and the task was queued for that robot instead, even though it still had a task left to do.
- I’m using the RMF panel to dispatch the task (curious if
rmf-web shows the logs in a pretty/readable format)
I’m wondering if this is related to the other point I made, which is that the robots are told to navigate to the closest vertex (“Station” task?) continuously. Perhaps the robot happened to be executing that right when I dispatched the task and then the task got assigned to the other robot as a result.