Post on 03-Jan-2016
description
CS 415 – A.I.
Slide Set 8
Agenda
• Today– Subsumption Architecture
• Wednesday–Mapping
• Other Topics– Emergent Knowledge– Computer Vision– Stochastic Learning– Knowledge Representation–Group Robotics
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
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.
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...
Classification of items depending on the robot’s model :
Vegetable with peel or not, time needed to be cooked
Detection of dirtiness, texture sensors
Tasks planning to synchronized actions
Actions : wash or peel vegetables, put
it in a sauce pan until it is cooked.
7
Let’s imagine a robot that cooks...
• Subsumption architecture robots
Preparing vegetable to be
cooked
Detection of dirtiness, texture sensors
Cook
Avoid from burning
Wash vegetable in water or peel it
Heat sensor, texture sensor, detection of
dirtiness
Smoke detection
Put vegetable in a sauce pan
Served vegetable
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
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
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
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
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
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
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
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
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)
• 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
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
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?