Can bottom-up architectures be effectively programmed in top-down paradigms?

Question

The subsumption architecture, proposed by Rodney Brooks in 1986, is a "bottom-up" approach, in which robots are designed using simple hierarchical models. These models build upon and subsume the lower modules to form a final product. For example, a robot can be given a "find opening" module which is subsumed by a more abstract "find doorway" module, which is then itself subsumed by an "exit the playing field" module.

Now, obviously, in a more "object-oriented" design, we could have started the design with the "exit the playing field module", but for sake of argument, assume some of the more primitive components (as "functions") will likely get reused in other higher concepts.

Realizing that implementing this robot in a procedural language (or a functional one, for that matter) could be the simplest, but is it counterproductive to try to conceive of a subsumption architecture-based robot in an object-oriented programming paradigm? (realizing also that it's perhaps difficult to weigh a software engineering paradigm against a robotics one) To obtain a solution, is there some form of "adapter" that can be implemented for increasing the effectiveness of using what may be two conflicting paradigms?

Answer 1

I would like to generalize this into a more common scenario. This I believe makes sense since the particulars of subsumption architecture are perhaps not a primary aspect in the question (and the same problems occur in non-robotic fields as well).

In general software archtitecture there is a bi-directional approach, or multi-paradigm approach, as in the question. The bottom most layer of an operating environment is generally written bottom up. Very specific code bits are written to driver very specific hardware elements on the system. These are then combined to form higher level components. I suspect we could easily describe this as a subsumption approach if we simply describe our robot as the system itself, and the goals to control specific aspects of that system. Though I'm not sure it is improtant to do so.

From the top-down most applications are written in higher level languages, or described in terms of an abstract machine. This is quite far removed from the bottom most libraries which will actually be doing the work.

At some point these two layers have to meet -- actually they meet at many locations in a variety of scenarios. This where you have to "adapt" the layers to be suitable for the other layer. The term "adapter" here is 100% correct. There is indeed a software pattern called "adapter" which is used for this purpose.

Aside from specific adapters we can actually consider the entire toolchain of any modern programming. The compiler itself, along with the liner and an execution VM, are the primary interface between the two layers. That is, a high level language is written in one domain, and the compiler is what allows it to work in the lower level domains.

If you are looking specifically for paradigm effectivness, consider that high-level languages exist for imperative programming (C++), functional programming (Haskell), and declarative programming (Prolog). These paradigms all ultimately work on the same underlying low-level libraries.

Is the question in robotics much different? No, I don't believe so. Indeed if the same ideas were formulated today I don't think they'd have a robotic specific term (subsumption architecture) as there is no strong difference from normal software architecture. You even indicate in your last paragraph both a functional and imperative paradigm for controlling a robot. I would however use a domain specific language to be used -- and again, the vast assortment of domain specific languages is further evidence that multiple paradigms can be efficiently adapted to each other.