README
mrpt_tps_astar_planner
Overview
This package provides a ROS 2 node that uses the PTG-based A* planner from
mrpt_path_planning to compute collision-free waypoint sequences for a
non-holonomic robot, respecting its real shape, orientation, and kinematic
constraints.
Planning is performed on a SE(2) lattice using Parameterized Trajectory
Generator (PTG) families that encode the robot’s motion primitives. The result
is published as a mrpt_msgs/WaypointSequence (and a nav_msgs/Path for
visualization) and/or returned as the response of a ROS 2 service call.
The node supports concurrent service requests: each executor thread owns a lazily-initialized planner instance, so multiple clients can request plans simultaneously without blocking each other.
How to cite
Configuration
Key configuration files passed as ROS 2 parameters:
Parameter |
Description |
|---|---|
|
INI file describing PTG families (robot kinematics) |
|
YAML file with A* algorithm parameters |
|
YAML file for costmap obstacle-inflation parameters |
|
YAML file for waypoint-preference cost weights |
Demos
See the path-planner-sandbox/ subdirectory for standalone test scripts and
sample maps.
Node: mrpt_tps_astar_planner_node
Working rationale
Obstacle data are maintained from subscribed gridmaps and/or point-cloud topics (updated asynchronously, protected by a mutex).
On each planning request (topic goal or service call) the node snapshots the current obstacle data, builds cost evaluators, and runs the A* planner.
The planned path is interpolated at a fixed time step and converted to a
WaypointSequence.
The A* implementation is an anytime algorithm: it improves the solution while
time allows, then returns the best found. An optional refinement pass
(astar_skip_refine: false) further smooths the result.
ROS 2 parameters
Parameter |
Default |
Description |
|---|---|---|
|
|
Open an MRPT 3D window showing maps and the planned path |
|
|
TF frame of the global map |
|
|
TF frame of the robot |
|
|
|
|
(empty) |
Comma-separated occupancy-grid topics for obstacles |
|
(empty) |
Comma-separated |
|
|
Subset of the above topics to subscribe with transient-local QoS |
|
|
Topic on which to publish the resulting waypoint sequence |
|
|
Prefix for costmap debug publishers |
|
(required) |
Path to PTG |
|
(required) |
Path to planner YAML file |
|
(required) |
Path to costmap YAML file |
|
(required) |
Path to waypoint-preference YAML file |
|
|
Extra margin [m] added around the planning bounding box |
|
|
If true, obstacle extents are excluded from the bounding box |
|
|
If true, skip the post-A* trajectory refinement pass |
|
|
Acceptance radius [m] for intermediate waypoints |
|
|
Acceptance radius [m] for the goal waypoint |
|
|
Whether intermediate waypoints may be skipped |
|
|
Whether the final waypoint may be skipped |
|
|
Whether heading is ignored at intermediate waypoints |
|
|
Whether heading is ignored at the final waypoint |
Subscribed topics
Topic |
Type |
Description |
|---|---|---|
|
|
Goal pose; triggers a plan from current TF robot pose |
|
|
Occupancy grid(s) used as static obstacles |
|
|
Point cloud(s) used as dynamic obstacles |
Published topics
Topic |
Type |
Description |
|---|---|---|
|
|
Full waypoint sequence with per-waypoint tolerances and flags |
|
|
Same path as |
|
|
Inflated costmaps (one per obstacle source), published after each plan |
Services
Service |
Type |
Description |
|---|---|---|
|
|
Plan from the current robot TF pose to a given goal |
|
|
Plan between two explicitly given |
Both services are registered in a reentrant callback group so multiple
clients can be served simultaneously by the MultiThreadedExecutor.
Template ROS 2 launch file
ros2 launch mrpt_tps_astar_planner tps_astar_planner.launch.py \
ptg_ini:=/path/to/ptgs.ini \
planner_parameters:=/path/to/planner-params.yaml \
global_costmap_parameters:=/path/to/costmap-obstacles.yaml \
prefer_waypoints_parameters:=/path/to/costmap-prefer-waypoints.yaml \
topic_obstacles_gridmap_sub:=/map \
topic_static_maps:=/map
All parameters have defaults in the launch file; only the config-file paths are typically required to be overridden for a real deployment.