|
For my use case, the solution you outline would be fine, provided
I can control the crossing via TraCI, preferably via an index in
the traffic-light-control-string. Also the
count-waiting-pedestrians functionality should be available
regardless of the type of traffic light, that is, also when it is
controlled via TraCI.
There is a use case where the lights for pedestrians in the
middle of the road would be there own 'group', as would be the
lights on the outside be. That is a very typical Dutch solution
though, and even then it is relatively rare. It could be solved by
using multiple parallel crossings. Normally, a pedestrian crossing
consists either of one crossing, or two consecutive crossings that
are controlled independently, but corrdinated based on which
button has been pressed. So with [] being a crossing and {} being
a button, given {a1}[A]{a2}-{b2}[B]{b1}, if {a1} is pressed, [A]
and [B] will get green, and there will be a timer that controls
extra green time for [B] so the pedestrian is able to cross the
entire complete crossing. Same for {b1} the other way. If {a2} or
{b2} are pressed, only [A] or [B] will be green. This is a very
common scenario in Holland. Given the amount of detection and the
fact that very often actual behavior of pedestrians is irrelevant
for testing traffic controller software, this is the reason I have
stuck with the E2-detector+pedestrians-as-vehicles approach so
far.
Greets, Menno
On 28/08/2019 12:32, Jakob Erdmann
wrote:
You will find that pedestrians in either of the 4 junction
corners may potentially wait for 1 of 2 crossings (horizontal,
vertical). To actuate a traffic light, it is important to know
which way each pedestrian wants to go.
Since identifying crossings by their internal edge id or by
the edges they cross is somewahat messy, I'm leaning towards
the idea of putting the count-waiting-pedestrians
functionality into the traffic light itself as outline in my
previous mail.
Would your use-case also be covered by such a solution or
do you need to distinguish the different sides of the road
(where crossings would switch to green in the same phase)?
Hey Jakob,
maybe it would be possible (and maybe relatively easy?)
to implement a dedicated pedestrian detector that reports
true if any pedestrians are inside its area that have not
moved the timestep before (or the number of those
pedestrians). That would be much like an E2 detector.
Similar to your idea, but not bound to a particular
crossing. Or does that not accommodate the situation you
describe with 4 possible outgoing directions? Direction is
then typically not important, since pedestrians that just
crossed will typically walk onward.
The detector could even be generic, a kind of special
type of E2 detector, and just report all
waiting/not-moving vehicles inside its area - or an option
for an E2 detector 'only report waiting vehicles' or so.
Then again, pedestrians are not actually vehicles, which
might complicate that idea bit.
Greets, Menno
On
27/08/2019 20:17, Jakob Erdmann wrote:
There is no strong technical reason that prevents
E2-detectors from handling pedestrians. It might also
be useful to configure it for detecting pedestrians
either in forward, backward or both directions.
However, that still would not solve the use case of a
pedestrian push-button.
This is because pedestrians wait on an walkingarea
before using a crossing and there may be more than 2
directions in which this walkingarea is used. At a
junction corner with 2 sidewalks and 2 crossings,
there are actually 4 possible (outgoing) walking
directions and 2 push-buttons that must be
distinguished.
I think it makes more sense to implement a
dedicated pedestrian detector that can be used to
query the number of pedestrians that are waiting for a
particular crossing (and maybe even combines the
pedestrians from both sides of the same crossing).
An alternative solutions (maybe more elegant) would
be to add a function to traci.trafficlights that can
report the number of waiting pedestrians for a given
phase (by checking all the crossings that would turn
green in that phase).
regards,
Jakob
Hello Jakob,
thanks for your reply.
Is detection of pedestrians by E2 detectors a
planned feature? Or is it just not meant to
function that way. Anyway I noticed that if I use
--persontrips true with od2trips, SUMO does not
find connections for pedestrians the way I modeled
my network now (with connections instead of
crossings). The simulations reports an error. So
that I'd need to revise the network there anyway.
For now, I will stick with my incorrect approach,
since it allows for much easier detection of
pedestrians, with a single TraCI command. Also I
find creating connections somewhat more intuitive
than creating crossings in NETEDIT. It would be
nice to be able to model pedestrians as vehicles,
and still have them walk alongside one another on
a sidewalk, maybe even in both directions, instead
of in a line. But that is probably just not a
typical use case.
Thanks, greets,
Menno
On
26/08/2019 17:23, Jakob Erdmann wrote:
Dear all,
currently, when modelling pedestrians, I
always use 'regular' edges and
connections. This results in warnings
(such as "Warning: Vehicle type '7' with
vClass=pedestrian should only be used for
persons and not for vehicle 'ped26'."),
and sometimes pedestrians accidentally end
up on the street (which I can solve by
disallowing them). I do nonetheless
because: it allows usage of E2 type
detectors to detect presence of
pedestrian-style vehicles, and it is easy
to build the network cause I can just use
regular connections. Pedestrians will
stand in line at the intersection, but I
am mostly interested in the general flow
of traffic, and there are generally few
pedestrians in the simulation.
However, it would be nice to model the
pedestrians more correctly. I wonder,
given an intersection like this:
How can I build the network so that the
pedestrians will only cross from the
sidewalk edges on the one side to the
sidewalk edges on the other side, and have
a detector (button) on either side of the
crossing? Beause of the way my TraCI
application works, most preferably this
would be an E2 detector.
Should I create sidewalk-edges only in a
single direction, since pedestrians can
walk in two directions? If so, how to
avoid pedestrians that just crossed the
intersection from activating the
detection?
Actually all traffic has detectors, that
I did add draw in the above simplified
example. A typical intersection may look
more like this:
And in the simulation like this (note a
lot of traffic lights are light blue, and
thus actually not controlled):
any help is appreciated!
Greets, Menno
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user
|
