Fading Coder

One Final Commit for the Last Sprint

Home > Tech > Content

ROS-Based Autonomous Driving Planning and Control Framework with Apollo and Autoware Algorithm Integration

Tech Jun 21 1

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 colcon build conventions and use modern rclcpp patterns.

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.

Related Articles

Understanding Strong and Weak References in Java

Strong References Strong reference are the most prevalent type of object referencing in Java. When an object has a strong reference pointing to it, the garbage collector will not reclaim its memory. F...

Comprehensive Guide to SSTI Explained with Payload Bypass Techniques

Introduction Server-Side Template Injection (SSTI) is a vulnerability in web applications where user input is improper handled within the template engine and executed on the server. This exploit can r...

Implement Image Upload Functionality for Django Integrated TinyMCE Editor

Django’s Admin panel is highly user-friendly, and pairing it with TinyMCE, an effective rich text editor, simplifies content management significantly. Combining the two is particular useful for bloggi...

Leave a Comment

Anonymous

◎Feel free to join the discussion and share your thoughts.