This repository improves upon the work done previously on the sampling based planners in frenet frame. The improvements were done by Parv Maheshwari and Animesh Jha.
Here is a brief summary of the changes and improvements made in the planner:
- ROS Melodic and Gazebo 9 compatibility added
- Provisions for stopping the car have been added
- Reduced the time spent on generating a path (by 5-6 times) through parallel processing and other optimisations
- Fixed the issue of ghost obstacles caused due to faulty lidar data processing by car_demo
A short video of a demo run
This is an implementation for a sampling based planner in frenet frame. The original paper discusses about converting normal coordinate frame to frenet frame & sampling of paths, selecting the them based on cost associated with each path.
The planner has been tested in various environments. But is formed & found to be useful for high speed scenarios with minimal curves in path. This converts to highway scenario in the the physical world.
There are a lot of cases that require dynamic consideration of other traffic participants for complex maneuvers like merging into traffic flow, passing with on- coming traffic, changing lanes, or avoiding other vehicles.
Heuristics based planners sort all these quite easily. But in cases of time sparsity these planners don't perform well. So there in comes the concept of taking time 't' into consideration at planning & execution level. This is what the planner handles through taking maneuver time into account in sampling.
Based on whether you have Ubuntu 16 or 18, the packages you require changes. The first options are for Ubuntu 16 while the 2nd ones are for Ubuntu 18.
The following commands are to be run from your terminal:
$ roscore
$ roslaunch car_demo demo.launch
$ roslaunch frenet_planner frenet_planner.launch
$ python ~ catkin_ws/src/tracking_control/src/scripts/tracking_Methods/pure_pursuit.py
$ python ~ catkin_ws/src/tracking_control/src/scripts/controllers/PID_MIT_velocity_controller.py
The original paper doesn't take the vehicle dynamics(Max. Acceleration & Turning Radius) into account. We have implemented a check function to prevent generation of paths with yaw greater than turning radius of our car. But a mathematical approach to incorporate this in the cost is still to be thought of.
Currently we are iterating through the entire cost map for checking presence of obstacles. But this approach, though foolproof, isn't optimized & requires a lot of computation, specially in the urban environments.
Our main task for the planner is to find the best suited path. In the original paper this was done through sampling. But on close observation & after checking it's mathematical validity, we are trying to make an Reinforced Learning based model learn the same on it's own. This would thus reduce the computation by a lot while maintaining the stability of the planner.
- Original Paper
- Notes on the Paper
- Simple Python Implementation
- Video of simulation
Contributors: