The relative heading of the given heading with respect to ego (or the heading provided with the optional from heading)
The apparent heading of the OrientedPoint, with respect to the line of sight from ego (or the position provided with the optional from vector)
The distance to the given position from ego (or the position provided with the optional from vector)
The heading (azimuth) to the given position from ego (or the position provided with the optional from vector). For example, if angle to taxi is zero, then taxi is due North of ego
The altitude to the given position from ego (or the position provided with the optional from vector ). For example, if altitude to plane is π, then plane is directly above ego.
Whether or not a position or Object is visible from a Point or OrientedPoint, accounting for occlusion.
See the :ref:`Visibility System <visibility>` reference for a discussion of the visibility model.
Whether a position or Object lies in the Region; for the latter, the object must be completely contained in the region.
Whether an Object/Region intersects another Object/Region, i.e. whether any portion of the occupied spaces intersect.
When working with 2D regions, it can be useful to check intersection with the :term:`footprint` of a region, e.g. when checking whether a car intersects a given lane. In this case, one would write :scenic:`car intersects lane.footprint` instead of :scenic:`car intersects lane`. For more details, see :term:`footprint`.
The given angle, interpreted as being in degrees. For example 90 deg evaluates to π/2
The orientation specified by the vector field at the given position
The orientation obtained by starting in the second direction and then rotating according to the first direction. For example, :scenic:`-5 deg relative to 90 deg` is simply 85 degrees. If either direction is a vector field, then this operator yields an expression depending on the :prop:`position` property of the object being specified. Both operator values must be of type heading, Orientation, or vectorField, not tuples, as tuples are by default intepreted as Vector objects.
Note
This operator is not necessarily commutative, for example, when composing two 3D orientations.
The first vector, interpreted as an offset relative to the second vector (or vice versa). For example, :scenic:`(5, 5, 5) relative to (100, 200, 300)` is :scenic:`(105, 205, 305)`. Note that this polymorphic operator has a specialized version for instances of OrientedPoint, defined :ref:`below <{vector} relative to {OrientedPoint}>`: so for example :scenic:`(-3, 0, 0) relative to taxi` will not use the version of this operator for vectors (even though the Object taxi can be coerced to a vector).
The second vector, interpreted in a local coordinate system centered at the first vector and oriented along the given direction (which, if a vector field, is evaluated at the first vector to obtain an orientation)
The part of the given region which is visible from the ego object (i.e. the intersection of the given region with the :term:`visible region` of the ego).
The part of the given region which is not visible from the ego object (as above, based on the ego's :term:`visible region`).
The part of the given region visible from the given Point or OrientedPoint (like :scenic:`visible {region}` but from an arbitrary Point/OrientedPoint).
The part of the given region not visible from the given Point or OrientedPoint (like :scenic:`not visible {region}` but from an arbitrary Point/OrientedPoint).
The given vector, interpreted in the local coordinate system of the OrientedPoint. So for example :scenic:`(1, 2, 0) relative to ego` is 1 meter to the right and 2 meters ahead of ego.
Equivalent to :scenic:`{vector} relative to {OrientedPoint}` above
The midpoint of the corresponding side of the bounding box of the Object, inheriting the Object's orientation.
The midpoint of the corresponding edge of the Object’s bounding box, inheriting the Object's orientation.
The corresponding corner of the Object’s bounding box, inheriting the Object's orientation.
Temporal operators can be used inside :keyword:`require` statements to constrain how a dynamic scenario evolves over time. The semantics of these operators are taken from Linear Temporal Logic (specifically, we use RV-LTL [B10] to properly model the finite length of Scenic simulations).
Require the given condition to hold throughout the execution of the dynamic scenario.
Require the given condition to hold at some point during the execution of the dynamic scenario.
Require the given condition to hold at the next time step of the dynamic scenario.
For example, while :scenic:`require X` requires that X
hold at time step 0 (the start of the simulation), :scenic:`require next X` requires that X
hold at time step 1.
The requirement :scenic:`require always (X implies next X)` says that for every time step N, if X
is true at that time step then it is also true at step N+1; equivalently, if X
ever becomes true, it must remain true for the rest of the simulation.
Require the second condition to hold at some point, and the first condition to hold at every time step before then (after which it is unconstrained).
Note that this is the so-called strong until, since it requires the second condition to eventually become true. For the weak until, which allows the second condition to never hold (in which case the first condition must always hold), you can write :scenic:`require ({X} until {Y}) or (always {X} and not {Y})`.
Require the conclusion to hold if the hypothesis holds.
This is syntactic sugar for :scenic:`not {hypothesis} or {conclusion}`.
It is mainly useful in making requirements that constrain multiple time steps easier to read: for example, :scenic:`require always X implies Y` requires that at every time step when X
holds, Y
must also hold.
References
[B10] | Bauer et al., Comparing LTL Semantics for Runtime Verification. Journal of Logic and Computation, 2010. [Online] |