ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

After making sure the odom message is being published is correctly, the main issue on getting it to run smoothly was the laptop.

To make sure the CPU didn't stall, I essentially lowered the local/global maps and move_base controller update frequency to a point where the navigation wouldn't work well at all. For me, the map updating/publishing rates were down to 3Hz and 2Hz, respectively. The move_base frequency was also down to 3-4Hz. On top of this, I was running rviz on the same laptop on an integrated graphics card.

Some of the behaviors I had while running with the above setup was:

  1. The local planar detected an obstacle. As it moves around it, the obstacle was dragged across the local map, enclosing the robot an completely unmovable space.

  2. This lead to the robot getting lost, a lot. I would see it moving to the goal designated, but when it gets there, it would spin to get the correct orientation. While this happens, the laser scan would slowly move out of place of the global map.


Here is a couple general rule of thumb if you want to run the navstack.

  1. Use gnome-system-monitor to see if the CPU is close to stalling. If you are, try splitting some of the cpu intensive nodes across different machines. http://wiki.ros.org/ROS/NetworkSetup Or run rviz on different machine and just have the navstack run on the local machine.

  2. Don't run the map/controller frequency lower than the ros nav stack guide.


I upgraded to a laptop with an i7-4th gen (~2.2Ghz), and an nvidia graphics card. I run the map publish rates and controller publish rates to twice the ros tutorial's values. It can run at higher velocities and smoother motions!

Hopefully this post will help someone run the navstack successfully for the first time(like me). If any of this is incorrect, please comment and I'll edit the post!

After making sure the odom message is being published is correctly, the main issue on getting it to run smoothly was the laptop.

To make sure the CPU didn't stall, I essentially lowered the local/global maps and move_base controller update frequency to a point where the navigation wouldn't work well at all. For me, the map updating/publishing rates were down to 3Hz and 2Hz, respectively. The move_base frequency was also down to 3-4Hz. On top of this, I was running rviz on the same laptop on an integrated graphics card.

Some of the behaviors I had while running with the above setup was:

  1. The local planar detected an obstacle. As it moves around it, the obstacle was dragged across the local map, enclosing the robot an completely unmovable space.

  2. This lead to the robot getting lost, a lot. I would see it moving to the goal designated, but when it gets there, it would spin to get the correct orientation. While this happens, the laser scan would slowly move out of place of the global map.


Here is a couple general rule of thumb if you want to run the navstack.

  1. Use gnome-system-monitor to see if the CPU is close to stalling. If you are, try splitting some of the cpu intensive nodes across different machines. http://wiki.ros.org/ROS/NetworkSetup Or run rviz on different machine and just have the navstack run on the local machine.

  2. Don't run the map/controller frequency lower than the ros nav stack guide.


I upgraded to a laptop with an i7-4th gen (~2.2Ghz), and an nvidia graphics card. I run the map publish rates and controller publish rates to twice the ros tutorial's values. It can run at higher velocities and smoother motions!

Hopefully this post will help someone run the navstack successfully for the first time(like me). If any of this is incorrect, please comment and I'll edit the post!

Edit: Naturally, those errors when away after the upgrade and the CPU stopped stalling/running so slow.

After making sure the odom message is being published is correctly, the main issue on getting it to run smoothly was the laptop.

To make sure the CPU didn't stall, I essentially lowered the local/global maps and move_base controller update frequency to a point where the navigation wouldn't work well at all. For me, the map updating/publishing rates were down to 3Hz and 2Hz, respectively. The move_base frequency was also down to 3-4Hz. On top of this, I was running rviz on the same laptop on an integrated graphics card.

Some of the behaviors I had while running with the above setup was:

  1. The local planar detected an obstacle. As it moves around it, the obstacle was dragged across the local map, enclosing the robot an completely unmovable space.

  2. This lead to the robot getting lost, a lot. I would see it moving to the goal designated, but when it gets there, it would spin to get the correct orientation. While this happens, the laser scan would slowly move out of place of the global map.


Here is a couple general rule of thumb if you want to run the navstack.

  1. Use gnome-system-monitor to see if the CPU is close to stalling. If you are, try splitting some of the cpu intensive nodes across different machines. http://wiki.ros.org/ROS/NetworkSetup Or run rviz on different machine and just have the navstack run on the local machine.

  2. Don't run the map/controller frequency lower than the ros nav stack guide.


I upgraded to a laptop with an i7-4th gen (~2.2Ghz), and an nvidia graphics card. I run the map publish rates and controller publish rates to twice the ros tutorial's values. It can run at higher velocities and smoother motions!

Hopefully this post will help someone run the navstack successfully for the first time(like me). If any of this is incorrect, please comment and I'll edit the post!

Edit: Naturally, those errors when went away after the upgrade and the CPU stopped stalling/running so slow.