Related Work

Additional Thoughts / Influences

  • "Memory is an active system"

Available Concepts

  • Short-term buffer
  • Egocentric representation
  • Prediction-correction pattern (usually requires some kind of transformation from input data to different output data)
  • Event-based interface
  • Discretizaton of space (from egosphere concept)
  • Activation network (from egosphere concept)
  • Reliability decay
  • Temporal query / event notification

Use Cases and Comparable Approaches

  • Temporal Coincidence Detection (things happen at the same time)
    • Fusion
    • Approach: Complex Event Processing
  • Location coincidence Detection
    • Fusion
    • Approach: Complex Event Processing
  • Lookup of past events
    • When is this necessary?
      • Probably only for higher-level tasks. Others use implicit temporal representation
      • Thus, requires query capabilities for on-demand processing (e.g. user asked a question to the robot)
  • Location-based activation (e.g. used as saliency):
    • probably hard to implement with other means?
  • Store fact-like knowledge:
    • probably not short-term?
    • Approach: simple database
  • Centrally available state:
    • Approach: root scope in RSB (assuming every component publishes it's state)
  • Algorithms on central state:
    • Approach: Complex event processing on root scope in RSB


  • In which situations is it beneficial to have a shared state space?
    • Fusion
    • For system development: addition of new fusion components because all data required for the new algorithm is instantaneously available
  • How to support multimodal integration / fusion?
  • How to evaluate quantitatively the applicability of the concepts?
  • Relational integrity? Is support required? (Contents of one buffer reference the other buffers' contents and will be updated when they are removed there)
  • How does the event-based nature relate to sub-symbolic / connectionist approaches for memory?

Required Decisions

  1. general tool vs. enforcing a specific functional architecture

Possible Consequences

  • Do we need a (single combined) memory at all?
    • Separate active parts as usual RSB-attached processes and provide history lookup as a unique function in a separate component
    • Events really must reflect state changes of components (as defined e.g. by Ted Faison)

Identified Problems

  • Single scope hierarchy (we probably need multiple bands, otherwise scope modeling becomes tedious)
  • Learning on unified representation not enforced (e.g. everything must be XML with position tags)
  • Aggregation functionality of RSB is nice, representation in other middleware concepts could be more work
  • Argumentation not possible on single component level. Instead, whole system needs to be analyzed
  • Updates of state published by one component not easily possible by another (e.g. in same event). New event (on different scope) required.

Scope Idea



Common use cases in HUMAVIPS:
  • Location information:
    • Image coordinate system:
      • 2D
      • 3D
      • 6D with pose or maybe only 4D in simple cases (2D + 2D)
    • Localization coordinate system
      • 2.5D? Maybe full 3D or even 6D?
    • Spherical coordinates or polar coordinates for sound processing
  • Reliability for percepts
  • Tracking information (track ID)
  • Result vector and reliabilities from a classification process