Buffers¶

Related Work¶

• Simulink Data Store Memory
• State space
• ruleCore engine
• http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=0CG8QFjAG&url=http%3A%2F%2Fptolemy.eecs.berkeley.edu%2F~kienhuis%2Fftp%2Fasap97.pdf&ei=HolpT9ScCIGO4gTjrrDQAw&usg=AFQjCNHU_0PVPBXTSNnyjAfTh23p_RcbZg
• A scenario-aware data flow model for combined long-run average and worst-case performance analysis
• A FAULT-TOLERANT DISTRIBUTED DATA FLOW ARCHITECTURE FOR REAL-TIME DECENTRALIZED CONTROL
• http://gradworks.umi.com/34/86/3486845.html

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

Questions¶

• 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¶

/data/{a,b,c}
/mean/{a,b,c}
/frequency/{a,b,c}

Representations¶

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