lcodeca / lustscenario Goto Github PK

First of all, thanks for great work with building up a realistic scenario. It is really appreciated.

I have one question regarding the actuated traffic lights: It seems like the phases do not have minDur and maxDur attributes in the lust.net.xml file. Instead, the phases just have the duration attribute (that is different from tll.static.xml, so the "actuated" simulations will yield different results anyway), and hence the traffic signals will not behave like actuated according to the documentation (http://sumo.dlr.de/wiki/Simulation/Traffic_Lights#Based_on_Time_Gaps).

Can it have something to do with this bug? https://sourceforge.net/p/sumo/mailman/message/35513637/
Or have I misunderstood something?

Best regards,
Gustav

Since 1.1.0 spaces are no longer allowed as file path separator and ',' must be used.
It would be great if LuST could be used with a recent sumo.

hello,

I would like to add a car into this dataset, but when I am given a certain path, the ego car tends to rerouting.

I want to add a car in this dataset, it only follows the path I give, and the path will not be redefined, how can I achieve this?

I am currently using the VeReMi configuration for OMNET++, Veins, and SUMO which uses the LUST scenario. Is there any way to limit the number of vehicles as well as increase the number of transmissions a vehicle receives? It seems as if hundreds of vehicles are being created in a simulation whereas I prefer a small number of vehicles transmitting messages to each other over a long period of time (~a few hours).

How can I accomplish this?

I observe huge gridlock in this scenario, by running
sumo -c due.static.sumocfg

This makes the whole scenario unreal.
Is there a way to fix it?

Hi
Thanks for the wonderful work that you have put into this project. Is there a specific reason why you have enabled dynamic rerouting while, providing specific routes, which I assume were achieved after doing the dynamic user equilibrium process?
Should we (users) do a DUE loop before we use it for doing additional analysis?

Thanks

Hi,

I downloaded the latest version of the LuST scenario and I ran it on SUMO 1.2. When I checked the results, I found out that the route length for some vehicles is a very large number. I checked further and it looks like this is the case for some vehicles across all 4 cases, included in the scenario:

grep 17976931348 dua.static.tripinfo.xml | grep c1carIn32725
<tripinfo id="c1carIn32725:1" depart="46563.00" departLane="-30762#0_0" departPos="896.28" departSpeed="0.00" departDelay="0.00" arrival="46564.00" arrivalLane="-30762#0_0" arrivalPos="222.90" arrivalSpeed="0.00" duration="1.00" routeLength="179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00" waitingTime="1.00" waitingCount="1" stopTime="0.00" timeLoss="1.00" rerouteNo="0" devices="tripinfo_c1carIn32725:1 routing_c1carIn32725:1" vType="passenger1" speedFactor="1.00" vaporized=""/>
<tripinfo id="c1carIn32725:3" depart="72253.00" departLane="-30762#0_0" departPos="725.21" departSpeed="0.00" departDelay="0.00" arrival="72254.00" arrivalLane="-30762#0_0" arrivalPos="526.77" arrivalSpeed="0.00" duration="1.00" routeLength="179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00" waitingTime="1.00" waitingCount="1" stopTime="0.00" timeLoss="1.00" rerouteNo="0" devices="tripinfo_c1carIn32725:3 routing_c1carIn32725:3" vType="passenger2b" speedFactor="0.92" vaporized=""/>

grep 17976931348 due.static.tripinfo.xml | grep c1carIn32725
<tripinfo id="c1carIn32725:3" depart="72253.00" departLane="-30762#0_0" departPos="485.00" departSpeed="0.00" departDelay="0.00" arrival="72254.00" arrivalLane="-30762#0_0" arrivalPos="407.84" arrivalSpeed="0.00" duration="1.00" routeLength="179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00" waitingTime="1.00" waitingCount="1" stopTime="0.00" timeLoss="1.00" rerouteNo="0" devices="tripinfo_c1carIn32725:3" vType="passenger2b" speedFactor="0.92" vaporized=""/>

grep 17976931348 due.actuated.tripinfo.xml | grep c1carIn32725
<tripinfo id="nrh01c1carIn32725:1" depart="46563.00" departLane="-30762#0_0" departPos="1002.74" departSpeed="0.00" departDelay="0.00" arrival="46564.00" arrivalLane="-30762#0_0" arrivalPos="877.28" arrivalSpeed="0.00" duration="1.00" routeLength="179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00" waitingTime="1.00" waitingCount="1" stopTime="0.00" timeLoss="1.00" rerouteNo="0" devices="tripinfo_nrh01c1carIn32725:1" vType="passenger1" speedFactor="1.10" vaporized=""/>

grep 17976931348 dua.actuated.tripinfo.xml | grep c1carIn32725
<tripinfo id="nrh01c1carIn32725:1" depart="46563.00" departLane="-30762#0_0" departPos="887.69" departSpeed="0.00" departDelay="0.00" arrival="46564.00" arrivalLane="-30762#0_0" arrivalPos="143.21" arrivalSpeed="0.00" duration="1.00" routeLength="179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00" waitingTime="1.00" waitingCount="1" stopTime="0.00" timeLoss="1.00" rerouteNo="0" devices="tripinfo_nrh01c1carIn32725:1" vType="passenger1" speedFactor="1.10" vaporized=""/>

grep 17976931348 dua.static.tripinfo.xml | wc -l
563

grep 17976931348 due.static.tripinfo.xml | wc -l
533

grep 17976931348 dua.actuated.tripinfo.xml | wc -l
541

grep 17976931348 due.actuated.tripinfo.xml | wc -l
545

Do you have any explanation what causes these results?

Thanks for this repo!

I am having trouble using this scenario in omnet++ via veins. Specifically I do not manage to produce a launchd.xml. In your paper you describe having run this with omnet++ and veins.

Is this code, or other similar example code, available anywhere. Otherwise, could it be made available?

We decided to keep the configuration file with threads, however we are incurring in several random crashes of the simulation while using the thread option.

We already asked to the SUMO developers about it, and they confirmed that SUMO suses libfox1.6 to implement the threads so different packages of the library may result in different behaviours in different systems.

We tested it with Mac OSX 10.10.3 and Ubuntu 14.04.2 LTS and in both cases we had random crashes. You are welcome to try on your system and report the outcome.

How changed is LuSTScenario from the real Luxemburg? I need to add elevation data to the scenario but it looks pretty difficult to adapt the data of an osm of Luxemburg, with 3D information, to this scenario.

Thanks for this great data.But is there something I can figure out how the acuated traffic lights work?

Thanks for this well-designed scenario.

from what I can tell, commit c4bd5bd contains a bug in junction -13968, as two links of this junction are not controlled by the junction's traffic light (see picture attached).

I have also attached a hand-crafted patch.

Regards,
Holger Doebler

fix_junction_-13968.zip