Open rueckert opened 9 years ago
@traversaro any word on this? I can see he installed yarp (and possibly also icub) through the superbuild which doesn't make me want to relocate the issue just yet as an icub-main one.
@traversaro correct me if I am wrong but compile tests install both YARP and iCub using the proper distribution (see procedure here: http://wiki.icub.org/wiki/Linux:Installation_from_binaries). Moreover, iKinCartesianSolver is not compiled by default and requires a suitable cmake flag (ENABLE_icubmod_cartesiancontrollerserver). @rueckert are you compiling on your local laptop or in the iCub-pc104? In any case I would recommend the installation of YARP and iCub from sources http://wiki.icub.org/wiki/Linux:Installation_from_sources.
As mentioned before, the installation instructions (https://github.com/robotology/codyco-superbuild#system-dependencies-2) recommend to get YARP&iCub using the standard documentation exactly for this kind of reasons.
However I just added the flags necessary to compile the cartesian controller in the BuildICUB.cmake
file ( see commit https://github.com/robotology/codyco-superbuild/commit/04fab61d18328286d4b4a028e8c694fede5b828f ) so in the future even if the user install icub-main
from the superbuild it will automatically compile the cartesian controller.
That being said @rueckert, you can opt for one of the following two options:
$CODYCO_SUPERBUILD_DIR
directory (the build directory only) and make sure you install iCub
and YARP
first as pointed out in the previous comments. Then, please make sure all the steps on the installation of the software, namely, codyco-superbuild
have been thoroughly followed and build again the superbuild. codyco-superbuild
(git pull
from $CODYCO_SUPERBUILD_ROOT
), configuring again, (cmake ../
from $CODYCO_SUPERBUILD_DIR
) and compiling again (make
from $CODYCO_SUPERBUILD_DIR
). Hi,
thank you for your suggestions. We now did a reinstallation as suggested and compiled icub-main and yarp from source, and thereafter installed codyco-superbuild. Everything went fine, despite that the cmake paths (ICUB_DIR & YARP_DIR) are not correctly propagated to the subprojects (see Issue https://github.com/robotology/codyco-superbuild/issues/24 in the codyco-superbuild build). Our workaround was to set these env. variables first.
Regarding the skin sensor readings, we chatted with @randaz81 this morning (Here a big Thank to @randaz81 for that quick step-in). We hope that marco can help us here. We are currently not using the latest (icub-main, yarp & icub-firmware-shared) commits but rather versions from the 2nd of February. The reason for that is that an upgrade to the latest commits would require flashing the motor-borads. That's something marco should propose if necessary.
Best, Elmar
HI @rueckert regarding the environment variables do you still have the file bashrc_icub?
An old version was like written here (http://www.ausy.tu-darmstadt.de/Research/IcubInstallationSoftware)
echo "Exporting iCub environment variables from specific file.." export ICUB_INSTALL_PREFIX=/home/icub/software export YARP_ROOT=$ICUB_INSTALL_PREFIX/src/yarp export YARP_DIR=$YARP_ROOT/build export YARP_CONF=/home/icub/.yarp export YARP_ROBOT_NAME=iCubDarmstadt01 export ICUB_ROOT=$ICUB_INSTALL_PREFIX/src/icub-main export ICUB_DIR=$ICUB_ROOT/build export YARP_DATA_DIRS=$ICUB_INSTALL_PREFIX/share/yarp:$ICUB_INSTALL_PREFIX/share/iCub:$ICUB_INSTALL_PREFIX/share/ICUBcontrib export IPOPT_DWN_DIR=$ICUB_INSTALL_PREFIX/src/Ipopt export IPOPT_DIR=$ICUB_INSTALL_PREFIX/src/Ipopt/build export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/home/icub/software/lib/pkgconfig/ export PATH=$PATH:$ICUB_INSTALL_PREFIX/bin:$ICUB_INSTALL_PREFIX/scripts export LD_LIBRARY_PATH=$ICUB_INSTALL_PREFIX/lib:$IPOPT_DIR/lib export GAZEBO_PLUGIN_PATH=$GAZEBO_PLUGIN_PATH:$ICUB_INSTALL_PREFIX/lib export GAZEBO_MODEL_PATH=$GAZEBO_MODEL_PATH:$ICUB_INSTALL_PREFIX/src/icub_gazebo echo "Welcome $YARP_ROBOT_NAME!"
Hi,
with help from marco, we found out that whenever we update icub-main our hardware/skin ... .xml files get replaced by wrong versions for the iCubGenova .
Roberto managed to fix the skinSpecs file for the left arm "partially". Now the left_arm and the left_forarm are working. Not the hand, nor the complete right arm and the legs.
Is there a copy of the correct files for our robot? We should commit the correct files such that this will not happen after every git pull.
Actually, if I take a look at the files on the git, they seem to be ok (https://github.com/robotology/icub-main/commit/b66bbb76f3a4da1c999932049e2f36262338167e). Maybe I am missing some important details here.
@serena-ivaldi Thank you for the bash_rc content but our env. variables are ok. We can run all applications despite the skinGui.
I have some copies of files... myabe I can find the xml files! Can you give me the path and where they are located? @rueckert
Hi guys,
taking a look on the CMakeLists under
./app/robots/iCubDarmstadt01/CMakeLists.txt
it says that it copies the conf file with the macro
yarp_install()
which I believe it is only invoked with
make install
Since at the documentation of "Compilation_on_the_pc104" explicitly says that we should not do make install (or then we should change some of the env vars) the files are not copied. Would that be a problem or the resource finder can still find the correct ones?
-Alex
Hi Alex,
yarp_install
macro is also copying file in the build directory, see https://github.com/robotology/yarp/blob/master/conf/YarpInstallationHelpers.cmake#L268 .YARP_DATA_DIRS
is correctly configured. More information on the ResourceFinder can be found at http://wiki.icub.org/yarpdoc/yarp_resource_finder_tutorials.html . icub-main has been updated with new configuration files for iCubDarmstadt01. Since a new yarp version has been released in the meanwhile, you need to: -yarp git pull + make on pc104 and console(s) -icub-firmware-shared git pull + make on pc104 only -icub-main git pull + make on pc104 and console(s) -firmware update of all board (EMS, skin, 2FOC)
Hi,
@randaz81 thank you for the git update. Would you have time today to do the firmware update with us once more together. We will update all our computers such that only the firmware update of all boards has to be done.
Thank you very much, Elmar
Description: Dear Jorhabib,
Thank you for your swift replay. Sorry for opening a second issue on the same topic (the previous one was Issue #75). I had to learn about that script first.
After a clean build (to solve an issue related to the zero torque mode in the demoForceControl, discussed in Issue #68) I have two open problems:
First, the raw data stream from the skin ports transmit constants i.e., sequences of the number 240.0. Second, the executeable iKinCartesianSolver is neither in the path nor in our installation folder (/home/icub/software/codyco-superbuild). Maybe, the problem is that the _ICUBROOT: variable is not set. These might be stupid questions, however, initially Serena was our expert and did all the icub installations for us.
Both, problems may better fit to the icub-main list. Is there also such a script to open an issue?
Best, Elmar
Further Information:
Linux tomlinson 3.14.3-rt4tk #3 SMP PREEMPT RT Wed Jul 23 17:40:17 CEST 2014 x86_64 x86_64 x86_64 GNU/Linux
master
8c08d70cee361883ed663b226d3f6c546e0324f2
:/home/icub/software/codyco-superbuild/build/install/share/codyco
iCubDarmstadt01
/home/icub/software/codyco-superbuild/build/install/bin/yarpserver
:/home/icub/software/codyco-superbuild/build/install/lib:/home/icub/software/codyco-superbuild/build/install/lib/