AccelerationCondition triggered by the acceleration with SpeedProfileAction

[chiomega]

Hi, there.
I would like to make scenario which is stop-triggered by the AccelerationCondition given by SpeedProfileAction.
I set the speed profile as an uniform jerk acceleration motion with 1m/sec^3 from initial 10m/sec.

<LongitudinalAction>
<SpeedProfileAction followingMode="follow">
<SpeedProfileEntry time="0.0" speed="10.0"/>
<SpeedProfileEntry time="1.0" speed="10.5"/>
<SpeedProfileEntry time="2.0" speed="12.0"/>
<SpeedProfileEntry time="3.0" speed="14.5"/>
<SpeedProfileEntry time="4.0" speed="18.0"/>
</SpeedProfileAction>
</LongitudinalAction>

and then, I wrote AccelerationCondition in StopTrigger.

<SpeedCondition rule="greaterOrEqual" value="12"/>

Unfortunately, It does not trigger with t=3sec.
Is there any better way?

[eknabevcc]

Just to clarify my understanding: The issue is not that stopTrigger does not happen, but that it happens at not exactly 3 sec.

Actually I think you encountered a bug.

I created two variants of your scenario: speed_variants.zip.
In speed_init.xosc the speed action is put in the Init section, while in speed_maneuver.xosc the speed action is in the Story.

Running the "init" variant I got:

2.950: Trigger /------------------------------------------------
2.950: StopCondition == true, speed: 12.00 >= 12.00, edge: none
2.950: Triggering entity 0: Car
2.950: Trigger  ------------------------------------------------/

While running the "story" variant I got:

3.000: Trigger /------------------------------------------------
3.000: StopCondition == true, speed: 12.00 >= 12.00, edge: none
3.000: Triggering entity 0: Car
3.000: Trigger  ------------------------------------------------/

The different is a consequence of updating Init actions (but not story actions) before stepping time and checking the story stopTrigger. Which is wrong, the story stop check should be first. It's now fixed by commit 4270410.

Please test and report if it works as expected. Let us know if you need a release.

[chiomega]

eknabevcc

Thanks for your reply and good examples.
I am sorry I had mistyped the line in my previous writing. It should be

<!-- <SpeedCondition rule="greaterOrEqual" value="12"/> -->
<AccelerationCondition rule="greaterOrEqual" value="2"/>

I attached modified scenario codes. This works without error but the stopping is triggered incorrectly than I expected.
I want to set the velocity profile with uniform jerk motion on straight road (initially, v=10m/sec, accleration=0m/sec^2 and jerk=1m/sec^3 as a constant value).

This setting is expected the time evolutions for x[m], v[m/sec], a[m/sec^2].

______| a[m/sec^2] | v[m/sec] | x[m]
0sec  | 0                 | 10.0        | 0
1sec  | 1                 | 10.5        | 10.166
2sec  | 2                 | 12.0        | 21.333
3sec  | 3                 | 14.5        | 34.5
4sec  | 4                 | 18.0        | 50.667
5sec  | 5                 |  22.5       | 70.833
6sec  | 6                 |  28.0       | 96.0

One question is why the above acceleration condition is satisfied in the first step unexpectedly on attached scenarios. I will attach the log files for the sample scenarios.

• log_init.xosc #generated from speed_init_edit.xosc, it is copied and edited the eknabevcc's examples with a replacement from speedcondition to accelerationcondition.
• log_story.xosc #generated from speed_story_edit.xosc
• log_story_trajectory.xosc #generated from speed_story_edit.xosc but I wrote private action with redundant expression, that is RoutingAction tag.

Actually I guess the esmini would calculate the acceleration numerically with given discrete velocities. The prompt termination would be caused by the exaggerated value of acceleration. The sudden jump of acceleration would not be realistic for driving car. I would like to ease the overestimation of acceleration in initial state if possible. If the calculation scheme is carried out with the 1st order difference formula, it would be improved with using 2nd order one.

speed_variants_edit.zip

[eknabevcc]

I think there a misinterpretation of the time attribute in the speed profile entries. Time is specified in delta steps, so I think your time entries should be something like 0, 1, 1, 1, 1, ...

Please see speed_init_edit-mod.xosc.txt.
I run it with:

./bin/esmini --headless --fixed_timestep 0.02 --record sim.dat --osc speed_init_edit-mod.xosc --csv_logger csv_log.csv

It results in this Excel graph:

and with plot_dat.py:

Uncomment the acceleration condition gives:

Do you think this makes more sense and will be useful for your use case?

[chiomega]

Thanks eknabevcc,

It works correctly. I checked "time" means delta step in this tag.
The SpeedPrifileAction is useful to define the movement of acceleration and decelation more precisely.

I think there a misinterpretation of the time attribute in the speed profile entries. Time is specified in delta steps, so I think your time entries should be something like 0, 1, 1, 1, 1, ...
Do you think this makes more sense and will be useful for your use case?

[eknabevcc]

Great! Thanks for feedback.
I close the issue.