leo_navigationpackage first. To do this, start by accessing a remote terminal session on the Rover by logging via ssh:
leo_navigationpackage to the source space:
rosdepto install dependencies:
base_linkto frame ids associated with the sensor messages, available in the tf tree.
leo_navigationpackage and how to use them.
ekf_localization_nodewhich implements Extended Kalman Filter algorithm and the
ukf_localization_nodewhich implements Unscented Kalman Filter. We will use the first option as it is less computationally expensive but the latter is a more stable alternative.
odometry.launchfile and the connections between them:
leo_navigationpackage provides the
/wheel_odomtopic, publishes a message on the
/wheel_odom_with_covariancetopic which contains the same data but with an added covariance matrix,
/imu/gyromessages, publishes a message on
/imu/data_rawtopic which combines the two messages and adds covariance matrices.
ekf_localization_nodelistens for the
base_link->imutf transform to transform IMU readings to a common reference frame (
base_linkin this case).
/odometry/filteredtopic and the pose is also broadcasted as the
odom->base_linktransform. That's why, having the Fixed Frame set to
odomin RViz, you can see the model moving.
three_dargument set to
odometry.launchfile now changes a little:
/imu_filter_nodewhich takes messages from the
/imu/data_rawtopic (gyroscope and accelerometer data), calculates the orientation of the sensor and publishes the data with added orientation quaternion on the
/imu/datatopic. The node can also optionally incorporate the
/imu/magtopic (magnetometer data).
/ekf_localization_nodenow uses different configuration which takes the data from
/imu/datatopic and uses the orientation quaternion in the state estimation.
/message_filternode, there is the config/message_filter.yaml file in which you can change the values on the diagonals of the covariance matrices, which represent the variances (the uncertainty) of the measurements.
/ekf_localization_nodecan be found in the config/ekf_localization_node/ directory. There are two files: ekf_2d.yaml and ekf_3d.yaml. The appropriate file is chosen depending on the value of
3dargument passed to the launch file.
use_magparameter and want use the heading information (compass) in
/ekf_localization_node, just modify the
imu0_configparameter so that the yaw value is fused into the state estimate:
gmapping.launchfile is pretty straightforward:
/slam_gmappingnode takes as the input:
/gmappingnode can draw unnecessary resources for its mapping part. When map is no longer updated, it is more efficient to just use an algorithm that will only track robot's position against the map you have generated.
gmapping.launchinstance by clicking Ctrl+C on the terminal session it is running on. Then start
<path_to_the_map_file>with the absolute path to the mymap.yaml file. If the file is in your current working directory, you can instead type:
/amcltakes the laser range data (
/scantopic) as input and provides the odometry drift information by broadcasting the
map->odomtransform. The difference is that instead of publishing to the
/maptopic, it receives the (previously generated) map from the
/amcl_pose− estimated pose of the robot within a map, with covariance,
/particlecloud− a set of pose estimates being maintained by the Monte Carlo localization algorithm.
AMCL Poseand/or the
AMCL Particle Clouddisplays in RViz.
map_update_interval− control how often to update the map.
temporalUpdate− control when to process new laser scans.
particles− increasing this number may improve the quality of the map at the cost of greater computational load.
minimumScore− you can experiment with this parameter if you are experiencing jumping pose estimates in large open spaces.
maxRange− try to set these parameters like this:
maxUrange< maximum range of your LiDAR sensor <=
delta− increasing this will lower the resolution of the map but may improve performance.
max_particles− higher number of particles may increase the accuracy of the estimates at the cost of computational load.
update_min_a− control when to perform filter updates.
initial_pose_a− initial mean pose used to initialize the filter.
laser_max_beams− you can experiment with this parameter. Higher number may increase the accuracy at the cost of computational load.
/move_basenode's inputs include:
/move_basenode can receive navigation goals in 2 ways:
/move_base_simple/goaltopic − upon receiving a PoseStamped message on this topic, the node will cancel any running operation and try to reach the new destination. This is how the 2D Nav Goal tool in RViz sends the pose selected by the user.
/twist_muxnode chooses which topic with velocity commands to forward to the
/cmd_veltopic. If no messages are sent on
/nav_cmdwill be selected. To utilize the other topics when using a joystick or the Web UI, you need to make sure the velocity commands from these components are published on corresponding topics.
cmd_vel_topicargument to the launch file:
ui_velin the /opt/leo_ui/js/leo.js file on your rover. You might also need to clear the cache data on your browser.
/move_basenode as a black box to which we send navigation goals and get velocity commands in return. This is fine to start with, but if you want to fine-tune configuration for your environment, you might need to know about various components of
move_baseand how do they work with each other. This will help you to understand the meaning behind the parameters.
/maptopic) and marks cells in the costmap as either "Unknown", "Freespace" or "Lethal" depending on the value of corresponding pixels on the map.
global_costmap− used for creating long-term plans over the entire environment. Combines all 3 defined layers and runs in the
local_costmap− used for local planning and obstacle avoidance. Utilizes only the Obstacle and Inflation layers. Uses the "Rolling Window", meaning that it will remain centered around the robot as it moves to represent only the local surroundings. Runs in the
odomcoordinate frame to guarantee that the pose of the robot in the map will be continuous.
/move_basenode uses components that have their own ROS APIs, the configuration has been split into multiple files to make it more modular. There is a total of 6 files under the config/move_base/ directory. Here is a short description of each file and some parameters you can try to adjust:
controller_frequency– increasing this may improve the response time, but be careful not to violate the real-time constraint.
clearing_rotation_allowed– you may want to disable clearing rotations when debugging the local planner.
conservative_reset_dist– smaller values will clean more space on Conservative reset.
footprint– if you have mounted additional equipment to your rover that expands the outer dimensions of the robot, you should modify this parameter.
obstacle_layer/obstacle_range– set it to the usable range of your LiDAR sensor.
obstacle_layer/raytrace_range– set it slightly larger than the usable range of your sensor but smaller than the maximum range.
obstacle_layer/scan/expected_update_rate– set it slightly larger than the update rate of your sensor (time between scan messages).
inflation_layer/inflation_radius– larger values will make the planners prefer paths more distant from the obstacles but can make it difficult to travel through narrow corridors.
inflation_layer/cost_scaling_factor– let's you control how the cost values decrease with distance. Larger values will make the cost decay function more steeper.
update_frequency– increasing it improves the response time to obstacles but affects performance.
publish_frequency– higher values will make RViz visualization more responsive at the cost of increased network throughput.
update_frequency– as above.
publish_frequency– as above.
height– let's you control how much of the local surroundings to remember.
resolution– smaller values will make the map more precise at the cost of increased size.
default_tolerance– you can set it if there is a possibility of an obstacle in the goal position.
use_dijkstra– setting this to
falsewill make the Global Planner use A* algorithm for path searching which is more efficient than Dijktra but may not find the optimal path. Useful in very large maps.
xy_goal_tolerance– a too small value can make the robot oscillate in goal position.
yaw_goal_tolerance– you can increase it if you don't care that much about the resulting orientation of the rover.
occdist_scale– these parameters may require some trial and error to fine-tune them to your environment.