How to reduce update rate of global planner on Navigation?

asked 2022-05-20 16:08:22 -0600

51 ●6 ●7 ●9

updated 2022-05-30 06:31:58 -0600

Hello there! I've looked for this question around, but haven't found anything close to it, so I've been a bit confused.

The problem is that what I'm using to control and run ROS and Navigation (ROS1, using Kinetic) in my robot, a Raspberry Pi 4, seems to be struggling a bit with all the processing - it's mostly a hunch, and not a confirmation. For the most part, the Rasp has been just fine - however, one little thing has been bugging me:

When the robot goes around, at some times, especially when going in a straight line, the robot... kind of "hiccups", stopping for a little second, and continuing its navigation like nothing happened. The prime suspect for this is that the global planner is updating too fast, every time, and I wanted to find a way to reduce the update rate or, even more, completely take it off, so the robot doesn't update its own rate and recalculate the global plan at all, just stopping in case it sees an unavoidable obstacle.

Is there a way to do that, to reduce or remove the updating of the path at all?

Thanks in advance!

Edit: The parameters I'm using on the planner, and the error that appears when navigating:

Global Costmap:

robot_base_frame: base_link

update_frequency: 0.4

publish_frequency: 1.0

transform_tolerance: 0.5

resolution: 0.05

obstacle_range: 2.5

raytrace_range: 3.0

global_frame: map

static_map: true

track_unknown_space: true

Local Costmap:

robot_base_frame: base_link

update_frequency: 0.4

publish_frequency: 1.0

transform_tolerance: 0.5

resolution: 0.05

obstacle_range: 2.5

raytrace_range: 3.0

global_frame: odom

static_map: false

rolling_window: true

This is the error I get when trying to run:

[ WARN] [1653910255.369828451]: Control loop missed its desired rate of 5.0000Hz... the loop actually took 0.2608 seconds

[ WARN] [1653910255.747803223]: Control loop missed its desired rate of 5.0000Hz... the loop actually took 0.2391 seconds

[ WARN] [1653910256.155917322]: Control loop missed its desired rate of 5.0000Hz... the loop actually took 0.2472 seconds

[ WARN] [1653910256.552435223]: Control loop missed its desired rate of 5.0000Hz... the loop actually took 0.2437 seconds

edit retag flag offensive close merge delete

Comments

What makes you think the global planner is executing multiple times? In a well-operating system, it only runs once for each goal you provide.

Mike Scheutzow ( 2022-05-20 19:02:55 -0600 )edit

Is the planner_frequency of move_base set to the default value of 0.0?If 0.0, this should be the behavior you want.

ref : http://wiki.ros.org/move_base#line-689

miura ( 2022-05-20 20:22:41 -0600 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2022-05-21 05:55:46 -0600

joao.aguizo
53 ●3 ●9 ●10

updated 2022-05-21 12:47:06 -0600

As @miura suggested you could start by looking into the planner_frequency parameter, although if this does not help you could try to look a bit further.

For example, do you see any sort of warning messages whenever the robot is moving towards a goal? If the answer to this question is yes, and the warnings are related with the control loops of the costmaps' planning, you could try to take a look into the these parameters. More specifically, the rate parameters of both your global and local cost maps. If these are too high, specially the local, the behavior you described could be justified.

Other parameters worth checking are the width, height and resolution of the aforementioned cost maps. Once more, if these are either too high (width and height) or to low (resolution), behaviors like the ones you described could be observed.

Keep in mind that in most cases global cost maps with high resolutions are not ideal since these will only be used to calculate a rough path to the target pose. This means that usually you should prefer to have bigger maps with lower resolution as your global, and smaller maps with higher resolution as your local, since the latter is the one that is actually used to execute the fine trajectory.

edit flag offensive delete link

Comments

Alright, thank you so much for the detailed response! I passed the last days doing some tests with the things you said to the robot.

Yes, there are a lot of warnings about rate when executing the navigation! It says the rate is fixed in 5.0Hz, when the adequate level would be around 0.3-0.7Hz. I tried changing its value in the parameters of the global costmap, local costmap and common costmap, but even when changing in all three to 0.4, the warning continued, still saying it was in 5Hz.

I tried changing the size of the costmap, too - the local costmap was around 4 meters, so I tried to change it to 2 and 3. The navigation got considerably slower the smaller the local costmap got, but it helped orientating the robot somewhat when the navigation stopped?

As for the planner_frequency_paramenter, I found out that it ...(more)

FFelizpe ( 2022-05-26 12:39:11 -0600 )edit

In any case, even with all these tests and discovering important stuff, the problem with the "hiccups" continue, and I don't know if there's more I can do. I suppose the problem was never the global planner rate, then, given it was already at zero?

FFelizpe ( 2022-05-26 12:39:33 -0600 )edit

That is a possibility, since according to the documentation it should only run the planner once whenever its value is set to that 0. Although, there might be other configurations worth checking. Could you edit your question with your current navigation configurations, as well as the exact warning string that you get from running those?

joao.aguizo ( 2022-05-26 16:30:56 -0600 )edit

There! Sorry for taking a while. Edited the question with the current configs, and the warning that applies when executing the navigation!

FFelizpe ( 2022-05-30 06:32:36 -0600 )edit

After taking a look into those, the first thing that called my attention was the resolution of both cost maps, their values are considerably low, specially considering your current setup. Remember that low values there equal to high resolutions, putting it other way, if you have a map with a size of 5x5 m^2, with a resolution of 1 m/cell you will have 25 cells; with your current values (0.05), for the same size, you will end up with 10000 cells per cost map (assuming that both are the same size). I do believe that this is the root of your current problem.

Other than that, I do not see anything inherently wrong. I will just leave you a question that might help you: Do you need to keep publishing / updating your global cost map?

OBS: On simpler use-cases, in which we have known maps a priori ...(more)

joao.aguizo ( 2022-05-30 11:40:09 -0600 )edit

add a comment

answered 2022-07-22 10:02:55 -0600

FFelizpe

51 ●6 ●7 ●9

Did some more stuff here, after resetting every parameter and starting from scratch, turns out the problem is probably because of how I'm clearing obstacles in the map - I have a clear_costmaps routine that's running every two seconds and probably causing a lot of processing issues with the robot.

I think that goes to its own thread with its own problems, though.

Thanks for everyone who helped! <3

edit flag offensive delete link

add a comment

How to reduce update rate of global planner on Navigation?

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

How to reduce update rate of global planner on Navigation? edit

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

How to reduce update rate of global planner on Navigation?