pandora-auth-ros-pkg / pandora_fsm Goto Github PK

Agent fails to transition to gui_validation state of fsm given a victim with high enough probability to progress. Seems like a race condition because most times it fails to transit, but sometimes it does transit successfully. Below you will find a typical log of showing this error (from official run #1 of 21/5/2015).

https://slack-files.com/T03DJBDCK-F050FC16K-d3819d0289

Senario:

• Before:
  Agent has entered exploration state
• Actions:
  1. Agent gets an empty world model (see wm.a)
  2. Agent gets a world model with a candidate victim (see wm.b)
  3. Agent changes to identification state, moves base successfully, changes to sensor_hold state, timeout on probability thres and validates victim on data fusion as false.
  4. Agent gets a world model with a visited victim (see wm.c). Agent returns to exploration state but i dont know when relatively to the world model update, because world model update happens asyncronously.
  5. Agent gets the same world model as 4 (see wm.c)
• After: Crush with 'maximum recursion depth reached error'
• wm.a:
  victims: [] visitedVictims: []

• wm.b:
  `
  victims:

  id: 0
  victimFrameId: victim_0
  victimPose:
  header:
  seq: 0
  stamp:
  secs: 0
  nsecs: 0
  frame_id: /map
  pose:
  position:
  x: 9.78176074115
  y: -0.39768439749
  z: 0.486580014229
  orientation:
  x: 0.0
  y: 0.0
  z: 0.906307553515
  w: 0.422618762529
  probability: 0.0
  sensors: []
  valid: False
  visitedVictims: []
  `

• wm.c:
  `
  victims: []
  visitedVictims:

  id: 0
  victimFrameId: victim_0
  victimPose:
  header:
  seq: 0
  stamp:
  secs: 0
  nsecs: 0
  frame_id: /map
  pose:
  position:
  x: 9.78176074115
  y: -0.39768439749
  z: 0.486580014229
  orientation:
  x: 0.0
  y: 0.0
  z: 0.906307553515
  w: 0.422618762529
  probability: 0.0
  sensors: []
  valid: False
  `

Agent Fatal!: "bad callback: Agent: receiveworldmodel at agent.py line 338
Attribute_error 'NoneType' object has no attribute 'probability' "

Discovered at 'run 2' of 21/5/2015

Please rename navigation client to exploration client, applying whatever changes this means. Also, rename control client to navigation client.

This is happening in order to have an inspection of the system's integration inside agent module. Pandora_navigation repo exposes a move_base action interface and thus the respective client side should be named after navigation. Similarly, pandora_exploration exposes a do_exploration action interface and thus the respective client side should be named after exploration.

https://github.com/pandora-auth-ros-pkg/pandora_fsm/blob/hydro-devel/src/pandora_fsm/clients/navigation.py
https://github.com/pandora-auth-ros-pkg/pandora_fsm/blob/hydro-devel/src/pandora_fsm/clients/control.py

It is purely typical changes 😛

Agent should not have knowledge of end effector model of our robot. She should describe in high level language what we want to do. End effector controller module has robot specific knowledge and is delegated with the task to split the actuating problem into actuating sub-problems of our robot's end effectors. So, end effector controller describes what our robot in specific should do and delegates how it should be done to linear movement controller and sensor orientation controller. Linear movement controller actuates linear motors accordingly and so does sensor orientation controller for pan tilt of a sensor.

https://github.com/pandora-auth-ros-pkg/pandora_control/tree/end_effector_refactoring

So in general the only one who should has the MoveLinearAction is end effector controller.
https://github.com/pandora-auth-ros-pkg/pandora_fsm/blob/hydro-devel/src/pandora_fsm/clients/linear.py
Please delegate all such functionality to end effector controller.

Scenario:

1. victim is found: victimsToGo: [1]
2. while victim is getting validated, we get another victim found: victimsTogo: [1, 2]
3. Victim 1 gets validated and we return to exploration
4. Agent does not proceed to change to identification state with 2, until another victim alert arrives. Last world model update happened at event 2

Found with STDR and mass alert publisher as a testing/simulation tools.

Agent's log below

Possible cause (?):
Agent's error in acquiring victim 0 reveals that next candidate victim selection happened before the change in the world model, due to victim validation, was known to the agent