Transcript downloading
PDR- Team Status Brafman, Shani, Shimony: PLPs General tasks • PLP definition • PLP support tools – Editor – Code support (with Cogniteam) • Support for PLP definition by members – Feedback on PLP – Measurement of quantitative aspects in simulation • PLP-generated monitoring (with Cogniteam) • Algorithm for generating PLP of sequences 2 Resources- people, IP • • • • PIs: Ronen Brafma, Guy Shani, Eyal Shimony Post-doc (starting Jan): Simon Shamoun Student: Liat Cohen IP: PLPs?? 3 Current milestone tasks • Preliminary PLP Definition 4 Achievements • Preliminary PLP definition • Initial concept of integration into ROS setting 5 Activities in the near future • PLP Editor • Final(?) PLP Definition • PLPs for planned modules 6 Requirements\Expectations from partners • PLPs: We expect module suppliers to provide PLPs for their modules – Our post-doc will meet you to help you with the process • PLPs (longer term): We need access to modules and test inputs to provide success and runtime statistics • Code Support/Monitoring – in collaboration with Cogniteam. 7 Module Types • Achieve – try to get something to be true – Achieve – robot standing, robot in car, robot in position • Maintain – keep some condition true – Maintain heading (based on map, for example) – Maintain perimeter clean • Observe – determine the value of some variable – Observe distance to wall – Observe tool position • Detect – the “maintain” variant of observe (redundant?) – Detect intruder – Detect object 8 Repeat Flag • Special construct added to match current architecture. • Most modules repeatedly perform some operation with some frequency. • Example: Build map – Gets input from perception at some frequency – Outputs updated map with some frequency – Essentially: Repeat/Achieve 9 Repeat • Repeat flag possible for Achieve/Observe • Can be used to define Monitor/Detect • Add new parameters: – Input frequency – Output frequency – Termination condition 10 11 12 13 14 15 Achieve(holding-cup) Set of variables: arm-empty, wet-cup, clear-path(cup) • Parameters: none, or cup-location • Achievement goal: holding-cup • Guarantees: all other objects unaffected • Requires resources: robot-arm (exclusive) • Preconditions: arm-empty, clear-path(cup), cup-ok • Concurrency conditions: • Concurrent modules: • Side effects: not arm-empty • (Optional) failure modes: (1) not holding-cup (2) not holding-cup and cup- • broken Probability of success: 0.9 if not(cup-wet), 0.3 if cup-wet • Failure probability: (1) 0.08 if not(cup-wet), 0.4 if cup-wet (2) 0.02, 0.3 • Running time distribution given success: Some normal distribution. • Running time distribution given failure: Some normal distribution. •