Add tolerances and steady state to Synchronize action

Describe the feature

The SynchronizeAction of v1.0 lacks tolerance attributes for the two target positions. It is left to the simulator to decide when an entity has reached its destination point. It has come to our understanding that one criteria doesn't fit all use cases. For example, when following a trajectory you could use a tight tolerance and get precise results. On the contrary, a human driver in the loop will come more or less far away from a destination point, calling for a more generous tolerance. By introducing optional tolerances the user can adapt and optimize the behavior to the use case.

Additionally, it has been requested to add an optional final SteadyState phase, which would ensure the controlled object to have a constant speed during a final part of the travel to target destination. This seems to be useful for many use cases, e.g. EuroNCAP AEB VRU. In effect this means that synchronization, i.e. regulating vehicle speed, will only happen until steady state starts, but synchronization taking the final phase with constant speed into account. The start of steady state is specified as either a distance to the target position (minus tolerance) or remaining time until arrival to target position (minus tolerance).

Describe the solution you would like

Add tolerance attributes for the two positions plus steady state element:

<xsd:complexType name="SynchronizeAction">
    <xsd:all>
        <xsd:element name="TargetPositionMaster" type="Position"/>
        <xsd:element name="TargetPosition" type="Position"/>
        <xsd:element name="FinalSpeed" type="FinalSpeed" minOccurs="0"/>
    </xsd:all>
    <xsd:attribute name="masterEntityRef" type="String" use="required"/>
    <xsd:attribute name="targetToleranceMaster" type="Double" use="optional"/> *
    <xsd:attribute name="targetTolerance" type="Double" use="optional"/> *
</xsd:complexType>

<xsd:complexType name="FinalSpeed">
    <xsd:choice>
        <xsd:element name="AbsoluteSpeed" type="AbsoluteSpeed"/>
        <xsd:element name="RelativeSpeedToMaster" type="RelativeSpeedToMaster"/>
    </xsd:choice>
    <xsd:all> *
        <xsd:element name="SteadyState" type="SteadyState" minOccurs="0"/> *
    </xsd:all> *
</xsd:complexType>

<xsd:complexType name="SteadyState"> *
    <xsd:choice> *
        <xsd:element name="TargetDistanceSteadyState" type="TargetDistanceSteadyState"/> *
        <xsd:element name="TargetTimeSteadyState" type="TargetTimeSteadyState"/> *
    </xsd:choice> *
</xsd:complexType> *

<xsd:complexType name="TargetDistanceSteadyState"> *
    <xsd:attribute name="distance" type="Double" use="required"/> *
</xsd:complexType> *

<xsd:complexType name="TargetTimeSteadyState"> *
    <xsd:attribute name="time" type="Double" use="required"/> *
</xsd:complexType> *

* added lines

Description:

SteadyState               Optional final phase of constant (final) speed, start of which defined by distance or time.
TargetDistanceSteadyState The distance between object and target position.
TargetTimeSteadyState     The remaining time for object to reach target position.
targetToleranceMaster     double 0..1 Radius of tolerance circle around given TargetPositionMaster. Unit: m; Range: [0..inf].
targetTolerance           double 0..1 Radius of tolerance circle around given TargetPosition. Unit: m; Range: [0..inf].

Further description to be added either into reference (model) documentation or the User Guide

Distance to target position

The distance is measured from the scenario object's reference point to the outer edge of the target position tolerance circle (radius = tolerance). In effect subtracting the tolerance from the total distance between the object and the target position. See dashed lines in the image. In the case where the object hits the tolerance circle (case A and B in image) the distance decreases continuously, although not necessarily linearly, to zero. In the case where object do not hit the tolerance circle (case C), the distance will begin to increase before reaching zero.

Edit: following text and image removed according to decision at work group meeting 2020-12-17

If a valid route is found from the scenario object to its corresponding target position, either through road network or along a trajectory, then the distance is calculated along the identified route. Otherwise the Euclidean distance is applied.

End of action

The action ends when either of the following occurs:

• The action object reaches its target position
• The reference object reaches its target position
• The action object is moving away from its target position (distance is increasing)
• The reference object is moving away from its target position (distance is increasing)

The last two bullets implies that if the tolerance circle is missed, the action will end anyway when passing the destination (i.e. when distance change from decreasing to increasing), see case 3 in image above. In other words, the trigger and target positions should be defined in such a way that ever decreasing distance should be expected. It may, for example, be required to define two consecutive actions, like in the image below.

Steady State

Steady state is an optional final phase of the action where action object keeps constant speed. The start of this phase is defined by one of two options:

1. Action object reach a point where distance to target position (minus tolerance) is less than specified value.
2. Action object reach a point where remaining travel time, at specified FinalSpeed, to target position (minus tolerance) is less than specified value.

Describe alternatives you have considered

An alternative solution to tolerances would be to detect when the distance starts increasing instead of decreasing, as an indication of the destination has been reached or passed. But this lacks a way for the user to control the measurement of distance. Let say the use case is such that the target position might be missed with up to 5 meters. Then having no tolerance would result in action ending prematurely when 5 meters remains, with incorrect synchronization of positions and speed as a bad side effect.

So the circular tolerance area can be used as a tool to optimize behavior of the action. The increased distance stop trigger is a good fall back, if target is missed in spite of tolerance.

Regarding steady state, we have not come up with any alternatives to consider.

Just introducing optional tolerances and steady state is fairly 1. low risk and 2. non complicated in proportion to the value it brings.

By the way, the tolerance attribute would be the same attribute as used in the ReachPositionCondition.

Describe the backwards compatibility

Yes, making the new elements and attributes optional will keep the action XSD backward compatible. Omitting the attributes simply leaves it open to the simulator to determine when a destination has been reached, as it is in v1.0.