table of Contents
8 Navigation
Navigation is one of the most basic functions of robots. ROS provides us with a complete set of Navigation solutions, including global and local path planning, cost maps, abnormal behavior recovery, and map servers. This function is placed in the Navigation Stack ROS metapackage, which contains packages for path planning, positioning, maps, and abnormal behavior recovery.
| Package names |
Features |
| amcl |
Positioning |
| fake_localization |
Positioning |
| map_server |
Provide a map |
| move_base |
Path planning node |
| nav_core |
Interface classes for path planning, including base_local_planner, three interfaces base_global_planner and recovery_behavior |
| base_local_planner |
Implemented two local planning algorithms, Trajectory Rollout and DWA |
| dwa_local_planner |
Reimplemented DWA local planning algorithm |
| parrot_planner |
Implemented a simpler global planning algorithm |
| navfn |
Implemented Dijkstra and A * global planning algorithms |
| global_planner |
Reimplemented Dijkstra and A * global planning algorithms |
| clear_costmap_recovery |
Realize the recovery behavior of clearing the cost map |
| rotate_recovery |
Realizes the recovery behavior of rotation |
| move_slow_and_clear |
Achieves slow-moving recovery behavior |
| costmap_2d |
Two-dimensional cost map |
| voxel_grid |
Three-dimensional small square |
| robot_pose_ekf |
Kalman filtering of robot pose |
8.1 Navigation working framework
Enter:
- / tf: The tf provided by the feed includes map_frame, odom_frame, base_frame and a complete tf tree between each joint of the robot.
- / odom: odometer information
- / scan or / pointcloud: The input information of the sensor, the most commonly used is the laser radar (sensor_msgs / LaserScan type), and also has point cloud data (sensor_msgs / PointCloud).
- / map: The map can be provided by the SLAM program, or a known map can be specified by map_server.
The above four topics must be continuously provided to the navigation system. The following is a topic that can be published at any time:
- move_base_simple / goal: target point location.
Output:
- / cmd_vel: geometry_msgs / Twist type, the speed information planned for each moment. The format is as follows:
geometry_msgs/Vector3 linear
float64 x
float64 and
float64 with
geometry_msgs/Vector3 angular
float64 x
float64 and
float64 with
Service provided by move_base :
- make_plan: nav_msgs / GetPlan type, the request is a target point, and the response is a planned trajectory, but the trajectory is not executed.
- clear_unknown_space: std_srvs / Empty type, allowing users to clear the map of unknown areas.
- clear_costmaps: std_srvs / Empty type, allowing users to clear obstacles on the cost map.
8.2 move_base
move_base is the core node in Navigation, it is in a dominant position in the navigation task, and some other packages are its plug-ins.
To move_base to run, you need to choose a plug-in, including three plug-ins: base_local_planner, base_global_planner and recovery_behavior, these three plug-ins must be specified, otherwise the system will specify the default value. Navigation provides us with a lot of candidate plugins, which can be selected when configuring move_base.
base_local_planner plugin:
- base_local_planner: implements two local planning algorithms, Trajectory Rollout and DWA
- dwa_local_planner: Implemented DWA local planning algorithm, which can be seen as an improved version of base_local_planner
base_global_planner plugin:
- parrot_planner: implements a simpler global planning algorithm
- navfn: implemented Dijkstra and A * global planning algorithms
- global_planner: Reimplemented Dijkstra and A * global planning algorithms, which can be seen as an improved version of navfn
recovery_behavior plugin:
- clear_costmap_recovery: implements the recovery behavior of clearing the cost map
- rotate_recovery: implements the recovery behavior of rotation
- move_slow_and_clear: A slow-moving recovery behavior is achieved
costmap plugin:
The plug-in has been selected by default. The default is costmap_2d, which cannot be changed.
Plug-in can be selected in the parameter setting of move_base. Because there are too many parameters to configure, the configuration is usually written in a yaml file. We use param / move_base_params.yaml to save the above parameters.
8.3 Costmap
The map in ROS is the topic / map. It is also a picture. One pixel represents the actual area, and the gray value is used to indicate the possibility of obstacles. However, in actual navigation tasks, it is not enough to have a map. The robot needs to be able to dynamically add obstacles, or clear obstacles that no longer exist, and sometimes mark dangerous areas on the map to plan the route. Provide more useful information.
Because of the need for navigation, a cost map appears. The cost map can be understood as the addition of several maps on top of / map, which not only contains the original map information, but also adds other auxiliary information.
The cost map has the following characteristics:
1. First of all, there are two cost maps, one is local_costmap and one is global_costmap, which are used for local path planner and global path planner, respectively, and these two costmaps are default and can only select costmap_2d as a plug-in.
2. Whether it is local_costmap or global_costmap, you can configure their Layer, you can choose multiple levels.
The costmap Layer includes the following:
- Static Map Layer: Static map layer, usually a static map created by SLAM.
- Obstacle Map Layer: Obstacle map layer, used to dynamically record the obstacle information sensed by the sensor.
- Inflation Layer: Inflation layer, inflate (expand outward) on the above two layers of map to avoid the robot's outer layer
- The shell will hit an obstacle.
- Other Layers: You can also implement costmap yourself in the form of plug-ins. Currently, Social Costmap
- Open source plugins such as Layer and Range Sensor Layer.
You can select multiple Layers to coexist at the same time.
The costmap configuration is also saved with yaml. Since costmap is usually divided into local and global coastmap, we are used to separate the two cost maps.
8.4 map_server
In a fixed scenario, we already know the map (whether through SLAM or measurement), so that the robot can best load the known map directly every time it starts, rather than rebuilding every time it is turned on. In this case, you need to have a node to publish / map to provide scene information. map_server is such a function package, which can publish known maps for navigation and other functions, and can also save the maps created by SLAM.
To make map_server publish / map, you need to input two files to it:
- Map files, usually in pgm format;
- Map description file, usually in yaml format
With the above two files, you can load this map through instructions, map_server related commands are as follows:
- rosrun map_server map_server Software_Museum.yaml loads a custom map
- rosrun map_server map_saver -f mymap save the current map as mymap.pgn and mymap.yaml
map_server will provide the following topics and services:
- Topic
- / map_metadata: Publish map description information
- / map: Publish the latched map message
- Service
- static_map: Used to request and respond to the current static map.
Param: map_server has a parameter that needs to be set, which is the frame for publishing the map.
~ frame_id: string type, default is map. Which frame in the tf to bind the published map to is usually the map.
8.5 AMCL positioning
Adaptive Mentcarto Localization (AMCL): Monte Carlo adaptive positioning is a very commonly used positioning algorithm, which locates by comparing detected obstacles with known maps.
The communication architecture on AMCL is as follows:
Much like the previous SLAM framework, the main difference is that / map is used as an input, not an output, because the AMCL algorithm is only responsible for positioning, regardless of building maps.
