You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I noticed that there is a commented out definition of MultiThreadedSpinner in the move_base_node.cpp. I'm wondering if there is any particular reason that it is commented out and if you are aware of any risks that come with using MultiThreadedSpinner in move_base?
To give a bit more context, in our application map can get quite large and I noticed that when the global costmap's inflation layer updates, it somehow blocks the local costmap's sensor callbacks (ObstacleLayer with LaserScan and PointCloud2) . As observation buffers are not updated, it results in an emergency stop of the robot. I noticed that using even two threads for spinning solves the problem. I'm not yet sure what exactly can block the callback queue - I haven't found anything suspicious in the inflation layer (we also have some custom costmap layers, but it seems to happen during the inflation layer update).
Thanks,
Mac
The text was updated successfully, but these errors were encountered:
move_base is already multi threaded in a few spots - the planner spins up a separate planning thread and each costmap has it's own update thread. I think adding additional threads for the main loop probably has some risk since it is likely there are things touching the same data that are not appropriately locked.
Hi,
I noticed that there is a commented out definition of
MultiThreadedSpinner
in themove_base_node.cpp
. I'm wondering if there is any particular reason that it is commented out and if you are aware of any risks that come with using MultiThreadedSpinner in move_base?To give a bit more context, in our application map can get quite large and I noticed that when the global costmap's inflation layer updates, it somehow blocks the local costmap's sensor callbacks (ObstacleLayer with LaserScan and PointCloud2) . As observation buffers are not updated, it results in an emergency stop of the robot. I noticed that using even two threads for spinning solves the problem. I'm not yet sure what exactly can block the callback queue - I haven't found anything suspicious in the inflation layer (we also have some custom costmap layers, but it seems to happen during the inflation layer update).
Thanks,
Mac
The text was updated successfully, but these errors were encountered: