Subsumption Architecture

From BEAM Robotics Wiki

(Redirected from Subsumption architecture)
Jump to: navigation, search

We apologize for the need to display ads on this wiki. But somehow we must pay for hosting.

The BEAM Glossary says:


[edit] Brooks' Brainstorm

Introduced by Rodney Brooks and his colleagues in 1986, Subsumption Architecture has had a strong influence in the area of Autonomous Robots.

Whereas traditional Artificial Intelligence tends to rely on a centralized, top down, planning, execution and monitoring structure, subsumption architecture is a distributed, bottom up, reflexive approach to robot control.

Firure 1 - Block Diagram of a Subsumptin Based Robot
Firure 1 - Block Diagram of a Subsumptin Based Robot

Subsumption Architecture breaks complicated intelligent behaviors into many "simple" behavior modules. These modules are in turn organized into layers, each layer implementing a particular goal of the robot. Higher layers become increasingly more abstract with each layer subsuming the goals of the layers below it.

This means for instance that a decision to move made by the Explore layer (see Figure 1) must take into account the decision of the 'Follow Light layer directly below it, as well as the lowest layer labeled Avoid Obstacle.

Each layer can access all of the sensor data and generates commands for the actuators. And each separate tasks can suppress (or overrule) inputs or inhibit outputs. This way, the lowest layers can work like fast-adapting mechanisms (reflexes), while the higher layers work to achieve the overall goal.

[edit] Nervous net as the Lowest Layer in a Subsumptive Design

The idea of of merging BEAM circuits with subsumption architecture goes way back to the earliest days of BEAM Robotics. As proof, note that the following quote from Mark W. Tilden, which dates back to Oct of 1996. {{Mark Tilden|Mark]] made these comments in a post he sent to the original BEAM email list, in response to another post about using a “Tilden-esque nervous net as the lowest layer in a Brooks-style subsumption architecture”.

Well, it works, but there's a problem.

When I first started reading Brooks, I immediately built a variety of my own Subsumption based machines (micromouse, two-legged walker, three legged hopper, remote submarine, etc), and immediately found the same problem I'd had with conventional parallel-design robotics. To whit...

Tilden's Design Law: If, for a linear increase in ability, an exponential increase in complexity is required, then start over from scratch.

Subsumption is better than parallel-control designs (which are VERY brittle, especially as they are so software/connection dependent), but the same complexity problem kept popping up in my subsumption designs as well. The layered structure is a beautiful, threaded way to think about behavioral control, but when one exception is made, you have to make other exceptions to counter it, and after a while, you have a mess you've forgotten how to debug five minutes after the download.

The Nv approach is not just a robust way to phase-drive motors, it's my attempt at a design methodology that gives linear ability for linear complexity. If you've built the bare-bones Nv walker you know it works. The secrets are minimality and symmetry (I get pissed if I have to use two whole hex inverters for a complete walking design, and doubly so if the circuit has ugly bumps in the schematic).

But there's more. Nv tech is not just a bunch of oscillators, work we're doing now shows that given the right type of Nv designs, capable autonomy is not just possible, it is, given the right neural morphology, damn well inevitable over a vast spectrum. That is, there now exist Nv designs that give Exponential ability increase for linear complexity increase, and they still work even if the damn thing gets chain-sawed!

I think the secret of life is anything that exhibits more competent survival behaviors than components (biological plausable? Anyone?). The problem is, if you stick a processor on top of it, you run the risk of violating this rule, and even worse, imposing artificial values from the uP on a Nv more capable of handling itself.

Getting a Nv to work is simple. Hooking it up so it can work with other influences, aye therrre's the rub, and a major unexplored research field. We've had one successful uP interface (Telluride, July 96), but not a few other laughable failures (i.e.: the apply named Spazbot).

So it can be done, but my recommendation (or perhaps it's just my private mania) is to see just how far we can push Nv tech into doing things we'd nomally expect the uP to do. Is there a limit to Nv adaptability? Don't know. More machines necessary.

Is all.


[edit] The H-Switch

Firure 2 - Bruce Robinson's H-Switch concept with Truth Table
Firure 2 - Bruce Robinson's H-Switch concept with Truth Table

This is not unlike the H-Switch (Hierarchical switch) concept that Bruce Robinson introduced to the BEAM community. (see Figure 2). Bruce developed the H-Switch in attempt to provide a high level of control for a BEAM based soccer playing robot.

His intent was to create a simplified form of a general control that would be able to...

“receive input from half a dozen types of sensons and produce 10 to 20 behaviors that would give a simple approximation of playing soccer"
(From a post by Bruce Robinson to the BEAM email list)

The general principle is that signals would be received from various sensors and pre-processed to give a set of "conditions". Signal representing these conditions would then be sent to a control unit. The control unit would consist of a network of H-Switches', which would determine which behavior module should be activated. The selected module would then execute the desired behavior, or sequence of activities, by activating the required motors as needed. A behavior module could be as simple as a complete bicore walker circuit.

The H-Switch is not defined by a specific circuit. Rather, it is a concept for which there has been a variety of proposed and constructed implementations. A more complete explanation of the H-Switch will be found >HERE<

[edit] Another Stacked Behavior Concept

Firure 3 - A Stacked Behavior Circuit Concept
Firure 3 - A Stacked Behavior Circuit Concept

Droidmakr (AKA Clifford Boerema) also posted a related circuit concept that can be seen in figure 3.

More to Come

[edit] External References

The following articles can be found on the Johuco Ltd. website.

This wiki is sponsored and hosted by Interactive Matter
Personal tools
Ads to finance this wiki