The default rules for an allway_stop are, that vehicles without waitingTime
are forbidden from passing the intersection (this is why you keep seeing
isOpen=False). Internally, the rule is indeed to compare waitingTime and
give priority to the vehicle with the larger value (some subsecond noise is
added as a tiebraker).
regards,
Jakob
Am Do., 29. Feb. 2024 um 16:54 Uhr schrieb Daniel Aguilar Marsillach via
sumo-dev :
> Hi there,
>
> I am trying to extract vehicle priority information in two cases: 1)
> four-way priority-based intersection 2) four-way always stop intersection.
> I am using the latest version of SUMO and am developing through the Python
> API.
>
> I have used sumolib.net to perform a static map analysis of what lanes
> have priority and which are foes of each other, from which I can extract
> map-based priority rules at priority-based junctions.
>
> However, for the always stop case, how can I extract which vehicle has
> priority at a given moment in time if there are multiple vehicles approach
> the intersection or if there are multiple vehicles stopped at the
> intersection? I have been using traci.vehicle.getJunctionFoes(veh_id),
> traci.vehicle.getNextLinks(veh_id), traci.lane.getLinks(lane),
> traci.lane.getFoes(lane_ID, to_laneID) but I have run into some issues.
>
> I believe that traci.lane.getLinks(lane), traci.lane.getFoes(lane_ID,
> to_laneID) are useful for static map analysis but not for the dynamic
> scene. Is this correct?
>
> I setup a case where a single vehicle approaches the four-way (always
> stop) scenario without any other traffic. The vehicle stops but getLinks()
> is always returning isOpen=False, hasPrio=False, and hasFoe=False. Is this
> the standard output at an always stop case? Do those boolean flags ever
> change with time? I have noticed the same with
> traci.vehicle.getNextLinks(veh_id).
>
> However, self.k.kernel_api.vehicle.getJunctionFoes(veh_id) does return an
> empty list in this toy example. Is it sufficient to consider the foes of
> each vehicle at an intersection and if any vehicle has an empty list of
> foes, then it is the vehicle with right of way? I know that impatience
> parameters can affect which vehicle crosses whhen as well.
>
> I initially thought that using traci.vehicle.getWaitingTime() or
> traci.vehicle.getAccumulatedWaitingTime() would indicate which vehicle at
> intersection has right-of-way (the one with the highest waiting time).
> Should this be the case? getWaitingTime() resets to 0 if a vehicle inches
> near the stop line so I am not sure this would be the most reliable
> indicator. Is there a different way to extract which vehicle's turn it is
> to cross in an always stop scenario? What are the rules being used for
> this?
>
> Let me know if you have any suggestions on how to do extract vehicle
> priorities in dynamic/interaction-based intersections.
>
> Best,
>
> Daniel
>
>
>
>
>
> Nothing in this message is intended to constitute an electronic signature
> unless a specific statement to the contrary is included in this message.
>
> Confidentiality Note: This message is intended only for the person or
> entity to which it is addressed. It may contain confidential and/or
> privileged material. Any review, transmission, dissemination or other use,
> or taking of any action in reliance upon this message by persons or
> entities other than the intended recipient is prohibited and may be
> unlawful. If you received this message in error, please contact the sender
> and delete it from your computer.
>
> Nothing in this message is intended to constitute an electronic signature
> unless a specific statement to the contrary is included in this message.
>
> Confidentiality Note: This message is intended only for the person or
> entity to which it is addressed. It may contain confidential and/or
> privileged material. Any review, transmission, dissemination or other use,
> or taking of any action in reliance upon this message by persons or
> entities other than the intended recipient is prohibited and may be
> unlawful. If you received this message in error, please contact the sender
> and delete it from your computer.
> ___
> sumo-dev mailing list
> sumo-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/sumo-dev
>
___
sumo-dev mailing list
sumo-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-dev
