Introduce OSI Traffic Participants #56
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6 tasks
|
Output from CCB meeting - 11.11.2020 Actions:
|
clemenshabedank
approved these changes
Jan 25, 2021
Contributor
|
@pmai will we tag this version as 1.1.0? My changes then have a typo (i typed 1.2.0). Other than that it would be ready to merge in my opinion. |
Contributor
Author
|
@clemenshabedank yes, 1.1.0 would be better. Will change while rebasing for merge. Thanks for the clarifications! |
Signed-off-by: Pierre R. Mai <[email protected]>
Signed-off-by: Pierre R. Mai <[email protected]>
A few of the stated requirements were not actually needed. Relax these, to make it simpler for simulation environments to provide the needed data to the models. Signed-off-by: Pierre R. Mai <[email protected]>
In case a traffic participant does not need the initialization message, it can be omitted. Signed-off-by: Pierre R. Mai <[email protected]>
Signed-off-by: Pierre R. Mai <[email protected]>
Signed-off-by: Pierre R. Mai <[email protected]>
Fix missing mention of traffic participant models in first sentence. Use version=3.3.0 for examples where top-level messages are introduced in V3.3. Signed-off-by: Pierre R. Mai <[email protected]>
pmai
force-pushed
the
feature/osi-traffic-participants
branch
from
3942adc to
fce3f0d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is part of the SETLevel4To5 extensions of OSI and OSMP, introducing Traffic Participant as a model kind, as well as optionally separating out static content handling for planning and efficiency purposes:
A new model kind of Traffic Participant is added, which has one or more SensorView inputs, an optional TrafficCommand input, and a TrafficUpdate output which is fed back into the simulation. The optional TrafficCommand input allows control of the traffic participant by e.g. a scenario engine.
Optional GroundTruthInit parameters are introduced to all model kinds to allow receiving a complete set of static ground truth data prior to initialization start; this enables inter alia complex pre-processing to occur without endangering real-time performance.
As a corollary a PR to add a flag to omit static ground truth content from SensorView to the SensorViewConfiguration message is created in OSI. In combination this approach allows the reduction of transferred data by eliminating redundant transfer of static content.
It is currently on purpose left undefined, what exactly constitutes static content, since this definition should be done across OSI as a whole through the ASAM development process (i.e. to answer questions like: Are StationaryObjects static, even if they could be moved - e.g. traffic cones?, etc.).
The setup described by these changes is being used as mainbranch development platform for SETLevel4To5 model development.
It is being provided as a draft PR to aid in discussion of those changes in the relevant ASAM working packages. Additional changes from SETLevel4To5 might be pushed to the branch when released.
Check the checklist