Access Element doesn't impact route

[JulianCzymmeck]

Hi sumo team,

I have a network (urban aerial mobility) that is completely disjointed from the rest of the "normal" road network. In order to create access for pedestrians to said disjointed network, i connected a bus stop from the uam network with an access element to the road network. But pedestrians defined via personTrip or by appending stages returned by traci.simulation.findIntermodalRoute to a pedestrian using traci don't generate a route using the access element. They avoid the uam network completely. But as soon as I add another edge (that allows pedestrians), connecting the uam network to the road network, the pedestrians correctly traverse through the uam network, using the access element (the new edge is never actually used).

Theoretically nothing should change when adding that additional edge, as the network was reachable before. Could it be that an access element alone doesn't get considered upon route creation? If so, it would be very nice to add that functionality.

Screenshot of one of the connection points. Just before the screenshot a pedestrian used the access element. Without the edge on the left side, the access element was unable to get used.

SUMO-version: v1_20_0+1515-4ddffc3948b

operating system: win11

[m-kro]

But do the persons have other options to reach their destination in your example or not? Maybe it is more about how routing works rather than the routing network itself. In this test the access is the only connection between two net parts and is used by the person.

[JulianCzymmeck]

Yes, there is the option to reach the destination by foot in my example. But using a taxi via the uam network should be way faster and thus preferred, right?

This following screenshot shows the pedestrian (modes = "taxi") walking to the destination by foot, instead of using a taxi:

This screenshot show a completely identical simulation, with the only difference between the two being the added edge connecting the road and uam network. This time the pedestrian chooses to use the uam taxi, even though "nothing" changed for the pedestrian. They would still be able to reach their destination by foot.

[m-kro]

In any case, a small sample scenario may help us to identify the underlying problem...So if you are willing to provide one, that would be of help.

[JulianCzymmeck]

I can't recreate the problem in a small sample scenario. No matter what I do the routing seems to work just fine when running the sample scenarios directly via sumogui. This problem might be correlated to something custom I am doing with traci. But I can't get further information about that, since trying to run the sample scenarios with my traci code crashes on step 4 with no usable error. The only return I get is the following:

Simulation step: 4
Traceback (most recent call last):
  File "C:\Users\Julian\Documents\BA\sumo-uam-2024\uamTraCI.py", line 601, in <module>
    run()
  File "C:\Users\Julian\Documents\BA\sumo-uam-2024\uamTraCI.py", line 447, in run
    traci.simulationStep()
  File "C:\Program Files (x86)\Eclipse\Sumo\tools\traci\main.py", line 198, in simulationStep
    connection.check().simulationStep(step)
  File "C:\Program Files (x86)\Eclipse\Sumo\tools\traci\connection.py", line 369, in simulationStep
    result = self._sendCmd(tc.CMD_SIMSTEP, None, None, "D", step)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Program Files (x86)\Eclipse\Sumo\tools\traci\connection.py", line 232, in _sendCmd
    return self._sendExact()
           ^^^^^^^^^^^^^^^^^
  File "C:\Program Files (x86)\Eclipse\Sumo\tools\traci\connection.py", line 137, in _sendExact
    raise FatalTraCIError("Connection closed by SUMO.")
traci.exceptions.FatalTraCIError: Connection closed by SUMO.

Is there a way to get more information about that crash?

[m-kro]

The message means that SUMO terminated for some (internal) reason/crash/... You can start sumo / sumo-gui from command line using the --remote-port option (see doc) and then connect with your TraCI script traci.connect(). Hopefully a message will get printed to the sumo cmd when it exits.

Last option: compile SUMO yourself, connect as described above and step through the code in debug version...

[m-kro]

@JulianCzymmeck Did you make any progress?

[JulianCzymmeck]

So far I have failed to create a simple scenario which mimics this behaviour, but it happens in all of my "complex" scenarios. I will try to investigate further and I will let you know if I can find out why that happens. For the moment I simply added a lane, permitting only pedestrians as a temporary fix. Thank you for your support.

[namdre]

Can you provide (private) access to the larger and crashing scenario?

[JulianCzymmeck]

Here is the github repository containing a scenario, where the access element alone doesn't enable pedestrian routing to the uam network: https://github.com/M-Colley/uam-sumo Steps to reproduce:

1. running uamTraCI.py without any changes will start the working simulation with intermodal routes using the uam network
2. to switch to the problematic scenario, set the value for scenario = to disconnected in the file simConfig.py. This is the completely identical network and configuration as the first network, but with the connecting lanes removed
3. run uamTraCI.py again. Note that no route using the uam network is generated

Note that in the simulation some of the pedestrians are colored (orange and red). The uam customers are generated by converting vehicles to pedestrians. If the generated route (findIntermodalRoute) doesn't contain the use of an uam taxi, they are colored orange. If they contain one, they are colored red.