Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FatalTraCIError on traci.person.getPosition() #5674

Closed
falcaopetri opened this issue May 25, 2019 · 4 comments

Comments

@falcaopetri
Copy link

commented May 25, 2019

The problem

Calling traci.person.getPosition(id) is not valid for all id's returned by traci.person.getIDList(), i.e. it seems that we can only call traci.person.getPosition(id) if traci.person.getStage(id)!= 5.

The "problem" is that sometimes a person's id is returned before its depart time (apparently one timestep before depart) with stage set to 5 (personTrip). This means that the following code might not work (unless we add the stage check before calling getPosition):

while traci.simulation.getMinExpectedNumber() > 0:
    traci.simulationStep()
    people = traci.person.getIDList()
    for person in people:
        print('stage', traci.person.getStage(person))
        # the following throws traci.exceptions.FatalTraCIError if stage == 5:
        print('position', traci.person.getPosition(person)) 

I don't know if there is a reason for people getting added before their depart time, but getting a sumo crash for calling getPosition at the wrong time seems at least an odd behavior.

Is the stage check something we are supposed to do? I didn't find any documentation about this.

Further investigation

It seems that the error is raised by MSTransportable::Stage_Trip::getPosition (I got at this function serching for "Should not get here!", and not by debugging):

throw ProcessError("Should not get here!");

As it can be seem MSTransportable::Stage_Trip::getAngle is also "affected".

Questions

  • Is a person being added as stage 5 before its depart time an expected behavior?
  • Is the position/angle ill defined at stage 5?
  • Is there any documentation about this?
  • Or could these functions be implemented to return proper values?

How to reproduce

Using traci_pedestrian_crossing demo

  • Get the traci_pedestrian_crossing example file (latest master commit here);
  • Edit the simulation loop to look something like:
while traci.simulation.getMinExpectedNumber() > 0:
    traci.simulationStep()
    people = traci.person.getIDList()
    print(people)
    if len(people) > 0:
        print(traci.person.getPosition(people[0]))

Run the script:

$ python runner.py --no-gui
Loading configuration... done.
Success.
 Retrying in 1 seconds
Loading configuration... done.
***Starting server on port 59523 ***
Loading net-file from 'data/../pedcrossing.net.xml'... done (15ms).
Loading additional-files from 'data/pedcrossing.tll.xml'... done (12ms).
Loading done.
Simulation version 1.2.0 started with time: 0.00
('ped0',)
Error: Should not get here!
Quitting (on error).
Traceback (most recent call last):
  File "runner.py", line 159, in <module>
    run()
  File "runner.py", line 76, in run
    print(traci.person.getPosition(people[0]))
  File "/usr/lib/python3.7/site-packages/traci/_person.py", line 65, in getPosition
    return self._getUniversal(tc.VAR_POSITION, personID)
  File "/usr/lib/python3.7/site-packages/traci/domain.py", line 115, in _getUniversal
    self._cmdGetID, varID, objectID)
  File "/usr/lib/python3.7/site-packages/traci/connection.py", line 134, in _sendReadOneStringCmd
    return self._checkResult(cmdID, varID, objID)
  File "/usr/lib/python3.7/site-packages/traci/connection.py", line 162, in _checkResult
    result = self._sendExact()
  File "/usr/lib/python3.7/site-packages/traci/connection.py", line 105, in _sendExact
    raise FatalTraCIError("connection closed by SUMO")
traci.exceptions.FatalTraCIError: connection closed by SUMO

Using the zipped project

@namdre namdre self-assigned this May 25, 2019

@namdre

This comment has been minimized.

Copy link
Contributor

commented May 25, 2019

regression in 1.1.0

@namdre

This comment has been minimized.

Copy link
Contributor

commented May 25, 2019

@behrisch why was the depart stage removed for persontrip in 6ea168a ?

@behrisch

This comment has been minimized.

Copy link
Contributor

commented May 25, 2019

@namdre I thought it was redundant given that all the information is now in the person trip or rather the stop should be added once the trip is resolved into a plan (if it is still necessary then). I would rather consider the visibility of a person in TraCI before depart a bug (Is this true for vehicles as well)?

@namdre

This comment has been minimized.

Copy link
Contributor

commented May 25, 2019

With the current architecture, the fact that a person has not departed, is deduced from it being in stage WAITING_FOR_DEPART (libsumo/Person.cpp:60).
Since that stage was no longer added for a personTrip, traci included it in the list of departed persons.
After my revert, this is working as expected again.

Undeparted vehicles are also not included in getIDList. However, they can still be the subject of commands such as moveTo which can be used to force them into the network.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.