ROS Navigation-----Navigation function package set and configuration Learning __ Navigation feature Package set

This paper mainly introduces the configuration and use of navigation function package set.

1 Robot Setup

Assuming that we have set up the robot in a specific way, the navigation feature pack set will make it available for movement. This configuration is outlined in the figure above. The white part is the required and implemented component, the gray part is optional and implemented , and the blue part is the component that must be created for each robot platform.

1.1 ROS

The navigation Feature Pack set assumes that your robot uses the ROS system. Check out the ROS documentation to learn how to install Ros on your robot.

1.2 tf Transformation Configuration (other transformations)

The navigation Feature Pack set requires the robot to continually use TF to publish information about the relationship between coordinate systems. For a detailed configuration tutorial consult: TF configuration.

1.3 Sensor information (sensor source)

The navigation feature package uses information from the sensor to implement obstacles in the physical environment, and assumes that these sensors are constantly releasing Sensor_msgs/laserscan messages or Sensor_msgs/pointcloud messages on Ros. For a tutorial on releasing these messages on Ros, consult the release of sensor data streams on Ros. The following are some of the sensors already supported by Ros and related driver links:

Scip2.2-compliant Hokuyo Laser Devices as the Hokuyo Model 04LX, 30lx-urg_node (English)

SICK lms2xx Lasers-sicktoolbox_wrapper (English)

1.4 Mileage information (odometry source)

The navigation Feature Pack sets need to use mileage information published through TF and nav_msgs/odometry messages. Here's a tutorial on how to publish mileage information: Release mileage information on Ros. The following are some of the platforms that support the mileage meter and the available drivers:

Videre Erratic:erratic_player (English)

Pr2:pr2_mechanism_controllers (English)

1.5 Pedestal Controller (base controller)

The navigation Feature Pack sets the geometry_msgs/twist type of message on the "Cmd_vel" topic to reach the base to send the speed command to control the base movement. This means that there must be a node subscribing to the "Cmd_vel" topic, the speed information on the topic is (VX, VY, Vtheta) <===> (cmd_vel.linear.x, Cmd_vel.linear.y, Cmd_ VEL.ANGULAR.Z), and can convert these velocity information to the control motor by the command sent to the mobile pedestal.

The following is a partial support platform for the base controller and the available drivers:

Videre Erratic:erratic_player (English)

Pr2:pr2_mechanism_controllers (English)

1.6 Map (map_server)

Although the navigation Feature Pack set configuration does not need to operate the map, but given the following use case, we assume you have a map. If you do not consult the tutorial create a map to learn how to create a map in your system environment details.

2 navigation feature package set settings

This section describes how to configure the Navigation Feature Pack set. Assume that all of the required environments are met. A special reminder here is that the robot must be able to publish coordinate frames using TF to receive Sensor_msgs/laserscan or Sensor_msgs/pointcloud messages from the sensor for use in the navigation function package. can use TF and nav_msgs/odometry messages to publish mileage messages, and can also accept speed commands and send to the base. If you don't have any of these configurations, refer to the robot configuration above to complete them.

2.1 Create a package

First, we create a package to save the configuration files and startup files that are required to use the navigation feature package set. This package relies on some other packages for implementing the Robot configuration section and provides a move_base package for the navigation feature package set access interface.

Now select the location for your package and execute the following command:

Catkin_create_pkg my_robot_name_2dnav move_base my_tf_configuration_dep my_odom_configuration_dep my_sensor_ Configuration_dep

2.2 Creating a robot startup profile

Now that we have a workspace for the configuration and startup files, we will create a roslaunch file to start all the hardware and release the TF required by the robot. Please paste the following to My_robot_configuration.launch. You can change "My_robot" to the name of your robot. You can also make similar changes to the launch files you use below.

<launch>
  <node pkg= "sensor_node_pkg" type= "Sensor_node_type" name= "Sensor_node_name" output= "screen" >
    <param name= "Sensor_param" value= "Param_value"/>
  </node>

  <node pkg= "Odom_node_pkg" "Type=" Odom_node_type "name=" Odom_node "output=" screen ">
    <param name=" Odom_param "value=" Param_value "/ >
  </node>

  <node pkg= "transform_configuration_pkg" type= transform_configuration_type "Name=" Transform_configuration_name "output=" screen ">
    <param name=" Transform_configuration_param "value=" param _value "/>
  </node>
</launch>

OK, now we have a launch file template, but we need to refine it according to our own robot. The following chapters, we will gradually change it.

  <node pkg= "sensor_node_pkg" type= "Sensor_node_type" name= "Sensor_node_name" output= "screen" >
    <param Name= "Sensor_param" value= "Param_value"/>
  </node>

The above node starts the sensor that the robot needs to run the navigation function pack. Replace "Sensor_node_pkg" with the Ros-driven package of your sensor, replace "Sensor_node_type" with your sensor type (usually the same as the node name), and replace "Sensor_node_name" with your sensor section names. Sensor_param "contains all the required parameters. Note that if you have multiple sensors, define them together here.

  <node pkg= "odom_node_pkg" type= "Odom_node_type" name= "Odom_node" output= "screen" >
    <param name= "Odom_" Param "value=" param_value "/>
  </node>

Above we start the base (chassis) mileage meter. Similarly, replace the corresponding pkg, type, name, and specify the relevant parameters according to the actual.

  <node pkg= "transform_configuration_pkg" type= transform_configuration_type "Name=" Transform_configuration_name "output=" screen ">
    <param name=" Transform_configuration_param "value=" Param_value "/>
  </node >

Above we start the corresponding TF transformation. Similarly, replace the corresponding pkg, type, name, and specify the relevant parameters according to the actual.

2.3 Configuration Cost Map (LOCAL_COSTMAP) & (Global_costmap)

The navigation Feature Pack set requires two cost maps to preserve the real-world barrier information. A cost map is used to create long-term planning throughout the environment, and another for local planning and real-time avoidance. There are some parameters two maps are needed, while some are different. Therefore, for cost maps, there are three configuration items: Common configuration items, global configuration items, and local configuration items.

Note: The next item is just the basic configuration of the cost map. To see the full configuration, refer to the costmap_2d documentation.

2.3.1 Co-configuration (Local_costmap) & (Global_costmap)

The navigation Feature Pack set uses the cost map to store the obstacle information. Here we need to point out the topic of the sensor to monitor to update the data.

To do this we create a file called Costmap_common_params.yaml, which reads as follows:

obstacle_range:2.5
raytrace_range:3.0
footprint: [[X0, y0], [x1, y1], ... [Xn, yn]]
#robot_radius: Ir_of_robot
inflation_radius:0.55

observation_sources:laser_scan_sensor point_cloud_ Sensor

Laser_scan_sensor: {sensor_frame:frame_name, Data_type:laserscan, Topic:topic_name, Marking:true, Clearing:true}

point_cloud_sensor: {sensor_frame:frame_name, Data_type:pointcloud, Topic:topic_name, marking: True, clearing:true}

The above code explains the following:

obstacle_range:2.5
raytrace_range:3.0

These parameters set the threshold value of the barrier information for the cost map. The "Obstacle_range" parameter determines the maximum range of sensor probes that introduce obstacles to cost maps . Here, we set it to 2.5 meters, which means that the robot will only update the barrier information to the cost map with its chassis as the center radius of 2.5 meters. The "Raytrace_range" parameter is used to remove the obstructions in the range of the robot during the moving process in order to obtain free moving space . Setting it to 3.0 meters means that the robot will be based on sensor data to try to remove obstacles in the space 3.0 meters ahead of it to gain free space.

Footprint: [[X0, y0], [x1, y1], ... [Xn, yn]]
#robot_radius: Ir_of_robot
inflation_radius:0.55

Here we set the footprint of the robot or the radius of the robot (if it is circular). When the footprint is specified, the center of the robot is considered to be the origin (0.0,0.0), which is supported by both clockwise and counterclockwise specifications. The geometric parameters of the robot are told to the navigation function package set. In this way, the robot can maintain a reasonable distance from the obstacle, that is to say, there is a door in front, to detect whether the robot can penetrate the door in advance. We will also set the cost map expansion radius Inflation_radius The minimum distance that must be maintained between the robot and the obstacle. According to the inscribed radius of the robot, the expansion process of the obstacle is carried out. For example, the expansion radius set at 0.55 meters means that the robot remains 0.55 meters or more away from the obstacles in all paths.

Observation_sources:laser_scan_sensor Point_cloud_sensor

The "observation_sources" parameter defines a series of sensors that transmit spatial information to the cost map.

Laser_scan_sensor: {sensor_frame:frame_name, Data_type:laserscan, Topic:topic_name, Marking:true, clearing:true}

This line sets the sensor mentioned in "Observation_sources". This example defines the laser_scan_sensor. The "frame_name" parameter should be set to the name of the sensor coordinate frame, and the "data_type" parameter should be set to Laserscan or Pointcloud, depending on the message used by the theme, and "topic_name" should be set to the name of the subject that publishes the sensor data. The "marking" and "clearing" parameters determine whether the sensor is used to add obstacle information to the cost map, or to remove the barrier information from the cost map, or both.

2.3.2 Global Configuration (GLOBAL_COSTMAP)

Below we will create a file that stores the specific global cost map configuration options. Create a new file: Global_costmap_params.yaml and paste the following:

Global_costmap:
  global_frame:/map
  robot_base_frame:base_link
  update_frequency:5.0
  static_map: True

The "Global_frame" parameter defines the coordinate system in which the cost map is run. In this case, we will select the/map coordinate system. The "Robot_base_frame" parameter defines the robot base coordinate system for the reference of the cost map. Global_costmap and Robot_base_frame define the coordinate transformation between the robot and the map, and the global cost map must use this transform. The "update_frequency" parameter determines how often the cost map is updated. The "Static_map" parameter determines whether the price map is initialized according to the map provided by Map_server. If you don't use the existing map, set it to false.

2.3.3 Local Configuration (LOCAL_COSTMAP)

Below we will create a file that stores the map configuration for specific local costs. Create a new file: Localal_costmap_params.yaml and paste the following:

Local_costmap:
  global_frame:odom
  robot_base_frame:base_link
  update_frequency:5.0
  publish_ frequency:2.0
  static_map:false
  rolling_window:true
  width:6.0
  height:6.0
  resolution:0.05

"Global_frame", "Robot_base_frame", "update_frequency", "static_map" parameters have the same meaning as the global configuration. The "publish_frequency" parameter determines how often a cost map publishes visual information. Setting the "Rolling_window" argument to true means that as the robot moves in the real world, the cost map will remain robot-centric without scrolling through the window. "width", "height", "Resolution" parameter set the price map width (m,) height (m) and resolution (M/unit) respectively. Note that the resolution here may differ from the resolution of your static map, but we usually set them to the same.

2.3.4 Complete configuration options

Here is the simplest configuration for startup and running, more cost map setup details see the costmap_2d documentation.

2.4 Base Local planner configuration

Base_local_planner is responsible for calculating the speed command to be sent to the robotic base according to the high-level planning. We need to configure some options to start and run normally according to our robot specifications.

Create a new file named Base_local_planner_params.yaml, which reads as follows:

Note: This section covers only some of the basic configuration options for the amount Trajectoryplanner. All the options for the document, see the Base_local_planner documentation.

Trajectoryplannerros:
  max_vel_x:0.45
  min_vel_x:0.1
  max_vel_theta:1.0
  Min_in_place_vel_theta: 0.4

  acc_lim_theta:3.2
  acc_lim_x:2.5
  acc_lim_y:2.5

  holonomic_robot:true

The first part of the above parameter defines the speed limit of the robot. The second part defines the limit of the robot's acceleration. Holonomic_robot: If your robot is a omnidirectional mobile robot then this value is true and the difference is false.

2.5 Create a startup file for the Navigation Feature Pack set

Now that we have all the profiles, I can use the configuration file created earlier to create a startup file for the Navigation Feature Pack set , and create a file named Move_base.launch that reads as follows:

 <launch> <master auto= "Start"/> <!--Run the map server--> <node name= "Map_server" 
  Map_server "type=" Map_server "args=" $ (find my_map_package)/my_map.pgm my_map_resolution "/> <!---Run AMCL--> <include file= "$ (find amcl)/examples/amcl_omni.launch"/> <node pkg= "move_base" type= "Move_base" respawn= "f Alse "Name=" move_base "output=" screen "> <rosparam file=" $ (find My_robot_name_2dnav)/costmap_common_ Params.yaml "command=" Load "ns=" Global_costmap "/> <rosparam file=" $ (find My_robot_name_2dnav)/costmap_common_ Params.yaml "command=" Load "ns=" Local_costmap "/> <rosparam file=" $ (find My_robot_name_2dnav)/local_costmap_ Params.yaml "command=" Load "/> <rosparam file=" $ (find My_robot_name_2dnav)/global_costmap_params.yaml "command = "Load"/> <rosparam file= "$ (find My_robot_name_2dnav)/base_local_planner_params.yaml" command= "Load"/> &l T;/node> </launch> 

The only place you need to modify is to change the map server point to your existing map, and if you have a differential-driven robot, change "Amcl_omni.launch" to "Amcl_diff.launch".

For how to create a map, consult the Create a map.

2.6 amcl configuration (AMCL)

AMCL There are many configuration options that affect positioning performance. For more information about AMCL, see the AMCL documentation.

Using Adaptive Monte Carlo localization (AMCL) algorithm to locate robot, this method is a probabilistic statistic method of mobile robot in 2D environment, and the realization of this method in Ros system is to track the pose of robot by using particle filtering algorithm on the basis of known map. If you do not set the initial pose through the 2D Pose estimate button in the Rviz, then AMCL assumes that your robot will start at the origin of the coordinates. This packet default LiDAR data, you can also modify the source code, adapt to such as binocular sensors. Amcl_diff.launch is designed to support a differential-driven robotic platform.
3 running Navigation function pack set

Now that the configuration is over, we can run the set of navigation feature packs. For this we need to start two terminals on the robot. On one terminal, we will run the My_robot_configuration.launch file on the robot setup, and on the other end we will start the move_base.launch that we just created for the navigation function.

Terminal 1:

Roslaunch My_robot_configuration.launch

Terminal 2:

Roslaunch Move_base.launch

Refer to the Rviz and navigation tutorials on how to send target information to the navigation feature set through a graphical interface. If you want to use code to send navigation targets to the navigation feature pack set, see Send a simple navigation target tutorial.

4 Troubleshooting