Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sumo-user] modelling pedestrians correctly
Each crossing is controlled by either one index in the traffic light state or even by two indices (if both directions of walking are controlled separately). Middle islands can be modelled as well by defining subsequent crossings for passing both parts of the road. If the signal plan contains a phase where entering the crossing via sidewalk is forbidden but leaving the middle island is still allowed, the number of pedestrians on the middle island could be retrieved with the outlined API.

regards,
Jakob

Am Mi., 28. Aug. 2019 um 20:23 Uhr schrieb Menno van der Woude <menno@xxxxxxxxxxxxxxxxxx>:

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)?

Am Mi., 28. Aug. 2019 um 11:08 Uhr schrieb Menno van der Woude <menno@xxxxxxxxxxxxxxxxxx>:

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

Am Di., 27. Aug. 2019 um 10:33 Uhr schrieb Menno van der Woude <menno@xxxxxxxxxxxxxxxxxx>:

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:
Hello,
E2-detectors currently cannot detect pedestrians. and the only way to implement a pedestrian-pushbutton is by checking the walking direction of the pedestrians explicitly. This is demonstrated in https://sumo.dlr.de/wiki/Tutorials/TraCIPedCrossing

Sidewalks should be modelled with a single lane that serves for both directions. Also, I recommend reading https://sumo.dlr.de/wiki/Simulation/Pedestrians#Generating_a_network_with_crossings_and_walkingareas

regards,
Jakob


Am Mo., 26. Aug. 2019 um 16:47 Uhr schrieb Menno van der Woude <menno@xxxxxxxxxxxxxxxxxx>:

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
_______________________________________________
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

Back to the top