This tutorial demonstrates how are the motion primitives used in solving motion planning problems generated.
%% Cell type:markdown id: tags:
## 0. Preparation
Before you proceed with this tutorial, make sure that
* you have gone through the tutorial for **CommonRoad Input-Output**.
* you have installed all necessary modules for **CommonRoad Search** according to the installation manual.
The configuration parameters related to our motion primitive generator are stored in **generator_config.yaml**. The configuration file contains the following parameters:
***output setting**:
* output_directory: output directory of the generated motion primitives. The path can be either **relative** to this notebook or **absolute**.
***vehicle setting**:
* vehicle_type_id: id of vehicle type. 1: FORD_ESCORT, 2: BMW_320i, 3: VW_VANAGON
***primitive setting**:
* duration: time length of trajectory [s].
* dt_simulation: time step for forwad state simulation [s]. Note that CommonRoad scenarios have a discrete time step dt of 0.1 seconds
* velocity_sample_max: maximum sampling velocity [m/s].
* num_sample_velocity: number of velocity samples.
* steering_angle_sample_min: minimum sampling angle [rad]. Note that here we only consider steering to one side, as we will mirror the primitives afterwards.
* steering_angle_sample_max: maximum sampling angle [rad]. If set to 0, it will be assigned the maximum permissible value given by the selected vehicle parameter.
* num_sample_steering_angle: number of steering angle samples
***sample trajectory setting**:
* num_segment_trajectory: number of segments in sample trajectories
* num_simulations: number of sample trajectories to be generated
**Note**: Generating too sparse primitives (low branching factor) may restrict the search space such that no feasible solution can be found. On the other hand, generating too dense primitives (high branching factor) may dramatically inscrease the time of search. Thus striking a balance between diversity and efficiency is important here.