Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sumo-user] Weird situation where wantsAndCouldChangeLane fails and cooperative action clarification

Hello Jakob, thank you again for the explanation. Is it possible to know when the ego vehicle may choose to overtake a blocking leader, or is there a 50% chance it may do one of the two?

Also, I just realized I can use TraCI's openGap() function ( https://sumo.dlr.de/daily/pydoc/traci._vehicle.html#VehicleDomain-openGap ) to try and define my custom "cooperate" function as I am not able to point the cases where setting lcCooperative to 1 would fail to act as a "cooperate" function. I know that there is a way to get the vehicles that block a certain ego vehicle for any lateral and longitudinal direction using getNeighbors(self, vehID, mode) function, but is it possible to get the vehicles that are being blocked by a specified ego vehicle? For example, ego vehicle "f1" is blocking vehicles "f2" and "f3" from completing a lane change action into the ego vehicle's lane?

Thank you.

Sincerely,
Hriday


On Thu, 21 Apr 2022 at 08:03, Jakob Erdmann <namdre.sumo@xxxxxxxxx> wrote:
lcCooperative=1 (or rather lcCooperativeSpeed=1 which takes lcCooperative as it's default) is mainly responsible for slowing down to open gaps:
- ego slows down if it is the follower
- the blocker slows down if it is the follower
Either slowing down is hindered if the vehicle to slow down has lcCooperativeSpeed < 1
Note, that sometimes, the ego vehicle may elect to overtake a blocking leader rather than to slow down and merge behind.

Am Do., 21. Apr. 2022 um 00:08 Uhr schrieb Hriday Sanghvi via sumo-user <sumo-user@xxxxxxxxxxx>:
Hello Jakob,

Thank you for your reply.

Regarding 2., Is this the only "speed adjustment" that setting lcCooperative to 1 for a particular vehicle would do - it would change the speed of the blocking vehicle(s) such that the condition for the secure gap between leader and follower holds true? Or it doesn't work that way because of the referenced bug previously - a bug where "the ego may ignore advice that it gives to itself (i.e. slow down to merge behind the leader) because it currently does not distinguish who is helped by any given speed advice"?

Sincerely,
Hriday

On Tue, 19 Apr 2022 at 19:38, Jakob Erdmann <namdre.sumo@xxxxxxxxx> wrote:
1.
a) wantsAndCouldChangeLane always returns false for direction=0 at the moment
b) Yes. the lane change state is only stored for "legal" targets

2. for any vehicle that will have lateral overlap with ego (during or at the end of the maneuver) the distance between the follower and the leader must be at least as big as the value of
traci.vehicle.getSecureGap(followerID, followerSpeed, leaderSpeed, leaderMaxDecel, leaderID)

regards,
Jakob

Am Di., 19. Apr. 2022 um 00:10 Uhr schrieb Hriday Sanghvi via sumo-user <sumo-user@xxxxxxxxxxx>:
Hello, if this question needs more information / screenshots - I could try and modify it if it's not clear.

Thank you.

Sincerely,
Hriday


On Wed, 13 Apr 2022 at 19:58, Hriday Sanghvi <sanghvih@xxxxxx> wrote:
Hello,

Lane change mode: 1621 (default)
Lane change model: SL2015
Max. duration given for a vehicle to perform a lane change: 10 s (arbitrary)

1. I am trying to discourage lane changes enforced by TraCI that are not valid, i.e.,

A vehicle trying to move to the right or the left from the rightmost or leftmost lane in the network respectively, or a vehicle that cannot perform a certain lane change operation within the given time due to other vehicles blocking it.

For a lane change operation initiated on a vehicle by

traci.vehicle.changeLaneRelative(vehID=veh_id, indexOffset=dr, duration=lc_max_duration)

The following code should tell me if the lane change will be a success:

lcs = traci.vehicle.getLaneChangeState(vehID=veh_id, direction=dr)[1] # index 1 for TraCI
lc_success = traci.vehicle.wantsAndCouldChangeLane(vehID=veh_id, direction=dr, state=lcs)

However, in the particular case where direction=0 (stay in the same lane), it still returns false. This made sense in a situation where the vehicle was still in the middle of a previous lane change from another lane (where it was between two lanes, and hence cannot "stay" in the same lane).

a. But it also happened to a vehicle that had departed from the rightmost lane and chose to "stay". I could not understand it even with the help of the console output's 'pretty' version of the Lane change state for the TraCI command as shown:

veh id: f.2 (currently on lane 0)
lc success: False
lcs pretty: ['stay', 'TraCI', 'sublane']
Direction: 0

b. On a side note, the pretty version of the lane change state seems to be empty when it encounters a situation where the TraCI command tries to move the vehicle to a lane that doesn't exist, i.e. "move right" on the rightmost lane - just looking for confirmation?

veh id: f.0 (currently on lane 0)
lc success: False
lcs pretty: []
Direction: -1

2. I am trying to program an action that translates to "cooperate" with another vehicle. For this, I need to know what needs to be done in a situation where a leader/follower vehicle on the same or a different lane is blocking another vehicle from changing lanes. So if I can figure out the minimum changes that need to be made to resolve this situation - for example, the lateral distance between the ego vehicle and blocking vehicle has to be at least m and the longitudinal distance between ego and blocking vehicle has to be at least Y m or maybe the relative speed difference has to be at least S m/s, then the lane change can go ahead.

As I understand it, my question would be answered from this:

but there are many components like the TraCI constant tc.LC_BLOCKED and how/when it is set that I don't fully understand.

Please advise. Thank you.

Sincerely,
Hriday
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user

Back to the top