- Generated by
1.13.2
|
|
When you start using ArmarX on a code level, you probably first install Axii - the ArmarX integrated installer, which serves as a package manager. Then, you create a workspace, which is a way to encapsulate installed software. This allows you to have several independent installations on the same user account of your PC. You then add (Axii) modules to the workspace, which declares that certain software shall be installed to that workspace. Once you update (or, doing several steps at once, upgrade) the workspace, the respective git repositories will be cloned. The code of each git repository is also referred to as a package, e.g., when using ArmarX PackagePaths.
When you start using ArmarX on a GUI level, you will first open an ArmarX GUI, which mainly uses widgets to provide all the specific functionalities. Most often you will use the Log (technically speaking, Meta.LogViewer) and a scenario manager (ScenarioManager). If you want to see a 3D visualization, ArViz (ArViz and Visualization.3D Viewer) or ArViz Godot (arviz_godot) are what you need. In cases that a functionality is not provided by a stand-alone widget, there often is a tab in the RemoteGUI (RemoteGUI) widget, which is faster to implement. If there are too many tabs in the RemoteGUI to easily find what you are looking for, enable group tabs and select the category that you are interested in. Other frequently used widgets are the MemoryViewer (MemoryViewer) to see the current content of the robot's working memory, and the SkillManager (Skills.Manager) to invoke functionalities of the robot that are provided in a specific skill format. More on the memory and on skills later in their dedicated sections.
Inside a package, the code usually follows a fixed structure.
If the package contains (also) python code, there will be a python folder with subfolders for each python package. Each python packages is usually installed separately, having its own virtual environment, being located at its top-level folder.
If the package contains (also) C++ code, there is a source folder with a subfolder according to the package. The main content of most repositories is inside that folder. Typically, there is a components folder, which are - apart from some details explained in the glossary - the programs that can actually be started in the ArmarX GUI. The other folders in there are less standardized. Modern packages often have a core folder that contains central data types. C++ libraries, which is code that cannot directly be executed but is included by other code, is located in separate folders on the same level. In older packages, there typically are separate folders for interfaces, libraries and others.
Further common directories are:
build, where all auto-generated files are written intodata (with a subfolder according to the package), where data like images or object models is stored inetc, which contains the doxygen folder for documentation, among othersexamples (if available), containing code you can just try out to get familiar with the packagescenarios, in which the configuration files of scenarios visible in the ArmarX GUI are storedOne of the main parts of our robot software framework is the memory system. It functions as a mediator-level between low-level sensor and hardware functionalities and high-level functionalities of the system like skill executions, object detection etc. ArMem is a distributed system consisting of different memory servers which can recide on different PCs. A memory server can be defined in any ArmarX package and defines which semantic kind of data it stores (e.g. robot state, object classes and instances, visual data, speech, ...). As each server is a separate component describing its own structure, it is simple to add new memory servers containing special data types, which can also be defined in other ArmarX packages. All memory servers follow the same hierarchical data structure and self-describing data format. The data structure in each memory server consists of several levels (Core Segments, Provider Segments, Entities, Entity Snapshots, and Entity Instances). An Entity's location is determined by the Core Segment and Provider Segment, while its history/timeline is represented by Entity Snapshots and, in each of them, one or multiple Entity Instances. The common data format is ArmarX Object Notation (ARON) / Interpretable Data Format (IDF), 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.
Also see the extensive explanation of the ArmarX memory system.
When implementing a functionality of the robot, this can be done as a so-called skill. This means that the implementation inherits from a certain class, and thus follows a specific structure. The advantage is that skills can easily be invoked via the GUI, via speech commands, or from code. Also, they have a clearly defined initialization and tear-down process, and can easily be parameterized.
If you want to implement a skill, you need to parts: The first part is the skill library, which is just C++ library¹ code. Here, or in further code included here, the actual implementation takes place. The second part is the skill provider, which is an executable component*. The skill provider is what is started in the scenario manager¹. It creates instances of the skill on demand, using a skill factory.
There also is the skill memory, which is a memory server¹ dedicated to keep information about the runtime status of skills. For example, it contains which skill was started with which paramters, and whether the execution is still ongoing, was successful, or failed.
¹ For theses terms, which were already introduced, see the explanations above if needed.
The current memory implementation in ArmarX, also called ArMem. Not to be confused with its predecessor MemoryX. The ArmarX Memory is central for ArmarX' memory-centric architecture and serves, among others, to exchange and store data.
armarx-package is a command line utility that helps to create and extend ArmarX packages. It is part of the "ArmarXCore" ArmarX package. See also: ArmarX package.
An ArmarX package corresponds to a CMake project, typically contained in a separate git repository. ArmarX packages are used (i) in the ScenarioManager of an ArmarX GUI and (ii) to specify ArmarX package paths. See also: armarx-package.
ArmarX can be run as a distributed system, i.e., accross multiple computers in the same network. To do so, Ice is used as the middleware. ArmarX Profiles are used to specify which Ice server to connect to. You can check which profile is currently activated by running armarx profile and switch to another profile (including creating a new one) by running armarx switch <name>.
ARON (ArmarX Object Notation) is the ArmarX implementation of variants which can be transferred over the network via ZeroC Ice. It is our instantiation of an Interpretable Data Format (IDF). Further, ARON is the data representation used in the ArmarX Memory System.
Axii is the ArmarX Integrated Installer, which greatly helps to install and update your Armarx installation. It serves as a package manager, similar to Ubuntu's apt tool.
Entity A single thing or concept whose properties change over time. An entity has a history / timeline, i.e. a sequence of snapshots, each storing the entity's properties at a specific point in time.
Entity Instance One instance of the provider segment's ARON type.
Entity Snapshot 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.
Instance See Entity Instance
See MMM
MMM (Master Motor Map) can refer to two things:
See Memory Server, which the term usually refers to. Alternatively, see ArmarX Memory for the complete system.
A Memory Server is a component in ArmarX that provides certain interfaces and recides on one physical computer. It groups several core segments, which typically have a semantic relation to eachother.
Predecessor of the ArmarX Memory system. Partially used by old code, but not to be used by new code.
Provider Segment 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.
Simox is a software library outside of ArmarX, which many ArmarX packages depend on. It provides fundamental functionality, e.g., with respect to kinematic structures or path planning algorithms.
See Entity Snapshot
Multiple ArmarX installations can co-exist on the same user account. A workspace is used for each of them to encapsulate them, avoiding side-effects between workspaces. Use Axii to create workspaces, and to activate them. In ROS, catkin workspaces serve a similar purpose.
1.13.2