Robotics Control with Subsumption Architecture | Enhancing Autonomous Behavior

1. CS 415 – A.I. Slide Set 8

2. Agenda • Today • Subsumption Architecture • Wednesday • Mapping • Other Topics • Emergent Knowledge • Computer Vision • Stochastic Learning • Knowledge Representation • Group Robotics

3. What kind of control? • Deliberative Control • Think Hard, Act Later • Reactive Control • Don't Think, React • Hybrid Control • Think Sometimes • Behavior-Based Control • Emergent Behavior

4. Subsumption Architecture • Brooks Paper-1985 • One particular, popular way to generate reactive control architectures • Interesting Note • Rodney Brooks co-founded, and is Chief Technical Officer and currently sits on the Board of iRobot corp.

5. Possible Approaches • Traditionally • Robotics Control was conceptualized linearly • Figure 1 • Decompose problem into a series of functional units • Subsumption Architecture • Robotics Control in Parallel • Figure 2 • Revolutionary – Turn model on its end • Decompose problem into task achieving behaviors

6. Let’s imagine a robot that cooks vegetables... • Traditional AI robots Colour, shape, odor, consistency... Detection of dirtiness, texture sensors Classification of items depending on the robot’s model : Vegetable with peel or not, time needed to be cooked Actions : wash or peel vegetables, put it in a sauce pan until it is cooked. Tasks planning to synchronized actions

7. Let’s imagine a robot that cooks... • Subsumption architecture robots Avoid from burning Smoke detection Served vegetable Heat sensor, texture sensor, detection of dirtiness Cook Put vegetable in a sauce pan Preparing vegetable to be cooked Detection of dirtiness, texture sensors Wash vegetable in water or peel it

8. Requirements • Multiple goals • Sometimes conflicting • Differing/changing relative importance • Multiple sensors • Error prone, No direct relation to real world • Inconsistent Readings • Robustness • Overcome failures • Processor, environment, sensors • Extensibility

9. Assumed Dogmas • We want autonomous robots • Map making is crucial • The map should be 3D • Relative maps are better than global • Complexity behavior doesn't assume complex design • Keep things simple • Visual data is most desirable • Self-calibration and recovery • Self-sustaining artificial beings

10. The Testbed • Processing – offboard LISP • 3 parallel drive wheels • 12 Sonar (rotating body)‏ • 2 CCD Cameras (tilt head)‏ • On board processor – Intel 8031 • 12K/sec Radio link

11. Levels of Competence • Traditional Approach • Slice problem according to internal workings of solution • Brooks Approach • Slice problem according to desired external manifestation • Level of Competence – informal specification of a desired class of behaviors for a robot over any and all environments

12. Particular Levels • 0 – Obstacle Avoidance • 1 – Wander aimlessly while avoiding • 2 – Explore (pick a destination)‏ • 3 – Mapping • 4 – Notice changes in the environment • 5 – Reason about identified objects • 6 – Change the world somehow • 7 – Reason about behavior of objects/modify your plans • IMPORTANT – each higher level includes as a subset previous layers

13. Building the Controller • Build an entire robot that realizes level 0 “perfectly” • Never change this level • Build another layer (level 1) on top of level 0 • Level 1 knows about, can examine data from and can inject data into the data flow of level 0 • Each higher level subsumes lower ones • No level knows anything about levels above it

14. Relating to our Goals • Multiple Goals – concurrent goal pursuit is possible/beneficial • Don't need to decide ahead of time what goal to pursue • Multiple Sensors – don't need to enforce a central representation • Robustness – Higher levels may be slower, but lower levels still run • Extensibility – smarter and smarter higher levels

15. Control System Spec. Lang • Each processor is a finite state machine. • Named states • NIL, reset, • Types of States • Output, Side effect, Conditional dispatch, Event dispatch • Multiple inputs/outputs • Can be suppressed/inhibited • Example pg 10 and 11 • LISP-like spec for avoid module • Schematic

16. Early Implementations • Level 0 and Level 1 (part of Level 2)‏ • Evolving Schematics on pgs 11-16 show how the subsumption architecture “evolves” • Paper also describes a simulated robot implementing the theory where hardware could not (as of August 1985)‏

17. Since then, many subsumption architectures have been developed • Robot named Herbert • Designed by Jonathan Connell • Aluminum can collector • Layer 2 was programmed to pick likely locations of empty cans • Layer N handled the gripping arm

18. Packbot (2002)‏ • help clear caves and bunkers, search buildings and cross live anti-personnel minefields • speed of up to 14 km/h • continuous 360 degrees rotation • negotiation of rough terrain and obstacles such as stairs, rocks, logs, rubble and debris. • can climb grades up to 60% • can survive submersion in water up to two meter deep

19. R-gator (2006): • The R-Gator Unmanned Vehicles for Physical Security pilot project: • Teleoperation • Autonomous waypoint navigation with “Teach & Playback” • Robotic following • Obstacle avoidance • Manual operation

20. Planetary Rover • A system suitable for a Mars Rover robot • Tasks • Move autonomously upon the rocky, cratered Martian surface • Gathering soil, atmospheric samples and images • Difficulty • No knowledge of the appearance of the ground, the locations and the obstacles is available

21. Mars Rovers • R. Brooks and A. Flynn (1989), "Fast, cheap, and out of control: A robot invasion of the solar system," J. Brit. Interplanetary Soc., vol. 42, no. 10, pp. 478-485, 1989. • Mars Pathfinder • Mars Exploration Rovers • These still have human intervention, however, but not much

22. Problems in 1985 • Painfully slow processors • Very close link between code and hardware • Low level considerations were necessary • How many logic gates does this bit of LISP take

23. Problems that are still applicable today? • Any ideas? • Scalability • Like hybrid control – what action do I do next? • What makes a good subsumption architecture? • What should the hierarchy look like? • Why are you worrying about it? • How flexible is the design... really?