|
Before importing scenes into MemoryX it is required to start MongoDB:
armarx memory start
If an error occurs during the execution of this script follow the given advice and run
armarx memory repair
Currently, three different importers are available in Memoryx:
Use the memoryx::PriorKnowledgeImporter if you want to import OpenInventor (IV) models into a PriorKnowledge segment of MemoryX. It works by scanning a specified directory and importing all found *.iv and *.wrl files.
Each object is stored in MongoDB as
The object name with which the object can be retrieved from memory is determined by stripping .iv or .wrl from the filenames to be imported.
For importing IV files into MemoryX take a look at the scenario MemoryX/scenarios/PriorKnowledgeImporter/. This scenario starts all required components to import files from a single directory. The following component properties control from where the files are imported and into which part of the memory:
For importing complete scenes (including PriorKnowledge) the SimoxSceneImporter should be used. The import of a Simox scene description XML includes the follwowing steps:
An example on how to import Simox scenes can be found in the scenario MemoryX/scenarios/SimoxSceneImporter/. All required components for importing Simox scenes are started by this scenario. To adapt the import process to your needs take a look at the following component Properties:
The XMLSceneImporter is usde to import scene descriptions which were exported from Blender (how does this export work?). During import, all found entities referenced in the file will be added to the WorkingMemory (objectInstances memory segment) but no objects will be added to PriorKnowledge. After WorkingMemory has been filled with object instances, a snapshot is generated.
The scenario MemoryX/scenarios/XMLSceneImporter/ starts all required components for importing Blender scene descriptions. It can be adjusted by tuning the following component Properties:
The following files which can be imported with this method can be found in MemoryX/data/MemoryX:
H2T-Kitchen.xml H2T-Kitchen-open-cupboards.xml H2T-Kitchen-open-fridge.xml H2T-Kitchen-alternate-orientation.xml MobileKitchen.xml
An easy-to-use GUI for accessing and querying MongoDB is RoboMongo.
RoboMongo connects to an MongoDB instance and allows you to inspect and edit the current conent of the database.
How to retrieve a ChannelRef from an object name and trigger continuous object recognition every 30 milliseconds.
The objectInstanceChannel now contains the information about the instance of the object and queried as shown below.
How to retrieve position and orientation from a ChannelRef
How to use a ChannelRef to install a condition:
Required code in toplevel CMakeLists.txt
Required libraries to link to your (statechart) library
Databases are automatically created on the fly depending on the configuration of the components you are starting in your scenario. If you specify a collection in the LongtermMemory config file that does not exists, the database and the collection will be created automatically. With the Collections config parameters in the PriorKnowledge configuration it is also possible to use multiple databases at once since the database and collection name need to be specified for each collection (e.g. memdb.ObjectClasses).
If you want to create and use a new empty database, your CMakeLists.txt hase to contain following lines:
set(SCENARIO_CONFIGS config/LongtermMemory.cfg )
Furthermore you have to insert following line into the file config/LongtermMemory.cfg:
MemoryX.LongtermMemory.DatabaseName = new_db
where "new_db" has to be replaced with the name of the database you want to create.
MemoryX provides cosistent mechanisms to store data files in mongodb (see GridFS files and file reference attributes for details). Since some APIs need data files to be locally present (i.e. accessible via the file system), MemoryX offers methods to download/cache these data files to a local directory on your host. The default cache directory is
~/.armarx/mongo/.cache/files
On request the files are cached to that directory and can be accessed via standard file I/O operations. You can manually inspect the content of this directory if you need to know which files are used. Note, that any changes that are made here will be overwritten automatically whenever the file is accessed through MemoryX. In addition, the GridFS File Editor Gui Plugin can be used to inspect and to edit the files that are stored in the database.
It is possible to obtain a lock on the memory for any other access to prohibit any other changes (and access at all) to the memory. For this it is needed to call the function MemoryInterface::lockSegment() (this works only on remote calls!). After this, the segment is locked for any reading or writing call unless the specific token received from lockSegment() is passed in (the functions will wait until the segment is unlocked again). This lock prevails until the return value of lockSegment() goes out of scope or unlockSegment() is called. Long story short, here is an easy example:
An automatic keepAlive makes certain that the segment is also unlocked if your program crashes.