Bug in inductionLoop output triggered by lane-changing (trac #1831)

[behrisch]

Report by Mani:

I am having problem with loop detector detection logic. I have recorded a video and I would appreciate it if you could have a look (I am running the simulation step by step using Ctrl + D):

https://www.dropbox.com/s/789zjrpd4zrzzzk/loopDetector.mp4?dl=0

Vehicles are queueing up before the intersection and I am using a loop detector in each lane (in yellow). My focus is on the second loop detector from the top and I am printing the last detection time in the output console. Everything looks fine, but at t=159.7 some vehicles perform a lane change to the upper lane and that’s where I see a strange output in console. The last detection time at t=159.9 becomes 37.2889 and at t=161.4, last detection time is 0.001.

Migrated from http://sumo.dlr.de/ticket/1831

{
    "status": "assigned", 
    "changetime": "2016-10-14T10:39:37Z", 
    "description": "Report by Mani:\n\nI am having problem with loop detector detection logic. I have recorded a\nvideo and I would appreciate it if you could have a look (I am running the\nsimulation step by step using Ctrl + D):\n\nhttps://www.dropbox.com/s/789zjrpd4zrzzzk/loopDetector.mp4?dl=0\n\nVehicles are queueing up before the intersection and I am using a loop\ndetector in each lane (in yellow). My focus is on the second loop detector\nfrom the top and I am printing the last detection time in the output console.\nEverything looks fine, but at t=159.7 some vehicles perform a lane change to\nthe upper lane and that\u2019s where I see a strange output in console. The last\ndetection time at t=159.9 becomes 37.2889 and at t=161.4, last detection time\nis 0.001.", 
    "reporter": "namdre", 
    "cc": "", 
    "resolution": "", 
    "_ts": "1476441577749276", 
    "component": "simulation data output", 
    "summary": "Bug in inductionLoop output triggered by lane-changing", 
    "priority": "major", 
    "keywords": "", 
    "time": "2015-06-30T08:06:53Z", 
    "milestone": "1.0.0", 
    "owner": "namdre", 
    "type": "defect"
}

[behrisch]

@namdre commented:

The original scenario contains custom code so we probably need to replicated this ourselves.

[behrisch]

@behrisch changed milestone from "0.24.0" to "0.25.0"

[behrisch]

• @namdre changed milestone from "0.26.0" to "0.27.0"
• @namdre changed owner from "" to "namdre"
• @namdre changed status from "new" to "assigned"

[behrisch]

• @leoluecken changed _comment0 from:

I think that I found something related:

Tracing the calls to MSInductLoop::leaveDetectorByMove() and MSInductLoop::enterDetectorByMove() in test output/e1/one_vehicle/lane_change gives:

enterDetectorByMove(), detector = 'instant_beg_0_before', veh = 'v0' leaveDetectorByMove(), detector = 'instant_beg_0_before', veh = 'v0' enterDetectorByMove(), detector = 'instant_beg_0_at', veh = 'v0' leaveDetectorByMove(), detector = 'instant_beg_1_before', veh = 'v0' leaveDetectorByMove(), detector = 'instant_beg_1_at', veh = 'v0' enterDetectorByMove(), detector = 'instant_beg_1_after', veh = 'v0' leaveDetectorByMove(), detector = 'instant_beg_1_after', veh = 'v0'

This shows that 1) either the enter-call misses for 'instant_beg_1_before' or the corresponding leave-call should be disregarded (it leads to an update of myLastLeaveTime, but this might be ok [see below]). 2) either the leave-call misses for 'instant_beg_0_at' or the corresponding enter-call should be disregarded.

We need to define how a lane changing vehicle triggers enter and leave events in the surrounding inductionloops. Another situation arises if it changes while being on a detector partly or entirely (e.g. for high time resolution) and yet another for continuous lane-changing. I don't know how much of these situations are already solved for different detector types?

There seems to exist a lot of code duplication around there, by the way (see notifyMove()-variants of E1,2,3 and MeanData).

to:

1474618561870373

• @leoluecken commented:

Edit: I just saw that there exists also a method MSInductLoop::leaveDetectorByLaneChange() (albeit no MSInductLoop::enterDetectorByLaneChange()). Added call-traces for that function to the output below. I think that everything is fine except the extra call to leaveDetectorByMove() in case oldBackPos > myPos, which leads to an update of myLeaveTime, which shouldn't occur. I'm not sure if that can be responsible for the reported bug.

-------- first comment version -------

I think that I found something related:

Tracing the calls to MSInductLoop::leaveDetectorByMove() and MSInductLoop::enterDetectorByMove() in test output/e1/one_vehicle/lane_change gives:

enterDetectorByMove(), detector = 'instant_beg_0_before', veh = 'v0' leaveDetectorByMove(), detector = 'instant_beg_0_before', veh = 'v0' enterDetectorByMove(), detector = 'instant_beg_0_at', veh = 'v0' leaveDetectorByLaneChange(), detector = 'instant_beg_0_at', veh = 'v0' leaveDetectorByLaneChange(), detector = 'instant_beg_0_after', veh = 'v0' leaveDetectorByMove(), detector = 'instant_beg_1_before', veh = 'v0' leaveDetectorByMove(), detector = 'instant_beg_1_at', veh = 'v0' enterDetectorByMove(), detector = 'instant_beg_1_after', veh = 'v0' leaveDetectorByMove(), detector = 'instant_beg_1_after', veh = 'v0'

This shows that 1) either the enter-call misses for 'instant_beg_1_before' or the corresponding leave-call should be disregarded (it leads to an update of myLastLeaveTime, but this might be ok [see below]). [2) either the leave-call misses for 'instant_beg_0_at' or the corresponding enter-call should be disregarded.] (Edit: the leave seems to be managed by method leaveDetectorByLaneChange())

We need to define how a lane changing vehicle triggers enter and leave events in the surrounding inductionloops. Another situation arises if it changes while being on a detector partly or entirely (e.g. for high time resolution) and yet another for continuous lane-changing. I don't know how much of these situations are already solved for different detector types?

There seems to exist a lot of code duplication around there, by the way (see notifyMove()-variants of E1,2,3 and MeanData).

[behrisch]

@behrisch changed milestone from "0.28.0" to "0.29.0"

[namdre]

needs a recheck