Hello,
As per the documentation (
https://sumo.dlr.de/docs/Definition_of_Vehicles,_Vehicle_Types,_and_Routes.html#repeated_routes),
repeat is similar to frequency, am I correct?.
Or, the frequency is similar to vehsPerHour defined in flow (
Hello,
I have the same issue, that is, tried to simulate bus service. For a line
(or public transit route), several vehicles (fleet) repeatedly make many
trips according to headway (period in SUMO) or frequency. As per the
suggestions @Jackob, I tried the following.
Jakob,
Thanks for your replay!
One more question.
The attribute of "halting" refers to vehicles which speed is less than
0.1m/s. Do vehicle stop at the intersection would be included?
Appreciated!
Jane Cheung
On Thu, Jun 11, 2020 at 11:09 PM Jakob Erdmann
wrote:
> Your scenario creates a
Thanks @namdre
I would like 70 buses to repeat a 40km loop stopping at defined
busstops along the way.
I tried re-router but I cant make the bus stop the second time around.
I tried to figure out a config that matches your suggestion.(just below).
May I ask for a sample config of a repeating
1) if you set your frequency to ~half the cycle time, you should see some
data points with higher flow. When averaging over a full cycle you would
still mix green and red phases
2) yes, each interval would give you one datapoint. For network-wide
density you could use the total number of vehicles
It means your input route file is not valid xml. Take a look at line 164.
Am Do., 11. Juni 2020 um 17:02 Uhr schrieb Fay Kostopoulou <
fayk...@gmail.com>:
> Thank you for your response.
>
> I tried it and it gives me the following message. Could you help me with
> it?
>
> Traceback (most recent
Thank you, dear Jakob.
1.now if I use freq equal to traffic light cycle the problem will be solved?
2.you said "the flow data points you are using are for individual edges. If
you need a whole-network diagram you need to sum up the edges flows and
compute an average density." for flow I should
Your scenario creates a circular deadlock. (each vehicle cannot move
because the downstream edge is full and this forms a closed loop).
Usually this is resolved by teleporting but you disabled this in your
configuration.
Such a situation can happen in real life and it can only be resolved by
Thank you for your response.
I tried it and it gives me the following message. Could you help me with it?
Traceback (most recent call last):
File "routeSampler.py", line 647, in
main(get_options())
File "routeSampler.py", line 399, in main
routes = Routes(options.routeFiles)
File
That option takes no arguments it just toggles whether sampling prior to
optimization should be done.
You can call it like this: --optimize-input --optimize 5
Am Do., 11. Juni 2020 um 16:08 Uhr schrieb Fay Kostopoulou <
fayk...@gmail.com>:
> Dear all,
>
> I am trying to optimize the output of
Dear all,
I am trying to optimize the output of routeSampler, using the
attribute --optimize-input, but it gives me the message below. I am running
C:\Program Files (x86)\Eclipse\Sumo\tools>python routeSampler.py -r
Test_calibration_warm.rou.xml -t turn-count-data_warm.xml -o
Dear Jakob,
Many thanks for your kind response and information.
It is working now after changing to the release version.
Regards
Radha
On Thu, Jun 11, 2020 at 1:13 PM Jakob Erdmann wrote:
> On linux you are somehow using the debug version which performs some extra
> tests and one of them
1) in your scenario, the flow is mostly affected by the traffic lights
rather than the vehicle density. Thus it will look different from a
motorway diagram
2) the flow data points you are using are for individual edges. If you need
a whole-network diagram you need to sum up the edges flows and
On linux you are somehow using the debug version which performs some extra
tests and one of them is raising this error.
If you build the release version instead it should behave as on windows
(and also run *much* faster).
Am Do., 11. Juni 2020 um 12:12 Uhr schrieb Radha Reddy <
No. What you can do is override the estimated travel time used by the
routingDevice but this will affect all vehicles.
To get vehicle-specific weights you need to trigger manual rerouting via
TraCI.
Am Do., 11. Juni 2020 um 11:11 Uhr schrieb marcelreppi <
marcelre...@gmail.com>:
> Hello,
>
> is
Hello,
is there a way to make the periodic rerouting device use the
vehicle-specific edge traveltimes that were set using
traci.vehicle.setAdaptedTraveltime()?
Or do I have to implement "manual periodic rerouting" using TraCI after I
changed the edge weights for individual vehicles?
Thanks!
Dear SUMO Users Community,
I am using SUMO for creating a few scenarios, some of which may be
dangerous for a driver. One of the scenarios focuses on sudden appearance
of pedestrians in front of an ego vehicle and it should lead to application
of emergency brakes.
Current progress achieved by me
The only way to achieve this is by preparing both lanes/edges beforehand:
- an extra lane in the forward direction that is forbidden initialize
(disallow="all"),
- an edge in the opposite direction that is geometrically on top of that
lane.
At some point in the simulation you can change
Hi Michael,
I notice that in some cases (i.e. for specific edges) the result is different.
How the length of the edge is estimated? Does the estimated length of the edge
exist in any output of the model?
Also, the units are given as g/km/hour. In fact, this correspond to g/ (km*h),
right ?
Hi Jakob,
Thanks for your help.
I know the opposite lane is allowed to use by the option --opposite.guess,
However, I want to know if I can change the lane direction in the
simulation, for example,
from 10s to 50s, the lane direction of A1B1_0 is upstream, and in rest
time, its direction is
Hi Natalia,
can you please give an example, because it should be exactly as you
stated.
If you have an interval length of one hour, dividing the absolute
emissions
by the edge length should give the normalized emissions.
Best regards,
Michael
Am 2020-06-11 00:46, schrieb Natalia Liora:
Hi,
21 matches
Mail list logo
