robotology / icub-main

The iCub Main Software Repository

iCub

Maintainers

This repository is maintained by:

	@pattacini

See COPYING and AUTHORS for licensing info, authors and copyright holders.

The iCub manual contains more details about the structure of the repository and how the code is organized, being the most up-to-date source of information.

Direct link to installation instructions: https://icub-tech-iit.github.io/documentation/sw_installation.

Contributing

We accept contributions via forks and pull-requests.

Working on your first Pull Request? You can learn how from this free series How to Contribute to an Open Source Project on GitHub

icub-main's Issues

master branch does not compile

CMake Error: File /usr/local/share/yarp/cmake/template/YarpPluginPath.cmake does not exist.
CMake Error at src/libraries/icubmod/CMakeLists.txt:107 (configure_file):
  configure_file Problem configuring file


CMake Error: File /usr/local/share/yarp/cmake/template/YarpPluginPath.cmake does not exist.
CMake Error at src/libraries/icubmod/CMakeLists.txt:109 (configure_file):
  configure_file Problem configuring file

See also the Travis build of icub-main : https://travis-ci.org/robotology/icub-main/builds/47503668 .

cc @barbalberto

object creation slows down iCub_SIM

Hi all,
I am performing an experiment on the simulator in which an object on the table is moved by the iCub. Originally, for every new trial I just deleted the moved object and created a new object on the original position. When running this experiment for long periods of time, after around 30 -40 trials, that is 30-40 new objects, the simulator slowed down considerably, going from a recommended time step of 8-9ms at the beginning of the experiment up to 35-40 ms after those trials. Modifying the code so that the object was moved instead of created anew solved the problem, but the issue still remains that, even if they are deleted, the creation of objects slows the simulator down.
Any idea of why this can be, and/or how to solve it?
Best

Problem with movement of the real iCub's head

Hi,

we've got a problem with the real iCub's head when accessing the joints.
In our project we are working with the Oculus Rift and want to use the headtracking information to mirror it to the iCub but he is only partially doing what we want him to.
In the first few seconds it seems that he is moving like the Oculus but then the movement slows down or even stops completly.
By further random turning of the Oculus the iCub sometimes can shortly follow it but then it always slows down again.
We have plotted the calculated angles that we send to the robot (which we have limited too only those that are accessable by the real one) and everything seems to be fine and the simulation within gazebo is running smoothly.
First we thought that the update rate may be too high with which we update the joints because the yarp ports crashed but reducing them from 1kHz to even 25Hz did solve the yarpserver-crash but the problem from above still occured.

We're sending the data via IPositionControl and have not idea why this is happening.
Do we have to access the robot differently?

Wrong torque estimation with iDyn in case of contacts

When comparing the torques computed by the iDyn inverse model to the one measured using the Joint Torque Sensors (from the iCubParis2) there are large discrepancies for the joint 3 in case of contacts.

In the figure you can see one example. Even if the JTS and the IDYN are not scaled equally (gain), it is clearly visible that in some parts of the curve the JTS goes up while the IDYN goes down. These regions corresponds to contacts wit external objects.

My assumption is that the contribution of the external forces have the wrong sign when summed to the RBD. Do you have other possible explanations?

Unexpected change of control mode of a idling joint

It's been a while by now that we've been spotting the following strange behavior during the red-ball demo on Blacky (it happens very rarely but it does happen):

If a joint is put intentionally in idle because it's mechanically broken, then the subsequent commands of the red-ball demo will change its state back to position-control. This is visible by means of the robotMotorGui.

cc's: @randaz81 @alecive @maggia80 @vtikha

cmake error YarpPlugin.cmake

Hi all,

on the current version of both yarp and icub I got the following error:

CMake Error at /usr/local/share/yarp/cmake/YarpPlugin.cmake:388 (message):
Empty list (owner), this is likely due to a previous error, check the
output of CMake above.
Call Stack (most recent call first):
/usr/local/share/yarp/cmake/YarpPlugin.cmake:500 (yarp_end_plugin_library)
src/libraries/icubmod/CMakeLists.txt:64 (END_PLUGIN_LIBRARY)

CMake Error at /usr/local/share/yarp/cmake/YarpPlugin.cmake:391 (list):
list sub-command REMOVE_AT requires list to be present.
Call Stack (most recent call first):
/usr/local/share/yarp/cmake/YarpPlugin.cmake:500 (yarp_end_plugin_library)
src/libraries/icubmod/CMakeLists.txt:64 (END_PLUGIN_LIBRARY)

Doxygen documentation broken

Apparently there was a change in doxygen documentation URL that breaks a lot of links, for example "iCub Software Release" in http://wiki.icub.org/wiki/Main_Page .

Unfortunately this breaks also all the google results related to icub-main software, the best solution would be to put in place a 301 redirect, but I don't know how much this is feasible.

[1] : https://support.google.com/webmasters/answer/93633?hl=en

cc @lornat75 @mbrunettini

Add diagnostic capabilities to icub skin

The skin should be capable to relay status codes and error messages. @maggia80 and I are working on this.

iCub_SIM does not have the new motor interfaces

New motor interfaces are not available on the iCub Simulator. I'm referring to iVelocityControl2, but I assume the others are missing as well.

libiCubInterfaceGuiLib.so is not installed when running make install

• Installing the icub build does not seem to install libiCubInterfaceGuiLib.so.
  Furthermore I could not find install code for this here:
  src/libraries/iCubInterfaceGuiLib/CMakeLists.txt
• Note: ICUB_SHARED_LIBRARY is enabled.
• git revision used for testing:
  c8d48c4

yDebug yError etc

Hi all,

Just a quick question: how does the DebugStream library work? Also, should we start using it as part of a coding best practice for printing out erro/debug/info messages, rather than good old cout/printf etc?

Ciao,
Francesco

RobotMotorGui fixes and improvements

A reminder for some thing to be fixed/improved in the robotMotorGui.

1. Bug: If one part is not available, it crashes instead of closing down properly.

2. Sequence tabs
   2a)Bug: The gui opens ports for the sequence tab with improper name like:
   registration name /robotMotorGui/left_arm/sequence:o
   without the trailing number like the other ports, like in
   registration name /icub/robotMotorGui0/left_arm/command:o

when opening 2 motorguis, that will result in an address conflict and the second gui will not open the port. As a conseguence the sequence tab will silently not work. I propose to change those portNames adding at least the number and the robotname (like other ports).

2b) Optional improvement: The sequence tab are very rarely used; can those ports be opened only when actually needed by the user? This will save resources and will not pollute the port name list

3. Uniform way of calling port names: (User-friendlyness improvement)

The 'de facto' convention for opening ports is like:
/applicationName/[robotName]/partname/... which makes the related port easy to spot in the yarp name list output and to manually write from terminal.

here we have:
/icub/robotMotorGui0/left_arm/... // application name in the middle, mixes port from robotInterface and from motorGui
/robotMotorGui/left_arm/ // no number and no robot name, so different synatx from other ports from the same executable.

Can we make those names uniform using a syntax like the following?

/robotMotorGui/robotName/left_arm/command:o
/robotMotorGui/robotName/left_arm/rpc:o
/robotMotorGui/robotName/left_arm/state:i
/robotMotorGui/robotName/left_arm/sequence:o

Since we can use the robot and one or more simulator at the same time, the robotName is always useful, the sequence port shall follow.

iCub_SIM does not close gracefully

After the latest merge of InteractionMode branch into master branch, the simulator crashes with the following error upon closure:

yarp: semaphore wait failed (errno 6); gdb problem, or bad YARP+ACE flags

skinManager should report an error if it is not finding a patch port

iCub_SIM help required

Hello all

hello all

i have installed Yarp and iCub on my ubuntu 14.04 recently... both have installed properly but i am getting an error message when i type "iCub_SIM" on terminal

"iCub_SIM: symbol lookup error: iCub_SIM: undefined symbol: _ZN4yarp2os8Property5checkERKNS0_11ConstStringE"

plz guide me what is wrong with it...

controlBoardWrapper2 compilation error

I encountered this error while compiling the icub-main build on Ubuntu 12.04, g++ 4.6.3, yarp 2.3.63. See also robotology/yarp#203

[ 32%] Building CXX object src/libraries/icubmod/controlBoardWrapper2/CMakeFiles/controlboardwrapper2.dir/__/__/__/__/generated_code/yarpdev_add_controlboardwrapper2.cpp.o
In file included from /home/gsaponaro/NOBACKUP/icub-main/build/generated_code/yarpdev_add_controlboardwrapper2.cpp:21:0:
/home/gsaponaro/NOBACKUP/icub-main/src/libraries/icubmod/controlBoardWrapper2/ControlBoardWrapper2.h: In member function ‘virtual bool ControlBoardWrapper2::setOutput(int, double)’:
/home/gsaponaro/NOBACKUP/icub-main/src/libraries/icubmod/controlBoardWrapper2/ControlBoardWrapper2.h:3659:34: error: ‘class yarp::dev::IOpenLoopControl’ has no member named ‘setOutput’
/home/gsaponaro/NOBACKUP/icub-main/src/libraries/icubmod/controlBoardWrapper2/ControlBoardWrapper2.h: In member function ‘virtual bool ControlBoardWrapper2::setOutputs(const double*)’:
/home/gsaponaro/NOBACKUP/icub-main/src/libraries/icubmod/controlBoardWrapper2/ControlBoardWrapper2.h:3678:40: error: ‘class yarp::dev::IOpenLoopControl’ has no member named ‘setOutput’
/home/gsaponaro/NOBACKUP/icub-main/build/generated_code/yarpdev_add_controlboardwrapper2.cpp: In function ‘void* controlboardwrapper2_create()’:
/home/gsaponaro/NOBACKUP/icub-main/build/generated_code/yarpdev_add_controlboardwrapper2.cpp:40:1: error: cannot allocate an object of abstract type ‘ControlBoardWrapper2’
/home/gsaponaro/NOBACKUP/icub-main/src/libraries/icubmod/controlBoardWrapper2/ControlBoardWrapper2.h:256:7: note:   because the following virtual functions are pure within ‘ControlBoardWrapper2’:
/home/gsaponaro/NOBACKUP/yarp/src/libYARP_dev/include/yarp/dev/IPositionDirect.h:50:18: note:   virtual bool yarp::dev::IPositionDirect::setPositionDirectMode()
/home/gsaponaro/NOBACKUP/yarp/src/libYARP_dev/include/yarp/dev/IOpenLoopControl.h:89:18: note:  virtual bool yarp::dev::IOpenLoopControl::setRefOutput(int, double)
/home/gsaponaro/NOBACKUP/yarp/src/libYARP_dev/include/yarp/dev/IOpenLoopControl.h:94:18: note:  virtual bool yarp::dev::IOpenLoopControl::setRefOutputs(const double*)
/home/gsaponaro/NOBACKUP/yarp/src/libYARP_dev/include/yarp/dev/IOpenLoopControl.h:102:18: note:     virtual bool yarp::dev::IOpenLoopControl::getRefOutput(int, double*)
/home/gsaponaro/NOBACKUP/yarp/src/libYARP_dev/include/yarp/dev/IOpenLoopControl.h:109:18: note:     virtual bool yarp::dev::IOpenLoopControl::getRefOutputs(double*)
In file included from /home/gsaponaro/NOBACKUP/icub-main/build/generated_code/yarpdev_add_controlboardwrapper2.cpp:10:0:
/home/gsaponaro/NOBACKUP/yarp/src/libYARP_dev/include/yarp/dev/Drivers.h: In member function ‘yarp::dev::DeviceDriver* yarp::dev::DriverCreatorOf<T>::create() [with T = ControlBoardWrapper2]’:
/home/gsaponaro/NOBACKUP/icub-main/build/generated_code/yarpdev_add_controlboardwrapper2.cpp:40:1:   instantiated from here
/home/gsaponaro/NOBACKUP/yarp/src/libYARP_dev/include/yarp/dev/Drivers.h:127:20: error: cannot allocate an object of abstract type ‘ControlBoardWrapper2’
/home/gsaponaro/NOBACKUP/icub-main/src/libraries/icubmod/controlBoardWrapper2/ControlBoardWrapper2.h:256:7: note:   since type ‘ControlBoardWrapper2’ has pure virtual functions
make[2]: *** [src/libraries/icubmod/controlBoardWrapper2/CMakeFiles/controlboardwrapper2.dir/__/__/__/__/generated_code/yarpdev_add_controlboardwrapper2.cpp.o] Error 1
make[1]: *** [src/libraries/icubmod/controlBoardWrapper2/CMakeFiles/controlboardwrapper2.dir/all] Error 2
make: *** [all] Error 2

skinGui should not show temperature pads by default

It has been reported that by default the skinGui shows temperature pads. This is sometimes misleading for users bc it is difficult to tell the difference between temperature pads and actual pads. On the other hand temperature pads should be displayed only for debug and their output is used internally for compensation.

Default for the gui should be to not display temperature pads.It should be an easy fix.

@ale-git, can you implement this? @alecive given that you will be checking the development of the new skingui based on qt I recommen you follow closely this development.

iCubGUI won't start

Hi, I'm trying to launch iCubGui but it gives the following error and simply doesn't start:

<..>
||| found /home/icub/software/share/iCub/contexts/iCubGui/icons/play.png
Object::connect: No such signal Q3Action::triggered()
Object::connect: (sender name: 'playAction')
Object::connect: (receiver name: 'MainWindow')
iCubGui: symbol lookup error: iCubGui: undefined symbol: _ZN4yarp2os6Bottle4findERKNS0_11ConstStringE

any idea?

iCubGui: enhancing forces visualization

In the iCubGui, the visualization of forces at the feet should be improved. In particular, at present forces are not visible since they are visualized under the floor. Moreover, when standing forces at the feet (~120N) are much bigger than those at the arms (typically in the order of 10N). Visualization results in a very long arrow very difficult to visualize. It would be good to implement a better visualization, e.g. arrows that scale not only in length but also in thickness or color.

iCubTest/velocityControllerTest should be part of tests instead of stand-alone

pc104 canmotioncontrol compilation error, possibly related to icub-firmware-shared

On iCubLisboa01's pc104 we are running "Debian GNU/Linux 6.0.7 (squeeze) + iCub-oc 3.2" and CMake 2.8.7.

Today we tried to update yarp, icub-main and the recently required icub-firmware-shared, following the pc104 manual page at http://wiki.icub.org/wiki/Compilation_on_the_pc104

After fixing trying to fix a CMake problem described in robotology/icub-firmware-shared#1 , we get stuck at the following point:

[ 38%] Building CXX object src/libraries/icubmod/cartesianController/CMakeFiles/cartesiancontrollerserver.dir/__/__/__/__/generated_code/yarpdev_add_canmotioncontrol.cpp.o
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp:21:33: error: CanBusMotionControl.h: No such file or directory
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp: In function ‘void add_owned_canmotioncontrol(const char*)’:
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp:30: error: ‘CanBusMotionControl’ was not declared in this scope
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp:30: error: template argument 1 is invalid
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp:32: error: new initializer expression list treated as compound expression
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp:32: error: invalid conversion from ‘const char*’ to ‘int’
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp:32: error: cannot convert ‘int*’ to ‘yarp::dev::DriverCreator*’ in initialization
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp: In function ‘void* canmotioncontrol_create()’:
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp:40: error: expected type-specifier before ‘CanBusMotionControl’
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp:40: error: expected ‘;’ before ‘CanBusMotionControl’
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp:40: error: ‘CanBusMotionControl’ was not declared in this scope
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp: In function ‘void canmotioncontrol_destroy(void*)’:
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp:40: error: ‘CanBusMotionControl’ was not declared in this scope
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp:40: error: expected primary-expression before ‘)’ token
/usr/local/src/robot/icub-main/build/generated_code/yarpdev_add_canmotioncontrol.cpp:40: error: expected ‘;’ before ‘obj’
make[2]: *** [src/libraries/icubmod/cartesianController/CMakeFiles/cartesiancontrollerserver.dir/__/__/__/__/generated_code/yarpdev_add_canmotioncontrol.cpp.o] Error 1
make[1]: *** [src/libraries/icubmod/cartesianController/CMakeFiles/cartesiancontrollerserver.dir/all] Error 2
make: *** [all] Error 2

ALLOW_IDL_GENERATION compilation issue?

I do not have a complete understanding of this, but I just noticed that if I start from scratch, icub-main fails to compile if ALLOW_IDL_GENERATION is off (default value). After the first compilation, I can put it off again.
However:

• ALLOW_IDL_GENERATION is hidden in the icub-main advanced cmake menu
• The default value is off, and the documentation does not explain what to do.
• CREATE_IDLS on yarp cmake manke is also off by default.
  Maybe we can do something to make this more clear?

Error opening yarpdev in 'Face' app

When running the Face application on iCubGenova03 I get the following error in particular with the yarpdev module that it runs:

yarpdev --name /icub/face/raw --device serial --subdevice serialport --context faceExpressions --from serialport.ini --verbose
||| configuring
||| no policy found
||| added context faceExpressions
||| default config file specified as serialport.ini
||| checking [/home/icub/serialport.ini] (pwd)
||| checking [/home/icub/.config/yarp/robots/iCubGenova03] (robot YARP_CONFIG_HOME)
||| checking [/home/icub/.local/share/yarp/robots/iCubGenova03] (robot YARP_DATA_HOME)
||| found /home/icub/.local/share/yarp/robots/iCubGenova03
||| checking [/etc/yarp/robots/iCubGenova03] (robot YARP_CONFIG_DIRS)
||| checking [/usr/local/src/robot/yarp/build-pc104/share/yarp/robots/iCubGenova03] (robot YARP_DATA_DIRS)
||| checking [/usr/local/src/robot/icub-main/build-pc104/share/iCub/robots/iCubGenova03] (robot YARP_DATA_DIRS)
||| found /usr/local/src/robot/icub-main/build-pc104/share/iCub/robots/iCubGenova03
||| checking [/usr/local/src/robot/yarp/build-pc104/share/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| checking [/usr/local/src/robot/icub-main/build-pc104/share/iCub/config/path.d] (robot path.d YARP_DATA_DIRS)
||| checking [/home/icub/.local/share/yarp/robots/iCubGenova03/serialport.ini] (robot)
||| checking [/usr/local/src/robot/icub-main/build-pc104/share/iCub/robots/iCubGenova03/serialport.ini] (robot)
||| checking [/home/icub/.config/yarp/contexts/faceExpressions] (context YARP_CONFIG_HOME)
||| checking [/home/icub/.local/share/yarp/contexts/faceExpressions] (context YARP_DATA_HOME)
||| checking [/etc/yarp/contexts/faceExpressions] (context YARP_CONFIG_DIRS)
||| checking [/usr/local/src/robot/yarp/build-pc104/share/yarp/contexts/faceExpressions] (context YARP_DATA_DIRS)
||| checking [/usr/local/src/robot/icub-main/build-pc104/share/iCub/contexts/faceExpressions] (context YARP_DATA_DIRS)
||| found /usr/local/src/robot/icub-main/build-pc104/share/iCub/contexts/faceExpressions
||| checking [/usr/local/src/robot/icub-main/build-pc104/share/iCub/contexts/faceExpressions/serialport.ini] (context)
||| found /usr/local/src/robot/icub-main/build-pc104/share/iCub/contexts/faceExpressions/serialport.ini
Subdevice serialport
Starting Serial Port in /dev/ttyACM0 
Invalid communications port in /dev/ttyACM0 
yarpdev: ***ERROR*** driver <serialport> was found but could not open
cannot make <serialport>
yarpdev: ***ERROR*** driver <serial> was found but could not open
===============================================================
== Options checked by device:
== 
device=serial
==
===============================================================
yarpdev: ***ERROR*** device not available.
Suggestions:
+ Do "yarpdev --list" to see list of supported devices.

Doing yarpdev --list as suggested gives me the following:

yarpdev --list
Here are devices listed for your system:
Device "test_grabber", C++ class TestFrameGrabber, wrapped by "grabber"
Device "test_motor", C++ class TestMotor, wrapped by "controlboard"
Device "remote_grabber", C++ class RemoteFrameGrabber, wrapped by "grabber"
Device "grabber", C++ class ServerFrameGrabber, is a network wrapper.
Device "inertial", C++ class ServerInertial, is a network wrapper.
Device "sound_grabber", C++ class ServerSoundGrabber, is a network wrapper.
Device "pipe", C++ class DevicePipe, has no network wrapper
Device "group", C++ class DeviceGroup, has no network wrapper
Device "remote_controlboard", C++ class RemoteControlBoard, wrapped by "controlboard"
Device "controlboard", C++ class ServerControlBoard, is a network wrapper.
Device "analogsensorclient", C++ class AnalogSensorClient, has no network wrapper
Device "analogServer", C++ class AnalogWrapper, is a network wrapper.
Device "controlboardwrapper2", C++ class ControlBoardWrapper2, is a network wrapper.
Device "virtualAnalogServer", C++ class VirtualAnalogWrapper, is a network wrapper.
Device "portaudio", available on request (found in /usr/local/src/robot/yarp/build-pc104/lib/libyarp_portaudio.so library), wrapped by "grabber".
Device "serial", available on request (found in /usr/local/src/robot/yarp/build-pc104/lib/libyarp_serial.so library)is a network wrapper..
Device "serialport", available on request (found in /usr/local/src/robot/yarp/build-pc104/lib/libyarp_serial.so library), wrapped by "serial".

Current YARP branch in pc104: analogWrapperPortName
Current ICUB branch in pc104: master

Any idea?

iCub_SIM problems

Today I’ve just come across big problems with iCub_SIM reported in the following:

1. It does crash upon closure saying: “yarp: semaphore wait failed (errno 6); gdb problem; or bad YARP+ACE flags”.
2. It does continuously print out lots of “getOutputRaw not yet implemented for iCubSimulationControl” causing a significant slow-down.
3. It does open up motor ports with the double leading slash (e.g. //icubSim/left_arm/state:o).

Removing the definition file for skin error codes from src/libraries/icubmod/motionControlLib.

This is raised in #80.

Possible solution is to move skin error codes from motionControlLib to firmwareShared.

@barbalberto, @randaz81, @JoErNanO

dataSetPlayer unpredictably crashes with segmentation fault

The segmentation fault occurs after selecting the dataset folder to load into the dataSetPlayer. The fault is unpredictable as sometimes the same actions result in successful loading of the dataset. The dataset was loading consistently with a iCub-main build from around November last year and the error has only been occurring since updating from the repository on the 15/1/2015. I have attempted loading the dataset from different folder levels above the .log file without finding a solution that works consistently.

The dataset I am using is here

I have the following output upon trying to load the data at 3 different folder levels, the fifth attempt is successful:

aglover@iiticublap031:~$ dataSetPlayer 
||| clearing context
||| adding context [dataSetPlayer]
||| configuring
||| no policy found
||| default config file specified as config.ini
||| checking [/home/aglover/config.ini] (pwd)
||| checking [/home/aglover/.config/yarp/robots/default] (robot YARP_CONFIG_HOME)
||| checking [/home/aglover/.local/share/yarp/robots/default] (robot YARP_DATA_HOME)
||| checking [/etc/xdg/xdg-ubuntu/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/usr/share/upstart/xdg/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/etc/xdg/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/usr/share/ubuntu/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/ubuntu/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| found /usr/local/share/yarp/config/path.d
||| checking [/usr/local/share/ICUBcontrib/robots/default] (robot yarp.d)
||| checking [/usr/local/share/iCub/robots/default] (robot yarp.d)
||| checking [/home/aglover/.config/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_HOME)
||| checking [/home/aglover/.local/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_HOME)
||| checking [/etc/xdg/xdg-ubuntu/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/usr/share/upstart/xdg/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/etc/xdg/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/usr/share/ubuntu/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/local/share/ICUBcontrib/contexts/dataSetPlayer] (context yarp.d)
||| checking [/usr/local/share/iCub/contexts/dataSetPlayer] (context yarp.d)
||| found /usr/local/share/iCub/contexts/dataSetPlayer
||| checking [/usr/local/share/iCub/contexts/dataSetPlayer/config.ini] (context)
||| found /usr/local/share/iCub/contexts/dataSetPlayer/config.ini
yarp: Port /dataSetPlayer/rpc:i active at tcp://127.0.0.1:10002
window should be now visible
Segmentation fault (core dumped)
aglover@iiticublap031:~$ dataSetPlayer 
||| clearing context
||| adding context [dataSetPlayer]
||| configuring
||| no policy found
||| default config file specified as config.ini
||| checking [/home/aglover/config.ini] (pwd)
||| checking [/home/aglover/.config/yarp/robots/default] (robot YARP_CONFIG_HOME)
||| checking [/home/aglover/.local/share/yarp/robots/default] (robot YARP_DATA_HOME)
||| checking [/etc/xdg/xdg-ubuntu/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/usr/share/upstart/xdg/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/etc/xdg/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/usr/share/ubuntu/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/ubuntu/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| found /usr/local/share/yarp/config/path.d
||| checking [/usr/local/share/ICUBcontrib/robots/default] (robot yarp.d)
||| checking [/usr/local/share/iCub/robots/default] (robot yarp.d)
||| checking [/home/aglover/.config/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_HOME)
||| checking [/home/aglover/.local/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_HOME)
||| checking [/etc/xdg/xdg-ubuntu/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/usr/share/upstart/xdg/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/etc/xdg/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/usr/share/ubuntu/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/local/share/ICUBcontrib/contexts/dataSetPlayer] (context yarp.d)
||| checking [/usr/local/share/iCub/contexts/dataSetPlayer] (context yarp.d)
||| found /usr/local/share/iCub/contexts/dataSetPlayer
||| checking [/usr/local/share/iCub/contexts/dataSetPlayer/config.ini] (context)
||| found /usr/local/share/iCub/contexts/dataSetPlayer/config.ini
yarp: Port /dataSetPlayer/rpc:i active at tcp://127.0.0.1:10002
window should be now visible
Segmentation fault (core dumped)
aglover@iiticublap031:~$ dataSetPlayer 
||| clearing context
||| adding context [dataSetPlayer]
||| configuring
||| no policy found
||| default config file specified as config.ini
||| checking [/home/aglover/config.ini] (pwd)
||| checking [/home/aglover/.config/yarp/robots/default] (robot YARP_CONFIG_HOME)
||| checking [/home/aglover/.local/share/yarp/robots/default] (robot YARP_DATA_HOME)
||| checking [/etc/xdg/xdg-ubuntu/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/usr/share/upstart/xdg/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/etc/xdg/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/usr/share/ubuntu/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/ubuntu/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| found /usr/local/share/yarp/config/path.d
||| checking [/usr/local/share/ICUBcontrib/robots/default] (robot yarp.d)
||| checking [/usr/local/share/iCub/robots/default] (robot yarp.d)
||| checking [/home/aglover/.config/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_HOME)
||| checking [/home/aglover/.local/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_HOME)
||| checking [/etc/xdg/xdg-ubuntu/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/usr/share/upstart/xdg/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/etc/xdg/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/usr/share/ubuntu/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/local/share/ICUBcontrib/contexts/dataSetPlayer] (context yarp.d)
||| checking [/usr/local/share/iCub/contexts/dataSetPlayer] (context yarp.d)
||| found /usr/local/share/iCub/contexts/dataSetPlayer
||| checking [/usr/local/share/iCub/contexts/dataSetPlayer/config.ini] (context)
||| found /usr/local/share/iCub/contexts/dataSetPlayer/config.ini
yarp: Port /dataSetPlayer/rpc:i active at tcp://127.0.0.1:10002
window should be now visible
Segmentation fault (core dumped)
aglover@iiticublap031:~$ dataSetPlayer 
||| clearing context
||| adding context [dataSetPlayer]
||| configuring
||| no policy found
||| default config file specified as config.ini
||| checking [/home/aglover/config.ini] (pwd)
||| checking [/home/aglover/.config/yarp/robots/default] (robot YARP_CONFIG_HOME)
||| checking [/home/aglover/.local/share/yarp/robots/default] (robot YARP_DATA_HOME)
||| checking [/etc/xdg/xdg-ubuntu/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/usr/share/upstart/xdg/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/etc/xdg/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/usr/share/ubuntu/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/ubuntu/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| found /usr/local/share/yarp/config/path.d
||| checking [/usr/local/share/ICUBcontrib/robots/default] (robot yarp.d)
||| checking [/usr/local/share/iCub/robots/default] (robot yarp.d)
||| checking [/home/aglover/.config/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_HOME)
||| checking [/home/aglover/.local/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_HOME)
||| checking [/etc/xdg/xdg-ubuntu/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/usr/share/upstart/xdg/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/etc/xdg/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/usr/share/ubuntu/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/local/share/ICUBcontrib/contexts/dataSetPlayer] (context yarp.d)
||| checking [/usr/local/share/iCub/contexts/dataSetPlayer] (context yarp.d)
||| found /usr/local/share/iCub/contexts/dataSetPlayer
||| checking [/usr/local/share/iCub/contexts/dataSetPlayer/config.ini] (context)
||| found /usr/local/share/iCub/contexts/dataSetPlayer/config.ini
yarp: Port /dataSetPlayer/rpc:i active at tcp://127.0.0.1:10002
window should be now visible
Segmentation fault (core dumped)
aglover@iiticublap031:~$ dataSetPlayer 
||| clearing context
||| adding context [dataSetPlayer]
||| configuring
||| no policy found
||| default config file specified as config.ini
||| checking [/home/aglover/config.ini] (pwd)
||| checking [/home/aglover/.config/yarp/robots/default] (robot YARP_CONFIG_HOME)
||| checking [/home/aglover/.local/share/yarp/robots/default] (robot YARP_DATA_HOME)
||| checking [/etc/xdg/xdg-ubuntu/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/usr/share/upstart/xdg/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/etc/xdg/yarp/robots/default] (robot YARP_CONFIG_DIRS)
||| checking [/usr/share/ubuntu/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/yarp/robots/default] (robot YARP_DATA_DIRS)
||| checking [/usr/share/ubuntu/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/config/path.d] (robot path.d YARP_DATA_DIRS)
||| found /usr/local/share/yarp/config/path.d
||| checking [/usr/local/share/ICUBcontrib/robots/default] (robot yarp.d)
||| checking [/usr/local/share/iCub/robots/default] (robot yarp.d)
||| checking [/home/aglover/.config/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_HOME)
||| checking [/home/aglover/.local/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_HOME)
||| checking [/etc/xdg/xdg-ubuntu/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/usr/share/upstart/xdg/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/etc/xdg/yarp/contexts/dataSetPlayer] (context YARP_CONFIG_DIRS)
||| checking [/usr/share/ubuntu/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/share/gnome/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/local/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/share/yarp/contexts/dataSetPlayer] (context YARP_DATA_DIRS)
||| checking [/usr/local/share/ICUBcontrib/contexts/dataSetPlayer] (context yarp.d)
||| checking [/usr/local/share/iCub/contexts/dataSetPlayer] (context yarp.d)
||| found /usr/local/share/iCub/contexts/dataSetPlayer
||| checking [/usr/local/share/iCub/contexts/dataSetPlayer/config.ini] (context)
||| found /usr/local/share/iCub/contexts/dataSetPlayer/config.ini
yarp: Port /dataSetPlayer/rpc:i active at tcp://127.0.0.1:10002
window should be now visible
the full path is /home/aglover/workspace/datasets/eBottle_objects_no14 
The size of the file is 3 
The size of the file is 3 
 /home/aglover/workspace/datasets/eBottle_objects_no14/pliershand_small/eBottles/info.log IS present adding it to the gui
the size of subDirs is: 1
opening file /home/aglover/workspace/datasets/eBottle_objects_no14/pliershand_small/eBottles/info.log
the name of the port is /cbottletoebottle/cte:o
opening file /home/aglover/workspace/datasets/eBottle_objects_no14/pliershand_small/eBottles/data.log
1417017145.917771
the biggest timestamp is: index 0 with value 1417017145.917771
need to create new port Bottle for pliershand_small_eBottles
creating and opening Bottle port for part pliershand_small_eBottles
yarp: Port /cbottletoebottle/cte:o active at tcp://127.0.0.1:10012

icub-main build error in OS X with ICUB_SHARED_LIBRARY flag enabled

When compiling icub-main in os x (Travis configuration: http://docs.travis-ci.com/user/osx-ci-environment/ ) with ICUB_SHARED_LIBRARY flag enabled I get this error:

Linking CXX executable ../../../bin/icubmoddev
[ 31%] Built target icubmoddev
Scanning dependencies of target debugStream
[ 32%] Building CXX object src/libraries/icubmod/debugStream/CMakeFiles/debugStream.dir/Debug.cpp.o
/Users/travis/build/robotology-playground/codyco-superbuild/external/ICUB/src/libraries/icubmod/debugStream/Debug.cpp:67:11: warning:
add explicit braces to avoid dangling else [-Wdangling-else]
} else {
^
1 warning generated.
Linking CXX shared library ../../../../lib/libdebugStream.dylib
Undefined symbols for architecture x86_64:
"yarp::os::exit(int)", referenced from:
DebugStream::Debug::print_output(DebugStream::MsgType, std::__1::basic_ostringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, char const*, unsigned int, char const*) in Debug.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[5]: *** [lib/libdebugStream.1.1.15.dylib] Error 1
make[4]: *** [src/libraries/icubmod/debugStream/CMakeFiles/debugStream.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [external/ICUB/CMakeFiles/YCMStamp/ICUB-build] Error 2
make[1]: *** [CMakeFiles/ICUB.dir/all] Error 2
make: *** [all] Error 2

I am currently investigating the issue.

Anomaly in computational load - Reference to YARP issue #137

As suggested by @paulfitz , I'm copy pasting from YARP issue #137 : robotology/yarp#137

Repeatable situation (I'm talking about iCubGenova01 but I think that this applies to other robots as well):

• Turn on the iCub (robotInterface, gyarpmanager, etc)
• Turn on Calib_Cameras, iCubStartup, Skin_Gui_All_V2, iCubGui (just to test a standard startup)
• Do the "top" command on some of the machines (screenshot below - right terminal is icub15 [core i7 + SSD], left terminal is icub13 [core i7 + SSD], bottom terminal is icub-b1)
  
• Most of the processes - started moments before - are firing up their respective cpu.

I can expect higher cpu load from modules like wholeBodyDynamics, but I think that mere viewers such as yarpview an iCubSkinGui shouldn't burden the machines they belong to so much. In my opinion, even the skinManager/camCalib's load is too high.

Unfortunately, I don't have any comparison with the past, but I suppose that this is a recent bug (otherwise, someone else would have noticed before me).

Error during compilation of icub-main through the codyco-superbuild

When compiling icub-main (trought the codyco-superbuild) there is a compiling error.

[  7%] Performing build step for 'ICUB'
[  1%] Copying manager.py to /home/calandra/Software/codyco-superbuild/build/external/ICUB/bin/.
[  1%] Built target python-scripts
[  1%] Copying icub-cluster scripts to /home/calandra/Software/codyco-superbuild/build/external/ICUB/bin/.
[  1%] Built target cluster-scripts
Scanning dependencies of target iCubIDLClients
[  1%] Building CXX object src/libraries/iCubIDLClients/CMakeFiles/iCubIDLClients.dir/__/__/idl_generated_code/src/fingersTuner_IDL.cpp.o
[  2%] Building CXX object src/libraries/iCubIDLClients/CMakeFiles/iCubIDLClients.dir/__/__/idl_generated_code/src/depth2kin_IDL.cpp.o
[  2%] Building CXX object src/libraries/iCubIDLClients/CMakeFiles/iCubIDLClients.dir/__/__/idl_generated_code/src/PointReq.cpp.o
[  3%] Building CXX object src/libraries/iCubIDLClients/CMakeFiles/iCubIDLClients.dir/__/__/idl_generated_code/src/dataSetPlayer_IDL.cpp.o
Linking CXX static library ../../../lib/libiCubIDLClients.a
[  3%] Built target iCubIDLClients
Scanning dependencies of target iCubDev
[  3%] Building CXX object src/libraries/iCubDev/CMakeFiles/iCubDev.dir/src/LogpolarInterfaces.cpp.o
Linking CXX static library ../../../lib/libiCubDev.a
[  4%] Built target iCubDev
Scanning dependencies of target iCubInterfaceGuiLib
[  4%] Building CXX object src/libraries/iCubInterfaceGuiLib/CMakeFiles/iCubInterfaceGuiLib.dir/iCubBoardChannel.cpp.o
[  4%] Building CXX object src/libraries/iCubInterfaceGuiLib/CMakeFiles/iCubInterfaceGuiLib.dir/iCubBoard.cpp.o
[  5%] Building CXX object src/libraries/iCubInterfaceGuiLib/CMakeFiles/iCubInterfaceGuiLib.dir/iCubNetwork.cpp.o
[  5%] Building CXX object src/libraries/iCubInterfaceGuiLib/CMakeFiles/iCubInterfaceGuiLib.dir/iCubInterfaceGuiServer.cpp.o
Linking CXX static library ../../../lib/libiCubInterfaceGuiLib.a
[  5%] Built target iCubInterfaceGuiLib
Scanning dependencies of target logpolar
[  6%] Building CXX object src/libraries/logpolar/CMakeFiles/logpolar.dir/src/RC_DIST_FB_logpolar_mapper.cpp.o
Linking CXX static library ../../../lib/liblogpolar.a
[  6%] Built target logpolar
Scanning dependencies of target boostMIL
[  6%] Building CXX object src/libraries/boostMIL/CMakeFiles/boostMIL.dir/src/MILClassifier.cpp.o
[  7%] Building CXX object src/libraries/boostMIL/CMakeFiles/boostMIL.dir/src/SelectorClassifier.cpp.o
[  7%] Building CXX object src/libraries/boostMIL/CMakeFiles/boostMIL.dir/src/StrongClassifier.cpp.o
[  8%] Building CXX object src/libraries/boostMIL/CMakeFiles/boostMIL.dir/src/OnlineBoost.cpp.o
[  8%] Building CXX object src/libraries/boostMIL/CMakeFiles/boostMIL.dir/src/OnlineSupport.cpp.o
[  8%] Building CXX object src/libraries/boostMIL/CMakeFiles/boostMIL.dir/src/AdaBoost.cpp.o
[  9%] Building CXX object src/libraries/boostMIL/CMakeFiles/boostMIL.dir/src/AvgClassifier.cpp.o
Linking CXX static library ../../../lib/libboostMIL.a
[  9%] Built target boostMIL
Scanning dependencies of target ctrlLib
[  9%] Building CXX object src/libraries/ctrlLib/CMakeFiles/ctrlLib.dir/src/math.cpp.o
[  9%] Building CXX object src/libraries/ctrlLib/CMakeFiles/ctrlLib.dir/src/filters.cpp.o
[ 10%] Building CXX object src/libraries/ctrlLib/CMakeFiles/ctrlLib.dir/src/kalman.cpp.o
[ 10%] Building CXX object src/libraries/ctrlLib/CMakeFiles/ctrlLib.dir/src/pids.cpp.o
[ 11%] Building CXX object src/libraries/ctrlLib/CMakeFiles/ctrlLib.dir/src/tuning.cpp.o
[ 11%] Building CXX object src/libraries/ctrlLib/CMakeFiles/ctrlLib.dir/src/adaptWinPolyEstimator.cpp.o
[ 11%] Building CXX object src/libraries/ctrlLib/CMakeFiles/ctrlLib.dir/src/minJerkCtrl.cpp.o
[ 12%] Building CXX object src/libraries/ctrlLib/CMakeFiles/ctrlLib.dir/src/functionEncoder.cpp.o
[ 12%] Building CXX object src/libraries/ctrlLib/CMakeFiles/ctrlLib.dir/src/optimalControl.cpp.o
[ 13%] Building CXX object src/libraries/ctrlLib/CMakeFiles/ctrlLib.dir/src/neuralNetworks.cpp.o
[ 13%] Building CXX object src/libraries/ctrlLib/CMakeFiles/ctrlLib.dir/src/outliersDetection.cpp.o
Linking CXX static library ../../../lib/libctrlLib.a
[ 13%] Built target ctrlLib
Scanning dependencies of target skinDynLib
[ 14%] Building CXX object src/libraries/skinDynLib/CMakeFiles/skinDynLib.dir/src/skinContact.cpp.o
[ 14%] Building CXX object src/libraries/skinDynLib/CMakeFiles/skinDynLib.dir/src/skinContactList.cpp.o
[ 14%] Building CXX object src/libraries/skinDynLib/CMakeFiles/skinDynLib.dir/src/dynContact.cpp.o
[ 15%] Building CXX object src/libraries/skinDynLib/CMakeFiles/skinDynLib.dir/src/dynContactList.cpp.o
[ 15%] Building CXX object src/libraries/skinDynLib/CMakeFiles/skinDynLib.dir/src/common.cpp.o
Linking CXX static library ../../../lib/libskinDynLib.a
[ 15%] Built target skinDynLib
Scanning dependencies of target iKin
[ 16%] Building CXX object src/libraries/iKin/CMakeFiles/iKin.dir/src/iKinFwd.cpp.o
[ 16%] Building CXX object src/libraries/iKin/CMakeFiles/iKin.dir/src/iKinInv.cpp.o
[ 17%] Building CXX object src/libraries/iKin/CMakeFiles/iKin.dir/src/iKinHlp.cpp.o
Linking CXX static library ../../../lib/libiKin.a
[ 17%] Built target iKin
Scanning dependencies of target iDyn
[ 18%] Building CXX object src/libraries/iDyn/CMakeFiles/iDyn.dir/src/iDyn.cpp.o
[ 18%] Building CXX object src/libraries/iDyn/CMakeFiles/iDyn.dir/src/iDynInv.cpp.o
[ 18%] Building CXX object src/libraries/iDyn/CMakeFiles/iDyn.dir/src/iDynBody.cpp.o
[ 19%] Building CXX object src/libraries/iDyn/CMakeFiles/iDyn.dir/src/iDynTransform.cpp.o
[ 19%] Building CXX object src/libraries/iDyn/CMakeFiles/iDyn.dir/src/iDynContact.cpp.o
Linking CXX static library ../../../lib/libiDyn.a
[ 19%] Built target iDyn
Scanning dependencies of target learningMachine
[ 20%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/DatasetRecorder.cpp.o
[ 20%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/DummyLearner.cpp.o
[ 20%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/IFixedSizeLearner.cpp.o
[ 21%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/LinearGPRLearner.cpp.o
[ 21%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/LSSVMLearner.cpp.o
[ 21%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/RLSLearner.cpp.o
[ 21%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/FixedRangeScaler.cpp.o
[ 22%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/IFixedSizeTransformer.cpp.o
[ 22%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/IScaler.cpp.o
[ 23%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/LinearScaler.cpp.o
[ 23%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/Normalizer.cpp.o
[ 23%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/RandomFeature.cpp.o
[ 24%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/ScaleTransformer.cpp.o
[ 24%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/SparseSpectrumFeature.cpp.o
[ 25%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/Standardizer.cpp.o
[ 25%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/Math.cpp.o
[ 25%] Building CXX object src/libraries/learningMachine/CMakeFiles/learningMachine.dir/src/Serialization.cpp.o
Linking CXX static library ../../../lib/liblearningMachine.a
[ 26%] Built target learningMachine
Scanning dependencies of target perceptiveModels
[ 26%] Building CXX object src/libraries/perceptiveModels/CMakeFiles/perceptiveModels.dir/src/ports.cpp.o
[ 26%] Building CXX object src/libraries/perceptiveModels/CMakeFiles/perceptiveModels.dir/src/sensors.cpp.o
[ 27%] Building CXX object src/libraries/perceptiveModels/CMakeFiles/perceptiveModels.dir/src/nodes.cpp.o
[ 27%] Building CXX object src/libraries/perceptiveModels/CMakeFiles/perceptiveModels.dir/src/models.cpp.o
[ 28%] Building CXX object src/libraries/perceptiveModels/CMakeFiles/perceptiveModels.dir/src/springyFingers.cpp.o
[ 28%] Building CXX object src/libraries/perceptiveModels/CMakeFiles/perceptiveModels.dir/src/tactileFingers.cpp.o
Linking CXX static library ../../../lib/libperceptiveModels.a
[ 28%] Built target perceptiveModels
Scanning dependencies of target icubmod
[ 28%] Built target icubmod
Scanning dependencies of target actionPrimitives
[ 29%] Building CXX object src/libraries/actionPrimitives/CMakeFiles/actionPrimitives.dir/src/actionPrimitives.cpp.o
Linking CXX static library ../../../lib/libactionPrimitives.a
[ 29%] Built target actionPrimitives
Scanning dependencies of target icubmoddev
[ 30%] Building CXX object src/libraries/icubmod/CMakeFiles/icubmoddev.dir/__/__/__/generated_code/yarpdev_icubmod.cpp.o
Linking CXX executable ../../../bin/icubmoddev
[ 30%] Built target icubmoddev
Scanning dependencies of target d4c
[ 31%] Building CXX object src/libraries/d4c/CMakeFiles/d4c.dir/src/d4c_helpers.cpp.o
[ 31%] Building CXX object src/libraries/d4c/CMakeFiles/d4c.dir/src/d4c_server.cpp.o
[ 31%] Building CXX object src/libraries/d4c/CMakeFiles/d4c.dir/src/d4c_client.cpp.o
Linking CXX static library ../../../lib/libd4c.a
[ 31%] Built target d4c
Scanning dependencies of target demoModule
[ 31%] Building CXX object src/examples/demoModule/CMakeFiles/demoModule.dir/src/main.cpp.o
[ 31%] Building CXX object src/examples/demoModule/CMakeFiles/demoModule.dir/src/demoModule.cpp.o
[ 32%] Building CXX object src/examples/demoModule/CMakeFiles/demoModule.dir/src/demoThread.cpp.o
Linking CXX executable ../../../bin/demoModule
[ 32%] Built target demoModule
Scanning dependencies of target rpcIdl
[ 32%] Building CXX object src/examples/rpcIdl/CMakeFiles/rpcIdl.dir/src/RpcServerImpl.cpp.o
[ 33%] Building CXX object src/examples/rpcIdl/CMakeFiles/rpcIdl.dir/src/IRpcServer.cpp.o
[ 33%] Building CXX object src/examples/rpcIdl/CMakeFiles/rpcIdl.dir/src/main.cpp.o
Linking CXX executable ../../../bin/rpcIdl
[ 33%] Built target rpcIdl
[ 34%] Built target lib0
[ 34%] Built target lib1
[ 34%] Built target sharksWithLasers
Scanning dependencies of target takeOverTheWorld
[ 34%] Building CXX object src/examples/takeOverTheWorld/CMakeFiles/takeOverTheWorld.dir/src/main.cpp.o
Linking CXX executable ../../../bin/takeOverTheWorld
[ 34%] Built target takeOverTheWorld
Scanning dependencies of target actionPrimitivesExample
[ 34%] Building CXX object src/examples/actionPrimitivesExample/CMakeFiles/actionPrimitivesExample.dir/main.cpp.o
Linking CXX executable ../../../bin/actionPrimitivesExample
[ 34%] Built target actionPrimitivesExample
Scanning dependencies of target boostMILExample
[ 34%] Building CXX object src/examples/boostMILExample/CMakeFiles/boostMILExample.dir/main.cpp.o
Linking CXX executable ../../../bin/boostMILExample
[ 34%] Built target boostMILExample
Scanning dependencies of target logpolarConvertExample
[ 34%] Building CXX object src/examples/logpolarConvertExample/CMakeFiles/logpolarConvertExample.dir/src/main.cpp.o
Linking CXX executable ../../../bin/logpolarConvertExample
[ 34%] Built target logpolarConvertExample
Scanning dependencies of target cartesianInterfaceExample
[ 35%] Building CXX object src/examples/cartesianInterfaceExample/CMakeFiles/cartesianInterfaceExample.dir/main.cpp.o
Linking CXX executable ../../../bin/cartesianInterfaceExample
[ 35%] Built target cartesianInterfaceExample
Scanning dependencies of target perceptiveModelsExample
[ 35%] Building CXX object src/examples/perceptiveModelsExample/CMakeFiles/perceptiveModelsExample.dir/main.cpp.o
Linking CXX executable ../../../bin/perceptiveModelsExample
[ 35%] Built target perceptiveModelsExample
Scanning dependencies of target d4cExample
[ 36%] Building CXX object src/examples/d4cExample/CMakeFiles/d4cExample.dir/main.cpp.o
Linking CXX executable ../../../bin/d4cExample
[ 36%] Built target d4cExample
[ 37%] Built target ICUB_tinyxml
Scanning dependencies of target robotInterface
[ 37%] Building CXX object src/core/robotInterface/CMakeFiles/robotInterface.dir/main.cpp.o
[ 38%] Building CXX object src/core/robotInterface/CMakeFiles/robotInterface.dir/Action.cpp.o
[ 38%] Building CXX object src/core/robotInterface/CMakeFiles/robotInterface.dir/CalibratorThread.cpp.o
[ 38%] Building CXX object src/core/robotInterface/CMakeFiles/robotInterface.dir/Device.cpp.o
[ 39%] Building CXX object src/core/robotInterface/CMakeFiles/robotInterface.dir/Module.cpp.o
[ 39%] Building CXX object src/core/robotInterface/CMakeFiles/robotInterface.dir/Param.cpp.o
[ 40%] Building CXX object src/core/robotInterface/CMakeFiles/robotInterface.dir/Robot.cpp.o
[ 40%] Building CXX object src/core/robotInterface/CMakeFiles/robotInterface.dir/Types.cpp.o
[ 40%] Building CXX object src/core/robotInterface/CMakeFiles/robotInterface.dir/XMLReader.cpp.o
Linking CXX executable ../../../bin/robotInterface
[ 40%] Built target robotInterface
Scanning dependencies of target emotionInterface
[ 40%] Building CXX object src/core/emotionInterface/CMakeFiles/emotionInterface.dir/main.cpp.o
[ 41%] Building CXX object src/core/emotionInterface/CMakeFiles/emotionInterface.dir/emotionInterfaceModule.cpp.o
Linking CXX executable ../../../bin/emotionInterface
[ 41%] Built target emotionInterface
Scanning dependencies of target controlBoardDumper
[ 41%] Building CXX object src/tools/controlBoardDumper/CMakeFiles/controlBoardDumper.dir/genericControlBoardDumper.cpp.o
[ 42%] Building CXX object src/tools/controlBoardDumper/CMakeFiles/controlBoardDumper.dir/main.cpp.o
[ 42%] Building CXX object src/tools/controlBoardDumper/CMakeFiles/controlBoardDumper.dir/dumperThread.cpp.o
Linking CXX executable ../../../bin/controlBoardDumper
[ 42%] Built target controlBoardDumper
Scanning dependencies of target dataDumper
[ 43%] Building CXX object src/tools/dataDumper/CMakeFiles/dataDumper.dir/main.cpp.o
Linking CXX executable ../../../bin/dataDumper
[ 43%] Built target dataDumper
Scanning dependencies of target simpleClient
[ 43%] Building CXX object src/tools/simpleClient/CMakeFiles/simpleClient.dir/main.cpp.o
Linking CXX executable ../../../bin/simpleClient
[ 43%] Built target simpleClient
Scanning dependencies of target testStereoMatch
[ 43%] Building CXX object src/tools/testStereoMatch/CMakeFiles/testStereoMatch.dir/main.cpp.o
Linking CXX executable ../../../bin/testStereoMatch
[ 43%] Built target testStereoMatch
Scanning dependencies of target iCubTestLib
[ 44%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTestLib.dir/DriverInterface.cpp.o
[ 44%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTestLib.dir/TestSet.cpp.o
[ 45%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTestLib.dir/Test.cpp.o
[ 46%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTestLib.dir/Main.cpp.o
[ 46%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTestLib.dir/TestReport.cpp.o
[ 46%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTestLib.dir/testMotors/TestMotors.cpp.o
[ 46%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTestLib.dir/testMotorsStiction/TestMotorsStiction.cpp.o
[ 46%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTestLib.dir/testMotorsStictionIncremental/TestMotorsStictionIncremental.cpp.o
[ 46%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTestLib.dir/testRoie/TestRoie.cpp.o
Linking CXX static library ../../../lib/libiCubTestLib.a
[ 49%] Built target iCubTestLib
Scanning dependencies of target iCubTest
[ 49%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTest.dir/DriverInterface.cpp.o
[ 50%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTest.dir/TestSet.cpp.o
[ 51%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTest.dir/Test.cpp.o
[ 51%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTest.dir/Main.cpp.o
[ 52%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTest.dir/TestReport.cpp.o
[ 52%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTest.dir/testMotors/TestMotors.cpp.o
[ 52%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTest.dir/testMotorsStiction/TestMotorsStiction.cpp.o
[ 52%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTest.dir/testMotorsStictionIncremental/TestMotorsStictionIncremental.cpp.o
[ 52%] Building CXX object src/tools/iCubTest/CMakeFiles/iCubTest.dir/testRoie/TestRoie.cpp.o
Linking CXX executable ../../../bin/iCubTest
[ 55%] Built target iCubTest
Scanning dependencies of target fingersTuner
[ 55%] Building CXX object src/tools/fingersTuner/CMakeFiles/fingersTuner.dir/__/__/idl_generated_code/src/fingersTuner_IDL.cpp.o
[ 56%] Building CXX object src/tools/fingersTuner/CMakeFiles/fingersTuner.dir/main.cpp.o
Linking CXX executable ../../../bin/fingersTuner
[ 56%] Built target fingersTuner
Scanning dependencies of target imuFilter
[ 56%] Building CXX object src/tools/imuFilter/CMakeFiles/imuFilter.dir/main.cpp.o
/home/calandra/Software/codyco-superbuild/external/ICUB/src/tools/imuFilter/main.cpp:42:5: error: ‘MedianFilter’ does not name a type
     MedianFilter gyroFilt;
     ^
/home/calandra/Software/codyco-superbuild/external/ICUB/src/tools/imuFilter/main.cpp:43:5: error: ‘MedianFilter’ does not name a type
     MedianFilter magFilt;
     ^
/home/calandra/Software/codyco-superbuild/external/ICUB/src/tools/imuFilter/main.cpp: In constructor ‘FilterModule::FilterModule()’:
/home/calandra/Software/codyco-superbuild/external/ICUB/src/tools/imuFilter/main.cpp:56:22: error: class ‘FilterModule’ does not have any field named ‘gyroFilt’
     FilterModule() : gyroFilt(1,Vector(3,0.0)), magFilt(1,Vector(3,0.0)),
                      ^
/home/calandra/Software/codyco-superbuild/external/ICUB/src/tools/imuFilter/main.cpp:56:49: error: class ‘FilterModule’ does not have any field named ‘magFilt’
     FilterModule() : gyroFilt(1,Vector(3,0.0)), magFilt(1,Vector(3,0.0)),
                                                 ^
/home/calandra/Software/codyco-superbuild/external/ICUB/src/tools/imuFilter/main.cpp: In member function ‘virtual bool FilterModule::configure(yarp::os::ResourceFinder&)’:
/home/calandra/Software/codyco-superbuild/external/ICUB/src/tools/imuFilter/main.cpp:71:9: error: ‘gyroFilt’ was not declared in this scope
         gyroFilt.setOrder(gyro_order);
         ^
/home/calandra/Software/codyco-superbuild/external/ICUB/src/tools/imuFilter/main.cpp:72:9: error: ‘magFilt’ was not declared in this scope
         magFilt.setOrder(mag_order);
         ^
/home/calandra/Software/codyco-superbuild/external/ICUB/src/tools/imuFilter/main.cpp: In member function ‘virtual bool FilterModule::updateModule()’:
/home/calandra/Software/codyco-superbuild/external/ICUB/src/tools/imuFilter/main.cpp:106:21: error: ‘gyroFilt’ was not declared in this scope
         Vector gyro=gyroFilt.filt(imuData->subVector(6,8))-gyroBias;
                     ^
/home/calandra/Software/codyco-superbuild/external/ICUB/src/tools/imuFilter/main.cpp:107:20: error: ‘magFilt’ was not declared in this scope
         Vector mag=magFilt.filt(imuData->subVector(9,11));
                    ^
make[5]: *** [src/tools/imuFilter/CMakeFiles/imuFilter.dir/main.cpp.o] Error 1
make[4]: *** [src/tools/imuFilter/CMakeFiles/imuFilter.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [external/ICUB/CMakeFiles/YCMStamp/ICUB-build] Error 2
make[1]: *** [CMakeFiles/ICUB.dir/all] Error 2
make: *** [all] Error 2

skinManager drift compensation not working for foot patches

Currently the (thermal) drift on the skin tactile sensors is compensated through the skinManager module. Apparently its behaviour is not optimal for the foot skin patches, because if the robot is in double support, after some time (30 seconds/1 minute?) the skin compensated output goes to zero on most of the taxels.

I did not investigated appropriately this issue, but I guess that the root of the problem is that the compensator for the drift of the skin was originally designed under the assumption that no contact on the skin was persistent in time, and it was implemented as an high pass filter to discriminate between low frequency components (due to drift) and high frequency components (due to contacts). Unfortunately this assumptions does not hold any more for the foot contacts.

I don't plan to commit time to fix this issue in the short term, but perhaps a preliminary discussion on how to solve this problem can be useful. I guess for sure that @andreadelprete , the original author of skinManager, can provide useful hints.

some files not copied during installation to custom path

This is a minor issue, but when installing to a local path (i.e. the cmake_install_prefix is set to a specified folder) some files are nto copied, for example:
icub-cluster-run.sh
icub-cluster-server.sh

New Qt5 modules compilation failure

A fresh build (cmake cache purged) generates the following errors on my Windows:

Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.61030.0.
Copyright (C) Microsoft Corp. All rights reserved.
1>------ Build started: Project: cluster-scripts, Configuration: Release Win32 ------
1>  Copying icub-cluster scripts to C:/dev/icub-main/build/bin/Release
2>------ Build started: Project: frameGrabberGui2-qt, Configuration: Release Win32 ------
3>------ Build started: Project: QtICubSkinGuiPlugin, Configuration: Release Win32 ------
2>dc1394thread.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::RemoteFrameGrabberControlsDC1394(void)" (__imp_??0RemoteFrameGrabberControlsDC1394@dev@yarp@@QAE@XZ) referenced in function "protected: virtual void __thiscall DC1394Thread::run(void)" (?run@DC1394Thread@@MAEXXZ)
2>dc1394thread.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::~RemoteFrameGrabberControlsDC1394(void)" (__imp_??1RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE@XZ) referenced in function "public: virtual void * __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::`scalar deleting destructor'(unsigned int)" (??_GRemoteFrameGrabberControlsDC1394@dev@yarp@@UAEPAXI@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::close(void)" (?close@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getActiveDC1394(int)" (?getActiveDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual double __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getBrightness(void)" (?getBrightness@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAENXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getBytesPerPacketDC1394(void)" (?getBytesPerPacketDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAEIXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getColorCodingDC1394(void)" (?getColorCodingDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAEIXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getColorCodingMaskDC1394(unsigned int)" (?getColorCodingMaskDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAEII@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual double __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getExposure(void)" (?getExposure@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAENXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getFPSDC1394(void)" (?getFPSDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAEIXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getFPSMaskDC1394(void)" (?getFPSMaskDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAEIXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual double __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getFeatureDC1394(int)" (?getFeatureDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAENH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getFormat7MaxWindowDC1394(unsigned int &,unsigned int &,unsigned int &,unsigned int &,unsigned int &,unsigned int &)" (?getFormat7MaxWindowDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NAAI00000@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getFormat7WindowDC1394(unsigned int &,unsigned int &,int &,int &)" (?getFormat7WindowDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NAAI0AAH1@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual double __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getGain(void)" (?getGain@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAENXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual double __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getGamma(void)" (?getGamma@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAENXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual double __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getHue(void)" (?getHue@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAENXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getISOSpeedDC1394(void)" (?getISOSpeedDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAEIXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual double __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getIris(void)" (?getIris@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAENXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getModeDC1394(int)" (?getModeDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getOperationModeDC1394(void)" (?getOperationModeDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual double __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getSaturation(void)" (?getSaturation@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAENXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual double __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getSharpness(void)" (?getSharpness@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAENXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual double __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getShutter(void)" (?getShutter@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAENXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getTransmissionDC1394(void)" (?getTransmissionDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getVideoModeDC1394(void)" (?getVideoModeDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAEIXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getVideoModeMaskDC1394(void)" (?getVideoModeMaskDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAEIXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getWhiteBalance(double &,double &)" (?getWhiteBalance@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NAAN0@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::getWhiteBalanceDC1394(double &,double &)" (?getWhiteBalanceDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NAAN0@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::hasAutoDC1394(int)" (?hasAutoDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::hasFeatureDC1394(int)" (?hasFeatureDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::hasManualDC1394(int)" (?hasManualDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::hasOnOffDC1394(int)" (?hasOnOffDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::hasOnePushDC1394(int)" (?hasOnePushDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::open(class yarp::os::Searchable &)" (?open@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NAAVSearchable@os@3@@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setActiveDC1394(int,bool)" (?setActiveDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH_N@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setBrightness(double)" (?setBrightness@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NN@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setBroadcastDC1394(bool)" (?setBroadcastDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_N_N@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setBytesPerPacketDC1394(unsigned int)" (?setBytesPerPacketDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NI@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setCaptureDC1394(bool)" (?setCaptureDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_N_N@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setColorCodingDC1394(int)" (?setColorCodingDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setDefaultsDC1394(void)" (?setDefaultsDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setExposure(double)" (?setExposure@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NN@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setFPSDC1394(int)" (?setFPSDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setFeatureDC1394(int,double)" (?setFeatureDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NHN@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setFormat7WindowDC1394(unsigned int,unsigned int,int,int)" (?setFormat7WindowDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NIIHH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setGain(double)" (?setGain@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NN@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setGamma(double)" (?setGamma@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NN@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setHue(double)" (?setHue@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NN@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setISOSpeedDC1394(int)" (?setISOSpeedDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setIris(double)" (?setIris@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NN@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setModeDC1394(int,bool)" (?setModeDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH_N@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setOnePushDC1394(int)" (?setOnePushDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setOperationModeDC1394(bool)" (?setOperationModeDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_N_N@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setPowerDC1394(bool)" (?setPowerDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_N_N@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setResetDC1394(void)" (?setResetDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NXZ)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setSaturation(double)" (?setSaturation@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NN@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setSharpness(double)" (?setSharpness@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NN@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setShutter(double)" (?setShutter@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NN@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setTransmissionDC1394(bool)" (?setTransmissionDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_N_N@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setVideoModeDC1394(int)" (?setVideoModeDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NH@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setWhiteBalance(double,double)" (?setWhiteBalance@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NNN@Z)
2>dc1394thread.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall yarp::dev::RemoteFrameGrabberControlsDC1394::setWhiteBalanceDC1394(double,double)" (?setWhiteBalanceDC1394@RemoteFrameGrabberControlsDC1394@dev@yarp@@UAE_NNN@Z)
2>C:\dev\icub-main\build\bin\Release\frameGrabberGui2.exe : fatal error LNK1120: 63 unresolved externals
4>------ Build started: Project: python-scripts, Configuration: Release Win32 ------
4>  Copying manager.py to C:/dev/icub-main/build/bin/Release
3>  Fingertip2Left.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  Fingertip2Right.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  Fingertip.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  PalmLeft.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  PalmRight.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  qticubskinguiplugin.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  qticubskinguiplugin_plugin.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  Quad16.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  SkinMeshThreadCan.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  SkinMeshThreadPort.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  TouchSensor.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  Triangle_10pad.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  Triangle.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  QtICubSkinGuiPlugin_automoc.cpp
3>c:\dev\icub-main\src\tools\icubskingui-qt\plugin\include/TouchSensor.h(10): fatal error C1083: Cannot open include file: 'gsl/gsl_math.h': No such file or directory
3>  Generating Code...
========== Build: 2 succeeded, 2 failed, 90 up-to-date, 0 skipped ==========

RobotInterface: when attach fails the error message reports a wrong device name

src/core/robotInterface/Device.cpp al line 346 and 362
the error message says

yError() << "Device" << name() << "cannot execute" << ActionTypeToString(ActionTypeAttach) << "on device" << name()

The second name() sould be the name of the device it is trying to attach to instead of the name of the wrapper itself.

Note:
Find the correct name can be tricky in case the wrapper is attaching to more then one device.

Not such a big problem however

Compilation of DataDumper fails on pc104 without opencv (ADD_VIDEO)

Building CXX object src/tools/dataDumper/CMakeFiles/dataDumper.dir/main.cpp.o
/usr/local/src/robot/icub-main/src/tools/dataDumper/main.cpp: In member function ‘virtual bool DumpModule::configure(yarp::os::ResourceFinder&)’:
/usr/local/src/robot/icub-main/src/tools/dataDumper/main.cpp:820:71: error: ‘videoType’ was not declared in this scope
make[2]: *** [src/tools/dataDumper/CMakeFiles/dataDumper.dir/main.cpp.o] Error 1

iCub_SIM verbose messages

It does continuously print out lots of “getOutputRaw not yet implemented for iCubSimulationControl” causing a significant slow-down.

Initially reported by @pattacini in #76

Quoting @barbalberto reply:

2. this is "correct" in the sense that the new extended port is collecting more data than the old state port, therefore it is calling more low-level functions of the simulated controlBoard. If those functions are not implemented you see those print functions.
   The right solution is to implement the functions or make them quiet. You can also de-activate the extended port by setting yarp cmake flag CBW2_USE_YARP_THRIFT to false.

My suggestion: let's implement those methods to slient the printf.

Get rid of old-fashion app installation

I would remove old style macros such as icub_app and icub_app_install from cmake files.

Launching robotInterface and iCubStartup modules simultaneously

It would be worth devising a way to restore the old good feature we used to have along with the superseded iCubInterface back inside the new robotInterface, which was regarded with the possibility to launch at once all the modules of the iCubStartup application.

Past
Components such as iKinGazeCtrl, iKinCartesianSolver, fingersTuner, wholeBodyDynamics were able to continuously query about the existence of motor ports before going further with their own initialization. Since those ports were made available by the iCubInterface only as the very last operation, everything was running smoothly. As result, the user was able to press the overall start button of the iCubStartup application.

Present
robotInterface opens up motor ports not at the end of its start-up phase, hence the downstream modules believe they can proceed anyway while of course that's not true.

Is there any way to address this issue with the new software?
Maybe the PolyDriver::open() at the client side could exchange some message with the remote in order to be notified when robotInterface is really ready. I think now it returns true as soon as the connection with motor port is successful.

iCub_SIM creashes upon closure saying: “yarp: semaphore wait failed (errno 6); gdb problem; or bad YARP+ACE flags”.

This problem was reported by @pattacini in #76

@barbalberto is checking it.

Getting 3D skin data files

I cant find data files with the positions and orientations from each sensor. I used google and searched in the icub contribution page but only get a page which refers to the icub 3D skin gui which points to such files (http://eris.liralab.it/iCub/contrib/dox/html/group__icub__iCubSkinGUI3D.html), that I didnt found too (maybe because I cub 3d skin gui doesent exists anymore?).

robotInterface and controlBoardDumper

For some reason the controlBoardDumper launched with the following command:

controlBoardDumper --robot icub --part torso --rate 10 --joints "(0 1 2)" --dataToDumpAll

is not giving the expected results. In particular: (1) the port /controlBoardDumper/torso/getOutputs is giving always three null values despite of the fact that the robotInterface was launched with the proper broadcast enabled (broadcast_pid); (2) the robotInterface prints continuously the following message: "received an unknown request after a VOCAB_GET: dra"

Proposal for iCub naming conventions

In the process of producing software-friendly models for the iCub robot directly from the Creo CAD models in a semi-automatically, we needed a convention for naming the different elements that constitute the robot. I will proposed a convention extending existing naming schemes, and I will be happy to get any feedback. Sharing a common convention in existing software would help to reduce incompatibilities and integration problems.

Joints

1-DOF Joints

Note: it could be useful to distinguish between the two different concepts of degree of freedom and joint. For simplicity we decide to ignore for the time being this difference, that is relevant for multi-DOF joints and closed kinematic structures.

The joints are mechanism that connect two different links (as defined in the following section) of the robot. 1-DOF joints allow motion only along one direction between the two connected links.

For joints an existing convention is introduced in http://eris.liralab.it/wiki/ICub_joints . I do not know if this names are actually used anywhere in the code and/or documentation (@barbalberto perhaps in IAxisInfo implementation?). Unfortunately in that convention the names are not unique across the robot, so for example knee is used to refer to both left and right knee. So we propose to use that convention, with an additional l_ or r_ prefix for joints that come in symmetric pairs. Disregarding for the moment eyes and hands, then we have the following joint names:

Yarp ControlBoard name	Joint name
left_leg	l_hip_pitch
left_leg	l_hip_roll
left_leg	l_hip_yaw
left_leg	l_knee
left_leg	l_ankle_pitch
left_leg	l_ankle_roll
right_leg	r_hip_pitch
right_leg	r_hip_roll
right_leg	r_hip_yaw
right_leg	r_knee
right_leg	r_ankle_pitch
right_leg	r_ankle_roll
torso	torso_pitch
torso	torso_roll
torso	torso_yaw
head	neck_pitch
head	neck_roll
head	neck_yaw
left_arm	l_shoulder_pitch
left_arm	l_shoulder_roll
left_arm	l_shoulder_yaw
left_arm	l_elbow
left_arm	l_wrist_prosup
left_arm	l_wrist_pitch
left_arm	l_wrist_yaw
right_arm	r_shoulder_pitch
right_arm	r_shoulder_roll
right_arm	r_shoulder_yaw
right_arm	r_elbow
right_arm	r_wrist_prosup
right_arm	r_wrist_pitch
right_arm	r_wrist_yaw

I am personally ok with this names, but perhaps someone (@luca-fiorio ?) has some comments and may thinks that this names are misleading.

Fixed (0-DOFs) Joints

When dealing with 6-axis FT sensors, it is convenient to model them as joints that do not allow any motion between the two connected links.

In the iCub can be mounted up to 6 6-axis ft sensors.

Yarp AnalogSensor name	Fixed joint name
left_arm	l_arm_ft_sensor
right_arm	r_arm_ft_sensor
left_leg	l_leg_ft_sensor
left_foot	l_foot_ft_sensor
right_leg	r_leg_ft_sensor
right_foot	r_foot_ft_sensor

Links

The links are the physical rigid bodies that constitute the robot. Each link is characterised by a mass (represented in models by the inertial parameters) and a physical shape (represented in models by meshes).

For defining the links we are representing the robot as a directed tree, where the root_link is the body that can be attached to the pole, and the meaning of the other links can be deduced by their parent joint, as defined in the previous section.

The main idea behind this naming scheme is that "big" links (roughly speaking, the one that can reasonably interact with the user) are named with intuitive names such as upper_arm, forearm, upper_leg, lower_leg, chest, head, foot, hand. All the little links that instead are part of more complex linkages, take their name from the articulation, such as torso_1, torso_2.

Link Name	Parent Joint	Parent Link
root_link
l_hip_1	l_hip_pitch	root_link
l_hip_2	l_hip_roll	l_hip_1
l_hip_3	l_leg_ft_sensor	l_hip_2
l_upper_leg	l_hip_yaw	l_hip_3
l_lower_leg	l_knee	l_upper_leg
l_ankle_1	l_ankle_pitch	l_lower_leg
l_ankle_2	l_ankle_roll	l_ankle_1
l_foot	l_foot_ft_sensor	l_ankle_2
r_hip_1	r_hip_pitch	root_link
r_hip_2	r_hip_roll	r_hip_1
r_hip_3	r_leg_ft_sensor	r_hip_2
r_upper_leg	r_hip_yaw	r_hip_3
r_lower_leg	r_knee	r_upper_leg
r_ankle_1	r_ankle_pitch	r_lower_leg
r_ankle_2	r_ankle_roll	r_ankle_1
r_foot	r_foot_ft_sensor	r_ankle_2
torso_1	torso_pitch	root_link
torso_2	torso_roll	torso_1
chest	torso_yaw	torso_2
l_shoulder_1	l_shoulder_pitch	chest
l_shoulder_2	l_shoulder_roll	l_shoulder_1
l_shoulder_3	l_shoulder_yaw	l_shoulder_2
l_upper_arm	l_arm_ft_sensor	l_shoulder_3
l_elbow_1	l_elbow	l_forearm
l_forearm	l_wrist_prosup	l_elbow_1
l_wrist_1	l_wrist_pitch	l_forearm
l_hand	l_wrist_yaw	l_wrist_1
r_shoulder_1	r_shoulder_pitch	chest
r_shoulder_2	r_shoulder_roll	r_shoulder_1
r_shoulder_3	r_shoulder_yaw	r_shoulder_2
r_upper_arm	r_arm_ft_sensor	r_shoulder_3
r_elbow_1	r_elbow	r_arm
r_forearm	r_wrist_prosup	r_elbow_1
r_wrist_1	r_wrist_pitch	r_forearm
r_hand	r_wrist_yaw	r_wrist_1

Frames

In literature and in robotics software, the links and frames concepts are often confused, because every link is usually associated with a frame rigidly attached to it. However this link frame definition is dependent on the formalism that one uses for describing the robot. For example, if the Denavit Hartenberg convention is used the link frame origin is required to be placed on the axis of the child joint, while if the Modified Denavit Hartenberg convention or the URDF format the link frame origin is required to be place on the axis of the parent joint.
To avoid inconsistency, I think it is better to clearly separate frame and link concepts.
For the iCub, it could be useful to explicitly state the frame used for defining the kinematic chains used in the iKin library.
In particular a useful set of frames could be:

Frame Name	Link	Explanation
root_frame	root_link	Root reference frame, as defined in http://eris.liralab.it/wiki/ICubForwardKinematics
imu_frame	head	Inertial sensor (XSens MTx) reference frame, as defined in http://eris.liralab.it/wiki/ICubForwardKinematics
l_hand_dh_frame	l_hand	Left hand frame, as defined in http://eris.liralab.it/wiki/ICubForwardKinematics
r_hand_dh_frame	r_hand	Right hand frame, as defined in http://eris.liralab.it/wiki/ICubForwardKinematics
l_foot_dh_frame	l_foot	Left foot frame, as defined in http://eris.liralab.it/wiki/ICubForwardKinematics
r_foot_dh_frame	r_foot	Right foot frame, as defined in http://eris.liralab.it/wiki/ICubForwardKinematics
l_eye_frame	--- (missing at the moment)	Left eye frame, as defined in http://eris.liralab.it/wiki/ICubForwardKinematics
r_eye_frame	--- (missing at the moment)	Right eye frame, as defined in http://eris.liralab.it/wiki/ICubForwardKinematics
l_arm_ft_frame	l_upper_arm,l_arm	Left Arm FT sensor frame, as defined in http://wiki.icub.org/wiki/FT_sensor
r_arm_ft_frame	r_upper_arm,r_arm	Right Arm FT sensor frame, as defined in http://wiki.icub.org/wiki/FT_sensor
l_leg_ft_frame	l_hip_2,l_hip_3	Left Leg FT sensor frame, as defined in http://wiki.icub.org/wiki/FT_sensor
l_foot_ft_frame	l_upper_foot,l_foot	Left Foot FT sensor frame, as defined in http://wiki.icub.org/wiki/FT_sensor
r_leg_ft_frame	r_hip_2,r_hip_3	Right Leg FT sensor frame, as defined in http://wiki.icub.org/wiki/FT_sensor
r_foot_ft_frame	r_upper_foot,r_foot	Right Foot FT sensor frame, as defined in http://wiki.icub.org/wiki/FT_sensor

Skin Frames

An interesting set of frame is the frame defined by the iKin convention ( http://eris.liralab.it/wiki/ICubForwardKinematics ). This reference frames are used by the skin system to express contact points, force and torques (in skinDynLib data structures) and taxel positions.
The one currently used by the skin system are:

Frame Name	Link	Explanation
l_foot_dh_frame	l_foot	Frame of LEFT_FOOT SkinPart
r_foot_dh_frame	r_foot	Frame of RIGHT_FOOT SkinPart
l_upper_arm_dh_frame	l_upper_arm	Frame of SKIN_LEFT_UPPER_ARM SkinPart
l_forearm_dh_frame	l_forearm	Frame of SKIN_LEFT_FOREARM SkinPart
l_hand_dh_frame	l_hand	Frame of SKIN_LEFT_HAND SkinPart
r_upper_arm_dh_frame	r_upper_arm	Frame of SKIN_RIGHT_UPPER_ARM SkinPart
r_forearm_dh_frame	r_forearm	Frame of SKIN_RIGHT_FOREARM SkinPart
r_hand_dh_frame	r_hand	Frame of SKIN_RIGHT_HAND SkinPart

SkinPart RIGHT_LEG_UPPER, LEFT_LEG_UPPER, RIGHT_LEG_LOWER, LEFT_LEG_LOWER and SKIN_FRONT_TORSO are not currently correctly processed by the system and they are not assigned any frame. In particular SKIN_FRONT_TORSO is problematic because the Torso link for the DH convention used by iKin for frame placement has three different frames, depending on which chain is considered (if head, right arm or left arm).

For all this frames, an alternative naming could be:
"linkName_ikin_frame", to have a name that is directly related to the iKin software.

Other frames

Probably some other intermediate frame could also be useful, as something related to the neck.

Additional frames could be defined to improve compliance with REP-120 that is already used for different humanoids URDFs (Nao, Romeo, HRP-2, Coman).

This is an initial proposal that is not discussing several important aspects (eyes, hands, accelerometers, gyroscopes), but I guess it is already ready for getting some feedback.

cc @EnricoMingo @jeljaik @arocchi @hu-yue

Change force/torque name port

Change name for the force/torque ports in the wrappers.

[coman] Impedance Ctrl at DSP level

When switching to Impedance/Torque Ctrl the firmware expects a torque reference every x ms so we need to assure that reference, if not the board goes in protection. This issue is to remeber to check this with Alessio M.

Q: Installation of all robots contexts on windows

@elen4
On my windows machine, despite I ticked out ICUB_INSTALL_ALL_ROBOTS I got all the robots context installed under share dir.

Looking in the cmake code, might it be that since the option is "on" by default the subsequent lines enclosed by the if-statement get processed straightaway during the first pass and just before the user is able to make his selection?

However, it is still strange to me, because I've seen it working for linux, if I remember correctly. My cmake is the latest release 2.8.12.1.

Unit tests for motor control board

It has been discussed several times that we need to implement a set of tests for the robot. In particular it is important to implement a set of tests for motor control board. Test should be runnable on the real robot and the simulator.

The icub-main already contains an unit-test like infrastructure for testing that was implemented for this purpose.

@traversaro @randaz81 @arocchi @barbalberto @EnricoMingo

[robotInterface] Weird error message when forcing close (Ctrl+C) on robotInterface

When forcing close on robotInterface a weird error message appears. Attached is a screenshot.

BottleStyle.h not properly included

Compiling iCub gives the following error:
/Users/iron/Code/bin/include/yarp/os/idl/WireTypes.h:36:10: fatal error:
'yarp/os/idl/BottleStyle.h' file not found
which seems not to be installed by a fresh YARP installation form github master.

[iCubLondon01] xml calibrator + hardware/motorControl incorrect robot name

Hi,
Maxime and I just spotted that the robotName in some config files of iCubLondon01 is not set correctly. From the git history, it seems like something went wrong when the robot was upgraded.

The config files contain

instead of

Could someone please correct that?
Here is a list of the files:
./icub-main/share/iCub/robots/iCubLondon01/calibrators/left_hand_calib.xml
./icub-main/share/iCub/robots/iCubLondon01/calibrators/left_arm_calib.xml
./icub-main/share/iCub/robots/iCubLondon01/calibrators/right_arm_calib.xml
./icub-main/share/iCub/robots/iCubLondon01/calibrators/torso_calib.xml
./icub-main/share/iCub/robots/iCubLondon01/calibrators/head_calib.xml
./icub-main/share/iCub/robots/iCubLondon01/calibrators/right_hand_calib.xml
./icub-main/share/iCub/robots/iCubLondon01/calibrators/left_leg_calib.xml
./icub-main/share/iCub/robots/iCubLondon01/calibrators/right_leg_calib.xml
./icub-main/share/iCub/robots/iCubLondon01/hardware/motorControl/icub_right_leg.xml
./icub-main/share/iCub/robots/iCubLondon01/hardware/motorControl/icub_head.xml
./icub-main/share/iCub/robots/iCubLondon01/hardware/motorControl/icub_right_arm.xml
./icub-main/share/iCub/robots/iCubLondon01/hardware/motorControl/icub_torso.xml
./icub-main/share/iCub/robots/iCubLondon01/hardware/motorControl/icub_right_hand.xml
./icub-main/share/iCub/robots/iCubLondon01/hardware/motorControl/icub_left_hand.xml
./icub-main/share/iCub/robots/iCubLondon01/hardware/motorControl/icub_left_leg.xml
./icub-main/share/iCub/robots/iCubLondon01/hardware/motorControl/icub_left_arm.xml

Thanks,
Tobias and Maxime

skinManager having problems

I'm having problems with the skinManager in iCubDarmstadt01.
Sometimes I click on buttons (for example binarization on/off) and nothing happens.
@randaz81 also checked this.

IOL kinesthetic teaching fails due to a problem on torso pitch

While running the kinesthetic teaching part of the IOL demo, iCub starts leaning forward with the torso. Somehow, the torque applied to the torso pitch is not enough to counterbalance the gravity. As result, the operator is unable to teach the robot the correct posture.

Due to the somewhat importance of the IOL demo, we need to fix this problem asap.
I'm available to give help.