Startup loss time/reaction time

[urielka]

Using Sumo 1.6.0 (and earlier versions for this matter) it seems that vehicles start to move as soon as the light turns green. It seems like the have no reaction time delay which should allow to model the startup loss time in reality (measured in 2-4 seconds). Can this behavior be modeled with some parameters?

todo:

• add new vType (generic cfmodel) parameter startupDelay (s) - accessible by all models
  • intial implementation for krauss only
  • apply when following a leader and ego vehicle waiting time > some threshold (actionStepLength?)
• add new vType junction model parameter jmTLStartupDelay
  • apply for first vehicle when light switches from red to green if vehicle waiting time > some threshold (actionStepLength?)

needs new internal state to distinguish two types of waiting (waiting for obstacle -> waiting due to model parameter -> driving)

[namdre]

The default model has a 'sigma' parameter (default 0.5) which creates random slow-down including at startup. You could increase this to get a bigger startup loss. However, normal driving will also be affected. We do have plans to model startup-loss explicitly: #3920

If the startup time loss is homogeneous in your fleet, you could also just model it by increasing the length of the red phase (-:

Do you have a reference for the 2-4 second value? I would assume the average to be <2s but of course this may vary by locality.

[urielka]

I am aware about sigma and as you said it would affect not only the startup time but the whole driving.

Adding more red time is interesting but it would make looking at the simulation less realistic.

Maybe something we can do via Traci?

How complicated is it to add it to the CF model? How are traffic lights modeled in sumo CF models? As a stopped vehicle?

[Kitsunow]

The reference for lost startup time at traffic light systems might be found in "Comparison of delay estimates at under-saturated and over-saturated pre-timed signalized intersections". It should be around 3-4s.

You could model it via stochastic components, have a look at Kerner-Klenovs Stochastic Traffic Model.

[Domsall]

The lost startup time is a bit misleading. I also have data of vehicles passing an intersection and the time between a light signal turning green and the first vehicle starting to drive is actually <2s like @namdre pointed out. The 3-4s refer to the vehicles passing the stop line, because they actually may stand a few meters away of the line and need that extra time to accelerate to their max value.

[namdre]

Then you could also tune the effect by increasing the distance to the stop line using vType attribute jmStoplineGap

[namdre]

Maybe something we can do via Traci?

In principle you can do pretty much anything via TraCI. You could detect that a vehicle is accelerating from low speed in front of a traffic light and then temporarily reduce the speed.

How complicated is it to add it to the CF model? How are traffic lights modeled in sumo CF models? As a stopped vehicle?

traffic lights are handled by the intersection model in the main simulation loop. Interaction with the cf model is via the call to stopSpeed but the model doesn't know whether this is for a traffic light or a schedule stop (i.e. public transport).

[rlloretb]

Do you guys plan to include it as a car-following parameter or will also be approach-specific? Lost time is crucial parameter in cycle length optimization for instance. While extending red time is a workaround, it can have unintended consequences, especially in low traffic scenarios. Extending the stopbar location is not great solution, either.

[namdre]

@rlloretb The solution from #3920 would make this a vehicle type specific setting. Do you think it would be relevant to have a location specific factor? Also, the proposed workaround with jmStoplineGap would not actually move the stopBar (location specific, lots of manual work) but rather modify the distance to the stop bar at which vehicles of a certain type stop (could easily be made into a distribution of values). What would be your objection to this, specifically?

[rlloretb]

Lost time is actually a driver-specific parameter. Even within the same vehicle type there could be heterogeneity. The location-specific factor is due to visibility of the light, proximity to intersection (not seeing the light), etc. But these would be second-order of importance, in any case.

Thanks for the clarification on jmStoplineGap. This parameter modifies the space dimension, while lost time is purely time dimension. It clearly alters the space-time region in the direction of lost time, but it also makes the queue longer and could block incoming free-flow speed vehicles which would not stop otherwise.

[rlloretb]

A cheap alternative is introduce an orange phase of length equal to the lost time and subtract it to the green time, but we lose the opportunity to express heterogeneity here.

[namdre]

Thanks for your response. I thought of more points that would make a modification via jmStoplineGap undesireable:

• the speed when entering the intersection will be increased with a higher value of jmStoplineGap
• the cumulative effects of startup loss time will not be achieved since only the first vehicle in the queue is affected

Further notes:

• Sumo allows for an orange phase. (state code is 'u').
• To model driver heterogeneity via vType parameters, a distinct type for every driver is generated. This is streamlined by generating a distribution of types and assigning this distribution to the vehicles: see https://sumo.dlr.de/docs/Definition_of_Vehicles,_Vehicle_Types,_and_Routes.html#vehicle_type_distributions

[rlloretb]

Thanks for the reply on driver-specific parameters. Lost time is normally modeled as a fixed cost at the beginning of green. That is enough for most people. Vehicle-specific parameter should be enough, but bearing in mind that most part of that cost is due to first vehicle. Later vehicles lost time tends to be shorter as in a standard reaction time of a CFM. Definitely, do not implement anything via jmStoplineGap. And using orange light... it is what I was using right now, not great, but gets the job done meanwhile.

[urielka]

Seems like this sparked quite a conversation :)

@namdre the orange phase seems like a nice workaround, can you explain how the CF model/intersection model works in that case?

@Domsall you are right, 2-4 seconds is for the vehicle to pass the stopline from the second he gets the green. it is somewhere along 1-2 seconds until an average vehicle starts moving from the time the traffic light changes.

BTW Is there any reaction time parameter we can play with? in essence the startup loss time can be seen like a delay in the driver reaction to the traffic light changing, in some CF model implementations the acceleration for example is calculated for the next step so by design you have one step of delay (reaction time) which gives a simple solution for this.

[Domsall]

Car-Following models can use the parameter Actionsteplength: https://sumo.dlr.de/docs/Car-Following-Models.html#actionsteplength The reaction time is then decoupled from the simulation step time.

[urielka]

@Domsall I assume this can't be changed dynamically by traci?

[namdre]

• The vehicles treat the orange phase just like red so it's basically a visual aid.
• traci provides function vehicle.setActionStepLength

[Domsall]

what do you mean with dynamically changing it? There are many different ways implementing a reaction time:

• You can assign different vehicles a different actionsteplength via vtype, so each vehicle could have a different actionsteplength from the beginning
• You can use the python-API or libsumo to call setActionStepLength (https://sumo.dlr.de/docs/TraCI/Change_Vehicle_State.html) and define if the action should take place immediately. I actually can't find setActionStepLength in the C++-TraCI-API, but maybe I'm missing it.
• You could get the traffic light information via getNextTLS and use the distance and state to force the vehicle to wait 1-2s before driving off (with setSpeed)

As I was writing, namdre also posted the command.

[klqkevin]

Do you guys plan to include it as a car-following parameter or will also be approach-specific? Lost time is crucial parameter in cycle length optimization for instance. While extending red time is a workaround, it can have unintended consequences, especially in low traffic scenarios. Extending the stopbar location is not great solution, either.

I'd like to know what the consequences of adding an extra red light to simulate a vehicle's lost time at start-up, and why, especially in low traffic conditions? @rlloretb

[namdre]

I'd like to know what the consequences of adding an extra red light to simulate a vehicle's lost time at start-up, and why, especially in low traffic conditions? @rlloretb

The startup delay should only apply to vehicles that had previously stopped. In low traffic conditions it happens more frequently that vehicles which are approaching a traffic light do not actually stop. If a vehicle just happens to arrive at the time when the light switches to green it would be impacted by the extra red time.

[rlloretb]

Any news on this? How can I help?

[namdre]

Somewhat related has been the introduction of 'sigmaStep' which makes 'sigma' works consistently at all step-lengths (#10494)

The latest thought on the startup-timeLoss is to model an explicit delay time that is applied every time the vehicle is accelerating after accumulating a minimum amount of waiting time. It will probably be a vType attribute called 'startupDelay'. i.e.startupDelay="0.5". The waiting time threshold will probably be a global threshold set via an option (--startup-wait-threshold)

To make make sub-second delays work at any simulation step-length, the effect of the the attribute must be a combination of letting a vehicle stop and reducing it's accelerations. (i.e the effect of startupDelay=0.5 at step-length 1s is to have the vehicle accelerate with half it's desired acceleration for the first second).

Possible extensions are

• permit startupDelay to be configured with a distribution (i.e. startupDelay=normc(0.5,0.2,0,1))
• allow modelling startupDelay as a connection attribute which is somehow combined with the vType attribute

A key question is whether this model is sufficient to capture the headway distribution at a traffic light stop line (where the first headway is much larger than the subsequent headways). I'm somewhat hopeful that it does because the current behavior without explicit startupDelay already reproduces this difference in headways (as an emergent property of startup dynamics).

If you have any data points that could be used to determine sensible defaults for the proposed model parameters, that would help.

[Domsall]

A few points from my work (available here: https://sumo.dlr.de/2020/SUMO2020_paper_28.pdf):

1. The hardest time I had implementing this into the EIDM were all the exceptions. Especially at priority junctions the vehicles need to take this into account when adapting to foe vehicles. That is why I put it into the followSpeed/stopSpeed-calculation. There may also be a better spot in the Code for this?! Maybe directly before/after finalizeSpeed (calculated in every step independent of ActionStepLength)?!
2. The startup loss time is a function of the reaction time and a slow to start time. Reaction time can already be set via ActionStepLength or high step-lengths. In the EIDM, the slow to start time is a factor, which is multiplied with a_max during drive off.
3. According to my work, introducing a slow to start time/factor should be sufficient to capture the correct headway distribution of the first vehicles (at least with the IDM). As @namdre pointed out, Krauss and IDM are already producing correct headway distributions after the first vehicles.
4. Mean Parameters/values for internal combustion engines: 1s reaction time + another 1.5s until a_max is reached.
5. Great point with the sub-second delay issue. One could use the sub-second iteration from the IDM.
6. Variables used for the EIDM: time when startup started
7. Parameters used for the EIDM: time until a_max is reached (should be slightly lower than the 1.5s), other parameters are not needed if the curve is just linear (should be sufficient).

I hope this helps ;-)

[namdre]

@Domsall If I understand your model correctly, you are tapering the start of the acceleration curve for the first x seconds with a factor. This is slightly different from the idea of having the vehicle remain halting for some time before starting to drive off. Also, the actionStepLength cannot really capture this because it may happen that the signal state change falls onto an action step (thus give a reaction time of 0).

The difference should be negligible when trying to calibrate for a specific headway distribution (or rather headway sequence distribution) but speed trajectory measurements should be able to distinguish between both effects.

Do you think that both effects could complement each other to improve the match with real world trajectories even for EIDM?

I intend to add the halting time extension as a generic carFollowModel feature that can be configured for all models (with a default of 0).

[Domsall]

You are absolutely right. The part I explicitly added was the "slow to start time" (because of inertia, etc.).

The reaction time or "vehicle remain halting time" belongs to the second part of the startup loss time. I used the internal ActionStepLength of the EIDM for this (approx. 0.5s). After adding driving errors, the positive effect was that the vehicles would start driving approx. 1s after the vehicle in front starts driving off. The ActionStepLength+driving error causes the EIDM-vehicle to stop at lower distances than minGap (e.g. stop at 1m, minGap is 1.5m). Therefore, these 0.5m must first be driven by the vehicle in front before the vehicle behind reacts.

Yes, it often happens that the signal state change falls onto this action step and then the first vehicle immediately drives off... This happens seldom in reality (as you wrote reaction time = 0s). But for me the reason is the missing constant delay/reaction time of the models (see https://sumo.dlr.de/userdoc/Car-Following-Models/EIDM.html#notes). At an ActionStep all variables are always "instantaneously" changed. Normally the full reaction time would be the sum of the (variable) ActionStepLength and a constant delay time. An interesting publication on this topic: "Modeling the Imperfect Driver: Incorporating Human Factors in a Microscopic Traffic Model" by Lindorfer et. al. (www.doi.org/10.1109/TITS.2017.2765694)

Adding a constant reaction/delay time to all vehicles at all times would of course add new issues. So I think adding this "remain halting time after leader took off" would immediately help.

[rlloretb]

A related problem is the stop location at the stopbar line: not all first vehicles in a queue stop at the same position. Can this currently be modified?

[namdre]

Yes. See jmStoplineGap at https://sumo.dlr.de/docs/Definition_of_Vehicles,_Vehicle_Types,_and_Routes.html#junction_model_parameters

Probably requires createVehTypeDistrution.py to be useful.

[mschrader15]

@namdre initial sensitivity analyses are showing that network fuel consumption is quite sensitive to startupDelay. However, it is constant for a vehicle's lifetime (if I am not mistaken), which results in unrealistic trajectories in my opinion. The delay at three consecutive intersections is unlikely to be the exactly the same for a driver.

We think anecdotally that startupDelay at a newly green traffic light follows a log-normal distribution or similar for Tuscaloosa. Each vehicles' stops should be drawn independently from the distribution instead of the delay being constant at each stop that the vehicle makes.

Has there been any progress on the extensions that you refer to here ?

Possible extensions are

* permit startupDelay to be configured with a distribution (i.e. `startupDelay=normc(0.5,0.2,0,1)`)

* allow modelling startupDelay as a connection attribute which is somehow combined with the vType attribute

[Domsall]

@mschrader15 From what I understand, the issue is twofold:

1. Inter-driver variability: A startupDelay vType attribute configured with the distribution normc(0.5,0.2,0,1) would result in each driver having a different startupDelay (but constant over the vehicle's lifetime) and could possibly be implemented with #8492.
2. Intra-driver variability: What you are looking for. I would even go further and say every driver parameter should vary throughout the simulation. BUT: Calibrating this behavior is extremly hard. Nevertheless, I also think that getting a "new" startupDelay from a distribution before every startup makes sense in some cases. Until that kind of feature is added: You can add a variability through the ActionStepLength. This already changes the startupDelay for a single driver at every intersection. The distribution is just not a log-normal one.

[mschrader15]

Hey @Domsall thanks for the thoughts. We achieve Inter-driver variability through vehicle distribution files, which I think is nearly the same at #8492, provided the vehicle distribution file is sufficiently large.

Regarding 2, I agree that Intra-driver calibration would be extremely hard. However, I would argue that in most cases, Inter-driver startup delay should be modeled as Intra-driver delay for realistic trajectories. I have tried actionStepLength but the interplay of it with other car-following parameters raises other "realistic" driving issues.

Another interesting possibility is to model it as a junction or connection parameter. Important to note that this is purely from observation in the city that I am modelling, but drivers are more likely to begin looking at their phones during a red light event on a side street and thus having a long "startupDelay" before they realize that the red has switched to green at a signalized intersection.

(P.S. what you have done with EIDM is really interesting stuff. Enjoyed your SUMO UC paper on the development and validation of it!)

[namdre]

Has there been any progress on the extensions that you refer to here ?

Possible extensions are

* permit startupDelay to be configured with a distribution (i.e. `startupDelay=normc(0.5,0.2,0,1)`)

* allow modelling startupDelay as a connection attribute which is somehow combined with the vType attribute

Sorry for the late reply. There hasn't been progress on either of these points. Which one would you think to be more useful in the short term?

[mschrader15]

No problem! The most useful parameters for me would be startupDelay as a connection attribute, where each vehicle samples from a specified distribution for that connection.