SubsumptionArchitecture
ThoughtStorms Wiki
Subsumption architecture was proposed by RodneyBrooks as an alternative to decomposition by function.
Also called BehaviouralDecomposition.
In the classical example, if I want to build a WallFollowingRobot I would expect to decompose my control system into the following parts.
- a wall detection and mapping module which uses sensors to determine the position of the walls
- a route planner, which uses information from the wall detection and mapping module to plan a route beside the wall
- a movement controller, which uses information from the route planner to move the legs of the robot to walk it along the wall
Brooks thinks this kind of decomposition scales up badly, so proposes a different decomposition into layers of behaviour. Each layer of behaviour covers the whole robot including sensor, decision making and motor control functions. But the behaviours are limited by the circumstances where they are relevant and invoked and in the scope of what they are intended to achieve.
A behavioural decomposition of wall following might go like this.
- A forward motion behaviour ... if there's nothing in front of you, walk forward otherwise stop.
- A turn to avoid obstacle behaviour ... if there is something in front of you and you're stopped, begin to rotate
- A restart behavior ... if you're stopped and there's nothing in front, start walking forward.
Notes :
- these behavioural rules add up to wall following.
- The behaviours are also thought of as layers and are arranged hierarchically. Layers sit on top of layers.
- In simple subsumption architectures, as with ModelViewController, there's a separation of dependency between the layers. The lower level can be built and tested first, the higher layers can be added later.
- Behaviours don't depend on passing large data-strucures with complex InternalRepresentations to each other. They don't necessarily need any software communication. Instead the layers can communicate through the position of the body and environmental cues. In the example above, the "turn" behaviour may only be triggered by motion detectors that discover that the robot has stopped walking.
- Although may produce some unintended behaviours in unusual situations. That's acceptable because subsumption architecture acknowledges that the environment must be complicit in any control system. The important point is to design for whatever environoment you're likely to meet.
I guess the argument for subsumption is that it scales better because of cheaper communication costs between the behavioural modules than there would be between functional modules. Brooks has been trying to scale up his approach with the CogProject with some interesting results.
Any relation to :
Contrast the approach taken by the SemanticWeb
See also ModularityMistake, SystemsThinking
CategoryArtificialLife, CategoryArtificialIntelligence, CategoryRobots