search

eclipse-sumo / sumo

Eclipse SUMO is an open source, highly portable, microscopic and continuous traffic simulation package designed to handle large networks. It allows for intermodal simulation including pedestrians and comes with a large set of tools for scenario creation.
https://eclipse.dev/sumo
Eclipse Public License 2.0
2.5k stars 1.41k forks source link

allow probabilistic action-skipping #9681

Open namdre opened 2 years ago

namdre commented 2 years ago

To add a new cfmodel-independent mechanism for introducing driving error, define a new parameter x:

Each time a vehicle would compute new speed/acceleration (actionStep) it skips this action step with probability x and instead continues with the prior acceleration.

This is to model "distraction" rather than errors in estimation/actuation.

namdre commented 2 years ago

One might be tempted to put this into the driverstate device since it also features changing actionStep length based on awareness, however:

Thus action-skipping might be introduced on another level (executeMove, finalizeSpeed ?)

any suggestions @Domsall

Domsall commented 2 years ago

First of all, you are probably refering to the publication "The Intelligent Driver Model with stochasticity – New insights into traffic flow oscillations" from Treiber and Kesting?!

The EIDM already includes variable actionStep lengths (I think you already know this). But I think I need to explain the way it works and why I added the calculation to finalizeSpeed(), before I suggest anything:

When I started to work with SUMO back in 2017, the driverstate device did not exist yet. As I was new to SUMO and C++, I did not join the discussions and knew nothing about the ongoing parallel work. Therefore, I directly added the calculations to my model. The driverstate is actually implemented a lot better (modular framework/device for all cf-models) than what I did, although the error/perception functionality should somewhat be similar. I unfortunately did not have time to refactor my model code to include the driverstate device. I was too busy seperating the model from the rest of the code enhancements, which were pushed in different tickets.

However, from what I understand, there is one main difference: ActionPoints of the driverstate skip the whole CF/LC/junction calculation (planMoveInternal/patchSpeed/finalizeSpeed/setApproachingForAllLinks). That is great for speeding-up the simulation, but also makes it impossible to calculate a would if acceleration. Adding the (variable) action-step-length to the EIDM (with the correct storage of the underlying variables) was actually the hardest part of the model implementation.

The reasons: (also why to put the actionPoint update in finalizeSpeed()):

  1. The acceleration of the driverstate stays constant over the whole action-length. So driving errors only take effect every actionStep. The EIDM adds the errors to the acceleration in every timestep (to create noise).
  2. The main objective of the EIDM is to create a continuous change of acceleration. Especially in combination with the LC/Junction model and in subsecond simulation, the EIDM shall brake smoothly and not change its acceleration "hard". Therefore, I added temporal anticipation, which updates egos speed, the leaders speed and the gap according to the last actionPoint. So the model needs to calculate a new gap/speed/leaderspeed value each timestep (even between actionPoints).
  3. The first idea when implementing the EIDM was to use a reaction time instead of an action-step. A reaction time would mean that the model would always react to what happened 0.X s in the past. Due to memory issues, I did not implement the constant reaction time yet, because this would need vectors for all of the saved variables. Still, the original published Human Driver Model uses a reaction time and not an actionPoint.
  4. Lastly, the IDM-vehicles have problems changing the lane when only checking/adapting every actionPoint. The first assumption which resolved this issue: If the ego LC-model decides to change a lane, this wish can be seen as "immediate". Secondly, the model can then use the "immediate" value of patchSpeed() and for example slow down the execution or wait for the execution using actionPoints or reaction times (put the acc-value in a vector).

So my suggestions or suggested steps all together:

  1. Calculate and save the what-if-acceleration (maybe also the associated gap, speed, leaderspeed)
  2. If the acceleration difference between current-acc and would-if-acc is bigger than the probabilistic threshold, update with the previously calculated what-if-acc. If not, then use the current-acc (maybe with driver error and temporal anticipation additions?!).
  3. Make the new action-skipping selectable, so somebody not needing this feature would still profit from the speed-up of the current implementation