Re: [sumo-devel] Ticket 857

[Jakob E. <nam...@go...>]

Hi Daniel,
some fevered dreams again...

>> > right? If so: why not using the car-following rules to compute a safe
>> > velocity for the second vehicle?
>> This would indeed be the best way to solve the problem. I've so far
>> shied away from this approach because it would require quite  a few
>> changes to core microsim methods. Probably MSLink::open would have to
>> return the leader instead of a boolean. The gap would have to be
>> computed from both vehicles distance to the exit link or some such
>> thing.
>
>
> Yes. Sounds horrible. But maybe I'm just too lazy...
It turns out that it isn't horrible at all. Really only a few lines of
code and it is working great! (after looking at the regular tests,
iTETRIS and Braunschweig)

>
>>
>> Another problem: It is generally not clear which vehicle will be the
>> leader. Due to the issue of ticket #856 it may happen that the minor
>> link vehicle (veh1) starts to drive and suddenly a major link vehicle
>> (veh2) shows up and wants to drive as well. In some cases veh1 could
>> brake while on the junction and veh2 becomes the leader. In other
>> cases, veh1 is already to fast to brake and must itself become the
>> leader.
>> >
>>
>
> Hmm. "Suddenly" should but only happen if veh2 is inserted?
To rephrase ticket #856: "vehicles who change lanes in front of a
junction only set the approach information after the lane change. This
sometimes comes as a surprise to vehicles on minor links". The old
(and also the current) behavior is to let the major link vehicles
break if the minor link vehicle is already on the junction.

>>
>> > ) I do not understand what different time gaps for committed/uncommited
>> > means. What is the representation in reality? I mean, it surely makes
>> > sense
>> > to have different acceptance gaps per intersection - as they differ in
>> > size
>> > and in visibility conditions. But I think that, well, it may be a
>> > solution,
>> > but the original target is a different one, and it's always obscure when
>> > solving A suddenly while working on B.
>> >
This stuff is gone now, I reverted it to only use the single old magic
variable we've all come to love (-:

>> In [13315] I implemented a fix for #852. Since the check for current
>> occupancy of internal lanes is unreliable (lane processing order
>> depedent) I introduced checks for a junctions exitLink instead. I'm
>> not sure anymore whether this is the best way to fix this issue. If a
>> vehicle is already on the junction (committed to drive) it should only
>> rarely have to brake (namely, if the preceding vehicle brakes
>> unexpectedly) Thus I introduced a second acceptence gap (safety
>> threshold) for vehicles which are already on the junction. Again,
>> reworking the simulation so it can use normal car following rules in
>> this situation would be preferable.
>>
>
> Yes, I see. Indeed, I have not taken this into account when implementing it.
> But I must admit that I do not see what is done given the trac changeset
> view only.
fixed now. The check for vehicles on internal foe lanes now happens
during move() where everything is still synchronized.

> So in your opinion two vehicles may not enter the same inner lane? I cannot
> imagine this. I think this was avoided by not having the used lane in the
> list of lanes to check for ocupancy.
This was never a problem. The occupancy check only relates to all the
other lanes which are foes.

>
> What about crossing links, I mean ones crossing at 90° with different
> entry/exit lanes? The original code should have prohibited a vehicle to
> enter an intersection if another one occupies the place. Is this gone, now?
> You know, yes, it does not matter for teleports, but then you get vehicles
> running over each other.

It is removed in the current code but could be returned in a
synchronized way if desired.
In my opinion (from looking at the simulation) we can live without
this check now since the current acceptanceGaps and
checkRewindLinkLanes do quite a good job.  Also, since vehicles
blocking the junction in this way are forbidden in real life. the
simulation behavior would not be more realistic if we reimplemented
blocking. An additional supporting thought: if vehicles partially
block a junction in real life, other vehicles will usually start to
swerve around them.

> But this is a little bit more complicated, too. In more complex networks,
> you have (minor) intersections where no one (never ever) crosses the main
> direction of drive. No one would keep them free, it also looks odd in the
> simulation. I am not sure about it, but I think that vehicles are also
> prevented from entering intersections where one can only drive straight or
> right... And, I think vehicles even stop in front of plain "continuation
> nodes" (nodes in the middle of a road).
Lets find a small reproducing example and then work from that.

> I mean, coming back to the problem... We are dealing with an awful degree of
> complexity. Lanes/inner-lanes/intersections/inner-intersections/links and
> exit links? What the hell? It's not surprising that we are running into
> side-effects, undefined states, etc - at least we did, I must admit that I
> have not inspected your changes into depth. Both issues - deceleration when
> running after a vehicle along an inner lane and not taking into regard the
> occupancy of inner lanes which do not have the same destination lane - as
> well as the introduction of an additional concept (exitLinks) make me
> sceptical. You know, we discussed that we should not need a link to the
> inner lane and from the inner lane?
Right now I'm finding the exitLink quite usefull to manage what
happens on the junction (of course, this is more complicated than
without internal lanes)
Still, i'm quite happy with how simple the recent patch was.

> Aeh, the problem. Look: the point is that a vehicle is needing longer to
> leave the intersection than expected, right? Is that maybe just an issue of
> updating the leaveTime? Why not?
Once the vehicle is on the junction the entryLink is no longer being
approached. I played around with keeping the approachInfo until the
vehicle has passed the junction but that was definitely uglier than it
is now.

> I do not know why it always gets MORE complicated. Stating that I'm the
> author of many of those, aeh, uh, let's call it "concepts", I find the whole
> thing increasingly ridiculous. Have you investigated the
> "mayBrake"-or-how-is-it-called method which tries to predict whether a
> leader has to brake for knowing whether a vehicle can enter an intersection
> without blocking it? It's an additional heuristics to all this
> lane/inner-lane/junction/inner-junction/link and now exitLink stuff. Besides
> checkRewindLanes and what. Good god... We should rapidly go on with
> macrosimulation :-)
Agreed. Also, I'm still saving up some juicy bits of code for my next
big fever so no spoilers please.

Jakob

>> > 2013/2/14 Jakob Erdmann <nam...@go...>
>> >>
>> >> Dear Developers,
>> >> as you may have noticed there has been a lot of effort recently to get
>> >> rid of collisions in SUMO.
>> >> The 3 major problem spots were car-following, vehicle insertion and
>> >> junction control. Some of the collisions at junctions were due to
>> >> minor problems with the junction definitions themselves (NETCONVERT)
>> >> but most of them are related to intricate boundary conditions during
>> >> the simulation. At this time, only junction related collisions still
>> >> show up in our test scenarios.
>> >>
>> >> As you may know, junction control happens at the level of indiviual
>> >> links (connections across the junction). Each vehicle registers a
>> >> certain time slot for when it wishes to use the junction and according
>> >> to the priority of its lane may then drive or needs to wait.
>> >> In old versions of SUMO the vehicle movements while crossing a
>> >> junction were very simply which led to predictable time slots. Since
>> >> the introduction of internal lanes however, vehicles follow the same
>> >> complex behavioral rules whether their are on a normal lane or in the
>> >> middle of a junction. Among other things they sometimes brake while on
>> >> a junction which makes the registered time slots far less reliable.
>> >> Ticket 857 [https://sourceforge.net/apps/trac/sumo/ticket/857] is
>> >> about just this issue. Because SUMO-vehicles with the default
>> >> vehicleType parameters randomly decelerate (dawdle) they may find
>> >> themselves unable to leave the junction within their previously
>> >> registered time slot causing collisions. In the ticket I've suggested
>> >> 2 ways to deal with this problem.
>> >> I invite you to comment on these suggestions and to suggest
>> >> alternative solutions.
>> >>
>> >> best regards,
>> >> Jakob
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Free Next-Gen Firewall Hardware Offer
>> >> Buy your Sophos next-gen firewall before the end March 2013
>> >> and get the hardware for free! Learn more.
>> >> http://p.sf.net/sfu/sophos-d2d-feb
>> >> _______________________________________________
>> >> sumo-devel mailing list
>> >> sum...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/sumo-devel
>> >
>> >
>
>