Replies: 3 comments 3 replies
-
Yeah, I've seen this once in a while when running demos on real robots, but it happened too rarely for me to effectively debug it (and with COVID restrictions in place, my access to robot hardware is limited at the moment). If you're able to reliably reproduce this issue, you could be a great help in debugging it. My best guess is something is not being very smart in If it would help, I could create a branch of |
Beta Was this translation helpful? Give feedback.
-
Edit: The problem for behaviour described below was on my side, as I've done some changes in I've found a way to reproduce this issue. If I send a loop request to the robot and force the robot not to move (so it stays in place), every time that fleet adapter recalculates the plan (I get the |
Beta Was this translation helpful? Give feedback.
-
From what I can tell from further testing, the reason for this is that free_fleet_client did not send the remaining path properly. |
Beta Was this translation helpful? Give feedback.
-
I'm using
open-rmf
andfree_fleet_server
(on Foxy) together withfree_fleet_client
on real robot (running Melodic).Robot size is 1.6 m x 1 m,
free_fllet_adapter
settings for robot size arefootprint_radiu: 0.8
andvicinity_radius: 2.0
and I'm using full_control adapter.I've noticed that sometimes (mostly when collisions are detected, but sometimes also when using only one robot), path assigned to robot is missing some waypoints (e.g path includes only last waypoints) resulting in a path that goes through walls (doesn't follow lines drawn in traffic editor). Below are two pictures of such scenario:
Have you experienced something similar before? Can you give me some pointers (possible causes) on where to look when investigating this issue?
Attached arso also building file and generated navigational graph.
h4_building.zip
0.yaml.zip
Beta Was this translation helpful? Give feedback.
All reactions