Submitted BidProposal to accommodate task seems to not be accepted by RMF

[royito55]

Hi,

I am trying to set up RMF with a real robot.

I have sucessfully added localization and navigation configured for the free fleet to work together. That is, when I run an example with something like:

ros2 run ff_examples_ros2 send_destination_request.py -f barista -r barista_1 -x 0.0 -y 0.0 --yaw 0.0 -i 7,

where barista is the fleet and barista_1 the robot.
then the free fleet connects with nav2 and it goes to that location.

I have also gotten the rmf schedule to run without any errors, and I've noticed that when it is launched, the robot gets a little closer to the start of a navigation graph, which is a good sign. Plus, I see the yellow circle in rviz2 so I know that RMF knows where the robot is.

However, when I send a loop task, it seems like the process gets stuck in the bid proposal and the robot never starts moving.

Here are my terminals (free fleet server + client at the top, rmf_schedule and fleet adapter at the bottom).

Let me know if this rings a bell for anyone. Thank you!

[royito55]

Some more info on this:

I realized that the rmf_dispatcher_node publishes the bid_notice and receives the bid_response correctly.

However, the dispatch_resquest never gets published, (and therefore nothing comes up in dispatch_ack)

I can manually publish to dispatch_request and the fleet_adapter detects it and awards the task to the robot. It gets to the task beginning and I can even see the plan that RMF is trying to do in rviz2.

The problem is that the free_fleet_client outputs that the distance to first waypoint: 0.00, even if I move the robot around a bit. Then, the client just outputs

we reached our goal early! Waiting 6.61 more seconds

[Yadunund]

Instead of using ff_examples_ros2, could you try requesting for a task using the scripts from rmf_demos_tasks?

See usage examples below.
https://github.com/open-rmf/rmf_demos/tree/main/rmf_demos_tasks#flexible-tasks

[royito55]

Thanks for the tip, I tried it and it was a similar result. This is the output:

ros2 run rmf_demos_tasks dispatch_go_to_place -p waypoint [INFO] [1658913492.542044209] [task_requester]: Using 'dispatch_task_request' Json msg payload: { "type": "dispatch_task_request", "request": { "category": "compose", "description": { "category": "go_to_place", "phases": [ { "activity": { "category": "go_to_place", "description": { "waypoint": "waypoint" } } } ] }, "unix_millis_earliest_start_time": 1658913492542 } } Got response: {'state': {'booking': {'id': 'compose.dispatch-1', 'unix_millis_earliest_start_time': 1658913492542}, 'category': 'compose', 'detail': {'category': 'go_to_place', 'phases': [{'activity': {'category': 'go_to_place', 'description': {'waypoint': 'waypoint'}}}]}, 'dispatch': {'status': 'queued'}}, 'success': True}

So there is a response on that side. I also get the bid response and notice correctly, but the Fleet Client keeps telling me that the robot has reached the goal early, and it seems like it gets stuck there.

I discovered that my localization does not have the robot namespace, like nav2 does. Would this be a problem for the Free Fleet Client/Server? I had discarded it earlier because I saw that the topic fleet_states was giving me the correct location of the robot.

What is the purpose of robot_state? I only see it as a subscription to the State Aggregator node, but I suspect there is an issue between the Fleet Client/Server communication?

I looked at the free fleet client node code, and it seems the client never gets out of this loop:
while (now() < goal_path.front().goal_end_time) { rclcpp::Duration wait_time_remaining = goal_path.front().goal_end_time - now(); RCLCPP_INFO(get_logger(), "we reached our goal early! Waiting %.2f more seconds",

Does this ring any bells/does it sound like I'm going in the right direction? (sorry about the indentation I couldn't figure out the formatting in a reply)

[royito55]

I ruled out the localization theory I had. So never mind that.

Just one more thing, I noticed that this might be because the yellow marker (schedule_markers) seems to not be updating based on the position of the robot. If I move the robot around, the purple sphere moves accordingly (fleet_makers), but the yellow one fails to update. I think this is the missing step in my setup:

By the way, the exact same setup works in the simulation, but not in the real environment.

[aaronchongth]

Hello @royito55! Thanks for bringing this up! My first intuition is that there is a deadlock happening which spawns a large number of threads. Could I trouble you to provide me with the launch configuration of your free fleet client?

Side note, to insert a formatted code block, you can use 3 back ticks on a new line to start it and end it with another 3 back ticks on another new line.

[royito55]

Thank you for the tip!

I realized that I had use_sim_time set as true in the launch file that launched the rmf_traffic_schedule, and that fixed the issue.

[aaronchongth]

Perfect! Glad to hear that it was just that. I am rather intrigued that it indicated a same duration throughout, while it is stuck in a loop though, instead of giving the telltale sign of 50 years+ of seconds.