eclipse-sumo
EIDM strange acceleration behaviour
With timestep 0.5, everything is fine. With timestep 0.2 or below, the bus vehicle makes strange acceleration behaviour, see image and files below. Any idea, why this could happen? The action-step-length doesn't work with this model, so I don't know how to get a resolution smaller than 0.5s without that strange behaviour
SUMO-version: 1.13
Yes, I already saw it, but won't be in office until september.
What I can already tell you: The EIDM has received a lot of updates lately. Some are still open as pull request and some issues were already fixed with 1.14.1 (one issue was startupDelay, driving at low speeds with low timesteps).
When I am back in office, I will check out the updated SUMO version. I will then look into your scenario and fix the issue, if it still exists.
The issue is somewhat similar to #11461:
In
https://github.com/eclipse/sumo/blob/b1b3affb711ba6944307d7d4fb5eaf9adf5bed6f/src/microsim/MSVehicle.cpp#L2363
and
https://github.com/eclipse/sumo/blob/b1b3affb711ba6944307d7d4fb5eaf9adf5bed6f/src/microsim/MSVehicle.cpp#L2369
the freeSpeed/stopSpeed calculations update a future speed value. The EIDM assumes that the call to followSpeed/freeSpeed with the lowest calculated acc-value will result in the next speed update. This does not hold here and the model "gets confused". The saved values between two actionsteps do not belong to the correct followSpeed/freeSpeed-calculation.
@namdre:
- Can the values for
adaptLeaveSpeedbe picked up elsewhere? -
endPosis the position on the future lane withoutseen. CannewStopDistbe used here?
endPos is the position on the future lane without seen. Can newStopDist be used here?
The computed speed anticipates the point in the future where the lane with the stop is being entered. Thus, 'endPos' is the correct distance value here.
Can the values for adaptLeaveSpeed be picked up elsewhere?
As you have pointed out, some calls to the carFollowModel are used in reference to the current situation (i.e. current speed to follow a leader) whereas the adaptLeaveSpeed calls are in reference to distances and speed requirements that will be encountered in the future.
I think the cleanest solution would be to indicate this context to the carFollowModel by adding an new optional parameter to selected carFollowModel functions (futureSpeed=false)
We do have some precedence in using a global variable (gComputeLC) to indicate context but this follows a much cleaner seperation of code sections whereas the calls for adaptLeaveSpeed are interwoven with the current-situation calls. Hence I think an optional parameter would be cleaner.
@behrisch What do you think about this?
As you have pointed out, some calls to the carFollowModel are used in reference to the current situation (i.e. current speed to follow a leader) whereas the adaptLeaveSpeed calls are in reference to distances and speed requirements that will be encountered in the future.
I thought the double-calculation of freeSpeed and stopSpeed may be changed to one function call like in
https://github.com/eclipse/sumo/blob/7723a297573d9b92e0200b1b379a3144d4c349b1/src/microsim/MSVehicle.cpp#L2427-L2431
and
https://github.com/eclipse/sumo/blob/7723a297573d9b92e0200b1b379a3144d4c349b1/src/microsim/MSVehicle.cpp#L2451-L2454
(That was the original reason for my question about changing endPos to newStopDist)
I think the cleanest solution would be to indicate this context to the carFollowModel by adding an new optional parameter to selected carFollowModel functions (futureSpeed=false)
That would also help :)
I thought the double-calculation of freeSpeed and stopSpeed may be changed to one function call like in ...
The current code is the result of a recognized issue: https://github.com/eclipse/sumo/issues/1560
The problems with the other adaptLeaveSpeed calls are just a bit less obvious but it should be possible to construct a test which shows their problem.
These places actually compute a wrong upper bound on the leaveSpeed on occasion:
- the future leaveSpeed may be lower because the vehicle is closer to a lane end or to it's arrivalPos in the future.
- the future leaveSpeed may be higher because the current stopSpeed is constraint by maxNextSpeed
We do have some precedence in using a global variable (gComputeLC) to indicate context but this follows a much cleaner seperation of code sections whereas the calls for adaptLeaveSpeed are interwoven with the current-situation calls. Hence I think an optional parameter would be cleaner. @behrisch What do you think about this?
This would solve this issue and #11461. I can do the work.
This would solve this issue and https://github.com/eclipse/sumo/issues/11461. I can do the work.
Excellent! Please do.
After discussing with @behrisch we concluded that MSCFModel should get a new enum type with two values (CURRENT, FUTURE) and the new optional parameter should be of this type. This way it's easier to add more context categories later on.
ok, to get it right: CURRENT is the Default and freeSpeed/followSpeed/stopSpeed shall therefore all get a new input parameter?
After I uploaded the pull-request you can of course still change parts.
Yes. This way we only need to actively set the new parameter in the context of the adaptLeaveSpeed computations.
For stopSpeed, I need another differentiation:
- A call may come from adaptLeaveSpeed, which will not result in the current speed update (
FUTURE) - A call may come from the junction model, where it is not sure, if this will be part of the next speed (
?). See also #7642 - A call may come from the following line, which will be part of the current speed update (
CURRENT) https://github.com/eclipse/sumo/blob/b1b3affb711ba6944307d7d4fb5eaf9adf5bed6f/src/microsim/MSVehicle.cpp#L2367
What shall I use here? And: Can I set the Default of stopSpeed to this new value? That value was the standard for the EIDM until now.
I would also add a new value, called LANE_CHANGE to all Lane-Change calls, if this is wanted.
I suggest CURRENT_WAIT for the vLinkWait computation. I think the default should still be CURRENT: Calls related to stopping at lane-end or planned stops are always applied.
I think adding LANE_CHANGE would clutter up the code and be redundant since we already have gComputeLC. Also, we cannot get rid of gComputeLC since it's used in other parts of the code where it would be awkward to add new context parameters.
The followSpeed call from 9533f3912f8f7446432400a3fd50e961c0d6979f also requires the flag FUTURE
Update: I changed the Code, but stumpled across the function MSVehicle::adaptToJunctionLeader.
Its a bit tricky to implement the optional parameter for these calls, because not the lowest value is chosen (MIN) as next speed, instead the highest value is used (MAX).
One "easy" way to solve this issue, would be to call stop/follow with FUTURE. After the calculation, we could then call the "correct" stop/followSpeed with CURRENT again. I do not really like this solution, but am getting a headache trying to come up with other fixes.
Do you have any suggestions?
I don't like the idea of calling the method a third time, just to signal the 'correct' call. I'd rather invent another flag (CURRENT_LOWER_BOUND) which signals that the call establishes a lower bound on speed rather than an upper bound (as is the default). The model should be able to figure out how to integrate the data from such calls.
I don't like the idea of calling the method a third time, just to signal the 'correct' call.
hm... me neither. An extra flag seems not to work here, because the MAX-call is not done with the currently "saved" speed from previous calls. The model does not save values from previous calls, if they did not result in a lower speed. We even have 2 values that may influence the resulting speed (v2 and vStop)
I was thinking that your model could save all the calls with the new CURRENT_LOWER_BOUND_FLAG and then integrate them in a different manner. Or maybe even just ignore them (and see how far this gets you)
no matter what I do, it does not seem to work.
The last possibility I see, is to rewrite the function a bit and add a CFModel-dependent function. This function would only add a third call when running with the EIDM. I will push this for further review.
As far as I see it, the new context parameter should not make things worse than the old situation where the context is lacking. and with the new CURRENT_WAIT context some things should better than before. Maybe you can push this and we think about new model functions in a second step?
@Asocius Please check, if your issue still persists. You can get the updated SUMO-version by downloading the nightly build or by getting the current github-version and building yourself.
Sorry for getting back so late. It seems to be a lot better than before, here is a plot of 10 Hertz frequency with EIDM:
So we can finally use EIDM for subsecond simulation :-) Thank you both! Edit: It's the acceleration, not the speed - I screwed the axis labels up