1. Lecture 6: Hybrid Robot Control Gal A. Kaminka galk@cs.biu.ac.il Introduction to Robots and Multi-Robot Systems Agents in Physical and Virtual Environments

2. 2 © Gal Kaminka Last week, on Robots …. A little tutorial on empirical research Using RoboCup virtual robots A case study: The Design of two RoboCup team(s) Won 3 rd place in 1997 Won 4 th place in 1998

3. 3 © Gal Kaminka This week, on Robots…. Hybrid control: Using both reactive and predictive systems together Sometimes referred to as reactive and deliberative systems Key points: How to use systems in a complementary manner? Guidelines for use and design? Three-Tier, RCS architectures as case studies

4. 4 © Gal Kaminka The success of behavior-based control Planning (ala STRIPS) proven insufficient Brooks, behavior-based crowd claimed unnecessary No (uniform) representation of world Fast reaction to sensors Indeed, behavior based control successful Changed paradigm Showed everyone that robots can actually move…

5. 5 © Gal Kaminka The limits of (simple) behavior- based control Lots of hard work by designer Building behaviors is sometimes not easy Coordinating behaviors can be difficult Fine-tuning can be hell! Overly dependent on sensors Not that good at managing complexity e.g., the need for a temporal-coordinating FSA Needed: Prediction

6. 6 © Gal Kaminka Behavior-based control showed planning insufficient But planning (prediction) is still necessary Cases where sequence of behaviors is unknown in advance How do we get the best of reactivity and planning?

7. 7 © Gal Kaminka Hybrid Control Have planning and reactive subsystems Somehow make them control robot together Planner/ Decision Maker Behavior-Based/ Reactive Controller ?

8. 8 © Gal Kaminka Two Case Studies Atlantis, a 3-Tier hierarchical architecture A planner An executive/scheduler/command sequencer A (reactive) controller Actually one of 2-3 architectures with similar configuration RCS (Realtime Control System) Hierarchical, many layers (as many as necessary) Each layer can have several concurrent controllers Controller: Sensor readings, world modeling, action, etc.

9. 9 © Gal Kaminka ATLANTIS: Structure Overview Sequencer drives the control Makes queries to deliberator Deliberator Sequencer Controller Replanning Requests New plans Selected Behavior Success/ Failure

10. 10 © Gal Kaminka Controller Closed-loop controller (uses feedback) Fuzzy, PID, predictive Must be fast enough (constant time/space) Must be able to detect failure So sequencer can select another behavior, call replanner Avoid internal state (other than for state estimation) May have a library of controllers/behaviors Focus on one simple behavior at a time

11. 11 © Gal Kaminka Deliberator Operation initiated and terminated by sequencer No sensing---all internal state Time consuming tasks: e.g., Planning routes using maps Can have any representation or implementation As long as can pass useful information, on request

12. 12 © Gal Kaminka Sequencer (executive/scheduler) Interfaces controller to planner (deliberator) Selects which behavior to apply Sequences, loops, conditionals, parallel threads Drives execution Get success/failure status from controller Examine state of world Queries deliberator for heavy computations

13. 13 © Gal Kaminka Sequencer maintains internal state Key task is to select behaviors Makes decisions about selection For instance, when several options available Maintain queue of behaviors pending execution Keeps track of previously selected behaviors Keeps track of successes and failures

14. 14 © Gal Kaminka Key points Non uniform representation, methods 3T is a framework, with very loose guidelines e.g., Avoid internal state in controller, use more in deliberator e.g., gray area when it comes to differentiating the layers Layers are distinguished by processing speed Speed: With respect to response timing in the environment Layers function in parallel, asynchronously Controller must recognize successes and failures Planning is necessary, but only to guide execution 3T not a strict hierarchy—middle layer drives execution

15. 15 © Gal Kaminka שאלות?

16. 16 © Gal Kaminka Real-time Control System (RCS) Control Node Control Node Control Node Control Node Control Node Control Node Control Node Control Node Control Node Sensors and Actuators

17. 17 © Gal Kaminka Real-time Control System (RCS) Control Node Control Node Control Node Control Node Control Node Control Node Control Node Control Node Control Node Sensors and Actuators Perception Events Commands & Tasks Information sharing

18. 18 © Gal Kaminka Real-time Control System (RCS) Control Node Control Node Control Node Control Node Control Node Control Node Control Node Control Node Control Node Sensors and Actuators Exponential Response Duration

19. 19 © Gal Kaminka RCS Control Node: Modules Standard module components, designer-implemented Designer can merge components SP WM BG VJ Value Judgment Sensor Processing World Modeling Behavior Generation

20. 20 © Gal Kaminka RCS Control Node: Structure Standardized module interfaces SP WM BG VJ Behavior Eval. Virtual Behavior World State Expected Behavior Results Updates World Modeling State Evaluation Perceived Events Commands/ Goals/ Tasks Perceived Events Commands/ Goals/ Tasks

21. 21 © Gal Kaminka Connecting nodes at same level All WM are connected to each other, share information In principle, a distributed shared knowledge base SP WM BG VJ To sibling WM modules

22. 22 © Gal Kaminka RCS operator interface Operator interface not clearly specified SP WM BG VJ Operator Intervention

23. 23 © Gal Kaminka RCS Key points Framework, not a system Implementations exist Implementations can deviate in instantiation of modules Differentiates levels along exponential time scales Response duration Coupled sensing and acting at each level Similar to subsumption architecture But uses explicit world models, internal state, planning Strict hierarchy: Commands passed down, top node drives execution

24. 24 © Gal Kaminka 3T and RCS Hybrid Control Both differentiate time scales 3T: response timing, RCS: response duration Heterogeneous representations 3T almost no constraint, RCS structural constraints 3T not strict hierarchy—middle layer drives execution Differ in level of guidance to designer 3T less structured, less guiding RCS-based designs more guided, RCS more complex structure Designer has to instantiate more modules