Revision history [back]

You should try to debug mapping separately from navigation.

Assuming you're running a typical move_base setup, 'Map update loop missed' means that your pc was process costmap updates as quickly as it wanted. Since your system is not realtime, it tries to run loops at a certain rate set in the parameters. Specifically, one of the costmaps inside move_base was unable to update at 5 Hz, this is usually due to too much processing load on the system. However since that message only popped up once, it's likely a corner case and you shouldn't need to reduce/alter any of the rates in your parameter files.

From the remained of the messages, I'm guessing you're running eband_local_planner. If you're just trying to get the navigation stack up and running, you could try the defaultbase_local_planner instead, since it's a little more battle tested. Then you can tune the rest of the stack (move_base, costmap, and global_planner parameters) before delving into swapping in a more experimental planner.

You should try to debug mapping separately from navigation.navigation. If you don't have a good map of your environment already, setup navigation first without a static map, or get the static map via gmapping and teleoperation.

Assuming you're running a typical move_base setup, 'Map update loop missed' means that your pc was process costmap updates as quickly as it wanted. Since your system is not realtime, it tries to run loops at a certain rate set in the parameters. Specifically, one of the costmaps inside move_base was unable to update at 5 Hz, this is usually due to too much processing load on the system. However since that message only popped up once, it's likely a corner case and you shouldn't need to reduce/alter any of the rates in your parameter files.

From the remained of the messages, I'm guessing you're running eband_local_planner. If you're just trying to get the navigation stack up and running, you could try the defaultbase_local_planner instead, since it's a little more battle tested. Then you can tune the rest of the stack (move_base, costmap, and global_planner parameters) before delving into swapping in a more experimental planner.

I feel the map we are getting is pretty good .

Mapping (gmapping or etc.) doesn't have anything to do with the navigation stack. To experiment with getting a good nav setup, get a static map separately via gmapping and teleoperation, or setup navigation without a static map (using fake_localization instead of amcl to publish the odom->map transform).

Assuming you're running a typical move_base setup, 'Map update loop missed' means that your pc was process costmap updates as quickly as it wanted. Since your system is not realtime, it tries to run loops at a certain rate set in the parameters. Specifically, one of the costmaps inside move_base was unable to update at 5 Hz, this is usually due to too much processing load on the system. However since that message only popped up once, it's likely a corner case and you shouldn't need to reduce/alter any of the rates in your parameter files.

From the remained remainder of the messages, I'm guessing you're running eband_local_planner. If you're just trying to get the navigation stack up and running, you could try the defaultbase_local_planner instead, since it's a little more battle tested. Then you can tune the rest of the stack (move_base, costmap, and global_planner parameters) before delving into swapping in a more experimental planner.