Commit be959447 authored by Uwe Woessner's avatar Uwe Woessner
Browse files

Merge remote-tracking branch 'remotes/origin/servant' into hlrs

# Conflicts:
#	OpenPass_Source_Code/openPASS/Common/basicEvent.h
#	OpenPass_Source_Code/openPASS/Common/collisionEvent.h
#	OpenPass_Source_Code/openPASS/Common/commonTools.h
#	OpenPass_Source_Code/openPASS/Common/dynamicsSignal.h
#	OpenPass_Source_Code/openPASS/Common/globalDefinitions.h
#	OpenPass_Source_Code/openPASS/Common/postCrashDynamic.h
#	OpenPass_Source_Code/openPASS/Common/spawnPointDefinitions.h
#	OpenPass_Source_Code/openPASS/Components/AgentUpdater/agentUpdaterImplementation.cpp
#	OpenPass_Source_Code/openPASS/Components/CMakeLists.txt
#	OpenPass_Source_Code/openPASS/Components/Dynamics_CollisionPostCrash/CMakeLists.txt
#	OpenPass_Source_Code/openPASS/Components/Dynamics_CollisionPostCrash/dynamics_collisionPostCrash.cpp
#	OpenPass_Source_Code/openPASS/Components/Dynamics_CollisionPostCrash/dynamics_collisionPostCrashImplementation.cpp
#	OpenPass_Source_Code/openPASS/Components/Dynamics_CollisionPostCrash/dynamics_collisionPostCrashImplementation.h
#	OpenPass_Source_Code/openPASS/Components/Dynamics_RegularTwoTrack/CMakeLists.txt
#	OpenPass_Source_Code/openPASS/Components/Dynamics_RegularTwoTrack/
#	OpenPass_Source_Code/openPASS/Components/Dynamics_RegularTwoTrack/dynamics_regularTwoTrack.cpp
#	OpenPass_Source_Code/openPASS/Components/Dynamics_RegularTwoTrack/dynamics_regularTwoTrack.h
#	OpenPass_Source_Code/openPASS/Components/Dynamics_RegularTwoTrack/dynamics_regularTwoTrackGlobal.h
#	OpenPass_Source_Code/openPASS/Components/Dynamics_RegularTwoTrack/dynamics_regularTwoTrackImplementation.cpp
#	OpenPass_Source_Code/openPASS/Components/Dynamics_RegularTwoTrack/dynamics_regularTwoTrackImplementation.h
#	OpenPass_Source_Code/openPASS/Components/Dynamics_TrajectoryFollower/trajectoryFollowerCommonBase.cpp
#	OpenPass_Source_Code/openPASS/Components/Dynamics_TrajectoryFollower/trajectoryFollowerImplementation.h
#	OpenPass_Source_Code/openPASS/Components/Sensor_RecordState/sensor_recordStateImplementation.cpp
#	OpenPass_Source_Code/openPASS/CoreFramework/CoreShare/parameters.cpp
#	OpenPass_Source_Code/openPASS/CoreFramework/CoreShare/parameters.h
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/framework/runInstantiator.cpp
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/importer/profiles.h
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/importer/road.h
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/importer/road/roadSignal.h
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/importer/slaveConfigImporter.cpp
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/importer/vehicleModels.cpp
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/importer/vehicleModels.h
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/importer/vehicleModelsImporter.cpp
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/modelElements/agentBlueprint.cpp
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/modelElements/agentBlueprint.h
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/modelElements/component.h
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/modelElements/spawnPointNetwork.cpp
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/modelElements/spawnPointNetwork.h
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/modelInterface/modelBinding.cpp
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/modelInterface/modelBinding.h
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/observationInterface/observationBinding.cpp
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/observationInterface/observationBinding.h
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/spawnPointInterface/spawnPointBinding.cpp
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/spawnPointInterface/spawnPointBinding.h
#	OpenPass_Source_Code/openPASS/CoreFramework/OpenPassSlave/worldInterface/world.h
#	OpenPass_Source_Code/openPASS/CoreModules/Manipulator/CMakeLists.txt
#	OpenPass_Source_Code/openPASS/CoreModules/Manipulator/CollisionManipulator.cpp
#	OpenPass_Source_Code/openPASS/CoreModules/Manipulator/CollisionManipulator.h
#	OpenPass_Source_Code/openPASS/CoreModules/Manipulator/
#	OpenPass_Source_Code/openPASS/CoreModules/Manipulator/srcCollisionPostCrash/collisionDetection_Impact_implementation.cpp
#	OpenPass_Source_Code/openPASS/CoreModules/Manipulator/srcCollisionPostCrash/collisionDetection_Impact_implementation.h
#	OpenPass_Source_Code/openPASS/CoreModules/Manipulator/srcCollisionPostCrash/polygon.cpp
#	OpenPass_Source_Code/openPASS/CoreModules/Manipulator/srcCollisionPostCrash/polygon.h
#	OpenPass_Source_Code/openPASS/CoreModules/Observation_Log/observationFileHandler.cpp
#	OpenPass_Source_Code/openPASS/CoreModules/Observation_Log/observation_logImplementation.h
#	OpenPass_Source_Code/openPASS/CoreModules/SpawnPoint_OSI/SpawnPoint.cpp
#	OpenPass_Source_Code/openPASS/CoreModules/World_OSI/AgentAdapter.cpp
#	OpenPass_Source_Code/openPASS/CoreModules/World_OSI/AgentAdapter.h
#	OpenPass_Source_Code/openPASS/CoreModules/World_OSI/SceneryConverter.cpp
#	OpenPass_Source_Code/openPASS/CoreModules/World_OSI/SceneryConverter.h
#	OpenPass_Source_Code/openPASS/CoreModules/World_OSI/TrafficObjectAdapter.cpp
#	OpenPass_Source_Code/openPASS/CoreModules/World_OSI/TrafficObjectAdapter.h
#	OpenPass_Source_Code/openPASS/CoreModules/World_OSI/WorldImplementation.cpp
#	OpenPass_Source_Code/openPASS/CoreModules/World_OSI/WorldImplementation.h
#	OpenPass_Source_Code/openPASS/Interfaces/agentBlueprintInterface.h
#	OpenPass_Source_Code/openPASS/Interfaces/agentInterface.h
#	OpenPass_Source_Code/openPASS/Interfaces/eventInterface.h
#	OpenPass_Source_Code/openPASS/Interfaces/parameterInterface.h
#	OpenPass_Source_Code/openPASS/Interfaces/roadInterface/roadInterface.h
#	OpenPass_Source_Code/openPASS/Interfaces/spawnPointInterface.h
#	OpenPass_Source_Code/openPASS/Interfaces/spawnPointNetworkInterface.h
#	OpenPass_Source_Code/openPASS/Interfaces/vehicleModelsInterface.h
#	OpenPass_Source_Code/openPASS/Interfaces/worldInterface.h
#	OpenPass_Source_Code/openPASS/
#	OpenPass_Source_Code/openPASS_Resource/AEB/configs/VehicleModelsCatalog.xosc
#	OpenPass_Source_Code/openPASS_Resource/StaticAgentCollision/configs/PedestrianModelsCatalog.xosc
#	OpenPass_Source_Code/openPASS_Resource/StaticAgentCollision/configs/ProfilesCatalog.xml
#	OpenPass_Source_Code/openPASS_Resource/StaticAgentCollision/configs/ProfilesCatalog_GUI.ui
#	OpenPass_Source_Code/openPASS_Resource/StaticAgentCollision/configs/Scenario.xosc
#	OpenPass_Source_Code/openPASS_Resource/StaticAgentCollision/configs/SceneryConfiguration.xodr
#	OpenPass_Source_Code/openPASS_Resource/StaticAgentCollision/configs/SystemConfig.xml
#	OpenPass_Source_Code/openPASS_Resource/StaticAgentCollision/configs/VehicleModelsCatalog.xosc
#	OpenPass_Source_Code/openPASS_Resource/StaticAgentCollision/configs/slaveConfig.xml
#	OpenPass_Source_Code/openPASS_Resource/StaticAgentCollision/configs/systemConfigBlueprint.xml
#	OpenPass_Source_Code/openPASS_Resource/StaticAgentCollision/masterConfig.xml
#	OpenPass_Source_Code/openPASS_Resource/Static_AgentProfiles/configs/VehicleModelsCatalog.xosc
parents 67e0bf1b 41fbfeba
BasedOnStyle: llvm
Language: Cpp
ColumnLimit: 0
IndentWidth: 4
AccessModifierOffset: -4
IncludeBlocks: Regroup
- Regex: '^<(gtest|gmock)/)'
Priority: -1
- Regex: '^<[^Q]'
Priority: 1
- Regex: '^<Q'
Priority: 2
AlignTrailingComments: true
BreakConstructorInitializers: AfterColon
ConstructorInitializerAllOnOneLineOrOnePerLine: true
AllowShortFunctionsOnASingleLine: None
KeepEmptyLinesAtTheStartOfBlocks: false
BreakBeforeBraces: Custom
AfterClass: true
AfterControlStatement: true
AfterEnum: true
AfterFunction: true
AfterNamespace: false
AfterObjCDeclaration: true
AfterStruct: true
AfterUnion: true
AfterExternBlock: true
BeforeCatch: true
BeforeElse: true
IndentBraces: false
SplitEmptyFunction: true
SplitEmptyRecord: true
SplitEmptyNamespace: true
\ No newline at end of file
# qt artifact
\ No newline at end of file
# third party references
......@@ -16,7 +16,6 @@ project(openPASS C CXX)
set(CPACK_PACKAGE_VENDOR "simopenpass Eclipse project team")
......@@ -32,7 +31,7 @@ add_subdirectory(${CMAKE_CURRENT_LIST_DIR}/OpenPass_Source_Code)
# will be provided in the near future
<?xml version="1.0"?>
<FileHeader revMajor="0" revMinor="1" date="2018-12-03T10:00:00" description="openPASS default scenario" author="in-tech GmbH"/>
<Parameter name="OP_OSC_SchemaVersion" type="string" value="0.3.0"/>
<Directory path="VehicleModelsCatalog.xosc"/>
<Directory path="PedestrianModelsCatalog.xosc"/>
<Directory path=""/>
<Directory path=""/>
<Directory path=""/>
<Directory path=""/>
<Directory path=""/>
<Directory path=""/>
<Directory path=""/>
<Logics filepath="SceneryConfiguration.xodr"/>
<SceneGraph filepath=""/>
<Object name="Ego">
<CatalogReference catalogName="ProfilesCatalog.xml" entryName="MiddleClassCarAgent"/>
<Selection name="ScenarioAgents">
<!-- initial position and velocity of agents -->
<Private object="Ego">
<Lane roadId="1" s="0.0" laneId="-1" offset="0.0"/>
<!-- position -->
<Condition name="EndTime" delay="0" edge="rising">
<SimulationTime value="30.0" rule="greater_than"/>
<FileHeader revMajor="1" revMinor="0" date="2020-06-22T15:00:00" description="openPASS default scenario" author="in-tech GmbH"/>
<ParameterDeclaration name="OP_OSC_SchemaVersion" parameterType="string" value="0.4.0"/>
<Directory path="VehicleModelsCatalog.xosc"/>
<Directory path="PedestrianModelsCatalog.xosc"/>
<Directory path=""/>
<Directory path=""/>
<Directory path=""/>
<Directory path=""/>
<Directory path=""/>
<Directory path=""/>
<LogicFile filepath="SceneryConfiguration.xodr"/>
<SceneGraphFile filepath=""/>
<ScenarioObject name="Ego">
<CatalogReference catalogName="ProfilesCatalog.xml" entryName="MiddleClassCarAgent"/>
<EntitySelection name="ScenarioAgents">
<Private entityRef="Ego">
<LanePosition roadId="1" laneId="-1" offset="0.0" s="0.0"/>
<Condition name="EndTime" delay="0" conditionEdge="rising">
<SimulationTimeCondition value="30.0" rule="greaterThan"/>
......@@ -6,15 +6,18 @@
<tab type="usergroup" url="@ref sim" title="Simulation">
<tab type="usergroup" url="@ref dev" title="Development">
<tab type="user" url="@ref execution" title="Execution" />
<tab type="user" url="@ref dev_framework_modules" title="Framework Modules" />
<tab type="usergroup" url="@ref dev_framework_modules" title="Framework Modules">
<tab type="user" url="@ref dev_framework_modules_spawnpoints" title="SpawnPoints"/>
<tab type="user" url="@ref dev_conditionaleventdetector" title="Conditional EventDetectors"/>
<tab type="user" url="@ref dev_agent_modules" title="Agent Modules" />
<tab type="user" url="@ref scheduling" title="Scheduling" />
<tab type="user" url="@ref localization" title="Localization" />
<tab type="user" url="@ref adas" title="Advanced Driver Assistance Systems" />
<tab type="user" url="@ref scheduling" title="Scheduling" />
<tab type="user" url="@ref localization" title="Localization" />
<tab type="user" url="@ref adas" title="Advanced Driver Assistance Systems" />
<tab type="user" url="@ref io" title="Input &amp; Output">
<tab type="user" url="@ref scenario" title="Scenario" />
<tab type="usergroup" visible="yes" title="Developer Information">
<tab type="modules" visible="yes" title="" intro=""/>
......@@ -151,6 +151,93 @@ The input for this module is the steeringwheel angle and the new acceleration of
\section dev_bmw_agent_modules_fmuwrapper FMU wrapper
The FMU Wrapper provides a connection to arbitrary FMUs (Functional Mock-up Unit).
A FMU has to be compatible with the FMI 1.0 or FMI 2.0 specification (Functional Mock-up Interface) and has to be ABI (Application Binary Interface) compatible with the OpenPassSlave binary.
Additional reading about FMI is provided by the FMI standard website at
For interfacing the FMUs in openPASS, the Modelon FMI Library is used, which is recommended on the FMI standard website. See
\subsection dev_bmw_agent_modules_fmuwrapper_fmupackage FMU package format
FMI defines a packaging format for FMUs. The used container format is ZIP.
It basically contains - among other parts - the compiled FMU code (as *.dll or *.so, depending on the platform) and the `modelDescription.xml`.
Latter provides meta-data about the FMU, i. e.
- Author information
- Model name, identifier and description
- Generation timestamp
- Name and datatype of model variables (inputs and outputs)
\subsection dev_bmw_agent_modules_fmuwrapper_arch Architectural overview
The wrapper is instantiated as a component of an agent.
It reads the input variables for the FMU from the simulation and provides it the FMU and reads the output of the FMU and forwards it via signals to other agent components.
![FMU wrapper architectural overview](FmuWrapperOverview.svg)
\subsubsection dev_bmw_agent_modules_fmuwrapper_io_channels Framework channels
The wrapper can use input and output signals via `Channels` as every other agent component does.
Framework channels (signals) can provide data and can also be written to by the wrapper.
In addition, the wrapper is able to access the \c AgentInterface and \c WorldInterface methods.
\subsubsection dev_bmw_agent_modules_fmuwrapper_io_fmi FMI variables
Communication with the FMU happens via FMI variables (inputs and outputs).
The wrapper will read in available variables from `modelDescription.xml` in the FMU package.
These variables need to be mapped to variables and signals of OpenPASS in the VehicleComponentProfile.
FMI 1.0 supports these standard datatypes:
- bool
- integer
- real
- string
\subsection dev_bmw_agent_modules_fmuwrapper_config Configuration
Configuration of a particular FMU takes place in the [ProfilesCatalog.xml](\ref io_input_profilescatalog).
For selecting the path of a FMU, common wrapper settings and specifing the type of the FMI, a VehicleComponentProfile is created, i. e.
<VehicleComponentProfile Type="FMU1" Name="OSMP">
<String Key="FmuPath" Value="resources/OSMP.fmu"/>
<Bool Key="Logging" Value="true"/>
<Bool Key="CsvOutput" Value="true"/>
<Bool Key="UnzipOncePerInstance" Value="false"/>
<String Key="FmuType" Value="OSMP"/>
| **Key** | **Type** | **Description** |
| FmuPath | string | Path to FMU file. Relative and absolute paths are supported. |
| Logging | bool | If set to true, FMU initialization and execution task are logged to a text file. |
| CsvOutput | bool | If set to true, FMI outputs are logged to a CSV file. |
| UnzipOncePerInstance | bool | If set to true, unpack the FMU once for each running instance, instead of once per FMU file (forced to `true` on Linux systems) |
| FmuType | string | Type of the FMU (currently only "OSMP" supported") |
Upon instantiation of the FMU wrapper, it will extract the FMU ZIP file to a subfolder "Unzip", located at the same path as the FMU file itself.
Then the `modelDescription.xml` is parsed and the FMU is checked for compatibility.
If `CsvOutput` is set to `true`, a subfolder "Output" will be created in the path of the FMU file.
FMI output data will be logged to files inside this directory, with the agent id appended in the filename.
This output can then be used for visualization in a spreadsheet application or it may be processed in any other way.
Same goes for `Logging` with the folder "Log".
If `UnzipOncePerInstance` is set to `true`, an integer number will be appended to these subdirectories names.
\subsection dev_bmw_agent_modules_fmuwrapper_osmp OSMP FMU
OSMP is currently the only supported type of FMU.
It allows the pass input to the FMU as OSI messages as well as recieve output as OSI message.
For more information on OSMP see
\section dev_agent_modules_limiter LimiterAccelerationVehicleComponents
This module limits the AccelerationSignal from the PrioritizerAccelerationVehicleComponents to the constraints given by the vehicle. The [DynamicsTrajectoryFollower](\ref dev_agent_modules_dynamicsTrajectoryFollower) can then use this signal to calculate a trajectory.
......@@ -203,6 +290,24 @@ F<SUB>air</SUB> = rho<SUB>air</SUB> / 2 * A<SUB>front</SUB> * c<SUB>w</SUB> * v<
\section dev_agent_modules_oscActions OpenScenarioActions
As defined by openSCENARIO, OpenScenarioActions is the relaying module for:
- Trajectory-actions
- LaneChange-actions
- CustomLaneChange-actions
- UserDefined-actions.
If a
- TrajectoryManipulator
- LaneChangeManipulator
- CustomLaneChangeManipulator or a
- GazeFollowerManipulator
raises such an event for the specified agent, the module forwards it as signal to all interested module of the corresponding agent. The modules can than react on the signals content without time delay.
\section dev_agent_modules_parametersVehicle Parameters_Vehicle
The ParametersVehicle module forwards the VehicleModelParamters to all other moduls that need them via the ParametersVehicleSignal
......@@ -335,20 +440,20 @@ For convex BBoxes the above will give correct detection results.
Both polygons are constructed from corner-points consisting out of the intersection between the opening-angle boundaries at maximum detection range and their corresponding tangents.
\subsubsection dev_agent_modules_geometric2d_function Function
\subsection dev_agent_modules_geometric2d_function Function
1. Construct the polygon based on the opening-angle
2. Check if detection-field (polygon) intersects with any BBox (object-detection)
3. Calculate the distance between sensor and object
4. if (dist <= range && isIntersecting) -> object is in circular sector (object validation)
\subsubsection dev_agent_modules_geometric2d_cases Cases
\subsection dev_agent_modules_geometric2d_cases Cases
- For angles < 1.0 * pi a four-corner (kite) polygon can be constructed out of two radiuses and two tangents.
- For angles > = 1.0 * pi and < 2.0 * pi a five-corner polygon can be constructed of two radiusas an three tangents.
- For opening-angle of exactly 2.0 * pi the distance information suffices. No polygon is needed.
\subsubsection dev_agent_modules_geometric2d_obstruction Visual Obstruction
\subsection dev_agent_modules_geometric2d_obstruction Visual Obstruction
Objects in front of others block the sensors line of sight. If an object is large enough it might visually obstruct others.
......@@ -108,7 +108,6 @@ The slave uses the following core libraries:
* EventDetector
* Manipulator
* SpawnPoint
* Stochastics
* World
* Observation
......@@ -122,7 +121,6 @@ The core retrieves this information from the `<Libraries>` tag in the `slaveConf
......@@ -132,5 +130,5 @@ The core retrieves this information from the `<Libraries>` tag in the `slaveConf
If a mandatory library is missing, the slave tries to load a defaulted one, which is for e.g. `<SpawnPointLibrary>` `SpawnPoint.dll` under Windows or `` under Linux, respectively.
If a mandatory library is missing, the slave tries to load a defaulted one, which is for e.g. `<WorldLibrary>` `World.dll` under Windows or `` under Linux, respectively.
In such cases, a warning will be pushed to the log each.
......@@ -28,7 +28,7 @@ Right after execution of all agent-based tasks, the FinalizeRecurring phase sync
The scheduler handles 8 different task types:
* **Spawning** - triggers agent spawning while spawntime and parse agent tasks
* **Spawning** - triggers agent spawning
* **EventDetector** - execute event detector
* **Manipulator** - execute manipulator
* **Observation** - update observation modules
......@@ -41,8 +41,8 @@ The following table gives an overview to all phases.
| **Phase** | **Changeable**| **Task types**| **Notes**|
| ------------- |-------------|-------------|-------------|
| Bootstrap | no | Observation | |
| Common | no | Spawning, EventDetector, Manipulator, Observation| |
| Bootstrap | no | Spawning, Observation | PreRun Spawning occurs here |
| Common | no | Spawning, EventDetector, Manipulator, Observation| Runtime Spawning occurs here |
| Non recurring | yes | Trigger, Update | |
| Recurring | yes | Trigger, Update | |
| Finalize recurring | no | SyncGlobalData | Update the state of the agents and the virtual world (e.g. due to agent movements).|
\page dev_framework_modules_spawnpoints SpawnPoints
[//]: <> "Please sort by alphabet."
\section dev_framework_modules_spawnpoints_framework Framework
The current SpawnPoint setup allows users to generically add or remove SpawnPoints.
The SpawnPointNetwork can hold multiple SpawnPointLibraries.
These SpawnPointLibraries can generate multiple SpawnPoint instances.
All SpawnPoint instances are instantiated before each invocation.
![SpawnPoint Classes ](SpawnPointClasses.svg)
The SpawnPoints are responsible for interacting directly with the SpawnPoint dependencies (e.g. World, AgentFactory) in order to instantiate new Agents.
The SpawnPoints are configured through the SpawnPointsConfig in the SlaveConfig file.
If the Profile tag is existing, the related SpawnPoint profile with the specified name from the ProfilesCatalog is passed to the SpawnPoint as a ParameterInterface.
If the Profile tag does not exist, the Scenario file is passed to the SpawnPoint instead.
![SpawnPoint Dependencies ](SpawnPointDependencies.svg)
**Example SpawnPointsConfig (within slaveConfig.xml):**
| Name | Description |
| Library | Library name of the SpawnPoint |
| Type | Either "PreRun" or "RunTime". PreRun triggers only once before the invocation starts. RunTime continuously triggers during the run. |
| Priority | Determines the order in which SpawnPoints are triggered. SpawnPoints with higher priority are triggered first. Greater values equal higher priority. |
| Profile | Required only for the [PreRunCommon](\ref dev_framework_modules_spawnpoints_preruncommonspawnpoint) and [RuntimeCommon](\ref dev_framework_modules_spawnpoints_runtimecommonspawnpoint) SpawnPoints. Do not define for the [Scenario](\ref dev_framework_modules_spawnpoints_scenariospawnpoint) SpawnPoint.|
There are 3 types of SpawnPoints:
1. [Scenario](\ref dev_framework_modules_spawnpoints_scenariospawnpoint)
2. [PreRunCommon](\ref dev_framework_modules_spawnpoints_preruncommonspawnpoint)
3. [RuntimeCommon](\ref dev_framework_modules_spawnpoints_runtimecommonspawnpoint)
\section dev_framework_modules_spawnpoints_scenariospawnpoint ScenarioSpawnPoint
The Scenario SpawnPoint (included in library "SpawnPointScenario_OSI") is responsible for spawning Ego and Scenario vehicles as defined in the Scenario configuration file.
It is only called once initially and is recommended for each simulation.
This SpawnPoint should trigger before any other SpawnPoints.
A position and velocity are required for each Ego and Scenario agent in the scenario file.
The portion of the Scenario file relevant to this SpawnPoint can be found [here](\ref scenario_entities).
\section dev_framework_modules_spawnpoints_preruncommonspawnpoint PreRunSpawnPoint
The PreRun Spawnpoint (included in library "SpawnPointPreRunCommon_OSI") is responsible for populating the scenery/world with Common-Agents before the simulator starts.
This SpawnPoint only acts once before the simulator starts and not during the simulation run.
A traffic config is required for each PreRun SpawnPoint.
The PreRunCommon SpawnPoint requires a Spawner-Profile in the ProfilesCatalog. The SpawnerProfile contains information specifying the SpawnAreas and TrafficGroups
<ProfileGroup Type="TrafficGroup">
<Profile Name="ExampleTrafficGroup">
<List Name="AgentProfiles">
<String Key="Name" Value="LuxuryClassCarAgent"/>
<Double Key="Weight" Value="0.4"/>
<String Key="Name" Value="MiddleClassCarAgent"/>
<Double Key="Weight" Value="0.6"/>
<String Key="Name" Value="TruckAgent"/>
<Double Key="Weight" Value="0.0"/>
<NormalDistribution Key="Velocity" Max="68.5" Mean="43.5" Min="18.5" SD="5.0"/>
<LogNormalDistribution Key="TGap" Max="0.5" Min="0.5" Mu="0.5" Sigma="0.5"/>
<DoubleVector Key="Homogeneity" Value="0.8, 0.7"/>
<Bool Key="RightLaneOnly" Value="true"/>
<ProfileGroup Type="Spawner">
<Profile Name="ExamplePreRunSpawner">
<List Name="SpawnPoints">
<String Key="Road" Value="1"/>
<IntVector Key="Lanes" Value="-1,-2,-3,-4,-5"/>
<Double Key="SStart" Value="0.0"/>
<Double Key="SEnd" Value="1000.0"/>
<List Name="TrafficGroups">
<Double Key="Weight" Value="1"/>
<Reference Type="TrafficGroup" Name="ExampleTrafficGroup"/>
The SpawnAreas are defined by the following parameter:
| Name | Description |
| Road | The RoadID of the Road on which to spawn Agents |
| Lanes | The LaneIDs of the Lanes of the Road on which to spawn Agents |
| SStart | The S position specifying the minimum S for the range within which to spawn Agents |
| SEnd | The S position specifying the maximum S for the range within which to spawn Agents |
The TrafficGroups are defined by the following parameter:
| Name | Description |
| AgentProfiles | A set of <ListItem>s which define potential AgentProfile values for the Agents spawned in the SpawnArea and the probability at which the TrafficVolume will be selected |
| Velocity | A stochastic distribution describing the velocity in m/s of the spawned Agents |
| TGap | A stochastic distribution describing the gap in seconds between spawned Agents |
| Homogeneity | OPTIONAL: A vector describing the velocity increments for left lanes |
| RightLaneOnly | OPTIONAL: A flag determining whether this TrafficGroup can only be applied to the right most lane |
The PreRunCommon SpawnPoint will spawn common agents on the specified Lanes of the specified Road from the s position S-Start to the s position S-End with Traffic Parameters sampled from the specified TrafficVolumes, PlatoonRates, Velocities, and AgentProfiles lists with the following restrictions:
- If the Scenario Spawn Point spawned Scenario Agents (including the Ego agent) before this Spawn Point is triggered (in the intended order of these Spawn Points), ranges between the Scenario Agents are invalid for spawning by this Spawn Point.
The spawn ranges will only be augmented by Scenario Agents on the same Road and Lane.
As such, there are 7 different potential scenarios that may arise in terms of how the spawn point's valid spawn ranges may be impacted:
1. Two Scenario Agents on the same Road and Lane - one before S-Start position and one after S-End position
- This invalidates the entirety of the spawning range; no agents may be spawned here
1. Two Scenario Agents on the same Road and Lane - one between S-Start position and S-End position and one either before S-Start or after S-End
- The only valid spawn range is that on the opposite side of the in-specified-range Agent from the outside-specified-range agent
1. Two Scenario Agents on the same Road and Lane - both within the specified S-Start and S-End positions
- The valid spawn ranges are between S-Start and the first car and between the second car and S-End
1. Two Scenario Agents on the same Road and Lane - both outside the specified S-Start and S-End positions on the same side (both before S-Start or both after S-End)
- The specified spawn range is entirely valid
1. One Scenario Agent on the same Road and Lane - within specified S-Start and S-End positions
- The valid spawn ranges include all but the bounds of the Agent within the specified S-Start and S-End positions
1. One Scenario Agent on the same Road and Lane - outside specified S-Start and S-End positions
- The specified spawn range is entirely valid
1. No Scenario Agents on the same Road and Lane
- The specified spawn range is entirely valid
- If a non-existent road is specified, no spawning will occur
- If only non-existent lanes for an existent road are specified, no spawning will occur
- If some specified lanes exist and some are non-existent for an existent road, spawning will occur for the lanes which do exist
- If the specified S-Start and S-End positions are either beyond or before the S positions at which the specified Road and Lane combination exists, no spawning will occur
- In the situation where a section of a Road adds a new lane to the left of the currently existing lanes, one should be aware that the laneId "-1" will shift to the newest left lane and should adjust SpawnPoint profiles with this in mind
\section dev_framework_modules_spawnpoints_runtimecommonspawnpoint RuntimeSpawnPoint
The Runtime SpawnPoint (included in library "SpawnPointRuntimeCommon_OSI") is responsible for maintaining a populated scenery throughout the simulation runtime.
This SpawnPoint acts at each timestep throughout the simulation run and attempts to spawn Common Agents at the specified location(s).