Conversation
…es it back; RESTARTING EXECUTION UNTESTED
…e this not working smoothly because index increments before success is validated; UNTESTED
…icking, but that's more complex
Yeah, I think that probably makes sense. Especially since you could image other feedback communication that the lease monitor might want to try sending back to ROS. Overall the PR looks good! |
…ot's lease was taken
This nominally supports the graceful handoff between the spot executor and the tablet. It works well when the robot is following a continuous trajectory, but is a little less clean for the pick skill.
Pick Skill Comments We want to exit out of the pick skill when we lose the lease, but this does not happen until we actually try to pick up the object. If the detector has detected an object and the lease is hijacked, the pick skill will continue waiting for the user to confirm the detection is valid. If the user confirms before the lease is returned, a LeaseUseError will be thrown when the robot actually tries to pick up the object. HOWEVER, if the lease is returned and THEN the user confirms the detection, the robot will try to pick up the object with potentially the wrong xy location (e.g., if the robot was moved by the user). Thus, we need to raise a LeaseUserError if we lose the lease when we are waiting for confirmation.
Potential Solutions The RosFeedbackCollector does not have access to the spot_interface, so it cannot check if we have the lease. Currently, the LeaseManager does not have access to the RosFeedbackCollector instance (but could), where it would then set feedback.break_out_of_waiting_loop to True. @GoldenZephyr thoughts on passing feedback to monitor_lease?