search

open-rmf / rmf_ros2

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

Dock function called unexpectedly when patrol to a random waypoint(not "_start" waypoint) from dock #251

Closed Briancbn closed 1 year ago

Briancbn commented 1 year ago

Bug report

Required information:

Description of the bug

Assume the dock_name is some_dock, it is connected directly to 2 waypoints:

Sequence of events to reproduce the behavior

  1. I first ask the robot to go to the some_dock through some_dock_start, robot will stop at some_dock_start and starting the docking behavior.

  2. After finishing docking the fleet adapter tells rmf that the robot is at the some_dock waypoint.

  3. At the current state, if I send a task (Loop or Delivery), from some_dock to wp1.

    Robot will behave normally at some_dock, triggering the dispenser if it is a delivery and travel to wp1.

    After the robot reach wp1, it will trigger the dock() function again, which I believe is not how it supposed to behave.

Expected behavior

Robot not calling dock function after reaching wp1.

Actual behavior

Robot calling dock function after reaching wp1.

If the patrol task is to a waypoint beyond wp1 and wp1 is just passthrough, dock function will not get triggered.

Why it was done this way

Otherwise robot will take the extra path to the some_dock_start waypoint, which is less efficient than going to the target location directly. Since the robot will take a detour and turn.

I am pretty sure the docking is not supposed to be this way, but I can see others trying to do the same thing. Hope the maintainer can provide some insights on how to achieve the "Expected Behavior"

Potential Workaround

I can teleport the robot to a separate different waypoint after the dock behavior is completed and have that separate waypoint used as the starting waypoint for all future tasks.

mxgrey commented 1 year ago

I agree that the behavior you're describing is not intended behavior for RMF if I'm understanding everything correctly.

Please share a traffic map and scenario that reproduces this issue, otherwise it's not feasible for us to debug it.

If the traffic map is too sensitive to be shared publicly, feel free to send it to us through a side channel like email.

Briancbn commented 1 year ago

Hi @mxgrey, thanks for the quick response, it turns out we are accidentally calling the wrong ingestor that behaves like a docking function at the end of the wp1. The expected behavior works after that was resolved.