Re: [sumo-user] Different headways
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 <
stefano.bonas...@gmail.com>:
> 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
> departSpeed="25.64" probability="0.410184827871"
> end="2." 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:
> departSpeed="25.64" color="100,100,100" route="routehwy_rear_0" distance="0
> 0" speedFactor="1.0357" 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." posLat="0."
> waitingTime="10 0"/>
> departSpeed="20.00" color="red" route="routeramp_0" distance="379.59 0"
> speedFactor="1.0267" state="29 100 1 0.00 0 4.81 20100 0 0"
> pos="20.4100 15.4100 2." speed="20.
> 20." angle="90." posLat="0."
> waitingTime="10 0"/>
> departSpeed="25.64" probability="0.410184827871"
> end="2." 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
> and after loading, the correct headway appears within the simulation -> it
> seems this is the problem.
>
> From the add.xml file, everything seems ok:
>
> http://www.w3.org/2001/XMLSchema-instance";
> xsi:noNamespaceSchemaLocation="http://sumo.dlr.de/xsd/additional_file.xsd
> ">
>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"/>
>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"/>
>
>
> 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
> 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 <
>> stefano.bonas...@gmail.com>:
>>
>>> 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
>>> 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 exa
Re: [sumo-user] Different headways
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
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:
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
it
seems this is the problem.
>From the add.xml file, everything seems ok:
http://www.w3.org/2001/XMLSchema-instance";
xsi:noNamespaceSchemaLocation="http://sumo.dlr.de/xsd/additional_file.xsd";>
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 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 <
> stefano.bonas...@gmail.com>:
>
>> 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
>> 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 <
>>> stefano.bonas...@gmail.com>:
>>>
Hi Jakob,
Thanks for the prompt reply.
What I see in the vType in the saved file for both types is:
>>> speedFactor="normc(1.,0.1000,0.2000,2.)"
impatience="0.5000" maxSpeedLat="1."
latAlignment="center" minGapLat="0.6000" 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"/>
>>> speedFactor="normc(1.,0.1000,0.2000,2.)"
impatience="0.5000" maxSpeedLat="1."
latAlignment="center" minGapLat="0.6000" 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,
Re: [sumo-user] Different headways
> 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 <
stefano.bonas...@gmail.com>:
> 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
> 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 <
>> stefano.bonas...@gmail.com>:
>>
>>> Hi Jakob,
>>>
>>> Thanks for the prompt reply.
>>> What I see in the vType in the saved file for both types is:
>>>
>>> >> speedFactor="normc(1.,0.1000,0.2000,2.)"
>>> impatience="0.5000" maxSpeedLat="1."
>>> latAlignment="center" minGapLat="0.6000" 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"/>
>>>
>>> >> speedFactor="normc(1.,0.1000,0.2000,2.)"
>>> impatience="0.5000" maxSpeedLat="1."
>>> latAlignment="center" minGapLat="0.6000" 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
>>> 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 <
stefano.bonas...@gmail.com>:
> 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,
> assumin
Re: [sumo-user] Different headways
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 < stefano.bonas...@gmail.com>: > Hi Jakob, > > Thanks for the prompt reply. > What I see in the vType in the saved file for both types is: > > speedFactor="normc(1.,0.1000,0.2000,2.)" > impatience="0.5000" maxSpeedLat="1." > latAlignment="center" minGapLat="0.6000" 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"/> > > speedFactor="normc(1.,0.1000,0.2000,2.)" > impatience="0.5000" maxSpeedLat="1." > latAlignment="center" minGapLat="0.6000" 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 > 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 < >> stefano.bonas...@gmail.com>: >> >>> 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 >>> sumo-user@eclipse.org >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/sumo-user >>> >> ___ >> sumo-user mailing list >> sumo-user@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/sumo-user >> > > > -- > Kind regards, > Stefano. > ___ > sumo-user mailing list > sumo-user@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user >
Re: [sumo-user] Different headways
Hi Jakob, Thanks for the prompt reply. What I see in the vType in the saved file for both types is: 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 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 < > stefano.bonas...@gmail.com>: > >> 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 >> sumo-user@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/sumo-user >> > ___ > sumo-user mailing list > sumo-user@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user > -- Kind regards, Stefano. ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] Different headways
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 < stefano.bonas...@gmail.com>: > 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 > sumo-user@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user > ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
[sumo-user] Different headways
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 sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
