- Generated on Sat Oct 12 2024 09:14:23 for armarx_documentation by
1.8.17
|
|
Use the following commands if you want to do a "git pull" in every repository (please be aware of how git pull works if you are not on the master branch)
or
As an alternative to performing "git pull --rebase" it is also possible to use the following repo command. Please make sure you understand what REBASING means and what it will do if you are working on a branch. \warn Do not use this command if your branch has already been published!
With the armarx-dev script you can compile and pull all repositories needed for the compilation target with one command. Just pass –pull to the command. If you have changes in one or more of the repositories you can use –stashnpull. For example for RobotSkillTemplates use:
Ice does not like it when the network adapter get disabled or changes and thus everything of the Ice framework does not respond anymore. If all the apps/gui does not respond anymore and you cannot start new apps, you have the reset the Ice middleware. We provide a convenient command in the ArmarX CLI for this. To reset the Ice middleware and remove all it's configuration (you will only lose configurations if you use deployment) use the command:
This will stop Ice, remove the configurations directories and start it again with a fresh configuration.
If this does not help, there is another command to kill Ice the hard way:
This will kill all Ice middleware executables that ArmarX uses on your PC. Afterwards you should also use the reset command:
Currently ArmarX only works with the Ice encoding version 1.0. If you use Ice 3.5+ you will encounter the following error on start-up.
no suitable endpoint available for proxy `IceStorm/TopicManager -t -e 1.1'
To fix this, uncomment the following line in the ~/.armarx/default.cfg
#Ice.Default.EncodingVersion=1.0
This tells the Ice Runtime to use the old encoding version 1.0 instead of the new default (1.1).
While the exception NoObjectFactoryException is usually caused by missing objectfactories, this exception can also be caused by the wrong encoding.
If your ice nodes failed to start you will see an error like this
icegridnode: failure occurred in daemon
To inspect the startup procedure, you can check the log file
~/.armarx/icegridnode_data/NodeMain/log/stderr.log
An errror similar to the following line, indicates that another user is running ice deamons on the same port (or you may have already started ice):
NodeMain: error: an IceGrid registry is already running and listening on the client endpoints `tcp -p 4061'
You can change the port in the main armarx config file, which is located at
${HOME}/.armarx/default.cfg
More details can be found here: Multi-User Setup.
If you get an exception about mismatched types during the unmarshalling of any armarx::Variant subclass you probably forgot to initialize the required ObjectFactories. ObjectFactories are required by Ice in order to know how serialized objects can be deserialized after they have been transfered over the network.
For using LinkedPose instances you need to do the following:
#include <ArmarXCore/robotstate/RobotStateObjectFactories.h>
For any other armarx::Variant subclasses you need to locate the relevant factory and add this instead.
This error message can also occur when the Ice protocol version 1.1 is used (the default in Ice 3.5, but not in 3.4) in combination with statecharts. The problem then arises when a process not linked against the necessary library tries to deserialize a variant which is used, e.g. as a default value for a statechart parameter.
As a temporary fix, you can resort to Ice protocol version 1.0 which handles unknown types during deserialization more gracefully. To do this, add
Ice.Default.EncodingVersion=1.0
to your global ArmarX Ice config (default path: ~/.armarx/default.cfg).
YES.
For the long answer have a look at http://www.zeroc.com/forums/help-center/2435-multiple-incoming-connections-same-proxy.html
If you get segmentation faults in places were it is almost impossible (e.g. on accessing an object which has just been created) it might be a problem with the incremental building of cmake.
In this case it is usually best to recompile all ArmarX Packages starting with ArmarXCore. To do this delete the contents of the build directory and run cmake and make from scratch.
Whenever you are trying to use a new class you also need to link it to your library. Otherwise you will get 'undefined reference' errors. If you forget to link the library to a class you might get an error like this:
source/MemoryX/components/ProfilerStorage/CMakeFiles/ProfilerStorage.dir/ProfilerStorage.cpp.o: In function `memoryx::ObjectInstance::ObjectInstance()': /home/waechter/armarx/MemoryX/build/../source/MemoryX/libraries/memorytypes/entity/ObjectInstance.h:214: undefined reference to `VTT for memoryx::ObjectInstance'
Since ArmarX consists of many many libraries, we offer a convenient way to find where symbols in ArmarX are defined:
armarx-dev findSymbol -p VisionX -s "memoryx::ObjectInstance::ObjectInstance("
This will search in the VisionX project and all its ArmarX dependencies for the definition of constructors of the ObjectInstance class. The output will look like this:
Ice Config: /home/waechter/.armarx/default.cfg Profile: default Searching for memoryx::ObjectInstance::ObjectInstance( Searching in the following projects: ['ArmarXCore', 'ArmarXGui', 'RobotAPI', 'MemoryX', 'VisionX'] Found 4 matching symbol(s) in package MemoryX in file /home/waechter/armarx/MemoryX/build/lib/libMemoryXMemoryTypes.so.0.6.0 #1: memoryx::ObjectInstance::ObjectInstance(memoryx::ObjectInstance const&) #2: memoryx::ObjectInstance::ObjectInstance(std::string const&, std::string const&) #3: memoryx::ObjectInstance::ObjectInstance(memoryx::ObjectInstance const&) #4: memoryx::ObjectInstance::ObjectInstance(std::string const&, std::string const&)
This means you need to link the library MemoryXMemoryTypes, if you want to use the class ObjectInstance in your library.
If you get cmake or compiler warnings about missing files or dependencies it is usually a good idea to check against which ArmarX Packages you are compiling. This information can either be extracted from the CMake cache or by inspecting the output of a cmake run. The relevant lines will look like this:
-- Using ArmarXCore Source SDK from: /home/user/armarx/ArmarXCore/build -- Using ArmarXGui Source SDK from: /home/user/armarx/Gui/build -- Using MemoryX Source SDK from: /home/user/armarx/MemoryX/build -- Running on Mac OS X
If you use multiple checkouts of the same Package or multiple build directories for different configurations it can happen that CMake gets mixed up and uses the wrong directory. To fix this problem you can specify the dependent ArmarX Package directly upon cmake invocation with the following parameter:
cmake -D<ArmarXPackageName>_DIR=/path/to/package/build ..
This can be done for each ArmarXPackage.
If you have a subscriber to a topic but the subscriber is not called altough the provider calls the interface functions of the topic, check first if you use the correct name for the topic. You can use the SystemStateMonitor GUI to check the name of offered and used topics or you can search in the log for "topic" to find the log entries of offering und using a topic.
Additionally, if a subscriber throws an exception at least once the subscription will be canceled by Ice. Since this is Ice Internal it will not be shown in the ArmarX-Log. With the current Ice version (<=3.5) it is not possible to change this behaviour. You can inspect the log of IceStorm with the icegrid-gui of ZeroC Ice.
This problem shows itself in the form of a compiler error that says that you class does not unambiguously overwrite some functions like ice_is_a(...). This happens when you indirectly inherit from more than one Ice interface. To solve this, you have to find all Ice interfaces that are implemented by the classes that you inherit from (or that you inherit from yourself). Create an Ice interface that inherits from all those interfaces and inherit from that one.
ArmarXCore defines the compiler flag BOOST_ENABLE_ASSERT_HANDLER to prevent occurring Boost assertions from aborting running applications.
The linker error "undefined reference to boost::assertion_failed(char const*, char const*, char const*, long)" typically occurs if your library or executable does not link against ArmarXCore. In that case you can undefine the responsible compiler flag by adding
set(CXX_FLAGS -UBOOST_ENABLE_ASSERT_HANDLER)
in your CMakeLists.txt before defining the respective CMake target. Setting this CMake variable assumes that the variable CXX_FLAGS is passed on to the CMake target as additional compiler flags.
This is a problem with the Qt Creator version supplied with Ubuntu 14.04. Goto http://www.qt.io/download-open-source/ and download Qt 5.5.0 for Linux 64-bit. This will include Qt Creator 3.4.2, which will work better.
This is a problem with the Qt Creator. Go to Settings -> Text Editor -> Behaviour Uncheck "Mouse Navigation". This mens you can no longer use Ctrl+Click to navigate to a function, but Qt Creator will no longer hang 10 seconds randomly when pressing the Ctrl key. You can still navigate to a function/class by placing the cursor on the call / class name and press F2.
Often, offscreen rendering does not work. In Ubuntu 18.04 in /usr/share/X11/xorg.conf.d:
Add a new file 90-indirect.conf with the contents:
Section "ServerFlags" Option "IndirectGLX" "on" EndSection
Follow this instructions: http://askubuntu.com/questions/243639/ctrlspace-has-been-bound-to-invoke-some-input-method-and-does-not-work-in-ema
1.8.17