The sign of relative distance

[chiomega]

Dear, Developers Thanks for providing the esmini, It's one of the best simulator for OpenScenario.

I wonder how esmini consider the sign of relative distance. Openscenario specification does not refere the mathmatical form of relative distance.

We would chose two types of relative distance rule.

1. defined by the (target entity position - referenced entity position)
2. defined by the abs(target entity position - referenced entity position) #aboslolute value without sign are considered.

I checked the sign of value triggered by the larateral relative distance with test scenario (attached this issue.) The coordinateSystem and direction were chosen with 'entity' and 'lateral', respectively. esmini looked to adopt the rule 2.

I know there are pros and cons by using 1 or 2. I thought the rule 1 contains the meaning of the sign, for example, if the value is negative, target entity would exist the right hand side on the local entity coordinate. This is an advantage to investigate the condition of the target not only the distance but also the LR directions. Of course I can utilise the rule 2. But If we consider the concrete scenario as a kind of physics problem, the sign of the direction would help us to understand phenomena more precisely in my experience. I am not familiar the current field of study and just preffered the rule 1. If the policy of releative physical quantity is defined among the developers, I would like to know and refer the consideration.

References

• Specification of relative distance: https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/CoordinateSystem.html
• 6.3. Coordinate syst ems: https://www.asam.net/index.php?eID=dumpFile&t=f&f=4908&token=ae9d9b44ab9257e817072a653b5d5e98ee0babf8

relative_distance_lateral_direction_test.zip

[eknabevcc]

This is an interesting point. The standard stipulates non signed distance (your rule 2), see value range in RelativeDistanceCondition which is [0..inf].

I agree that as a result it's hard to distinguish inter-relative displacement, like in front/behind or left/right. Back in the days esmini actually accepted sign of distance for the LongitudinalDistanceAction. But from OSC 1.1 the displacement attribute was introduced to specify in-front or behind, (longitudinal and lateral).

It's a threshold to change current actions and conditions, but maybe OSC could introduce a condition (or two) to determine longitudinal and lateral displacement relation between objects (in-front/behind/left/right). Or simply add a boolean attribute (e.g. signed = true/false) to enforce signed distance.

But perhaps there is already a smart way to use existing condition to find out the same, that I miss here...?

E.g. Using DistanceCondition with RelativeRoadPosition to find out distance from road center (reference line) - to determine whether object is on right or left side of road. But I agree it's not elegant and there's limitations with this approach.

What would be your further thoughts on this topic?

[chiomega]

Dear, Developer

Thanks to reply for my issue.

I think the discussion of the sign may be trivial for just visualizing a simple scenario, but we would analyze the more complecated scenarios with helping of esmini's visualization.

I think the sign of relative distance would be important to analize or classify the scenario in case of the trajectory of cars intersect orthogonally. For example, the right turn scenario on junction. Egocar observes postive and negative relative distance from oncoming other car during standby for red traffic signal. This allows us to map the scenario on multidimensional linear space uniquely with smooth curve or surface and then these would be covenient to classify on the feature space with machine learning. (In my experience, abosolute value of some parameter would not be efficient to gain good results because it arises multi-solutions and we have to give some constraints additionally, usually such calculation needs "if divided sentence" for program.) The virture of the sign would be helpful for us to analyze the scenarios more simply. The relative speed would be considered as well in contrast to THW and TTC should be positive from the requirement of physical quantity.

I wonder these concern would be out of scope for a visualization tool. Originally, these should be discussed and be defined the mathematical expression of conditions by OpenScenario specification. I believe esmini become a standard visualization tool for OpenScenario and we will continue to use it. I wish abobe discussion would contribute to future development of esmini.