ROS Navigation Stack for Mobile Robots Technical Manual

The navigation stack is a powerful and reliable way to move from one place to another.

The job of the navigation stack is to process data from odometry and the environment map to produce a safe path for the robot to follow.

Maximizing the performance of this navigation stack requires some fine tuning, and it's not as easy as it seems.

If you don't have a clear understanding of the concepts and reasoning, you might try things haphazardly, which will waste a lot of time.

This article aims to guide readers to correctly fine-tune navigation parameters. When setting some key parameters, you need to know the "how" and "why".

This guide assumes that the reader has already set up the navigation stack and is ready to optimize. This is also a process I summarized in the ROS navigation stack.

text

1 Speed ​​and acceleration

This section deals with synchronously driven robots. Dynamics (i.e., velocity and acceleration of the robot) are essential for local planners including the dynamic window approach (DWA) and the timed elastic band (B).

In the ROS navigation stack, the local planner receives odometry messages (“odom” topic) and outputs velocity commands (“cmd_vel” topic) to control the robot’s motion.

Maximum/minimum speed and acceleration are two essential parameters of a mobile base station. Setting them correctly is very helpful for optimal local planning behavior.

To navigate in ROS, we need to know the translational and rotational velocities and accelerations.

1.1 Get the maximum speed

Usually you can refer to the manual of your mobile base station. For example, the maximum speed of SCITOS G5 is 1.4m/s.

In ROS, you can subscribe to the odom topic to get the current odometry.

If you can manually control your robot (such as via ), you can try running forward until a constant velocity is reached, then outputting the odometry data.

Translational speed (m/s) is the speed of the robot when it moves in a straight line. Its maximum value is the maximum value we obtained above.

The rotation speed (rad/s) is equivalent to the angular velocity, and its maximum value is the speed when the robot rotates into place.

To obtain the maximum angular velocity, we can rotate the robot 360° by controlling the joystick until its angular velocity reaches a constant value.

To be on the safe side, we tend to set the maximum translation and rotation speeds lower than their actual values.

1.2 Obtaining maximum acceleration

If the manual does not explain, there are a number of ways to get the maximum acceleration of a mobile base station.

In ROS, we can output the odometry data with a timestamp and see how long it takes for the robot to reach a constant maximum translational velocity ( ), and then use the acceleration from the odometry data ( nav_msgs/Odometry message) to calculate the acceleration during this process. Do this several times and average it out.

tt and tr are used to represent the time from static state to reach the maximum translation speed and the maximum rotation speed respectively.

The maximum translational acceleration is approximately equal to the maximum translational velocity divided by the time tt, and similarly, the maximum rotational acceleration is approximately equal to the maximum rotational velocity divided by the rotational time tr.

1.3 Setting the minimum value

The method for setting the minimum speed is different from the above. For the minimum translation speed, we set it to a large negative value, because this will make the robot move backwards when it gets stuck, even if it moves forward most of the time.

For the minimum rotation speed, we set it to a negative value if the parameters allow, so that the robot can rotate in any direction. Note that the DWA local planner uses the absolute value of the robot's minimum rotation speed.

1.4 Speed ​​in x and y directions

The x-speed is the speed parallel to the robot's linear motion, which is the same as the translation speed.

The velocity in the y direction is perpendicular to the linear motion and is called the “impact velocity”. For non-integral robots (such as differential wheel robots), the y velocity should be set to zero.

2 Global Path Planning

2.1 Selection of global path planning method

In order to use the move_base node in the navigation package, we need to have a global planner and a local planner. There are three global planners in the navigation package: the carrot planner, the navfn planner, and the global planner.

2.1.1 Carrot Planner

This is the simplest kind of planner. It checks if a given goal point is an obstacle, and if so, chooses an alternative goal that is close to the original goal by following the vector between the robot and the goal point.

Eventually it will give a valid goal point to the local planner or the interior. Therefore, this planner does not have any global path planning.

This approach is useful if you need the robot to get close to a given target even if it is out of reach, but it is not very practical in complex indoor environments.

2.1.2 navfn and the global planner

navfn uses dijkstra to find the least-cost route between the start and end points. The global planner establishes more flexible alternatives to navfn, including:

(1) Support A* algorithm (2) Switch to quadratic approximation (3) Switch to grid path. Both navfn and global planner are based on this paper:

https://cs.stanfd.edu/group/manips/publations/pdfs/Brock_1999_ICRA.pdf

2.2 Global Path Planning Parameters

Since the global planner is the more commonly used method, let's look at some of its key parameters.

Note: Not all parameters are available on the ROS web page, but you can view them by running rosrun rqt_reconfigure rqt_reconfigure.

We can set these defaults: allow unknown(true), use dijkstra(true), use quadrati c(true), use grid path(false), old navfn behavior(false) .

If we want to view the influence map in RVIZ we can set the visualize_potential value from FALSE to TRUE.

In addition to these parameters, there are three other parameters not listed that determine the performance of global path planning: cost_factor, neutral_cost, and lethal_cost.

In fact, these parameters are also mentioned in the navfn algorithm. This open source code explains in detail how navfn calculates these cost values.

https://github.com/rosplanning/navigation/blob/indigo-devel/navfn/include/navfn/navfn.h

The calculation method of navfn cost is as follows:

cost = COST_NEUTRAL + COST_FACTOR * costmap_cost_value

The cost value passed in is set in the range of 0 to 252. Further analysis:

When COST_NEUTRAL is 50, COST_FACTOR needs to be approximately 0.8 to ensure that the distribution of input values ​​causes the output values ​​to vary between 50 and 253.

If COST_FACTOR is high, the cost value will have a peak near the obstacle, and the planner will then consider the entire width of the narrow corridor as bad and will not follow the planned path.

Experimental Observations: These explanations are also confirmed by experiments. Setting the cost_factor too high or too low will degrade the path quality. These paths do not pass through the middle of the obstacles on each side, nor do they have relatively smooth curvature.

Extreme values ​​of COST_NEUTRAL have a similar effect. For critical cost values, setting them too low may result in no paths being generated, even when feasible paths are obvious.

Figure 5-10 shows the impact of COST_FACTOR and COS T_NEUTRAL on global path planning. The green line is the global path generated by the global planner. After several experiments.

We found that when COST_FACTOR=0.55, COST_NEUTRAL=66, cost=253, the global path is very good.

3 Local Path Planning

The local planners include the dwa local planner, the eband local planner, and the teb local planner.

They use different algorithms to generate velocity instructions. The dwa planner is the most commonly used, and we will discuss this algorithm in detail. Information about other planners will be provided later.

3.1 DWA Local Planner

3.1.1 DWA algorithm

The dwa local planner uses a dynamic window approach. The ROS wiki provides an introduction to the algorithm execution process:

1. Discretize the robot's control space (dx, dy, dtheta)

2. For each sampled speed, perform a forward from the robot’s current state to predict what would happen if the sampled speed were adopted in a short period of time

3. Evaluate each trajectory generated from the forward simulation using a metric that includes features such as: obstacle proximity, goal proximity, global path proximity, and speed, discarding illegal trajectories (trajectories that collide with obstacles)

4. Select the track with the highest score and send the associated speed to the mobile base station

5. Clear and repeat the above process. The DWA algorithm is a paper by Dieter Fox:

https://www.ri.cmu.edu/pub_files/pub1/fox_diet er_1997_1/fox_dieter_1997_1.pdf.

According to the paper, the goal of the DWA algorithm is to generate an action pair (v, w) that represents the optimal circular trajectory for the robot.

DWA achieves this by searching the velocity space over the next time interval.

The velocities in this space are constrained to be acceptable, meaning that the robot must be able to stop before reaching the nearest obstacle on the circular trajectory dictated by these acceptable velocities.

Furthermore, DWA will only consider velocities within a dynamic window, which is defined as the set of velocity pairs that are reachable within the next time interval given the current translational and rotational velocities and accelerations.

Now, let's look at the algorithm summary from the ROS Wiki. The first step is to sample velocity pairs (vx, vy, w) in velocity space within a dynamic window.