ROS-Based Autonomous Driving Planning and Control Framework with Apollo and Autoware Algorithm Integration
This repository provides a production-ready, modular autonomous driving planning and control framework built on ROS 1 (Melodic/Noetic) and ROS 2 (Foxy/Eloquent). It integrates core motion planning algorithms from Apollo (Lattice, EM Planner v3.5), Autoware (OpenPlanner), and widely adopted academic approaches—including Frenet-based sampling, hybrid A*, DWA, TEB, and lattice optimization—into a unified, extensible codebase.
The system supports both simulation and real-vehicle deployment. Key capabilities include:
- Multi-algorithm planning stack: Lattice planner with ST/SL obstacle projection, velocity sampling (cruise/following/overtaking), quadratic programming for trajectory optimization, and collision-aware cost synthesis.
- EM Planner implementation: Path generation via dynamic programming + QP smoothing, and speed profile optimization using DP+QP—configured for static single-obstacle avoidance (based on Apollo 3.5).
- Hybrid A* with motion primitives: Full path + velocity + curvature optimization for parking maneuvers; includes trajectory feasibility validation and basic controller tarcking support (PID/Pure Pursuit/LQR/Stanley/MPC).
- ROS-CARLA co-simulation: Bidirectional integration via
carla_ros_bridge(tested with CARLA 0.9.11 and 0.9.13), enabling closed-loop testing of planning modules in urban, intersection, and parking scenarios. - Lanelet2 map infrastructure: End-to-end workflow—from OSM import and JOSM-based lane editing to runtime loading and routing using Lanelet2 C++ APIs.
- Cross-platform support: Native compilation on Ubuntu 18.04/20.04 (bare metal only); ROS 2 components follow standard
colconbuild conventions and use modernrclcpppatterns.
All controllers expose standardized ROS interfaces: subscribers to /planning/trajectory, publishers to /control/cmd_vel or /vehicle/cmd_*. Sensor abstraction layers decouple planning logic from hardware—enabling seamlses migration from simulation to real vehicles by remapping topics (e.g., replace /sim_lidar/points with /lidar/points_raw and /sim_gps/fix with /gps/fix).
Example usage for launching the Lattice planner in ROS 2 Foxy:
# Build
cd ros2_ws && colcon build --packages-select lattice_planner
# Source and launch
source install/setup.bash
ros2 launch lattice_planner lattice_launch.py \
map_path:=/path/to/lanelet2_map.osm \
vehicle_param_file:=config/vehicle_kinematic.yaml
A corresponding ROS 1 Melodic example demonstrates how trajectory evaluation and safety checking are encapsulated:
// In trajectory_evaluator_node.cpp
void TrajectoryEvaluator::evaluateTrajectory(
const autoware_msgs::Trajectory& traj) {
double max_curvature = computeMaxCurvature(traj);
bool is_feasible = (max_curvature <= params_.max_curvature);
if (!is_feasible) {
RCLCPP_WARN(this->get_logger(),
"Trajectory rejected: curvature %.3f > limit %.3f",
max_curvature, params_.max_curvature);
return;
}
// Publish validated trajectory
pub_validated_traj_->publish(traj);
}
The framework intentionally avoids monolithic architecture. Each planner lives in its own package (lattice_planner, em_planner, hybrid_astar_planner) with clear dependency boundaries, enabling selective adoption and algorithm comparison. Simulation-ready launch files abstract environment-specific configuration (e.g., carla_sim.launch.py vs real_vehicle.launch.xml), while parameter YAML files separate vehicle dynamics, planner tuning, and sensor models.
For educational use, comprehensive documentation covers:
- Frenet frame derivation and reference-line smoothing (B-spline + curvature regularization)
- ST graph construction from dynamic obstacles and time-resolved collision checking
- Lattice trajectory synthesis pipeline: longitudinal sampling → lateral sampling → QP refinement → cost-weighted selection
- Hybrid A* state expansion with Dubins primitives and heuristic design (weighted Euclidean + orientation penalty)
- Lanelet2 routing API usage for topological path search and lane-change feasibility analysis
No Docker images are provided—environment setup relies on native package installation to ensure compatibility with hardware drivers and visualization tools like RViz2. All code is delivered as source; no binaries or obfuscated components are included.