teb_local_planner: Runtime Trajectory Optimization for ROS Robots

teb_local_planner's Place in ROS Local Navigation

teb_local_planner addresses the local planning stage of the ROS 2D navigation stack. It is not a complete navigation application and does not replace mapping, localization, global planning, or robot control. Instead, the C++ package implements a plugin for `base_local_planner`. A deployment still needs the surrounding ROS navigation components, a robot model, costmaps, localization data, and a controller capable of following the trajectory that the planner produces.

The package targets a limitation of path-only local planning. A sequence of collision-free points does not necessarily describe a motion that a particular robot can execute safely or promptly. According to the README, the Timed Elastic Band method locally optimizes the trajectory with respect to execution time, separation from obstacles, and compliance with kinodynamic constraints at runtime. Kinodynamic constraints connect robot kinematics and dynamics, so this distinction is relevant to platforms whose steering, speed, or turning behavior affects path feasibility.

The intended users are engineers developing mobile robots on ROS, particularly those working with non-holonomic or car-like platforms. The README links demonstrations set in simulation and on real robots. It also identifies version 0.2 examples for car-like robot support and costmap conversion. Those examples establish intended use cases, but they do not show that every geometry, sensor arrangement, or vehicle model works without configuration. The ROS wiki remains the documented source for complete setup instructions.

How the Timed Elastic Band Changes the Local Motion

The defining mechanism is online modification of a candidate robot trajectory. Rather than treating a geometric path as fixed, the Timed Elastic Band approach represents the motion as an optimizable sequence and modifies it while considering the current robot state, obstacles, timing, and motion constraints. The README specifically names trajectory execution time, obstacle separation, and compliance with kinodynamic constraints as optimization concerns.

Because the package plugs into `base_local_planner`, this optimization occurs inside the ROS 2D navigation architecture. The repository includes `cfg/`, `launch/`, `msg/`, `src/`, `include/`, `scripts/`, and `test/` directories. Those paths indicate that configuration, ROS interfaces, implementation code, launch assets, and automated tests are part of the project. The linked version 0.2 demonstration also refers to costmap conversion, but the README does not explain its data flow or conversion criteria.

The research record listed by the project covers online trajectory planning in distinctive topologies, sparse trajectory optimization, trajectory modification under dynamic constraints, multi-robot trajectory planning, and kinodynamic optimization for car-like robots. These topics clarify the design scope. They do not establish processing latency, convergence guarantees, or behavior under a specific obstacle density. The cleaned README gives no optimizer cycle time, numerical tolerance, failure mode, or recovery policy, so performance and failure behavior must be established against the actual configuration rather than inferred from the method name.

Installing teb_local_planner Through rosdep

The README gives a dependency-installation step but not a complete source-build tutorial. It directs users to install dependencies with `rosdep`. This command should run in a ROS development environment where `rosdep` and the intended ROS distribution are already available.

Use the documented command as follows:

rosdep install teb_local_planner

The command resolves dependencies declared through the ROS packaging system. The README identifies `package.xml` and `CMakeLists.txt` as the places where dependencies are listed. A successful dependency installation does not prove that the package will compile on a particular platform. Compilation also depends on the selected branch, installed ROS version, compiler environment, and optional third-party configuration.

There is an explicit branch question to settle before building. The repository default is `noetic-devel`, while the visible build-status text names `melodic-devel`. These branches target different ROS generations, so selecting a branch only by its name would be risky. The README does not give commands for cloning the repository, creating a catkin workspace, resolving the workspace, or launching the planner. Those steps must be taken from the linked ROS wiki or verified against the repository's own build files.

Preparing a First Local Planning Run

A first operational use takes place inside a ROS 2D navigation configuration because teb_local_planner is registered as a `base_local_planner` plugin. The README does not identify the launch filename, plugin-selection configuration key, required parameter file, robot footprint settings, or costmap names. Supplying guessed YAML would therefore be misleading.

The repository contents offer specific places to inspect next. `teb_local_planner_plugin.xml` exposes the plugin definition used by the ROS plugin infrastructure. Files under `cfg/` contain the package's parameter structure, while files under `launch/` contain launch assets. The package manifest and CMake configuration establish dependency and build requirements. An engineer should trace those files into an existing ROS navigation setup rather than assuming that installing the source package activates it automatically.

A useful first run must satisfy several conditions. The selected branch must match the target ROS distribution, dependencies from `package.xml` and `CMakeLists.txt` must be present, and the navigation configuration must load the plugin as a local planner. The robot configuration must describe the physical dimensions and motion behavior, while costmaps must expose obstacles relevant to local planning. The README shows that simulation and real-robot demonstrations exist, but it does not state their commands, required hardware, or parameter values. Those omissions prevent a complete executable example from being copied here without guessing.

teb_local_planner Failure Boundaries and Misuse Cases

The clearest misuse is expecting teb_local_planner to be a complete navigation system. The project targets local trajectory optimization within ROS. If the requirement includes map creation, localization, global route planning, task sequencing, or recovery management, another part of the navigation architecture must provide those capabilities. Installing teb_local_planner alone does not supply that broader system.

It is also a poor match for an offline trajectory-optimization library that will operate outside ROS. Although the Timed Elastic Band method and its supporting research are mathematically significant, the repository presents the implementation as a ROS package and exposes it through the ROS plugin ecosystem. The README does not promise a stable standalone API independent of ROS.

Robot compatibility presents another boundary. The project explicitly refers to car-like robot support and kinodynamic optimization, but it does not claim that any car-like robot works automatically. Wheelbase, steering behavior, velocity limits, footprint size, and costmap geometry can change the set of feasible trajectories. A planner can also fail to find a suitable solution when local constraints conflict or no trajectory meets the configured boundaries. The README does not document retry behavior, infeasibility reporting, or fallback logic, so these cases must be checked in configuration and observed in the target environment before deployment.

Alternative Local Planners and Their Design Difference

The direct alternative is another ROS `base_local_planner` plugin that follows an existing local path or applies a predefined local control rule. Such a plugin typically treats path following and local avoidance as the immediate task. teb_local_planner instead keeps a candidate trajectory flexible and modifies its shape and timing according to execution time, obstacle separation, and kinodynamic constraints.

This difference matters when a geometrically short route is unsuitable for the vehicle's turning limits, speed, or steering behavior. A time-aware optimization model can distribute movement across the trajectory rather than treating every segment as geometrically equal. The trade-off is additional configuration around objectives and robot behavior. The README does not provide resource measurements, so this article cannot claim that online optimization is faster, lighter, or more reliable than a fixed local-control method.

Another architecture is to generate a local geometric path and leave dynamic compliance entirely to a separate controller. That design keeps path generation and motion control separate. teb_local_planner incorporates dynamic and kinematic considerations during local trajectory optimization. Comparisons should therefore assess complete behavior, including obstacle clearance, trajectory execution, vehicle feasibility, and controller compatibility, rather than comparing path appearance alone.

Branch Currency, Releases, and Dependency Licenses

The repository is not archived, and the last push was on 2026-09-21. That indicates recent repository activity, but it does not establish a predictable release cadence. The only recent release listed is version 0.1.3 from 2015-05-20, while the README refers to features introduced in version 0.2. Readers should therefore distinguish branch activity from published releases and inspect `CHANGELOG.rst` when release-specific behavior matters.

Branch selection is part of upgrade work. The default branch is `noetic-devel`, but the visible build status names `melodic-devel`. A move between those targets can involve ROS APIs, dependency versions, platform packages, and configuration behavior. The repository includes `.travis.yml` and `.gitlab-ci.yml`, but the README does not define a release policy or upgrade procedure. Compatibility should therefore be checked from the target branch's build configuration rather than inferred from recent push activity.

teb_local_planner is licensed under BSD-3-Clause. The README says its ROS package dependencies are BSD licensed, while naming third-party components with separate terms. Eigen is identified as MPL2, Boost under the Boost Software License, and g2o as BSD, but the enabled `csparse_extension` is identified as LGPL3+. CSparse is also listed. This is not legal advice. A distributor should inspect the exact dependency versions, enabled features, and notices associated with the build, especially where `csparse_extension` is enabled.

Editorial conclusion

Adopt teb_local_planner when a ROS 2D navigation stack needs runtime trajectory optimization that accounts for execution time, obstacle separation, and robot motion constraints. Do not treat it as a standalone navigation system or assume that recent repository activity guarantees release maturity. Before adoption, verify compatibility with the selected ROS distribution, inspect the plugin and robot configuration, and confirm that the documented optimizer settings match the target platform.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. rst-tu-dortmund/teb_local_planner on GitHub