Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
V
vadere
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 110
    • Issues 110
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 4
    • Merge Requests 4
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • vadere
  • vadere
  • Issues
  • #285

Closed
Open
Opened Nov 27, 2019 by Philipp Schuegraf@hm-schuegra

Pedestrians do not move to a new target, if they reached their only target and get a new target

Summary

If pedestrians with one non-absorbing target reach it, they do not move to a new target, when this is set from outside (via TraCI).

What is the current bug behavior?

The pedestrians do not move anymore, even though they have a target.

What is the expected correct behavior?

The pedestrians should always be ready to receive a new target. E. g. if you meet with friends at a certain location, you might spontaneously decide to go to some other place.

Steps to reproduce

  1. Change absorbing to false for both targets
  2. Clean & Compile
  3. Start Manager
  4. Start TestClient
  5. ctr.nextStep until at least one pedestrian reached the target (27.11.2019 the default scenario has the targets with IDs "2" and "3").
  6. pers.setTargetList personID newTarget

personID is the ID of a pedestrian that reached its target,

newTarget is the ID of a target which is different than the target that pedestrian personID has reached

  1. ctr.nextStep

Relevant data

test_client_phsc/488f1e13

Scenarios/Demos/roVer/scenarios/scenario002.scenario

Quoting Stefan:

Es kann sein das die Personen beim OSM Model dann aus deiner liste raus-fliegen in der Pedestrians ein update call bekommen. Wie man das beheben kann weiß ich nicht genau. Das einfachste was mir einfällt wäre ein TargetChanger vor das non-absorbing Ziel setzen oder dem Pedestrian vor dem erreichen das non-absorbing Ziels ein neues Ziel in die Liste einfügen.

And:

Ja. Genau das wird gemacht. Hat ein Pedestrian mehrere ziele (targetList: [1, 2, 3]) und Ziel 1 ist non-absorbing, dann wird nach dem erreichen von ziel 1 die Liste verändert zu targetList:[2,3]. Wenn die Liste danach leer wird kann es gut möglich sein, dass diese Personen nie mehr ein update Call bekommen, weil irgendwo ein filter vorkommt mit getPedestriansWithTargetId(int x) o.ä. --> Vermutlich hats du hier einen Bug gefunden Eröffne mal ein Ticket. Ich weiß noch nicht was das gewünschte verhalten sein sollte.

@stsc

Edited Nov 27, 2019 by Philipp Schuegraf
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: vadere/vadere#285