Scheduled event lies in the past #326
-
|
I have built a scenario in a highway where vehicles need to update their speed and driving lane. Everything was going well until I introduced messages. As soon as I did that, I started having the error:
Even the lane changes and speed changes are all for future times. Does anyone have any idea what is causing this? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
I am almost positive it is caused by a change speedWithInterval called after a message was received. Probably because the simulation time when a message is received is not a round number; it is something like 385032908487, unlike what happens in scheduled events. |
Beta Was this translation helpful? Give feedback.
-
|
It is not uncommon for messages to have these kind of reception numbers, especially when you are using random delays. |
Beta Was this translation helpful? Give feedback.
-
|
It is a bit hard to send the code, but in summary, what I am doing when the error happens is:
What I think happens is because the simulation time at the message received time is not a multiple of the simulation time step (100 ms); when I try to change speed, it will create an event to a little after the next timestep. So, it will only handle it after two timesteps when, in reality, the event is in the past. I think I was able to fix that. So, now, if the simulation time is not a simulation time step, I calculate the needed offset for it to be and thus force the changeSpeedWithInterval to be in a multiple. |
Beta Was this translation helpful? Give feedback.
-
|
Hey, I was able to reproduce this issue and also think I found the error source and the issue was exactly what you've described. Looks like we had a little bit of a regression during one of our refactors. If you change the above line in the AbstractSumoAmbassador as follows, the times should be properly adjusted to the next simulation step in SUMO. Alternatively, you just wait a couple of days and merge the main-branch into yours.
long adjustedTime = adjustToSumoTimeStep(changeSpeedTimestep, sumoConfig.updateInterval * TIME.MILLI_SECOND); Sorry for that inconvenience and thanks for pointing it out! |
Beta Was this translation helpful? Give feedback.
Hey, I was able to reproduce this issue and also think I found the error source and the issue was exactly what you've described. Looks like we had a little bit of a regression during one of our refactors.
mosaic/fed/mosaic-sumo/src/main/java/org/eclipse/mosaic/fed/sumo/ambassador/AbstractSumoAmbassador.java
Line 873 in 7edbd22
If you change the above line in the
AbstractSumoAmbassadoras follows, the times should be properly adjusted to the next simulation step in SUMO. Alternatively, you just wait a couple of days and merge the main-branch into yours.