Strange behavior when conflicting actions

[bleach31]

Regarding conflicting actions, OpenSCENARIO defineds it as follows:

https://www.asam.net/index.php?eID=dumpFile&t=f&f=4092&token=d3b6a55e911b22179e3c0895fe2caae8f5492467#_conflicting_actions

If it is determined that a newly triggered action conflicts with a currently ongoing action, the latter is overridden. Overriding a running action is equivalent to issuing a stop trigger to that action, see Section 4.4.

I'm doing an experiment on this using esmini v2.13.0.
I attached four sample scenarios of 2 sequential LaneOffsetAction : xosc.zip

The car is offset to 3m at the beginning, and next, the car is offset to 5m in the middle of first action.
priority attribute of all LaneOffsetAction is set to overwrite.

1. lane_offset_1_Event.xosc
   • LaneOffsetAction is written in two Actions in one Event
2. lane_offset_2_Maneuver.xosc
   • LaneOffsetAction is written in two Maneuver in one ManeuverGroup
3. lane_offset_3_ManeuverGroup.xosc
   • LaneOffsetAction is written in two ManeuverGroup in one Act
4. lane_offset_4_Act.xosc
   • LaneOffsetAction is written in two Act

Execution results:

• 1, https://www.youtube.com/watch?v=a9w7rpJZQ8wx
  • It looks like LaneOffsetAction is overwritten, but the car behaves non-continuously.
  • The lane offset begins again from the center of the lane, when the second LaneOffsetAction is started.
• 2 and 3 and 4, https://www.youtube.com/watch?v=b3OxcKr6Apw
  • When the second lane offset starts, the car behaves very strangely
  • The car is shaking and sliding, when the second LaneOffsetAction is started.

Neither of these results is what I expected.
I expected the car is offset to 5 m smoothly.

Is this bugs in esmini?
I'd like to hear the opinion about this of Esmini developers.

[esmini]

1
I see two events with one action each, not two actions in one event. And to me the behavior looks perfectly correct. The only strange "effect" is that the heading of the vehicle makes a discreet jump when event2 is triggered. But that's more a cosmetic side effect than a bug. Also note that it may look like the vehicle position jumps at that point, but the reference point is at rear wheel axle, which I believe is moving in a continuous way.

Please see screenshot below. It shows a replay of similar scenario (I adjusted timings for triggers and increased lateral acceleration to highlight the discreet heading change).

.\bin\esmini.exe --headless --fixed_timestep 0.01 --osc .\resources\tmp\lane_offset_1_Event.xosc --record sim.dat
.\bin\replayer.exe --window 60 60 800 400 --res_path .\resources --file .\sim.dat

2-4
Yes, you're absolutely right. The unexpected behavior is a result of esmini not resolving conflicting actions on same object and domain. Thanks for reporting this shortcoming and providing the scenario variants.

It should now be fixed by commit f5b3b40. It would be great if you could test it on your scenarios and report back if it works according to your expectations. Let us know if you need a release to test.

I created a modified version, xosc-modified.zip, of your scenarios exaggerating the maneuvers to more clearly see the effect. To compare results from the different scenarios I run:

.\bin\esmini.exe --headless --fixed_timestep 0.01 --osc .\resources\tmp\lane_offset_1_Event.xosc --record sim1.dat
.\bin\esmini.exe --headless --fixed_timestep 0.01 --osc .\resources\tmp\lane_offset_2_Maneuver.xosc --record sim2.dat
.\bin\esmini.exe --headless --fixed_timestep 0.01 --osc .\resources\tmp\lane_offset_3_ManeuverGroup.xosc --record sim3.dat
.\bin\esmini.exe --headless --fixed_timestep 0.01 --osc .\resources\tmp\lane_offset_4_Act.xosc --record sim4.dat

.\bin\replayer.exe --window 60 60 800 400 --res_path .\resources --file .\sim1.dat

looks exactly the same as the other:

.\bin\replayer.exe --window 60 60 800 400 --res_path .\resources --file .\sim2.dat
.\bin\replayer.exe --window 60 60 800 400 --res_path .\resources --file .\sim3.dat
.\bin\replayer.exe --window 60 60 800 400 --res_path .\resources --file .\sim4.dat

.\scripts\dat2csv.py .\sim1.dat
.\scripts\dat2csv.py .\sim2.dat
.\scripts\dat2csv.py .\sim3.dat
.\scripts\dat2csv.py .\sim4.dat

Comparing the resulting sim1.csv with sim2.csv, sim3.csv and sim4.csv in e.g. WinMerge or any other diff tool proves they are exactly the same.

Also we added a smoke-test using a modified version of your maneuver scenario (conflicting-domains.xosc), to ensure correct behavior is maintained. I hope that's OK with you.

[bleach31]

Thanks for the update.
I built it and tried it.

The strange behavior of case 2-4 is fixed completely!

Now, all case is the same behavior as case 1 of first comment.

But that's more a cosmetic side effect than a bug. Also note that it may look like the vehicle position jumps at that point, but the reference point is at rear wheel axle, which I believe is moving in a continuous way.

To validate this, I used CSV output.

Column971 is the moment of the second OffsetAction.

Y-axis acceleration and yaw rate appear to be still discontinuous.

[esmini]

Yes, that's correct. When the second LaneOffset interrupts the first one there is a sudden discontinuous change in heading and lateral velocity & acceleration. It's because the LaneChange action will always start with heading pointing along road direction.

The CSV output shows more clearly what can be seen in my screenshot above as a "knee" (heading discontinuity) in the trajectory where second LaneOffset take over.

This behavior is probably not preferred. A more realistic and elegant behavior would be to interpolate from current heading whatever that is. So you can regard the defect as a shortcoming in esmini, due to simple kinematics and lacking of transitions between actions. For now this will be the expected behavior from esmini (but maybe we'll add dynamics in future that optionally will produce more realistic motion).

[bleach31]

For now this will be the expected behavior from esmini (but maybe we'll add dynamics in future that optionally will produce more realistic motion).

Thank you for your views.

It is very helpful for understanding the scope of current esmini.

I understood that it is correct as OSC interpreter, and that it was a problem of the kinematic model.

I close this issue.

Thank you again.

[eknabevcc]

Thanks for good report and feedback after testing solution.