-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add conditions to sstudio
#1965
Conversation
ace7492
to
e335fe6
Compare
smarts/sstudio/types.py
Outdated
"""This compounds multiple conditions. | ||
|
||
The following cases are notable | ||
CONJUNCTION (A AND B) | ||
If both conditions evaluate TRUE the result is exclusively TRUE. | ||
Else if either condition evaluates EXPIRED the result will be EXPIRED. | ||
Else if either condition evaluates BEFORE the result will be BEFORE. | ||
Else FALSE | ||
DISJUNCTION (A OR B) | ||
If either condition evaluates TRUE the result is exclusively TRUE. | ||
Else if either condition evaluates BEFORE then the result will be BEFORE. | ||
Else if both conditions evaluate EXPIRED then the result will be EXPIRED. | ||
Else FALSE | ||
IMPLICATION (A AND B or not A) | ||
If the first condition evaluates *not* TRUE the result is exclusively TRUE. | ||
Else if the first condition evaluates TRUE and the second condition evaluates TRUE the result is exclusively TRUE. | ||
Else FALSE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is how the condition operators evaluate.
Notable oddities are:
- On conjunction, if either condition is expired the conjunction will always be expired.
- On disjunction, if both conditions are expired the disjunction will always be expired.
- On implication, the resulting condition can only be TRUE or FALSE. The only theoretical case where BEFORE or EXPIRED can occur is when the first condition evaluates as a constant TRUE (via LiteralCondition and negations and combinations of) but I have not handled that case.
scenarios/sumo/intersections/1_to_2lane_left_turn_t_agents_1/scenario.py
Outdated
Show resolved
Hide resolved
f"Actor aquisition skipped for `{agent_id}` scheduled to start between " | ||
+ f"`{mission.start_time}` and `{patience_expiry}` has expired with no vehicle." | ||
f"`simulation time: {sim.elapsed_sim_time}`" | ||
+ f"`Condition `{entry_tactic.condition}` has expired with no vehicle." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This message might need to be reworked since we aren't just dealing with a time window anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conditions have an EXPIRED
state which is lowest priority on OR operations and highest on AND operations. So it is still possible to expire. If the condition never generates EXPIRED
it will never expire.
There are cases like such:
>>> condition = LiteralCondition(ConditionState.FALSE).expire(20)
>>> condition.evaluate(time=10)
<ConditionState.FALSE: 0>
>>> condition.evaluate(time=21)
<ConditionState.EXPIRED: 2>
I have some thoughts that we should add utilities to handle additional temporal logic:
.hold(count_seconds=5, emit=ConditionState.True)
.then(other_condition)
.on_hold(count_seconds=5, hold_states=[ConditionState.FALSE, ConditionState.TRUE], emit=ConditionState.EXPIRED)
.on_expired(other_condition)
This introduces conditions to
sstudio
to give a way of expressing conditions on which something occurs. As part of this change, entry tactics will use conditions instead of the way they currently work.The condition operators are inspired by the OpenSCENARIO logical operators: https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/expressions_main.html#sec-lc-operators-logical
Closes #1963