- Generated by
1.8.17
|
|
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 storedSee 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>.
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.
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. 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.
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.
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.8.17