Notes: Design Patterns & Architecture

Collection of my notes on design patterns in software / firmware. These are distinct from data structures / algorithms (which can be found here).

Subsumption Architecture

  • Sometimes called / mixed with the concept of Horse-and-rider
    • Analogy is lower level is a horse and the intelligence layer is a rider
      • Horse is concerned with motor control, local navigation
      • Rider is concerned with goal execution, global nav, etc.
  • Idea of functional behavior layers with downward dependency

Rodney Brooks

  • A Robust Layered Control System for a Mobile Robot : https://apps.dtic.mil/sti/pdfs/ADA160833.pdf
    • “Layers are made up of asynchronous modules which communicate over low bandwidth channels”
    • “Higher level layers can subsume the roles of lower levels by suppressing their outputs”
    • Environment changes rapidly, sensors are noisy, no straightforward mapping between sensors and action (situated in instant or in future)
    • Traditional robot architecture (at the time) follows a pipeline of
      • Perception
        • Sensors (noisy)
      • Modeling
      • Planning
      • Task Execution
      • Motor Control
        • Actuators (imprecise)
    • However, we need a robot to entertain
      • multiple goals (which may be in conflict)
        • individual layers run concurrently, supression mechanisms select goal
      • multiple sensors (cameras, range finders, GPS, microphone, etc.)
        • Inconsistent (potentially limited) view of the world
        • Not all sensors need to feed to central representation
          • Each layer builds its own model
      • Must be robust
        • Environment change or sensor failure should result in a robot that fails gracefully into next best behavior
        • Lower level behavior benefits from robust debugging
      • Additivity
        • New behaviors, sensors, or actuators should be easily mixed into existing system
          • Obviously we have limited hardware but our architecture shouldn’t necessarily limit multi-node processes
    • Each module should be simple, with low complexity inputs / outputs
    • Mapping is critical for robots
      • Human world is 3D, robot must operate in this 3D space not a 2D surface map
      • Relational maps are more useful than absolute coordinate maps
    • Robot operate in real world not a sterile simplified demo space
    • Visual data better than ranging data
    • Robot should be able to perform when one or more sensors fail
      • Robot must be self sustaining
    • Levels of competence : informal spec of a desired behavior in all environments
      • Following were identified for autonomous robot
        • Avoid contact with objects
        • Wander aimlessly without hitting things
        • Explore world by seeing places in distance that may be reachable and heading for them
        • Build a map of environment and plan routes
        • Notice changes in static environment
          • As in identify what is actually not static
        • Reason about the world in terms of identifiable objects and perform tasks related to certain objects
          • **THIS SEEMS TRICKY / UNSOLVED
        • Formulate and execute plans which involve changing the state of the world in some desired way
          • **THIS SEEMS TRICKY / UNSOLVED
        • Reason about the behavior of objects in the world and modify plans accordingly
          • **THIS SEEMS TRICKY / UNSOLVED