Language subset proposal (including behavior tree)
Disclaimer: Initial draft - Work in progress!
This is a proposal for the language semantic group. It tries to follow the discussed structure of the specific meeting. It contains following concepts, even they are not related:
- Proposal for language subset (not final, just a draft)
- Proposal with BehaviorTrees for temporal composition with references
This not a final draft at all, this is is going to extended / modified!!!
Proposal for language Layers (layers as proposed in last meeting)
In the following a layered concept is described. The focus is to add functionality step by step while keeping as minimal dependencies as possible. For this reason, this concepts does not make any assumptions regarding the concepts from the domain model, the atomic actions, modifiers and more! This is independent and can be build upon if needed.
Language Layer 1 - Basic syntax
As a first layer I would propose simple syntax definitions (to be extended). This needs to allow the notation of the most basic things.
As a start point I propose to use python or C++ syntax: https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax) C++: https://en.wikipedia.org/wiki/C%2B%2B#Language Python: https://en.wikipedia.org/wiki/Python_syntax_and_semantics
As python is more used among people with less programming experience, I kept the proposal in python style: This style can be changes as well as the lexic.
# For comments use only one way: # Multiple ways to comment things easily confuses people
# Example for module import
import basic_scenario_actions_osc_1_0_0
from tool_provider_a import cool_vehicles# Example for variable declaration
# The available types and actions are defined by the domain model group / Additional types can be imported
vehicle_1: Vehicle# Example for scenario declaration
def Scenario(name):
# parameter declaration
vehicle_1: Vehicle
# behavior description starts with execute (only one execute in a scenario/ type and action is arbitrary)
execute vehicle_1.follow_lane(100s) # Expressions ?Open question: should we provide non mandatory naming convention? (vehicle_1 vs Vehicle1, etc)
Language Layer 2 - Temporal composition
As a second layer one could introduce temporal composition operators, which allow to compose complex behaviors. The following proposal is based on behavior trees, which is a well studied research field and widely used in the gaming industry, robotics and AI. Attached you will find a paper which concerns explicitly with the topic of behavior trees and scenarios.
The following links may be helpful. Also feel free to contact me regarding this matter.
For more information just google it - since they are heavily used in the gaming industry, there are tons of implementations and even more books, papers, blogs ...
The most common composition nodes are: Sequences, Parallel and Selectors/Fallbacks. However we must not restrict to these, but define more. Especially the concrete definition of these composition nodes require further discussion!!! However I am not sure in which group this may take place, therefore I leave the definition of these composition node quite vague at this moment.
Here is an example what we can do now:
# import some stuff (The most basic things are already included)
import basic_scenario_actions_from_osc_1_0_0
from tool_provider_a import cool_vehicles
# scenario
def Scenario(overtake):
ad_vehicle: CoolADVehicle
overtaker: CoolFastVehicle
execute
Parallel:
ad_vehicle.follow_lane(100s)
Sequence:
overtaker.lane_change(left)
overtaker.get_in_front(ad_vehicle)
overtaker.lane_change(left)Language Layer 3 - Decorators
Even decorators are an essential element of behavior trees (especially for more advanced event driven BTs), I concern it as a separate layer, just for the sake of clarification! It requires some differentiation to the existing modifier! They are related to constraints, but they allow more then just constraining something.
In behavior Trees, decorators are used to decorate a scenario behavior, but do not influence the scenario behavior itself! Such decorators allow to influence the triggering and the modification of returned execution states. Hereby it can be controlled if, when, how long, under which circumstances and how many times a behavior can be executed, but the scenario behavior itself stays as it is. Contrary to the constraint concept, decorators can additionally control the triggering of scenario behaviors.
Examples for a decorator which constraints a scenario and one which re-triggers a scenario:
def Scenario(example):
vehicle: Vehicle
execute
Sequence:
# Decorator: Check constraint if lane exists - same as before
decorate(left_adjacent_lane == true)
vehicle.lane_change(left)
% Multiple decorators: check constraint
decorate(repeat(2))
decorate(right_adjacent_lane == true)
vehicle.lane_change(right)**Language Layer 4 - Not defined yet **
WIP
As this level more concepts with dependencies to other teams could be added. This may include Entity definitions and the definitions of actions.