Goal Planner design#
Purpose / Role#
Plan path around the goal.
- Arrive at the designated goal.
- Modify the goal to avoid obstacles or to pull over at the side of the lane.
Design#
If goal modification is not allowed, park at the designated fixed goal. (fixed_goal_planner
in the figure below)
When allowed, park in accordance with the specified policy(e.g pull over on left/right side of the lane). (rough_goal_planner
in the figure below). Currently rough goal planner only support pull_over feature, but it would be desirable to be able to accommodate various parking policies in the future.
start condition#
fixed_goal_planner#
This is a very simple function that plans a smooth path to a specified goal. This function does not require approval and always runs with the other modules. NOTE: this planner does not perform the several features described below, such as "goal search", "collision check", "safety check", etc.
Executed when both conditions are met.
- Route is set with
allow_goal_modification=false
. This is the default. - The goal is set in the normal lane. In other words, it is NOT
road_shoulder
. - Ego-vehicle exists in the same lane sequence as the goal.
If the target path contains a goal, modify the points of the path so that the path and the goal are connected smoothly. This process will change the shape of the path by the distance of refine_goal_search_radius_range
from the goal. Note that this logic depends on the interpolation algorithm that will be executed in a later module (at the moment it uses spline interpolation), so it needs to be updated in the future.
rough_goal_planner#
pull over on road lane#
- The distance between the goal and ego-vehicle is shorter than
pull_over_minimum_request_length
. - Route is set with
allow_goal_modification=true
.- We can set this option with SetRoute api service.
- We support
2D Rough Goal Pose
with the key bindr
in RViz, but in the future there will be a panel of tools to manipulate various Route API from RViz.
- ego-vehicle is in the same lane as the goal.
pull over on shoulder lane#
- The distance between the goal and ego-vehicle is shorter than
pull_over_minimum_request_length
. - Goal is set in the
road_shoulder
.
finish condition#
- The distance to the goal from your vehicle is lower than threshold (default: <
1m
). - The ego-vehicle is stopped.
- The speed is lower than threshold (default: <
0.01m/s
).
- The speed is lower than threshold (default: <
General parameters for goal_planner#
Name | Unit | Type | Description | Default value |
---|---|---|---|---|
th_arrived_distance | [m] | double | distance threshold for arrival of path termination | 1.0 |
th_stopped_velocity | [m/s] | double | velocity threshold for arrival of path termination | 0.01 |
th_stopped_time | [s] | double | time threshold for arrival of path termination | 2.0 |
center_line_path_interval | [m] | double | reference center line path point interval | 1.0 |
Goal Search#
To realize pull over even when an obstacle exists near the original goal, a collision free area is searched within a certain range around the original goal. The goal found will be published as /planning/scenario_planning/modified_goal
.
-
The original goal is set, and the refined goal pose is obtained by moving in the direction normal to the lane center line and keeping
margin_from_boundary
from the edge of the lane. -
Using
refined_goal
as the base goal, search for candidate goals in the range of-forward_goal_search_length
tobackward_goal_search_length
in the longitudinal direction andlongitudinal_margin
tolongitudinal_margin+max_lateral_offset
in th lateral direction based on refined_goal. -
Each candidate goal is prioritized and a path is generated for each planner for each goal. The priority of a candidate goal is determined by its distance from the base goal. The ego vehicle tries to park for the highest possible goal. The distance is determined by the selected policy. In case
minimum_longitudinal_distance
, sort with smaller longitudinal distances taking precedence over smaller lateral distances. In caseminimum_weighted_distance
, sort with the sum of weighted lateral distance and longitudinal distance. This means the distance is calculated bylongitudinal_distance + lateral_cost*lateral_distance
The following figure is an example of minimum_weighted_distance. The white number indicates the goal candidate priority, and the smaller the number, the higher the priority. the 0 goal indicates the base goal.
-
If the footprint in each goal candidate is within
object_recognition_collision_check_margin
of that of the object, it is determined to be unsafe. These goals are not selected. Ifuse_occupancy_grid_for_goal_search
is enabled, collision detection on the grid is also performed withoccupancy_grid_collision_check_margin
.
Red goals candidates in the image indicate unsafe ones.
It is possible to keep longitudinal_margin
in the longitudinal direction apart from the collision margin for obstacles from the goal candidate. This is intended to provide natural spacing for parking and efficient departure.
Also, if prioritize_goals_before_objects
is enabled, To arrive at each goal, the number of objects that need to be avoided in the target range is counted, and those with the lowest number are given priority.
The images represent a count of objects to be avoided at each range, with priority given to those with the lowest number, regardless of the aforementioned distances.
The gray numbers represent objects to avoid, and you can see that the goal in front has a higher priority in this case.
Parameters for goal search#
Name | Unit | Type | Description | Default value |
---|---|---|---|---|
goal_priority | [-] | string | In case minimum_longitudinal_distance , sort with smaller longitudinal distances taking precedence over smaller lateral distances. In case minimum_weighted_distance , sort with the sum of weighted lateral distance and longitudinal distance |
minimum_weighted_distance |
lateral_weight | [-] | double | Weight for lateral distance used when minimum_weighted_distance |
40.0 |
prioritize_goals_before_objects | [-] | bool | If there are objects that may need to be avoided, prioritize the goal in front of them | true |
forward_goal_search_length | [m] | double | length of forward range to be explored from the original goal | 20.0 |
backward_goal_search_length | [m] | double | length of backward range to be explored from the original goal | 20.0 |
goal_search_interval | [m] | double | distance interval for goal search | 2.0 |
longitudinal_margin | [m] | double | margin between ego-vehicle at the goal position and obstacles | 3.0 |
max_lateral_offset | [m] | double | maximum offset of goal search in the lateral direction | 0.5 |
lateral_offset_interval | [m] | double | distance interval of goal search in the lateral direction | 0.25 |
ignore_distance_from_lane_start | [m] | double | This parameter ensures that the distance between the start of the shoulder lane and the goal is not less than the specified value. It's used to prevent setting goals too close to the beginning of the shoulder lane, which might lead to unsafe or impractical pull-over maneuvers. Increasing this value will force the system to ignore potential goal positions near the start of the shoulder lane, potentially leading to safer and more comfortable pull-over locations. | 0.0 |
margin_from_boundary | [m] | double | distance margin from edge of the shoulder lane | 0.5 |
Pull Over#
There are three path generation methods.
The path is generated with a certain margin (default: 0.75 m
) from the boundary of shoulder lane.
The process is time consuming because multiple planners are used to generate path for each candidate goal. Therefore, in this module, the path generation is performed in a thread different from the main thread.
Path generation is performed at the timing when the shape of the output path of the previous module changes. If a new module launches, it is expected to go to the previous stage before the goal planner, in which case the goal planner re-generates the path. The goal planner is expected to run at the end of multiple modules, which is achieved by keep_last
in the planner manager.
Threads in the goal planner are shown below.
The main thread will be the one called from the planner manager flow.
- The goal candidate generation and path candidate generation are done in a separate thread(lane path generation thread).
- The path candidates generated there are referred to by the main thread, and the one judged to be valid for the current planner data (e.g. ego and object information) is selected from among them. valid means no sudden deceleration, no collision with obstacles, etc. The selected path will be the output of this module.
- If there is no path selected, or if the selected path is collision and ego is stuck, a separate thread(freespace path generation thread) will generate a path using freespace planning algorithm. If a valid free space path is found, it will be the output of the module. If the object moves and the pull over path generated along the lane is collision-free, the path is used as output again. See also the section on freespace parking for more information on the flow of generating freespace paths.
Name | Unit | Type | Description | Default value |
---|---|---|---|---|
pull_over_minimum_request_length | [m] | double | when the ego-vehicle approaches the goal by this distance or a safe distance to stop, pull over is activated. | 100.0 |
pull_over_velocity | [m/s] | double | decelerate to this speed by the goal search area | 3.0 |
pull_over_minimum_velocity | [m/s] | double | speed of pull_over after stopping once. this prevents excessive acceleration. | 1.38 |
decide_path_distance | [m] | double | decide path if it approaches this distance relative to the parking position. after that, no path planning and goal search are performed | 10.0 |
maximum_deceleration | [m/s2] | double | maximum deceleration. it prevents sudden deceleration when a parking path cannot be found suddenly | 1.0 |
path_priority | [-] | string | In case efficient_path use a goal that can generate an efficient path which is set in efficient_path_order . In case close_goal use the closest goal to the original one. |
efficient_path |
efficient_path_order | [-] | string | efficient order of pull over planner along lanes excluding freespace pull over | ["SHIFT", "ARC_FORWARD", "ARC_BACKWARD"] |
lane_departure_check_expansion_margin | [m] | double | margin to expand the ego vehicle footprint when doing lane departure checks | 0.0 |
shift parking#
Pull over distance is calculated by the speed, lateral deviation, and the lateral jerk. The lateral jerk is searched for among the predetermined minimum and maximum values, and the one satisfies ready conditions described above is output.
- Apply uniform offset to centerline of shoulder lane for ensuring margin
- In the section between merge start and end, path is shifted by a method that is used to generate avoidance path (four segmental constant jerk polynomials)
- Combine this path with center line of road lane
Parameters for shift parking#
Name | Unit | Type | Description | Default value |
---|---|---|---|---|
enable_shift_parking | [-] | bool | flag whether to enable shift parking | true |
shift_sampling_num | [-] | int | Number of samplings in the minimum to maximum range of lateral_jerk | 4 |
maximum_lateral_jerk | [m/s3] | double | maximum lateral jerk | 2.0 |
minimum_lateral_jerk | [m/s3] | double | minimum lateral jerk | 0.5 |
deceleration_interval | [m] | double | distance of deceleration section | 15.0 |
after_shift_straight_distance | [m] | double | straight line distance after pull over end point | 1.0 |
geometric parallel parking#
Generate two arc paths with discontinuous curvature. It stops twice in the middle of the path to control the steer on the spot. There are two path generation methods: forward and backward. See also [1] for details of the algorithm. There is also a simple python implementation.
Parameters geometric parallel parking#
Name | Unit | Type | Description | Default value |
---|---|---|---|---|
arc_path_interval | [m] | double | interval between arc path points | 1.0 |
pull_over_max_steer_rad | [rad] | double | maximum steer angle for path generation. it may not be possible to control steer up to max_steer_angle in vehicle_info when stopped | 0.35 |
arc forward parking#
Generate two forward arc paths.
Parameters arc forward parking#
Name | Unit | Type | Description | Default value |
---|---|---|---|---|
enable_arc_forward_parking | [-] | bool | flag whether to enable arc forward parking | true |
after_forward_parking_straight_distance | [m] | double | straight line distance after pull over end point | 2.0 |
forward_parking_velocity | [m/s] | double | velocity when forward parking | 1.38 |
forward_parking_lane_departure_margin | [m/s] | double | lane departure margin for front left corner of ego-vehicle when forward parking | 0.0 |
arc backward parking#
Generate two backward arc paths.
.
Parameters arc backward parking#
Name | Unit | Type | Description | Default value |
---|---|---|---|---|
enable_arc_backward_parking | [-] | bool | flag whether to enable arc backward parking | true |
after_backward_parking_straight_distance | [m] | double | straight line distance after pull over end point | 2.0 |
backward_parking_velocity | [m/s] | double | velocity when backward parking | -1.38 |
backward_parking_lane_departure_margin | [m/s] | double | lane departure margin for front right corner of ego-vehicle when backward | 0.0 |
freespace parking#
If the vehicle gets stuck with lane_parking
, run freespace_parking
.
To run this feature, you need to set parking_lot
to the map, activate_by_scenario
of costmap_generator to false
and enable_freespace_parking
to true
Simultaneous execution with avoidance_module
in the flowchart is under development.
Parameters freespace parking#
Name | Unit | Type | Description | Default value |
---|---|---|---|---|
enable_freespace_parking | [-] | bool | This flag enables freespace parking, which runs when the vehicle is stuck due to e.g. obstacles in the parking area. | true |
See freespace_planner for other parameters.
collision check for path generation#
To select a safe one from the path candidates, a collision check with obstacles is performed.
occupancy grid based collision check#
Generate footprints from ego-vehicle path points and determine obstacle collision from the value of occupancy_grid of the corresponding cell.
Parameters for occupancy grid based collision check#
Name | Unit | Type | Description | Default value |
---|---|---|---|---|
use_occupancy_grid_for_goal_search | [-] | bool | flag whether to use occupancy grid for goal search collision check | true |
use_occupancy_grid_for_goal_longitudinal_margin | [-] | bool | flag whether to use occupancy grid for keeping longitudinal margin | false |
use_occupancy_grid_for_path_collision_check | [-] | bool | flag whether to use occupancy grid for collision check | false |
occupancy_grid_collision_check_margin | [m] | double | margin to calculate ego-vehicle cells from footprint. | 0.0 |
theta_size | [-] | int | size of theta angle to be considered. angular resolution for collision check will be 2\(\pi\) / theta_size [rad]. | 360 |
obstacle_threshold | [-] | int | threshold of cell values to be considered as obstacles | 60 |
object recognition based collision check#
A collision decision is made for each of the path candidates, and a collision-free path is selected. There are three main margins at this point.
object_recognition_collision_check_margin
is margin in all directions of ego.- In the forward direction, a margin is added by the braking distance calculated from the current speed and maximum deceleration. The maximum distance is The maximum value of the distance is suppressed by the
object_recognition_collision_check_max_extra_stopping_margin
- In curves, the lateral margin is larger than in straight lines.This is because curves are more prone to control errors or to fear when close to objects (The maximum value is limited by
object_recognition_collision_check_max_extra_stopping_margin
, although it has no basis.)
Then there is the concept of soft and hard margins. Although not currently parameterized, if a collision-free path can be generated by a margin several times larger than object_recognition_collision_check_margin
, then the priority is higher.
Parameters for object recognition based collision check#
Name | Unit | Type | Description | Default value |
---|---|---|---|---|
use_object_recognition | [-] | bool | flag whether to use object recognition for collision check | true |
object_recognition_collision_check_soft_margins | [m] | vector[double] | soft margins for collision check when path generation. It is not strictly the distance between footprints, but the maximum distance when ego and objects are oriented. | [5.0, 4.5, 4.0, 3.5, 3.0, 2.5, 2.0, 1.5, 1.0] |
object_recognition_collision_check_hard_margins | [m] | vector[double] | hard margins for collision check when path generation | [0.6] |
object_recognition_collision_check_max_extra_stopping_margin | [m] | double | maximum value when adding longitudinal distance margin for collision check considering stopping distance | 1.0 |
detection_bound_offset | [m] | double | expand pull over lane with this offset to make detection area for collision check of path generation | 15.0 |
safety check#
Perform safety checks on moving objects. If the object is determined to be dangerous, no path decision is made and no approval is given,
- path decision is not made and approval is not granted.
- After approval, the ego vehicle stops under deceleration and jerk constraints.
This module has two methods of safety check, RSS
and integral_predicted_polygon
.
RSS
method is a method commonly used by other behavior path planner modules, see RSS based safety check utils explanation.
integral_predicted_polygon
is a more safety-oriented method. This method is implemented because speeds during pull over are lower than during driving, and fewer objects travel along the edge of the lane. (It is sometimes too reactive and may be less available.)
This method integrates the footprints of egos and objects at a given time and checks for collisions between them.
In addition, the safety check has a time hysteresis, and if the path is judged "safe" for a certain period of time(keep_unsafe_time
), it is finally treated as "safe".
==== is_safe
---- current_is_safe
is_safe
^
|
| time
1 +--+ +---+ +---========= +--+
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
0 =========================-------==========--> t
Parameters for safety check#
Name | Unit | Type | Description | Default value |
---|---|---|---|---|
enable_safety_check | [-] | bool | flag whether to use safety check | true |
method | [-] | string | method for safety check. RSS or integral_predicted_polygon |
integral_predicted_polygon |
keep_unsafe_time | [s] | double | safety check Hysteresis time. if the path is judged "safe" for the time it is finally treated as "safe". | 3.0 |
check_all_predicted_path | - | bool | Flag to check all predicted paths | true |
publish_debug_marker | - | bool | Flag to publish debug markers | false |
collision_check_yaw_diff_threshold |
[rad] | double | Maximum yaw difference between ego and object when executing rss-based collision checking | 3.1416 |
Parameters for RSS safety check#
Name | Unit | Type | Description | Default value |
---|---|---|---|---|
rear_vehicle_reaction_time | [s] | double | Reaction time for rear vehicles | 2.0 |
rear_vehicle_safety_time_margin | [s] | double | Safety time margin for rear vehicles | 1.0 |
lateral_distance_max_threshold | [m] | double | Maximum lateral distance threshold | 2.0 |
longitudinal_distance_min_threshold | [m] | double | Minimum longitudinal distance threshold | 3.0 |
longitudinal_velocity_delta_time | [s] | double | Delta time for longitudinal velocity | 0.8 |
Parameters for integral_predicted_polygon safety check#
Name | Unit | Type | Description | Default value |
---|---|---|---|---|
forward_margin | [m] | double | forward margin for ego footprint | 1.0 |
backward_margin | [m] | double | backward margin for ego footprint | 1.0 |
lat_margin | [m] | double | lateral margin for ego footprint | 1.0 |
time_horizon | [s] | double | Time width to integrate each footprint | 10.0 |
path deciding#
When decide_path_distance
closer to the start of the pull over, if it is collision-free at that time and safe for the predicted path of the objects, it transitions to DECIDING. If it is safe for a certain period of time, it moves to DECIDED.
Unimplemented parts / limitations#
- Only shift pull over can be executed concurrently with other modules
- Parking in tight spots and securing margins are traded off. A mode is needed to reduce the margin by using a slower speed depending on the situation, but there is no mechanism for dynamic switching of speeds.
- Parking space available depends on visibility of objects, and sometimes parking decisions cannot be made properly.
- Margin to unrecognized objects(Not even unknown objects) depends on the occupancy grid. May get too close to unrecognized ground objects because the objects that are allowed to approach (e.g., grass, leaves) are indistinguishable.
Unimplemented parts / limitations for freespace parking
- When a short path is generated, the ego does can not drive with it.
- Complex cases take longer to generate or fail.
- The drivable area is not guaranteed to fit in the parking_lot.