README.md

Distributed Memory

The ArMem memory system is distributed: It is comprised of several memory servers storing data in a hierarchical structure. A memory server can be defined in any ArmarX package and defines which kind of data it stores (e.g. robot state, object classes and instances, visual data, speech, ...). As a memory server knows which data it stores, it can provide special behaviour, such as custom visualization, aggregation, interpolation or prediction. As each server is a separate component describing its own structure, it is simple to add new memory servers containing special data types, which are defined in ArmarX packages further down in the dependency chain.

All memory servers follow the same hierarchical data structure and self-describing data format. The data structure consists of several levels, storing histories/timelines of different entities stored in different segments (see "Memory Levels" below). The common data format is ARON (ArmarX Object Notation), which is a self-describing, hierarchical data format, allowing extensive introspection as well as general storage. Each item in the memory (i.e. entries in all levels) can be identified with a Memory ID, which contains the keys of each (specified) level. For example, a core segment ID specifies the memory name and core segment name, while an entity instance ID specifies the whole path to the leaf of the data structure.

Technically, each memory server is one ArmarX component implementing the armem::server::MemoryInterface (comprising a ReadingMemoryInterface and a WritingMemoryInterface). Memory servers register themselves in the Memory Name System (MNS), where they can be found by their (semantic) memory name (which is usually a short, human-readable name such as "Robot", "Object" or "Vision"). Memory servers receive data via commits (via the WritingMemoryInterface), and return data according to queries (via the ReadingMemoryInterface).

Memory Levels

A memory server stores data in a hierarchical structure consisting of several levels:

- Grasping (Memory)
  - Grasps (Core Segment)
    - KnownObjectGraspPlanner (Provider Segment)
      - my_object (Entity)
        - t = 2021-03-09 14:24:20.064524 (Entity Snapshot)
          - 00 (Entity Instance)
          - 01 (Entity Instance)
          - 02 (Entity Instance)

Level	Key	Description	Examples	Implementation
Memory	Name (String)	Semantic grouping of one or more core segments. Corresponds to one memory server.	Robot, Object, Vision	Memory
Core Segment	Name (String)	Building block of a memory containing homogeneous data of a specific (ARON) type. Specifies a Core Segment Type which all provided data must comply to.	(Robot) Configuration, (Object) Classes, Known (Object) Instances, ImageRGB	CoreSegment
Provider Segment	Name (String)	Sub-segment of a core segment which contains the data from a single source (e.g. a camera, a method, a component). Can define a Provider Segment Type which extends the Core Segment Type.	Primsense, SimTrack, MyGraspPlanner	ProviderSegment
Entity	Name (String)	A single thing or concept whose properties change over time. An entity has a history / timeline, i.e. a sequence of snapshots storing the entity's properties at a specific point in time.	image, some_object, some_object_grasps	Entity
Entity Snapshot	Timestamp (armem::Time aka IceUtil::Time)	An entry of an entity's history, i.e. the state of an entity at a specific point in time. Can contain multiple (entitiy) instances.	Image, object instance, grasp hypotheses at a time t	EntitySnapshot
Entity Instance	Index (int)	One instance of the segment's ARON type.	left/right stereo image (at time t), object (at time t), grasp hypothesis (one of many at time t)	EntityInstance
Entity Instance Metadata	--	Metadata stored alongside the instance's data.	Further timesteps, confidence	EntityInstanceMetadata