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.57k stars 1.44k forks source link

NEMA should support "fake" detector calls via Traci #10045

Closed mschrader15 closed 2 years ago

mschrader15 commented 2 years ago

We have two use cases for this currently:

  1. To enable advanced testing of the NEMA logic, I would like to "bypass" traffic generation all together and instead directly send detector calls to NEMA and SIL controller using Python. Doing this would let me properly unit test the NEMALogic.
  2. To emulate our field implementation of advanced control algorithms, where the control algo will be implemented by placing fake detector calls to the traffic light controller.

@qichaow what are your thoughts? This is almost the same as trafficlight.setNemaPhase(tlsID, xyz) referenced here https://github.com/eclipse/sumo/issues/9912#issuecomment-1009423114, but it has some important differences, specifically not bypassing the internal logic of the controller.

@namdre I suppose this could be implemented on the Detector traci API as well, which may make it more general. I'd defer to you on the best approach to take if we go that route. NEMALogic calls the https://github.com/eclipse/sumo/blob/e3988a169356cb505b5782974a7a12781528578c/src/microsim/output/MSE2Collector.cpp#L1460 function to check whether a detector is active or not.

namdre commented 2 years ago

I'm thinking of adding a function like traci.lanearea.setVirtualVehicleNumber(detID, count) to artificially inflate/deflate the returned value of getCurrentVehicleNumber() (deflating it could also be used to test detector malfunction!)

Not sure whether it would be better: a) automatically reset virtual vehicles after every step b) keep them indefinitely until removed with another call to setVirtualVehicleNumber(detID, 0)

Another related thing: I recently modified the naming schema for automatically-built-induction loops of traffic light type 'actuated' (#9955). It might be worthwhile to do a similar thing for the laneAreaDetectors built by NEMA so it's easier to figure out on what detID to call setVirtualVehicleNumber. In #9955 I tried to mirror the naming scheme used by German traffic engineers. Hence it would be good to know how NEMA detectors are typically named. Is there maybe a correspondence to your 8 NEMA phase component names (1-8)?

What do you think @mschrader15 @qichaow ?

namdre commented 2 years ago

we have just received the requirement for the related feature for induction loops of actuated traffic lights.

mschrader15 commented 2 years ago

@namdre regarding:

Not sure whether it would be better: a) automatically reset virtual vehicles after every step b) keep them indefinitely until removed with another call to setVirtualVehicleNumber(detID, 0)

I like option b. I think it would ultimately result in fewer traci calls.

@qichaow and I can rework the naming of the NEMA detectors. I'm not aware of a standard outside of using the phase number. The name currently is std::string id = "TLS_" + myID + "_" + myProgramID + "_E2DetectorOnLane_" + lane->getID(); but like you said this isn't as straightforward as something like myID + "_" + myProgramID + "_D" + phaseNumber + "." + laneIndex.

namdre commented 2 years ago

I like option b. I think it would ultimately result in fewer traci calls.

Agreed. Let's do b.

myID + "_" + myProgramID + "_D" + phaseNumber + "." + laneIndex.

would be my choice as well.

namdre commented 2 years ago

My new suggestion for the traci function would be overrideVehicleNumber(str, int). If you want to work on this, the commits in #10048 provide a straightforward implementation path (the same traci constant and reset-semantics can be used).

mschrader15 commented 2 years ago

Sounds good. I'll tackle it this weekend!