TEB Tuning Guide
Timed Elastic Band (TEB) locally optimizes the robot's trajectory with respect to execution time, distance from obstacles and kinodynamic constraints at runtime.
Last updated
Was this helpful?
Timed Elastic Band (TEB) locally optimizes the robot's trajectory with respect to execution time, distance from obstacles and kinodynamic constraints at runtime.
Last updated
Was this helpful?
teb_local_planner
for navigationThis guide is for you if you choose to use teb_local_planner
to navigate your robots. For more information, .
Filepath: catkin_ws/movel_ai/config/movel/config/
File to modify: base_local_planner_params.yaml
Note that config files for local planner is located in the movel
package. In the yaml file itself, you see there are actually 3 local planners included. But we will only use one of them. Uncomment the entire long section under TebLocalPlannerROS
.
These are the parameters that can be configured. Will explain how to tune these parameters later.
Warn: yaml forbids tabs. Do not use tabs to indent when editing yaml files. Also, check your indentations align properly.
After configuring Seirios to use teb planner, you need to sync the velocity with maximum velocity specified by teb planner.
Filepath: catkin_ws/movel_ai/config/velocity_setter/config/
File to modify: velocity_setter.yaml
Check local_planner
match the name of the planner in the base local planner configuration. You are configuring the maximum velocities to be the maximum velocities you specified in teb planner.
rviz: Use the 2D Pose Estimator tool to pinpoint the location of your robot on the map. You can use LaserScan to help you – increase the Size (m) to at least 0.05 and try to match the lines from the LaserScan as closely as possible with the map.
Seirios: Go to Localize. Use either your keyboard or the joystick button to align the laser with the map as closely as possible.
Filepath: catkin_ws/movel_ai/config/movel/config/amcl.yaml
File to modify: amcl.yaml
Amcl configuration file is in the same directory as base_local_planner_params.yaml.
Similarly, there are a lot of paramters in the amcl file although we are only interested in these 2 parameters:
Configure min_particles
and max_particles
to adjust the precision.
teb_local_planner
parametersThis section provides some suggestions on what values to give to the long list of parameters for TebLocalPlannerROS. Go back to the same base_local_planner_params.yaml file.
Tuneable parameters can be grouped into the following categories
Robot
Goal Tolerance
Trajectory
Obstacles
Optimisation
Tune robot related params with respects to the configurations specified by the manufacturer. i.e. The values set for velocity and acceleration should not exceed the robot's hardware limitations.
Kinematics
vel
parameters limits how fast the robot can move. acc
parameters limits how fast robot can accelerate. _x
specifies linear kinematics whereas _theta
specifies angular kinematics.
Footprint Model
radius
is required for type: "circular"
vertices
is required for type: "polygon"
Specifies how much deviation from the goal point that you are willing to tolerate.
xy_goal_tolerance
is the acceptable linear distance away from the goal, in meters.
yaw_goal_tolerance
is the deviation in the robot's orientation. i.e. Goal specifies that the robot should face directly in front of the wall but in actual, the robot faces slightly to the left.
Decides how the robot should behave in front of obstacles.
Experimentation is required to tune the planner to approach obstacles optimally. A riskier configuration will allow the robot to move in obstacle ridden paths i.e. narrow corridors but it might get itself stuck around obstacles or bump into obstacles. A more conservative configuration might cause the robot to rule out its only available path because it thinks its too close to obstacles.
The tricky part is really to achieve a balance between those two scenarios.
min_obstacle_dist
is the minimum distance you want to maintain away from obstacles.
inflation_dist
is the buffer zone to add around obstacles.
Besides configuring obstacle handling behaviours in local planner, we can also configure the costmaps.
A costmap tells a robot how much does it cost to move the robot to a particular point. The higher the cost, the more the robot shouldn’t go there. Lethal obstacles that could damage the robot will have super high cost.
Filepath: catkin_ws/movel_ai/config/movel/config/
File to modify: costmap_common_params.yaml
File is in the same directory as base_local_planner_params
.
footprint
must match the measurements specified in base_local_planner_params.yaml.
You can choose to add some or all of the layers in the common_costmap_params
into global_costmap_params
and local_costmap_params
.
This layer inflates the margin around lethal obstacles and specifies how much bigger you want to inflate the obstacles by.
inflation_radius
is the radius, in meters, to which the map inflates obstacle cost value. Usually it is the width of the bot, plus some extra space.
cost_scaling_factors
is the scaling factor to apply to cost values during inflation.
The
inflation_radius
is actually the radius to which the cost scaling function is applied, not a parameter of the cost scaling function. Inside the inflation radius, the cost scaling function is applied, but outside the inflation radius, the cost of a cell is not inflated using the cost function.You'll have to make sure to set the inflation radius large enough that it includes the distance you need the cost function to be applied out to, as anything outside the inflation_radius will not have the cost function applied.
For the correct
cost_scaling_factor
, solve the equation there ( exp(-1.0 * cost_scaling_factor * (distance_from_obstacle - inscribed_radius)) * (costmap_2d::INSCRIBED_INFLATED_OBSTACLE - 1)), using your distance from obstacle and the cost value you want that cell to have.
Ideally, we want to set these two parameters such that the inflation layer almost covers the corridors. And the robot is moving in the center between the obstacles. (See figure below)
The obstacle layer marks out obstacles on the costmap. It tracks the obstacles as registered by sensor data.
For 2D mapping, laser_scan_sensor
must be selected.
obstacle_range
is the maximum distance from the robot that an obstacle will be inserted into the costmap. A value of 10 means the costmap will mark out obstacles that are within 10 meters from the robot.
raytrace_range
is the range in meters at which to raytrace out obstacles. The value must be set with respects to your sensors.
max_obstacle_height
is the maximum height of obstacles to be added to the costmap. Increase this number if you have very tall obstacles. The value must be set with respects to your sensors.
Voxel layer parameters
origin_z
is the z-origin of the map (meters)
z_resolution
is the height of the cube
z_resolution
controls how dense the voxels is on the z-axis. If it is higher, the voxel layers are denser. If the value is too low (e.g. 0.01), you won’t get useful costmap information. If you set z resolution to a higher value, your intention should be to obtain obstacles better, therefore you need to increasez_voxels
parameter which controls how many voxels in each vertical column. It is also useless if you have too many voxels in a column but not enough resolution, because each vertical column has a limit in height.
z_voxels
is the number of voxels
Low obstacle layer is obstacle layer, but with additional parameters. Change your observation_sources
to the topic that you want to take in data from.
Use obs_cloud
if you want a PointCloud (3D) or mock_scan
if you want a LaserScan (2D). Or you can specify your own method.
There are only two important parameters to note.
min_obstacle_height
is the height of the obstacle below the base of the robot. Examples includes stairs. Specify this param so that the robot can detect obstacles below its base link and prevent it from falling into the pit...
max_obstacle_height
is the maximum height of obstacle. It is usually specified as the height of the robot.
You WILL definitely be encountering some of the issues. Because param tuning requires experimentation, it is suggested you test out your values in the console first before modifying the yaml files.
rosrun rqt_reconfigure rqt_reconfigure
Issue #1: Problems getting the robot to go to the other side of the narrow path.
It is noted from observations that the robot will be returning goal failure, or that robot will get itself uncomfortably close to walls and get stuck there.
Issue #2: Problems getting the robot to turn 90 degrees.
The planner somehow disregards the wall and direct the robot to go through it instead of making a 90 degree turn around the wall. Though it seems most robots are smart enough to recognize they cannot go through walls and will either abort the goal or get stuck trying.
Solution #1: Reducing the velocity and acceleration. The intuition is that by slowing down the movement and rotation of the robot, the planner might have more time to react to the obstacle and plan accordingly.
Solution #2: (For robots that refuse to go to the other side of the corridor.)
Shrink the inflation_radius
in both costmaps so that it does not cover the corridor. (Right figure) Noted with observation that if the radius covers the entire corridor, robot may refuse to move.
External resources if you need more information about planners and tuning planners.
for more information.
Literally a footprint. Ideally, configure the footprint to be slightly bigger than the actual measurement of the robot. footprint_model
should be configured with respects to the robot's measurements.
You must indicate the type
of the robot footprint. Different types include polygon
, circular
, two_circles
, line
, point
etc. For simplicity sake, footprints are usually circular or polygon. for more footprint information.
for more information about obstacle avoidance and penalty. And for known problems with regards to obstacle avoidance tuning.
There are several layers added into the costmap. Usually we follow the specifications .
For the costmap layers that you have decided to use, you must mount the layers into global_costmap_params.yaml
and local_costmap_params.yaml
as plugins. for more information on the difference between global and local costmaps.
Additional information to configure it correctly (directly lifted from )
Voxels are 3D cubes that has a relative position in space. Can be used for 3D reconstruction with depth cameras. Ignore the parameters below if you are not using 3D. More information .