You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: planning/behavior_path_start_planner_module/README.md
+51-50
Original file line number
Diff line number
Diff line change
@@ -146,7 +146,7 @@ The approach to collision safety is divided into two main components: generating
146
146
- Why is a margin from the rear object necessary?
147
147
For objects ahead, another behavior module can intervene, allowing the path to overwrite itself through an avoidance plan, even if the clearance from the path to a static obstacle is minimal, thus maintaining a safe distance from static obstacles. However, for objects behind the vehicle, it is impossible for other behavior modules other than the start_planner to alter the path to secure a margin, potentially leading to a deadlock by an action module like "obstacle_stop_cruise" and subsequent immobilization. Therefore, a margin is set for stationary objects at the rear.
148
148
149
-
Here's the expression of the steps start pose searching steps, considering the threshold levels are set at [2.0, 1.0, 0.5, 0.1 meters] as example. The process is as follows:
149
+
Here's the expression of the steps start pose searching steps, considering the `collision_check_margins` is set at [2.0, 1.0, 0.5, 0.1] as example. The process is as follows:
150
150
151
151
1.**Generating start pose candidates**
152
152
@@ -155,11 +155,16 @@ Here's the expression of the steps start pose searching steps, considering the t
155
155
- Generate candidate points for the start pose in the backward direction at intervals defined by `backward_search_resolution`.
156
156
- Include the current position as one of the start pose candidates.
If a safe path with sufficient clearance for static obstacles cannot be generated forward, a backward search from the vehicle's current position is conducted to locate a suitable start point for a pull out path generation.
184
+
185
+
During this backward search, different policies can be applied based on `search_priority` parameters:
186
+
187
+
Selecting `efficient_path` focuses on creating a shift pull out path, regardless of how far back the vehicle needs to move.
188
+
Opting for `short_back_distance` aims to find a location with the least possible backward movement.
`PriorityOrder` is defined as a vector of pairs, where each element consists of a `size_t` index representing a start pose candidate index, and the planner type. The PriorityOrder vector is processed sequentially from the beginning, meaning that the pairs listed at the top of the vector are given priority in the selection process for pull out path generation.
193
+
194
+
##### `efficient_path`
195
+
196
+
When `search_priority` is set to `efficient_path` and the preference is for prioritizing `shift_pull_out`, the `PriorityOrder` array is populated in such a way that `shift_pull_out` is grouped together for all start pose candidates before moving on to the next planner type. This prioritization is reflected in the order of the array, with `shift_pull_out` being listed before geometric_pull_out.
197
+
198
+
| Index | Planner Type |
199
+
| ----- | ------------------ |
200
+
| 0 | shift_pull_out |
201
+
| 1 | shift_pull_out |
202
+
| ... | ... |
203
+
| N | shift_pull_out |
204
+
| 0 | geometric_pull_out |
205
+
| 1 | geometric_pull_out |
206
+
| ... | ... |
207
+
| N | geometric_pull_out |
208
+
209
+
This approach prioritizes trying all candidates with `shift_pull_out` before proceeding to `geometric_pull_out`, which may be efficient in situations where `shift_pull_out` is likely to be appropriate.
210
+
211
+
##### `short_back_distance`
212
+
213
+
For `search_priority` set to `short_back_distance`, the array alternates between planner types for each start pose candidate, which can minimize the distance the vehicle needs to move backward if the earlier candidates are successful.
214
+
215
+
| Index | Planner Type |
216
+
| ----- | ------------------ |
217
+
| 0 | shift_pull_out |
218
+
| 0 | geometric_pull_out |
219
+
| 1 | shift_pull_out |
220
+
| 1 | geometric_pull_out |
221
+
| ... | ... |
222
+
| N | shift_pull_out |
223
+
| N | geometric_pull_out |
224
+
225
+
This ordering is beneficial when the priority is to minimize the backward distance traveled, giving an equal chance for each planner to succeed at the closest possible starting position.
179
226
180
227
### 2. Collision detection with dynamic obstacles
181
228
@@ -430,52 +477,6 @@ If a safe path cannot be generated from the current position, search backwards f
430
477
431
478
[pull out after backward driving video](https://user-images.githubusercontent.com/39142679/181025149-8fb9fb51-9b8f-45c4-af75-27572f4fba78.mp4)
432
479
433
-
### **search priority**
434
-
435
-
If a safe path with sufficient clearance for static obstacles cannot be generated forward, a backward search from the vehicle's current position is conducted to locate a suitable start point for a pull out path generation.
436
-
437
-
During this backward search, different policies can be applied based on `search_priority` parameters:
438
-
439
-
Selecting `efficient_path` focuses on creating a shift pull out path, regardless of how far back the vehicle needs to move.
440
-
Opting for `short_back_distance` aims to find a location with the least possible backward movement.
`PriorityOrder` is defined as a vector of pairs, where each element consists of a `size_t` index representing a start pose candidate index, and the planner type. The PriorityOrder vector is processed sequentially from the beginning, meaning that the pairs listed at the top of the vector are given priority in the selection process for pull out path generation.
445
-
446
-
#### `efficient_path`
447
-
448
-
When `search_priority` is set to `efficient_path` and the preference is for prioritizing `shift_pull_out`, the `PriorityOrder` array is populated in such a way that `shift_pull_out` is grouped together for all start pose candidates before moving on to the next planner type. This prioritization is reflected in the order of the array, with `shift_pull_out` being listed before geometric_pull_out.
449
-
450
-
| Index | Planner Type |
451
-
| ----- | ------------------ |
452
-
| 0 | shift_pull_out |
453
-
| 1 | shift_pull_out |
454
-
| ... | ... |
455
-
| N | shift_pull_out |
456
-
| 0 | geometric_pull_out |
457
-
| 1 | geometric_pull_out |
458
-
| ... | ... |
459
-
| N | geometric_pull_out |
460
-
461
-
This approach prioritizes trying all candidates with `shift_pull_out` before proceeding to `geometric_pull_out`, which may be efficient in situations where `shift_pull_out` is likely to be appropriate.
462
-
463
-
#### `short_back_distance`
464
-
465
-
For `search_priority` set to `short_back_distance`, the array alternates between planner types for each start pose candidate, which can minimize the distance the vehicle needs to move backward if the earlier candidates are successful.
466
-
467
-
| Index | Planner Type |
468
-
| ----- | ------------------ |
469
-
| 0 | shift_pull_out |
470
-
| 0 | geometric_pull_out |
471
-
| 1 | shift_pull_out |
472
-
| 1 | geometric_pull_out |
473
-
| ... | ... |
474
-
| N | shift_pull_out |
475
-
| N | geometric_pull_out |
476
-
477
-
This ordering is beneficial when the priority is to minimize the backward distance traveled, giving an equal chance for each planner to succeed at the closest possible starting position.
478
-
479
480
### **parameters for backward pull out start point search**
480
481
481
482
| Name | Unit | Type | Description | Default value |
0 commit comments