Thank you for the careful investigation! The problem is now fixed in the dev version: https://github.com/eclipse/sumo/issues/13384
Am Di., 6. Juni 2023 um 17:15 Uhr schrieb Stefano Bonasera < [email protected]>: > Thank you for the answer. > > After leaving this problem for a few months I had to recently get back at > it and it is still unsolved. However, I found out that: > 1) The headway problem at the moment of loading a saved state only happens > for vehicles of type "rl" > 2) The 'rl' vehicle is added to the simulation via the self.k.vehicle.add > command, calling the kernel_api.vehicle.addFull inside > 3) The other vehicles (of type "other") are added with an inflow - from > the saved state > <flowState id="flow_00" type="other" begin="1.00" departLane="0" > departSpeed="25.64" probability="0.410184827871" > end="200000000.000000000000" route="routehwy_rear_0" done="11" index="11"/> > 4) Looking at the saved state, all vehicles of type "other" have indeed > the type listed, while the same does not happen for the rl vehicle - > example: > <vehicle id="flow_00.9" type="other" depart="16.30" departLane="0" > departSpeed="25.64" color="100,100,100" route="routehwy_rear_0" distance="0 > 0" speedFactor="1.035700000000" state="2615 16300 0 5.10 0 0.85 20100 0 0" > pos="83.334363758822 78.334363758822 1.944504118608" speed="19.445041186084 > 19.456978560735" angle="90.000000000000" posLat="0.000000000000" > waitingTime="100000 0"/> > <vehicle id="rl_0" depart="0.10" departLane="0" departPos="0.00" > departSpeed="20.00" color="red" route="routeramp_0" distance="379.59 0" > speedFactor="1.026700000000" state="29 100 1 0.00 0 4.81 20100 0 0" > pos="20.410000000000 15.410000000000 2.000000000000" speed="20.000000000000 > 20.000000000000" angle="90.000000000000" posLat="0.000000000000" > waitingTime="100000 0"/> > <flowState id="flow_00" type="other" begin="1.00" departLane="0" > departSpeed="25.64" probability="0.410184827871" > end="200000000.000000000000" route="routehwy_rear_0" done="11" index="11"/> > > I tried to manually modify the saved state file (after saving it, but > before loading it), adding the correct type to the "rl_0", as > <vehicle id="rl_0" type="rl" depart="0.10" departLane="0" .... > and after loading, the correct headway appears within the simulation -> it > seems this is the problem. > > From the add.xml file, everything seems ok: > <?xml version='1.0' encoding='UTF-8'?> > <additional xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:noNamespaceSchemaLocation="http://sumo.dlr.de/xsd/additional_file.xsd > "> > <vType id="rl" accel="3.0" decel="5.5" sigma="0.0" tau="0.1" > minGap="2.0" maxSpeed="35.0" speedFactor="1.0" speedDev="0.1" > impatience="0.5" carFollowModel="IDM" laneChangeModel="SL2015" > lcStrategic="1.0" lcCooperative="1.0" lcSpeedGain="1.0" lcKeepRight="1.0" > lcLookaheadLeft="2.0" lcSpeedGainRight="1.0" lcSublane="1.0" lcPushy="1" > lcPushyGap="0" lcAssertive="1" lcAccelLat="10"/> > <vType id="other" accel="3.0" decel="5.5" sigma="0.0" tau="0.1" > minGap="2.0" maxSpeed="35.0" speedFactor="1.0" speedDev="0.1" > impatience="0.5" carFollowModel="IDM" laneChangeModel="SL2015" > lcStrategic="1.0" lcCooperative="1.0" lcSpeedGain="1.0" lcKeepRight="1.0" > lcLookaheadLeft="2.0" lcSpeedGainRight="1.0" lcSublane="1.0" lcPushy="1" > lcPushyGap="0" lcAssertive="1" lcAccelLat="10"/> > </additional> > > It seems to me the solution is to have the type specified also for the > 'rl' vehicle in the saved state, but I could not find a nice way to have it > besides writing it in the saved state after the saveState command. > Do you have a nicer solution to have the state specified naturally right > after the saveState command? > > Thank you in advance for your time and answer. > Stefano > > > On Sun, Apr 2, 2023 at 7:37 AM Jakob Erdmann <[email protected]> > wrote: > >> > Please let me know if I am missing anything. >> Reproducing the example requires the sumocfg (sumo.cfg in your log) and >> all files that are referenced within the sumocfg. >> >> > although I do .subscribe() and .subscribeLeader() for the rl vehicle, >> these are not showing in the log file. >> The following occurs in your log file: >> >> traci.vehicle.subscribe('rl_0', [82, 86, 80, 64, 50, 84, 66, 67, 177, >> 101, 132]) >> traci.vehicle.subscribeLeader('rl_0', 2000) >> traci.vehicle.subscribe('rl_0', (104,), 0, 2147483647, {104: ('d', 2000)}) >> traci.vehicle.unsubscribe('rl_0') >> traci.vehicle.subscribe('rl_0', [82, 86, 80, 64, 50, 84, 66, 67, 177, >> 101, 132]) >> traci.vehicle.subscribeLeader('rl_0', 2000) >> traci.vehicle.subscribe('rl_0', (104,), 0, 2147483647, {104: ('d', 2000)}) >> >> Am Di., 28. März 2023 um 18:23 Uhr schrieb Stefano Bonasera < >> [email protected]>: >> >>> I have attached the log file I retrieved. Please let me know if I am >>> missing anything. >>> It is interesting to see that, although I do .subscribe() and >>> .subscribeLeader() for the rl vehicle, these are not showing in the log >>> file. >>> Do you have any idea why this is happening? >>> >>> Stefano >>> >>> On Tue, Mar 28, 2023 at 2:32 AM Jakob Erdmann <[email protected]> >>> wrote: >>> >>>> The cascading types are expected when you call functions that change >>>> vType attributes on a singe vehicle (i.e. traci.vehicle.setLength). In >>>> order to change the property only for a single vehicle, the type is cloned >>>> every time. >>>> However, the reported information is insufficient to understand the >>>> problem. Please provide a minimal failure example. Instead of the traci >>>> script, please provide a full log of the traci commands as described here: >>>> https://sumo.dlr.de/docs/TraCI/Interfacing_TraCI_from_Python.html#generating_a_log_of_all_traci_commands >>>> >>>> >>>> Am Mo., 27. März 2023 um 19:40 Uhr schrieb Stefano Bonasera < >>>> [email protected]>: >>>> >>>>> Hi Jakob, >>>>> >>>>> Thanks for the prompt reply. >>>>> What I see in the vType in the saved file for both types is: >>>>> >>>>> <vType id="other" minGap="2.000000000000" maxSpeed="35.000000000000" >>>>> speedFactor="normc(1.000000000000,0.100000000000,0.200000000000,2.000000000000)" >>>>> impatience="0.500000000000" maxSpeedLat="1.000000000000" >>>>> latAlignment="center" minGapLat="0.600000000000" laneChangeModel="SL2015" >>>>> lcStrategic="1.0" lcCooperative="1.0" lcSpeedGain="1.0" lcKeepRight="1.0" >>>>> lcSublane="1.0" lcPushy="1" lcPushyGap="0" lcAssertive="1.0" >>>>> lcImpatience="0.001" lcTimeToImpatience="100" lcAccelLat="10" >>>>> lcLookaheadLeft="2.0" lcSpeedGainRight="1.0" carFollowModel="IDM" >>>>> accel="3.0" decel="5.5" tau="0.1"/> >>>>> >>>>> <vType id="rl" minGap="0.000000000000" maxSpeed="35.000000000000" >>>>> speedFactor="normc(1.000000000000,0.100000000000,0.200000000000,2.000000000000)" >>>>> impatience="0.500000000000" maxSpeedLat="1.000000000000" >>>>> latAlignment="center" minGapLat="0.600000000000" laneChangeModel="SL2015" >>>>> lcStrategic="1.0" lcCooperative="1.0" lcSpeedGain="1.0" lcKeepRight="1.0" >>>>> lcSublane="1.0" lcPushy="1" lcPushyGap="0" lcAssertive="1.0" >>>>> lcImpatience="0.001" lcTimeToImpatience="100" lcAccelLat="10" >>>>> lcLookaheadLeft="2.0" lcSpeedGainRight="1.0" carFollowModel="IDM" >>>>> accel="3.0" decel="5.5" tau="0.1"/> >>>>> >>>>> I tried to play around also with the minGap (only difference I see >>>>> between these two vTypes) and that is indeed influencing the headway - >>>>> only >>>>> for the rl type: >>>>> 1) If minGap = 0: I get the headway as reported above: pre load: >>>>> 245.65, post load and subscribe: 243.15 (from >>>>> kernel_api.vehicle.getSubscriptionResults(rl_id)) >>>>> 2) If minGap = 2: pre load: 245.65, post load and subscribe: 245.15 >>>>> 3) If minGap = 3: pre load: 245.65, post load and subscribe: 246.15 >>>>> >>>>> Moreover, if I setLength of a vehicle (as in case #2 above) I see that >>>>> multiple vTypes are generated with "cascade-like" vType ids as "rl@rl0 >>>>> @rl0'''. >>>>> >>>>> Stefano >>>>> >>>>> >>>>> On Fri, Mar 24, 2023 at 3:39 AM Jakob Erdmann <[email protected]> >>>>> wrote: >>>>> >>>>>> This sounds as if something goes wrong when loading the type of the >>>>>> rl vehicle. Please look into the saved state file and post the line that >>>>>> defines the vType of the rl vehicle. >>>>>> >>>>>> Am Do., 23. März 2023 um 14:47 Uhr schrieb Stefano Bonasera < >>>>>> [email protected]>: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I use sumo 1.16, interfacing with python. >>>>>>> I noticed a weird behavior when loading and saving state and I hope >>>>>>> you can help me explain the motivation behind it >>>>>>> >>>>>>> I have only two types of vehicles in my simulation (other and rl). >>>>>>> Assume the rl vehicle has as a lead vehicle, say, "flow_15" with an >>>>>>> headway >>>>>>> of 245.65. I save the state via saveState, and immediately after load >>>>>>> the >>>>>>> same exact state via loadState. After loading the state I notice that: >>>>>>> 1) If I subscribe the quantities I care about + the leader >>>>>>> (subscribe() + subscribeLeader()) for the rl vehicle and I request the >>>>>>> subscription results for the same vehicle, the correct leader shows up, >>>>>>> but >>>>>>> the headway is reduced by half the rl vehicle car length, i.e. 243.15, >>>>>>> assuming I am using the default value of 5 >>>>>>> 2) If I subscribe the rl vehicle (including also VAR_LENGTH), set >>>>>>> the length of the vehicle via setLength() and then subscribe the leader >>>>>>> through subscribeLeader, then both the correct lead vehicle and headway >>>>>>> show up from the subscriptionResults >>>>>>> >>>>>>> This change in headway happens only for the type of vehicle "rl", >>>>>>> not for the "other" type of vehicle, which present in the >>>>>>> subscriptionResults the correct lead vehicle and associated headway. >>>>>>> Is it an intended behavior or am I missing something? >>>>>>> Do you have a better approach to prevent this difference? >>>>>>> >>>>>>> Thanks a lot for all the continuous support! >>>>>>> >>>>>>> -- >>>>>>> Kind regards, >>>>>>> Stefano. >>>>>>> _______________________________________________ >>>>>>> sumo-user mailing list >>>>>>> [email protected] >>>>>>> To unsubscribe from this list, visit >>>>>>> https://www.eclipse.org/mailman/listinfo/sumo-user >>>>>>> >>>>>> _______________________________________________ >>>>>> sumo-user mailing list >>>>>> [email protected] >>>>>> To unsubscribe from this list, visit >>>>>> https://www.eclipse.org/mailman/listinfo/sumo-user >>>>>> >>>>> >>>>> >>>>> -- >>>>> Kind regards, >>>>> Stefano. >>>>> _______________________________________________ >>>>> sumo-user mailing list >>>>> [email protected] >>>>> To unsubscribe from this list, visit >>>>> https://www.eclipse.org/mailman/listinfo/sumo-user >>>>> >>>> _______________________________________________ >>>> sumo-user mailing list >>>> [email protected] >>>> To unsubscribe from this list, visit >>>> https://www.eclipse.org/mailman/listinfo/sumo-user >>>> >>> >>> >>> -- >>> Kind regards, >>> Stefano. >>> _______________________________________________ >>> sumo-user mailing list >>> [email protected] >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/sumo-user >>> >> _______________________________________________ >> sumo-user mailing list >> [email protected] >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/sumo-user >> > > > -- > Kind regards, > Stefano. > _______________________________________________ > sumo-user mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user >
_______________________________________________ sumo-user mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
