There is an interesting twist in the synchronization of our components. After successfully running the tables demo, the box is on the target table with the multimeter inside. These poses are stored in the pose_selector and thus can be retrieved as facts by the symbolic_fact_generation. Upon restarting the tables demo, the robot is set to assume that the items can be anywhere. So, when it looks at the target_table, even after the items have been removed from there, it does not clear the facts for this table, according to:
https://github.com/DFKI-NI/mobipick_labs/blob/noetic/tables_demo_planning/src/tables_demo_planning/tables_demo_api.py#L193
The symbolic_fact_generation thus returns the "facts" that box and multimeter are still on the target_table. This might explain some observations we made when repeating the demo without restarting the ROS nodes.
As probably easiest solution I will simply delete all poses for the demo items on demo initialization.
There is an interesting twist in the synchronization of our components. After successfully running the tables demo, the box is on the target table with the multimeter inside. These poses are stored in the pose_selector and thus can be retrieved as facts by the symbolic_fact_generation. Upon restarting the tables demo, the robot is set to assume that the items can be anywhere. So, when it looks at the target_table, even after the items have been removed from there, it does not clear the facts for this table, according to: https://github.com/DFKI-NI/mobipick_labs/blob/noetic/tables_demo_planning/src/tables_demo_planning/tables_demo_api.py#L193 The symbolic_fact_generation thus returns the "facts" that box and multimeter are still on the target_table. This might explain some observations we made when repeating the demo without restarting the ROS nodes.
As probably easiest solution I will simply delete all poses for the demo items on demo initialization.