Reference points in SyncAction

[ReiDa8684]

Hello,
i am following up the issue "Steady state phase of target in SyncAction" of @johannesWen
We still try to simulate a EURO NCAP CPTA scenario, in which the (planned or synchronized) crash point needs to be reached very exactly.
The SyncAction really simplifies a lot, but is there any way to use other reference points then the center of the rear axle in OpenScenario?

I tried several approaches to reach a precise crashpoint:

1) using just one global coordinate of the crashpoint for both, the syncpoint of the ego (SE) and the target (ST)
As you can see in the attached figure, this leads to the situation that the rear axles overlap at the correct point and time, but is obvioulsy not what was intended.

2) changing the bounding boxes of the vehicles
Maybe ok on straight trajectories, but in curves this led to very strange graphical representation, e.g. not respecting basic physics, that the wheels of the rear axle do not slide in lateral direction.

3) shifting the syncpoints of the ego (SE) and the target (ST)
As you can see in the attached figure, this solves the problem in principle, but:
the shifting of the syncpoints is dependent on the dimensions of the vehicle, the geometry of the trajectory before the crash and also the geometry of the bumper.

4) [I have a dream] use local syncpoints
I am looking for something like in the attached figure. Let's extend the SyncAction, so that it accepts other syncpoints than the center of the rear axle. If it would be possible to define a syncpoint in the local coordinate system of the vehicles, it may look like in the figure: Definition of a global target position to be reached by a local syncpoint.

Just one more screenshot from CPTA description to illustrate my motivation:

I am fully aware, that this is not a esmini-specific problem but a limitation of OpenScenario. Anyway, any useful hint how to solve such situations are appreciated.

[bleach31]

I thought I had found the same problem coincidentally.
Have a look here.

#185

[eknabevcc]

@bleach31 Yes, you have the same or similar use case. The #185 issue is about esmini not respecting axle definitions, instead assuming rear axle is according to bound box center definition (vehicle ref point coinciding with rear axle).

@ReiDa8684 Thanks for excellent description of your use case. While the initial idea was not to control the exact end positions, more to end up in a critical situation and then quit the action some short time/distance before actual collision. But I see the use case and find it very interesting. So thanks for sharing your "dream" :)

After quick thinking about it:
The current implementation will either use distance along the road or simple Euclidean distance from ref points, just as you explained. It shouldn't be too hard to define sync points in terms of local offset from ref point. These points would simply rotate with the entity heading (at least if projected/constrained to 2D).

A question: What about freespace (true) distance? Would it be an alternative approach addressing the same use cases or would that be a totally different case? The freespace would continuously evaluate and choose sync point according to the closest distance from any point along the entity bounding box (corner or along a side) to the target point.

I realize one potential disadvantage being that measurement might be discontinuous over time, e.g. if the vehicle heading changes resulting in shifting local sync point (which point along the bounding box is closest to target point). On the other hand, one advantage is that the user don't have to think about and hard code the local sync point.

I agree that this should be discussed within OpenSCENARIO 1.X work group. So I actually created an issue there, linking to this issue for your excellent description.
In parallel with OpenSCENARIO progress I think that prototyping in esmini could be valuable (for understanding and testing concepts). But I don't know when that could happen. It also depends on internal needs and priorities.

[ReiDa8684]

@bleach31 good to see, that I am not the only one struggling with this topic.

@eknabevcc thank you for the valuable feedback and proposed next steps:

as an add-on to my motivation:
The intention of these tests is of course, to avoid a crash by taking a counter-action when a critical situation arises. The critical situations are defined however sometimes in such a way, that the crash situation (without a braking action) is described by using syncpoints, e.g. in Figure 7.1 of https://cdn.euroncap.com/media/43371/euro-ncap-aeb-vru-test-protocol-v301.pdf
On a proving ground this is done by carefully placing the ego and target at the intended crash points, store these positions as syncpoints, drive the vehicles back to starting positions and start the test. We are looking for an approach to realize the same critical situation in a simulation with oscx.

Concerning the proposed usage of "freespace":
Is this option already available for the syncaction in OpenSCENARIO?
At the moment, I also see some advantages and disadvantages but it may be a working solution.
I will test this option of course, any hint about how to combine this with the SyncAction?

An alternative approach:
I just realized, that one option may also be to define the targetPosition of the target relative to the reference point of the ego within the ego coordinate system. I have to draw some figures first (in order to check if I am not stuck in circular reasoning) and test this approach, but will come back with my results here in this place soon.

[ReiDa8684]

@eknabevcc I analyzed some new approaches and would like to post them here, maybe they are useful for the discussions within the work group:

1) Using "tolerance"

This approach seams to be possible already in OpenScenario and esmini and I will set up an test example. For straight trajectories I do not see any potential problems in this approach.

2) using local coordinate system of other vehicle

In this approach, the syncpoint which shall be reached by the target reference point is defined in the ego vehicles coordinate system. I was quite optimistic on this approach, but it turned out to be not feasible:
When the target (in my case a pedestrian) starts to accelerate, the ego is still far away, so the distance to be travelled for the pedestrian is huge. The target is therefore accelerated strongly. The planned crashpoint is moving toward the target, so the target is too early at the crashpoint and the scenario fails.
I assume that the same problems will arise when using the "freespace" approach, mentioned by you before.

preliminary Summary:

1. Using "tolerance" may be the best solution concerning already available features in OpenScenario and esmini. There has to be done some basic geometric calculations to compute the correct value of tolerance, but this seams to be possible. I will test it an provide feedback.
2. Using different (local) syncpoints then the center of the rear axle as proposed above "in my dream" would simplify the situation. This should be easy to be implemented in simulators like esmini but requires an extension of OpenScenario. I would be thankful, if you can push this in the working group.