robotology / robots-configuration

Contains robots configuration files

Robots Configuration

Maintainers

This repository is maintained by:

	@pattacini	Main responsible
	@davidetome	Deputy
	@Nicogene	Deputy

Installation

Dependencies

Make sure you have available the following resources:

• YARP
• icub-contrib-common

Setting up your Robot

Unless you aim to install the configurations of all robots, you have to specify the name of your own robot by means of the environment variable YARP_ROBOT_NAME. Example:

export YARP_ROBOT_NAME=iCubGenova01

Build

From the repository root level do:

cmake -S . -B build
cmake --build build/ --target install

As result, the configurations files of your own robot should be placed in $ICUBcontrib_DIR/share/ICUBcontrib/robots/$YARP_ROBOT_NAME.

From this location you may want to tune/modify certain parameters by first copying out the installed files into user local directories. To this end, rely on the command below:

yarp-config robot --import $YARP_ROBOT_NAME

You should end up finding the local copies under ~/.local/share/yarp/robots/$YARP_ROBOT_NAME.

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

License

Material included here is Copyright of iCub Facility - Istituto Italiano di Tecnologia and is released under the terms of the GPL v2.0 or later. See the file LICENSE for details.

robots-configuration's Issues

Mismatch in the names of feet FT IMUs

While I was doing some base estimation experiments with the foot FT, I realized that there is a mismatch in the names of the foot FT IMUs added from the icub-model-generator robotology/icub-models-generator#122 and those added at the robots-configuration level #110

For example, considering the FT accelerometers, in the urdf model, these are added as r_foot_ft_acc_3b14 while in the robots configurations, these are loaded with the names r_lower_leg_ft_acc_3b14.

We need to choose to make changes to one of the places to be coherent and minimize work.
An alternative would be to set the proper metaData (sensorName, frameName, etc) through the MAS interface.

@nunoguedelha @traversaro @S-Dafarra @GiulioRomualdi @MiladShafiee @fjandrad

ETH Daisy Chain connection order in config

Refering to robotology/community/issues/134 , @marcoaccame suggested

The chain of ETH boards can change from robot to robot. The correct action would be to add the HW schematics in a file inside robots-configuration repository.

which is something I totally agree it should be done. I can do it for iCubDarmstadt01, however
you might prefer a specific format/template.

Add Gh action for CI

We should add a gh for the continuous integration

Head calibration delta parameter seems to have no effect

We were trying to calibrate the neck joints on iCubNancy01. In the configuration file for the head (here) we tried to modify the parameter calibrationDelta, but it seems that this parameters has no effect in the calibration procedure, and the joints always have the same error (according to the IMU measurements)

`controlboardwrapper2` deprecation

device controlboardwrapper2 was deprecated in previous yarp releases and it will be completely removed in the upcoming yarp 3.8.
The correct devices to use are: controlBoard_nws_yarp / controlboardremapper.
An update of the robot configuration files is highly recommended, otherwise, the robot will be not able to startup anymore.

iCubGenova09 yarprobotinterface throws error "Parameter networks use deprecated syntax"

Every time we run the yarprobotinterface we get the not fatal error

Parameter networks use deprecated syntax

It seems it is thrown by https://github.com/robotology/yarp/blob/9ce40a416ce872154c90130a04648eb6923eb536/src/devices/ControlBoardWrapper/ControlBoardWrapper.cpp#L489, but I am not able to spot what causes this issue in the configuration files, nor how to avoid that.

Request for Comments: Clarify location of robot-specific manually added files?

Historically, the robots-configuration has been used to host two kind of files:

• The "official" (with a lot of quotes : ) ) configuration files for a given robot, that are typically maintained by the iCub Tech, and that routinely need to be massively updated for several reason (bugs found, change in the software that requires update in the configuration files). This files are not exactly the same for two different (even if identical) robots, due to calibration settings and similar robot specific parameters, but at least their structure is (or should be) consistent across robot of the same version.
• Robot-specific configuration and material: this includes robot-specific material that is maintained by specific Research Lines that used the robot (in IIT) or robot groups. While one school of thought is that this material should be in repositories that are maintained by the groups that are responsible for them, in practice for configuration files that are part of the "robot setup" it is quite convenient to be able to managed them with the rest of the robot configuration files.

This is de-facto situation. However, I think that a possible improvement (especially to simplify the possibility of doing automatic changes to the "official" configuration files) is to dedicate a given directory in the robot directory for robot-specific files, something called extra or similar (bikeshedding on the name is welcome), in which all the robot-specific files can be placed. In this way, it would be easy to separate between "official" iCub configuration files and robot-specific ones.

Some robots configuration files try to run parametricCalibratorETH on CAN devices, in particular on the head

Complete list of robots that need a fix:

• iCubGenova02 https://github.com/robotology/robots-configuration/blob/master/iCubGenova02/calibrators/head-calib.xml
• iCubGenova06 https://github.com/robotology/robots-configuration/blob/master/iCubGenova06/calibrators/head-calib.xml
• iCubNancy01 https://github.com/robotology/robots-configuration/blob/master/iCubNancy01/calibrators/head-calib.xml
• iCubTwente01 https://github.com/robotology/robots-configuration/blob/master/iCubTwente01/calibrators/head-calib.xml → icebox ❄️
• iCubDarmstad01 https://github.com/robotology/robots-configuration/blob/master/iCubDarmstadt01/calibrators/head-calib.xml → icebox ❄️
• iCubSheffield01 https://github.com/robotology/robots-configuration/blob/master/iCubSheffield01/calibrators/head-calib.xml → icebox ❄️
• iCubNottingham01 https://github.com/robotology/robots-configuration/blob/master/iCubNottingham01/calibrators/head-calib.xml → icebox ❄️

Original issue: robotology/icub-main#388
Related issue: robotology/icub-main#240

cc @randaz81 @davidetome

robot-configuration fails to Configure testSkin

I was trying to build core profile of Superbuild, but I had the following error:

CMake Error at C:/Users/Kouro/rob-sb/build/install/share/yarp/cmake/YarpInstallationHelpers.cmake:389 (file):
  file COPY cannot find
  "C:/Users/Kouro/rob-sb/robotology/robots-configuration/testSkin/calibrators".
Call Stack (most recent call first):
  testSkin/CMakeLists.txt:8 (yarp_install)


CMake Error at C:/Users/Kouro/rob-sb/build/install/share/yarp/cmake/YarpInstallationHelpers.cmake:389 (file):
  file COPY cannot find
  "C:/Users/Kouro/rob-sb/robotology/robots-configuration/testSkin/cartesian".
Call Stack (most recent call first):
  testSkin/CMakeLists.txt:9 (yarp_install)


CMake Error at C:/Users/Kouro/rob-sb/build/install/share/yarp/cmake/YarpInstallationHelpers.cmake:389 (file):
  file COPY cannot find
  "C:/Users/Kouro/rob-sb/robotology/robots-configuration/testSkin/camera".
Call Stack (most recent call first):
  testSkin/CMakeLists.txt:12 (yarp_install)

Therefore, to build the core profile of the superbuild I commented the following lines in robots-configurations\testskin\CMakeLists.txt: (lines 8,9,12):

#yarp_install(DIRECTORY calibrators DESTINATION ${ICUBCONTRIB_ROBOTS_INSTALL_DIR}/${appname})
#yarp_install(DIRECTORY cartesian DESTINATION ${ICUBCONTRIB_ROBOTS_INSTALL_DIR}/${appname})
#yarp_install(DIRECTORY camera DESTINATION ${ICUBCONTRIB_ROBOTS_INSTALL_DIR}/${appname})

Machine: Windows 10
CC @traversaro

Strange issue on iCubGenova04

On iCubGenova04 we are having a strange issue (under investigation). Basically we modified the file , and if INSTALL_ALL_ROBOTS is ON the file is not updated and instead an old one is copied in the build directory and then installed, otherwise if we set INSTALL_ALL_ROBOTS to OFF the correct file is copied:

# Source file
icub@icub-head:/usr/local/src/robot/robotology-superbuild/build/robotology/robots-configuration (master)$ date -r ../../../robotology/robots-configuration/iCubGenova04/hardware/mechanicals/right_arm-eb28-j8_11-mec.xml 
Tue Nov 24 11:57:35 UTC 2020
# Configure with INSTALL_ALL_ROBOTS=ON
icub@icub-head:/usr/local/src/robot/robotology-superbuild/build/robotology/robots-configuration (master)$ cmake -DINSTALL_ALL_ROBOTS=ON . &> /dev/null 
# File in build directory has wrong modification date 
icub@icub-head:/usr/local/src/robot/robotology-superbuild/build/robotology/robots-configuration (master)$ date -r share/ICUBcontrib/robots/iCubGenova04/hardware/mechanicals/right_arm-eb28-j8_11-mec.xml 
Wed Sep 30 13:35:45 UTC 2020
# Configure with INSTALL_ALL_ROBOTS=OFF
icub@icub-head:/usr/local/src/robot/robotology-superbuild/build/robotology/robots-configuration (master)$ cmake -DINSTALL_ALL_ROBOTS=OFF . &> /dev/null
# File in build directory has correct modification date 
icub@icub-head:/usr/local/src/robot/robotology-superbuild/build/robotology/robots-configuration (master)$ date -r share/ICUBcontrib/robots/iCubGenova04/hardware/mechanicals/right_arm-eb28-j8_11-mec.xml 
Tue Nov 24 11:57:35 UTC 2020

On several robot, the eyes_version and eyes_vergence AxisName are inverted

See (for example, there are others):

• robots-configuration/iCubDarmstadt01/hardware/mechanicals/head-cfw2_can0-mec.xml

  Line 9 in 5f34919

  <param name="AxisName"> "neck_pitch" "neck_roll" "neck_yaw" "eyes_tilt" "eyes_vergence" "eyes_version" </param>

• robots-configuration/iCubGenova01/hardware/motorControl/icub_head_test.xml

  Line 36 in 5f34919

  <param name="AxisName"> "neck_pitch" "neck_roll" "neck_yaw" "eyes_tilt" "eyes_vergence" "eyes_version" </param>

The official ordering (from http://wiki.icub.org/wiki/ICub_joints#Head_2.0) should be "eyes_version" "eyes_vergence".

Why don't we directly modify the parameters in the source folder?

It is of common use (and written in the README) to install and import in the .local folder the configuration files available in this repo. Nevertheless, as a result there is always discrepancy between the files in the source and those in the .local folder. This causes problems every time a new firmware is released and one of us (usually @nunoguedelha) has to perform by hand what git is supposed to do, i.e. version control on the .local files, guessing who did what and why ("who changed the resolution of the DragonFly cameras???") copy (again by hand) the modifications on the source folder, open a pull request and have it merged before performing a firmware update. I think it is quite a long pipeline and very error prone.
So the question is, why can't we modify and commit directly the source folder? Every robot has already its own folder, and git can help understanding who changed what and when. What is the drawback for such a solution?
@DanielePucci @traversaro

Unintended change of frequency of iCub's controlBoard_nws_yarp instances from 100 Hz to 50 Hz

Historically, iCub's Network Wrapper Servers (i.e. the YARP devices that publish informations over YARP ports) have run at 100 Hz. I may be wrong, but it seems to me that in the latest NWS/NWC layers migration (see #321 and subsequent PRs), we switched to use 50 Hz frequency. It seems that this happend because we removed all the <param name="period">10</param> parameters, meaning that now we rely on the default period of controlBoard_nws_yarp, that is 1/0.02 = 50 Hz, see https://github.com/robotology/yarp/blob/v3.7.2/src/devices/ControlBoardWrapper/ControlBoard_nws_ros.h#L41 .

Where to report robot configuration files issues

I think there is a risk of overlap between the issue tracker of this repo (robots-configuration) and icub-support that covers issue relative to a specific instance of a robot.

Where should problems related to errors in configuration files be reported? Here or in icub-support?
What do you prefer to have them @julijenv ?

Cleanup iCubInterface-related configuration files

As emerged in robotology/icub-main#632, in this repo there are a lot of configuration files for the iCubInterface executable, that have been deprecated by robotinterface/yarprobotinterface in ~2012 and removed from the icub-main repo in 2016 (see robotology/icub-main@c603872).
We need to understand what to do with iCubInteface-related files still contained in this repo (see https://github.com/robotology/robots-configuration/search?utf8=%E2%9C%93&q=net_headtorso&type= for a short overview). I think it is perfectly safe to remove them.

`grabberDual` device removal in YARP 3.8.0

device grabberDual was deprecated in previous yarp releases and it will be completely removed in the upcoming yarp 3.8.
The correct device to use is: frameGrabber_nws_yarp
An update of the robot configuration files is highly recommended, otherwise, the robot will be not able to startup anymore.
It is also highly recommended to translate the current camera .ini configuration files to the xml format, as shown below.

Syncing configuration files with SW/FW

Following up robotology/icub-main#360, and in particular this comment by @lornat75, before proceeding with the use of this new repo, we need a run-time mechanism to check consistency among FW, yarprobotinterface and configuration files.

It should suffice to implement/verify that when e.g. one critical new parameter is missing from within the conf file, then yarprobotinterface will abort launching the robot, warning the user to do an update.

cc @randaz81 @marcoaccame @lornat75 @vtikha @drdanz @traversaro

Deal with optional/default values once and for good

Following up robotology/icub-main#662 (comment), it'd be great to harmonize robots configuration in order to solve the "dilemma" gravitating around the optional parameters with their default values, which happened to cause strong headaches in the past.

cc @randaz81

Update wiki and templates

@valegagge pointed out that we should update the manual containing the robots configuration information and the templates

cc @marcoaccame

INSTALL_ALL_ROBOTS option is broken

If the INSTALL_ALL_ROBOTS option is selected, the project does not configure due to some add_subdirectory that are pointing to directories that do not exist anymore:

CMake Error at CMakeLists.txt:56 (add_subdirectory):
  add_subdirectory given source "Nottingham01" which is not an existing
  directory.


CMake Error at CMakeLists.txt:65 (add_subdirectory):
  add_subdirectory given source "iCubRome01" which is not an existing
  directory.

@randaz81 I see that the file https://github.com/robotology/robots-configuration/blob/master/all_robots.xml seems to be automatically generated, do you think we can generate automatically also a file with all the correct add_subdirectory(...) calls?

Some of the gear ratios of the iCubGenova09 appear to be wrong

This issue was actually discovered by @pattacini @salvi-mattia. For example, the gear ratio on the ankle rolls is set to 160, but it is most probably 100

robots-configuration/iCubGenova09/hardware/mechanicals/right_leg-eb12-j4_5-mec.xml

Line 14 in 696b86c

<param name="Gearbox_M2J"> 100.0 160.0 </param>

Right now, this does not affect the position control loop, but it may be an issue for other types of controllers.

cc @traversaro @lrapetti

Add wholebodydynamics device configuration files for all robots with a modern CPU in icub-head

For all iCub with a modern CPU in the head, we should be able to provide wholebodydynamics device (i.e. the device available in https://github.com/robotology/whole-body-estimators/pulls) xml files such as the one that are available for iCubGenova02 and iCubGenova04 . First of all, we should be able to get a list of the iCubs with modern CPUs.

Update all ETH robots to motion control ver 6

As per robotology/community#377 we need to update the following ETH robots to the use of Motion Control Version 6:

• iCubDarmstadt01
• iCubEdinburgh01
• iCubHeidelberg01
• iCubLausanne02
• iCubNancy01
• iCubNottingham01
• iCubSheffield01
• iCubSingapore01
• iCubTwente01
• iCubHamburg01

cc @marcoaccame

Wrong coefficients coupling the eyes' vergence?

Given that the vergence Vg amounts to the difference between the single eyes' joints L-R (see the wiki), I think that the values contained in the eyes' coupling matrices should be -1.0 1.0 instead of -0.5 0.5.

Differently, as Vs = (L + R) / 2 it turns out that the line immediately above reporting 0.5 0.5 is spot on.

Can this reasoning be assumed correct?

This is somehow linked to robotology/icub-firmware#71.

cc @davidetome @randaz81 @ale-git @traversaro @plinioMoreno

Encoder Consistency test - hip pitch joint gear ratio

Hi all,

This issue connects with #76 since I found the same error when performing the encoders test on the last robots.

The hip_pitch joint has an additional cable transmission stage after the harmonic drive. The motor side pulley has a diameter of 50 [mm], while the joint side pulley has a diameter of 75 [mm], consequently, the additional reduction ration is: 75/50 =1.5

The encoder Consistency test cycles each joint and plots the joint parameters transported into the motor reference space (y-axis= motor encoder values) and the 2 trajectories should be overlapped.

This is the code implementing the test.

Each robot part has a .ini file where the J2M matrix is specified. In particular this is the coupling matrix and it is correct (element (1,1)=75/50=1.5 :

Therefore the matrix used in the test is not the one saved in the mechanical xml file of each robot (example iCubZagreb01) . I believe that this xml file is used by the test to extract the parameter gearbox (here).

This is what happens when modifying this the gearbox parameter in the robot xml file:

Case 1

If I only set Gearbox_M2J = 150 (see iCubZagreb01) and then I plot the joint position vs. motor position for the legs, I obtain a mismatch in j0 -pitch, since the test already takes into account a (correct) coupling matrix as above.

Case 2

 The original parameters in the previous robots (see iCubHongKong01) were:  Gearbox_M2J = 100 and identity coupling matrix M2J (wrong!)

With these parameters, when I perform the same encoder test I obtain the correct plots. This is expected because a unitary gear ratio and a correct coupling matrix allow a correct calculation:

Conclusions

In the mechanicals xml file of each robot I believe we need to do some corrections:

1. if Gearbox_M2J =100 --> matrixJ2M(1,1)=1.5 and matrixM2J(1,1) =1/1.5=0.667
2. if Gearbox_M2J =150 --> matrixJ2M(1,1)=1 and matrixM2J(1,1) =1 However in this case the .ini files of the encoder Consistency test must be modified with an identity matrix.

I suggest the option 1 for all the future robots, so I don't have to change the ini files, but I would like some feedback.

Thanks!

cc @Fabrizio69 @pattacini

[iCubHamburg01] Wrong Value of MotioncontrolVersion in yarprobotinterface

Hello,

Currently, I'm updating our iCub on the newest versions. I assume that everything was installed properly, but there seems to be a general Problem of our robot-configuration files. The installed embObjMotionControll driver seems to expect version 5, but receives version 3. This is a problem we seem to have since last year.

How could I fix this problem?

icub@icub-head:/usr/local/src/robot/old_versions/Nov18/robots-configuration/build$` yarprobotinterface 
||| configuring
||| default config file specified as yarprobotinterface.ini
||| checking [/usr/local/src/robot/old_versions/Nov18/robots-configuration/build/yarprobotinterface.ini] (pwd)
||| checking [/usr/local/src/robot/old_versions/Nov18/iCubContrib/share/ICUBcontrib/robots/iCubHamburg01/yarprobotinterface.ini] (robot)
||| found /usr/local/src/robot/old_versions/Nov18/iCubContrib/share/ICUBcontrib/robots/iCubHamburg01/yarprobotinterface.ini
||| finding file [config]
||| checking [/usr/local/src/robot/old_versions/Nov18/robots-configuration/build/./icub_all.xml] (pwd)
||| checking [/usr/local/src/robot/old_versions/Nov18/iCubContrib/share/ICUBcontrib/robots/iCubHamburg01/./icub_all.xml] (robot)
||| found /usr/local/src/robot/old_versions/Nov18/iCubContrib/share/ICUBcontrib/robots/iCubHamburg01/./icub_all.xml
[DEBUG]Reading file /usr/local/src/robot/old_versions/Nov18/iCubContrib/share/ICUBcontrib/robots/iCubHamburg01/./icub_all.xml 
[DEBUG]yarprobotinterface: using xml parser for DTD v3.x 
[DEBUG]Reading file /usr/local/src/robot/old_versions/Nov18/iCubContrib/share/ICUBcontrib/robots/iCubHamburg01/./icub_all.xml 
[DEBUG]Preprocessor complete in:  0.0150881 s 
||| finding paths [plugins]
||| checking [/usr/local/src/robot/old_versions/Nov18/robots-configuration/build/plugins] (pwd)
||| checking [/usr/local/src/robot/old_versions/Nov18/iCubContrib/share/ICUBcontrib/robots/iCubHamburg01/plugins] (robot)
||| checking [/home/icub/.config/yarp/plugins] (YARP_CONFIG_HOME)
||| checking [/home/icub/.local/share/yarp/plugins] (YARP_DATA_HOME)
||| checking [/etc/yarp/plugins] (YARP_CONFIG_DIRS)
||| checking [/usr/local/src/robot/old_versions/Nov18/yarp/build/share/yarp/plugins] (YARP_DATA_DIRS)
||| found /usr/local/src/robot/old_versions/Nov18/yarp/build/share/yarp/plugins
||| checking [/usr/local/src/robot/old_versions/Nov18/icub-main/build/share/iCub/plugins] (YARP_DATA_DIRS)
||| found /usr/local/src/robot/old_versions/Nov18/icub-main/build/share/iCub/plugins
||| checking [/usr/local/src/robot/old_versions/Nov18/iCubContrib/share/ICUBcontrib/plugins] (YARP_DATA_DIRS)
||| found /usr/local/src/robot/old_versions/Nov18/iCubContrib/share/ICUBcontrib/plugins
||| checking [/usr/local/src/robot/old_versions/Nov18/icub-tests/suits/plugins] (YARP_DATA_DIRS)
yarp: Port /icub/yarprobotinterface active at tcp://10.0.0.2:10002/
[INFO]startup phase starting... 
||| finding paths [plugins]
[DEBUG]eth::parser::print(pc104Data) for PC104: 
[DEBUG]PC104/PC104IpAddress:PC104IpPort =  10.0.1.104:12345 
[DEBUG]PC104/PC104TXrate =  1 
[DEBUG]PC104/PC104RXrate =  5 
[DEBUG]EthSender is a PeriodicThread with txrate = 1 ms 
[DEBUG]EthReceiver is a PeriodicThread with rxrate = 5 ms 
[WARNING]in EthReceiver::config() the config socket has queue size =  2097152 ; you request ETHRECEIVER_BUFFER_SIZE=  
[DEBUG]eth::parser::print(boardData) for BOARD head-eb20-j0_1 
[DEBUG]ETH_BOARD/ETH_BOARD_PROPERTIES: 
[DEBUG]ETH_BOARD/ETH_BOARD_PROPERTIES/IpAddress =  10.0.1.20 
[DEBUG]ETH_BOARD/ETH_BOARD_PROPERTIES/IpPort =  12345 
[DEBUG]ETH_BOARD/ETH_BOARD_PROPERTIES/Type =  mc4plus 
[DEBUG]ETH_BOARD/ETH_BOARD_PROPERTIES/maxSizeRXpacket =  768 
[DEBUG]ETH_BOARD/ETH_BOARD_PROPERTIES/maxSizeROP =  384 
[DEBUG]ETH_BOARD/ETH_BOARD_SETTINGS: 
[DEBUG]ETH_BOARD/ETH_BOARD_SETTINGS/Name =  head-eb20-j0_1 
[DEBUG]ETH_BOARD/ETH_BOARD_SETTINGS/RUNNINGMODE/(period, maxTimeOfRXactivity, maxTimeOfDOactivity, maxTimeOfTXactivity, TXrateOfRegularROPs) =  1000 400 300 300 5 
[DEBUG]ETH_BOARD/ETH_BOARD_ACTIONS/MONITOR_ITS_PRESENCE 
[DEBUG]ETH_BOARD/ETH_BOARD_ACTIONS/MONITOR_ITS_PRESENCE/(enabled, timeout, periodOfMissingReport) =  true 0.02 60 
[DEBUG]eth::EthMonitorPresence::config(): monitoring of presence is ON for BOARD 10.0.1.20 (head-eb20-j0_1) with timeout = 0.02 sec and period of missing report = 60 sec 
[DEBUG]TheEthManager::requestResource2(): has just succesfully created a new EthResource for board of type mc4plus with IP =  10.0.1.20 
[ERROR]embObjMC BOARD head-eb20-j0_1 (IP 10.0.1.20)  ------ ATTENTION!!!! Wrong value of <MotioncontrolVersion> parameter !!!! --------------------------------------------------------------------------------------- 
[ERROR]embObjMC BOARD head-eb20-j0_1 (IP 10.0.1.20)  ------ This means that the configuration files of this device are not compatible with my parser, so I cannot start.  
[ERROR]embObjMC BOARD head-eb20-j0_1 (IP 10.0.1.20)  ------ I need version  5 , but in configuration files have version  3 . 
[ERROR]embObjMC BOARD head-eb20-j0_1 (IP 10.0.1.20)  ------ Please update configuration files in robots-configuration repository. (see http://wiki.icub.org/wiki/Robot_configuration for more information).  
[ERROR]embObjMC BOARD head-eb20-j0_1 (IP 10.0.1.20)  ------ If the problem persists contact [email protected] . 
[ERROR]embObjMC BOARD head-eb20-j0_1 (IP 10.0.1.20)  ---------------------------------------------------------------------------------------------------------------------------------------------------------------- 
[ERROR]BOARD head-eb20-j0_1 (IP 10.0.1.20)  Missing motion control parameters in config file 
yarpdev: ***ERROR*** driver <embObjMotionControl> was found but could not open
[WARNING]Cannot open device head-eb20-j0_1-mc 
[WARNING]Cannot open device head-eb20-j0_1-mc 
[DEBUG]eth::parser::print(boardData) for BOARD head-eb21-j2_5 
[DEBUG]ETH_BOARD/ETH_BOARD_PROPERTIES: 
[DEBUG]ETH_BOARD/ETH_BOARD_PROPERTIES/IpAddress =  10.0.1.21 
[DEBUG]ETH_BOARD/ETH_BOARD_PROPERTIES/IpPort =  12345 
[DEBUG]ETH_BOARD/ETH_BOARD_PROPERTIES/Type =  mc4plus 
[DEBUG]ETH_BOARD/ETH_BOARD_PROPERTIES/maxSizeRXpacket =  768 
[DEBUG]ETH_BOARD/ETH_BOARD_PROPERTIES/maxSizeROP =  384 
[DEBUG]ETH_BOARD/ETH_BOARD_SETTINGS: 
[DEBUG]ETH_BOARD/ETH_BOARD_SETTINGS/Name =  head-eb21-j2_5 
[DEBUG]ETH_BOARD/ETH_BOARD_SETTINGS/RUNNINGMODE/(period, maxTimeOfRXactivity, maxTimeOfDOactivity, maxTimeOfTXactivity, TXrateOfRegularROPs) =  1000 400 300 300 5 
[DEBUG]ETH_BOARD/ETH_BOARD_ACTIONS/MONITOR_ITS_PRESENCE 
[DEBUG]ETH_BOARD/ETH_BOARD_ACTIONS/MONITOR_ITS_PRESENCE/(enabled, timeout, periodOfMissingReport) =  true 0.02 60 
[DEBUG]eth::EthMonitorPresence::config(): monitoring of presence is ON for BOARD 10.0.1.21 (head-eb21-j2_5) with timeout = 0.02 sec and period of missing report = 60 sec 
[DEBUG]TheEthManager::requestResource2(): has just succesfully created a new EthResource for board of type mc4plus with IP =  10.0.1.21 
[ERROR]embObjMC BOARD head-eb21-j2_5 (IP 10.0.1.21)  ------ ATTENTION!!!! Wrong value of <MotioncontrolVersion> parameter !!!! --------------------------------------------------------------------------------------- 
[ERROR]embObjMC BOARD head-eb21-j2_5 (IP 10.0.1.21)  ------ This means that the configuration files of this device are not compatible with my parser, so I cannot start.  
[ERROR]embObjMC BOARD head-eb21-j2_5 (IP 10.0.1.21)  ------ I need version  5 , but in configuration files have version  3 . 
[ERROR]embObjMC BOARD head-eb21-j2_5 (IP 10.0.1.21)  ------ Please update configuration files in robots-configuration repository. (see http://wiki.icub.org/wiki/Robot_configuration for more information).  
[ERROR]embObjMC BOARD head-eb21-j2_5 (IP 10.0.1.21)  ------ If the problem persists contact [email protected] . 
[ERROR]embObjMC BOARD head-eb21-j2_5 (IP 10.0.1.21)  ---------------------------------------------------------------------------------------------------------------------------------------------------------------- 
[ERROR]BOARD head-eb21-j2_5 (IP 10.0.1.21)  Missing motion control parameters in config file 
yarpdev: ***ERROR*** driver <embObjMotionControl> was found but could not open
[WARNING]Cannot open device head-eb21-j2_5-mc 
[WARNING]Cannot open device head-eb21-j2_5-mc 
[INFO]/icub/head : no ROS initialization required 
[INFO]/icub/head  initting YARP initialization 
yarp: Port /icub/head/rpc:i active at tcp://10.0.0.2:10003/
yarp: Port /icub/head/command:i active at tcp://10.0.0.2:10004/
yarp: Port /icub/head/state:o active at tcp://10.0.0.2:10005/
yarp: Port /icub/head/stateExt:o active at tcp://10.0.0.2:10006/
[INFO]created wrapper <controlboardwrapper2>. See C++ class yarp::dev::ControlBoardWrapper2 for documentation.
||| finding paths [plugins]
[INFO]created device <parametricCalibratorEth>. See C++ class yarp::dev::parametricCalibratorEth for documentation.
[WARNING]There was some problem opening one or more devices. Please check the log and your configuration 
[ERROR]One or more devices failed opening... see previous log messages for more info 
[ERROR]Error in startup phase... see previous messages for more info 
[WARNING]Interrupt # 1 # received. 
[INFO]Interrupt received. Stopping all running threads. 
[INFO]interrupt1 phase starting... 
[INFO]Entering action level 1 of phase interrupt1 
[ERROR]park device do not exists 
[ERROR]Cannot run park action on device head-calibartor 
[INFO]All actions for action level 1 of interrupt1 phase started. Waiting for unfinished actions. 
[INFO]All actions for action level 1 of interrupt1 phase finished. 
[WARNING]There was some problem running actions for interrupt1 phase . Please check the log and your configuration 
[INFO]interrupt1 phase finished. 
[ERROR]Error in interrupt1 phase... see previous messages for more info 
[INFO]shutdown phase starting... 
[INFO]Entering action level 5 of phase shutdown 
[ERROR]head-mc_wrapper is not a wrapper, therefore it cannot have detach actions 
[ERROR]Cannot run detach action on device head-mc_wrapper 
[INFO]All actions for action level 5 of shutdown phase started. Waiting for unfinished actions. 
[INFO]All actions for action level 5 of shutdown phase finished. 
[WARNING]There was some problem running actions for shutdown phase . Please check the log and your configuration 
[INFO]shutdown phase finished. 
[ERROR]Error in shutdown phase... see previous messages for more info 
[INFO]RFModule failed to open.
yarp: 
 Warning an issue has been found, please update the code.
     Clock is not initialized: This means YARP framework has not been properly initialized. 
     The clock can be initialized with one of the following methods:
     - Create yarp::os::Network object or call yarp::os::Network::init()
     - Call useSystemClock()
     otherwise use yarp::os::SystemClock::nowSystem() and yarp::os::SystemClock::delaySystem() instead of Time::now() and Time::delay()

Missing files in iCubNancy01

Dear all

we just updated the robot software/firmware on the pc104, and implemented the changes suggested here: robotology/community#143

We installed the new robot configuration files, but we found issues and we cannot proceed.

1. when we launch robotinterface on the pc104, the robotinterface looks for robotInterface.ini but in our folder we have instead yarprobotinterface.ini.
   We renamed the file to proceed temporarily - let us know if you plan to change it also in the robotinterface.

2. even fixing the file, the robotinterface crashed with a fatal error. It is looking for some configuration files that it can't find and it stops. The file generating the fatal error is: torso-ems5-mec.xml that we don't have in our hardware folder. We saw that other robots have it (Genova04, Darmstadt..) and from the logs it seems it is a new file. Could you add it to our robot too?

Thanks in advance

@paraschos @misaki43 @dgoepp

Inconsistencies of joint names

We recently noticed that there are some inconsistencies in the joints names of various robots. These inconsistencies are in ~21 robots out of 50. Some have different names, some have underscores some dashes etc...

Here are some examples:

Head:

eyes_version - > eyes_vers (https://github.com/robotology/robots-configuration/search?q=eyes_vers)
eyes_vergence -> eyes_verg (https://github.com/robotology/robots-configuration/search?q=eyes_verg)

Right Hand:

r_middle_proximal -> r_middle-proximal (https://github.com/robotology/robots-configuration/search?q=r_middle-proximal)
r_middle_distal -> r_middle-distal (https://github.com/robotology/robots-configuration/search?q=r_middle-distal)
r_pinky -> r_little-fingers (https://github.com/robotology/robots-configuration/search?q=r_little-fingers)

This is also valid for the left hand.

We suggest that we modify the joint names using the following standard as reported in the documentation

1. use of full names eg: eyes_version
2. use of underscores r_little_finger

iCubGenova02 branches

For iCubGenova02 currently we have the following branches:

• iCubGenova02-04/fixGyroscopesFullscale
• iCubGenova02_V2-5_plus_soles_speed
• iCubGenova02_V2-5_plus_soles
• iCubGenova02_noRightFTSensor
• iCubGenova02/createConfigInertialsMultipleAnalogSensors

Now that the strain2 FT have been installed probably we can clean up a bit.
Proposed approach:

• DELETE iCubGenova02_noRightFTSensor
• DELETE iCubGenova02/createConfigInertialsMultipleAnalogSensors
• MERGE devel into iCubGenova02_V2-5_plus_soles
• MERGE devel into iCubGenova02_V2-5_plus_soles_speed (help needed by @ale-git)

if possible:

• MERGE iCubGenova02_V2-5_plus_soles_speed into iCubGenova02_V2-5_plus_soles (help needed by @ale-git)
• DELETE iCubGenova02-04/fixGyroscopesFullscale

Once the new soles (15 [deg] offset) have been fully tested, we could merge into devel.

master and devel not aligned

master and devel branches are dangerously not aligned.
@davidetome Please always merge master in devel every time you push a new commit in master.

iCubGenova02 not starting after #178

After #178 was merged, the startup is failing. It is correctly started by moving back to previous commit 1a05e78.

I think the problem is due to the fact that the Firmware of the robot FTs is not updated.
CC @marcoaccame

Here is the output:
log.txt

The following error seems to be repeated for all the boards:

...
[WARNING]  from BOARD 10.0.1.6 (left_leg-eb6-j0_3) @ 81s 520m 402u: CAN discovery has detected a eobrd_strain2 board in CAN2 addr 13 with can protocol ver 2.0 and application ver 2.0.4 Search time was 2 ms
[ERROR] embObjStrain::open() has an error in call of ethResources::serviceVerifyActivate() for BOARD left_leg-eb6-j0_3 IP 10.0.1.6
[INFO] The embObjStrain device using BOARD left_leg-eb6-j0_3  w/ IP 10.0.1.6 has the following service config:
[INFO] - acquisitionrate = 10
[INFO] - useCalibration = true
[INFO] - STRAIN of type strain2 named id_l_upper_leg_strain @ CAN2:13 with required protocol version = (2, 0) and required firmware version = (2, 0, 7)
[ERROR]  from BOARD 10.0.1.6 (left_leg-eb6-j0_3) @ 81s 520m 547u: CAN discovery has detected 1 invalid eobrd_strain2 boards in CAN2:
[ERROR] 1 of 1: wrong eobrd_strain2 BOARD 10.0.1.6:CAN2:13 because it has:  WRONG APPLICATION VERSION 
[ERROR]  from BOARD 10.0.1.6 (left_leg-eb6-j0_3), src LOCAL, adr 0, time 81s 520m 685u: (code 0x05000009, par16 0x010d par64 0x0000000202000200) -> CFG: EOtheSTRAIN cannot be configured. can discovery fails. can address in p16, prot and vers in p64 lower 32 bits. Byte 5 of p64: 0x01 is strain, 0x02 is strain2 + .
[ERROR]  from BOARD 10.0.1.6 (left_leg-eb6-j0_3), src LOCAL, adr 0, time 81s 520m 814u: (code 0x05000009, par16 0x010d par64 0x0000000202000200) -> CFG: EOtheSTRAIN cannot be configured. can discovery fails. can address in p16, prot and vers in p64 lower 32 bits. Byte 5 of p64: 0x01 is strain, 0x02 is strain2 + .
[WARNING]  from BOARD 10.0.1.6 (left_leg-eb6-j0_3) @ 81s 520m 967u: CAN discovery has detected a eobrd_strain2 board in CAN2 addr 13 with can protocol ver 2.0 and application ver 2.0.4 Search time was 2 ms
[ERROR]  from BOARD 10.0.1.6 (left_leg-eb6-j0_3) @ 81s 521m 115u: CAN discovery has detected 1 invalid eobrd_strain2 boards in CAN2:
[ERROR] 1 of 1: wrong eobrd_strain2 BOARD 10.0.1.6:CAN2:13 because it has:  WRONG APPLICATION VERSION 
[WARNING]  from BOARD 10.0.1.6 (left_leg-eb6-j0_3), src LOCAL, adr 0, time 81s 521m 555u: (code 0x0000000b, par16 0x03c7 par64 0x0062003300980020) -> SYS: the RX phase of the control loop has last more than wanted. In par16: RX execution time [usec]. In par64: latest previous execution times of TX, RX, DO, TX [usec] + .
[WARNING]  from BOARD 10.0.1.6 (left_leg-eb6-j0_3), src LOCAL, adr 0, time 81s 522m 305u: (code 0x0000000b, par16 0x01d9 par64 0x002003c702e10225) -> SYS: the RX phase of the control loop has last more than wanted. In par16: RX execution time [usec]. In par64: latest previous execution times of TX, RX, DO, TX [usec] + .
yarpdev: ***ERROR*** driver <embObjStrain> was found but could not open
...

Consider adding all_joints controlboardwrapper and ROS joint_states related quantities as default to robots-configuration

This feature might be highly convenient while running estimation or control algorithms that gathers information from all the control boards.

As in a lot of code that the developer usually needs to run

• to open remote control boards and
• to open a remote control board remapper for the opened remote control boards

can be boiler-plate into the configuration file. In the end, the developer needs to run only an attach to the all_joints controlboardwrapper2 which in its underlying configuration does all the required remapping of the controlboards.

Further access to ROS joint states related quantities, brings in a lot of nice features that ROS-based protocols can offer, for instance, visualization and tf trees to be used conveniently with the regular workflow.

Most Importantly, since several iCubs already have that in their configuration files (see https://github.com/robotology/robots-configuration/search?q=all_joints&type=Code), we should consider making it default for all.

cc @traversaro

Head v3 and v2.5 configuration files have the wrong names

Since f6bba4f , the axis names in the configuration files for the Head v2.5 and v3 are wrong, i.e. do not follow the official joint names for the iCub [1]. In particular they follow the scheme neck-pitch (wrong) instead of neck_pitch (correct).

Example of affected configurations:

• https://github.com/robotology/robots-configuration/search?utf8=%E2%9C%93&q=neck-pitch
• https://github.com/robotology/robots-configuration/search?utf8=%E2%9C%93&q=neck-yaw&type=Code

[1] http://wiki.icub.org/wiki/ICub_joints

cc @valegagge @davidetome @randaz81

Regression on devel branch with INSTALL_ALL_ROBOTS option enabled

2020-02-05T02:08:44.3657211Z -- Exists
2020-02-05T02:08:44.3657583Z CMake Error at /home/runner/work/robotology-superbuild/robotology-superbuild/build/install/share/yarp/cmake/YarpInstallationHelpers.cmake:389 (file):
2020-02-05T02:08:44.3657716Z   file COPY cannot find
2020-02-05T02:08:44.3658072Z   "/home/runner/work/robotology-superbuild/robotology-superbuild/robotology/robots-configuration/iCubErzelli03/cartesian":
2020-02-05T02:08:44.3658195Z   No such file or directory.
2020-02-05T02:08:44.3658298Z Call Stack (most recent call first):
2020-02-05T02:08:44.3658390Z   iCubErzelli03/CMakeLists.txt:9 (yarp_install)
2020-02-05T02:08:44.3658458Z 
2020-02-05T02:08:44.3658506Z 
2020-02-05T02:08:44.3658885Z CMake Error at /home/runner/work/robotology-superbuild/robotology-superbuild/build/install/share/yarp/cmake/YarpInstallationHelpers.cmake:389 (file):
2020-02-05T02:08:44.3659018Z   file COPY cannot find
2020-02-05T02:08:44.3659364Z   "/home/runner/work/robotology-superbuild/robotology-superbuild/robotology/robots-configuration/iCubErzelli03/estimators":
2020-02-05T02:08:44.3659486Z   No such file or directory.
2020-02-05T02:08:44.3659584Z Call Stack (most recent call first):
2020-02-05T02:08:44.3659686Z   iCubErzelli03/CMakeLists.txt:13 (yarp_install)
2020-02-05T02:08:44.3659739Z 
2020-02-05T02:08:44.3659783Z 

Failed robotology-superbuild job: https://github.com/robotology/robotology-superbuild/actions/runs/34879920 .
It would be handy to have a GitHub Actions to check this regression.

iCubOsaka01 missing iKinGazeCtrl conf file

So, YARP_ROBOT_NAME is available, although iKinGazeCtrl gets configured based on its standard options, which are not robot specific. This may lead to incongruences.

I got it. iCubOsaka01 doesn't contain any robot-specific conf file for iKinGazeCtrl.
I consider this a bug. We will fix this soon.

cc @marcoaccame

Originally posted by @pattacini in robotology/community#388 (comment)

Robot with XSens MT IMU in waist still spawn the IMU YARP Hardware Device via inertial instead of separating hardware and Network Wrapper Servers

Before #116 all the head IMUs were not spawned on their own, but they were spawned by launching an inertial YARP device and specifing the YARP Hardware device name via the subdevice parameter. This was fixed in #116, in particular with the commits:

• abb5cad
• b73b48e

This change was never propagate to the waist Xsens IMU that are accessed via the xsensmt YARP hardware device. So, this device is still not expose via MAS (Multiple Anaog Sensor) interfaces.

Updated Black iCub configuration file after fine calibration

This is just a question about the configuration files in robots-configuration/iCubGenova01/hardware/motorControl of iCubGenova01.

Recently @giuliavezzani and I have fine calibrated the Black iCub and were wondering whether we should update such files here as well or not.
The robot head, torso and right arm were quite distant from the Zerosvalues.

Coupling matrices used in iCubGenova04 configuration files

After the recent improvements in the configuration files structure for iCub robots documented in https://github.com/robotology/icub-main/blob/master/src/doc/release/v1_8_0.md#configuration-files , I briefly tried to validate the coupling matrices for the iCub shoulders and torso committed in this repo for iCubGenova04 and contained in these files:

• Left Shoulder:

  robots-configuration/iCubGenova04/hardware/mechanicals/left_arm-eb1-j0_3-mec.xml

  Line 43 in 0ff6cee

  <param name ="matrixJ2M">

• Right Shoulder:

  robots-configuration/iCubGenova04/hardware/mechanicals/right_arm-eb3-j0_3-mec.xml

  Line 44 in 0ff6cee

  <param name ="matrixJ2M">

• Torso :

  robots-configuration/iCubGenova04/hardware/mechanicals/torso-eb5-j0_2-mec.xml

  Line 40 in 0ff6cee

  <param name ="matrixJ2M">

  
  and the coupling matrices documented in http://wiki.icub.org/wiki/ICub_coupled_joints , but I was unable to to do so.

In particular I have several findings/doubts.

Matrix serialization if the AxisMap argument is used

It is not clear the serialization used in the coupling matrix for the boards (like the torso) that have their axis remapped using the AxisMap argument.

Semantics of the matrixJ2M and matrixM2J parameters

It is not clear the meaning of the matrixJ2M (and matrixM2J) parameter, i.e. if it is the matrix mapping joint velocities to motor velocities (motor velocities to joint velocities) or the matrix mapping joint torques to motor torques (motor torques to joint torques).
The point of the code in which this variables are not clear to me enough to infer their meaning:

• https://github.com/robotology/icub-main/blob/2fe40bcad13734ce6800839a0492c5bae99f3cb6/src/libraries/icubmod/embObjMotionControl/embObjMotionControl.cpp#L1033
• https://github.com/robotology/icub-firmware/blob/f5850b0d935e814eab5f1a448a6471b141dfcc5f/emBODY/eBcode/arch-arm/embobj/plus/mc/Controller.c#L463
• https://github.com/robotology/icub-firmware/blob/f5850b0d935e814eab5f1a448a6471b141dfcc5f/emBODY/eBcode/arch-arm/embobj/plus/mc/JointSet.c#L141
• https://github.com/robotology/icub-firmware/blob/f5850b0d935e814eab5f1a448a6471b141dfcc5f/emBODY/eBcode/arch-arm/embobj/plus/mc/JointSet.c#L575
• https://github.com/robotology/icub-firmware/blob/f5850b0d935e814eab5f1a448a6471b141dfcc5f/emBODY/eBcode/arch-arm/embobj/plus/mc/JointSet.c#L597

Coupling matrix actually used in the configuration files

Trying to match the matrix documented in http://wiki.icub.org/wiki/ICub_coupled_joints with the one available in the configuration files, it seems that at least for the shoulder, the matrixM2J is the matrix mapping the motor velocities to the joint velocities. However, it is not clear what is the matrixJ2M, that is not the inverse, neither the transpose nor the inverse transpose of the matrixM2J parameter.

How have been this matrices chosen?

Tagging a few people that could provide precious information:
@valegagge @ale-git @marcoaccame @randaz81 @lornat75 @nunoguedelha @S-Dafarra @DanielePucci @francesco-romano @fiorisi .

Compilation error on devel branch

Setup:

• ubuntu 18.04
• yarp on devel (commit 7f180282a28b250900cae0ae9443aa38b3f152c9)

I tried to compile on devel branch and I get following error:

-- Found YARP: /home/vgaggero/MY_WORKSPACE/ROBOTOLOGY/yarp/build (found version "3.2.102+20191021.3+git7f180282a")
-- Found YARP: /home/vgaggero/MY_WORKSPACE/ROBOTOLOGY/yarp/build (found version "3.2.102+20191021.3+git7f180282a")
CMake Error at CMakeLists.txt:9999 (_yarp_component_path_is_deprecated):
  Unknown CMake command "_yarp_component_path_is_deprecated".
Call Stack (most recent call first):
  CMakeLists.txt:11 (list)


CMake Error: Error in cmake code at
Unknown:0:
A command failed during the invocation of callback "_yarp_component_path_is_deprecated".
-- Configuring incomplete, errors occurred!

Wrong hip_pitch to hip motor coupling in coupling matrices matrixM2J and matrixM2J

After a F2F discussion with @fiorisi about the low level torque control, we realized that the reduction ratio due to the cable transmission between the hip pitch joint and respective motor is not taken in account in the Gearbox ratio (Gearbox_M2J), nor in the coupling matrices (matrixM2J and matrixM2J).

As you can see in robotology/community#256 (comment)...

Further details on the hip_pitch joint

The hip_pitch joint has an additional cable transmission stage after the harmonic drive. The motor side pulley has a diameter of 50 [mm], while the joint side pulley has a diameter of 75 [mm], consequently, the additional reduction ration is: 75/50 =1.5

the reduction ratio due to the hip joint cable is 1.5, so we should get the following values for matrixM2J:

        <param name ="matrixM2J">
            0.667   0.000   0.000   0.000
            0.000   1.000   0.000   0.000
            0.000   0.000   1.000   0.000
            0.000   0.000   0.000   1.000
        </param>

the transformation from motor velocities to joint velocities being defined by:
$$
\dot{q} = T_{m2j} \: G_{m2j} \: \dot{\theta}
$$
where $T_{m2j}$ is the coupling matrix matrixM2J, $G_{m2j}$ the gearbox ratios, $\dot{q}$ and $\dot{\theta}$ respectively the vectors of joint and motor velocities.

Currently, matrixM2J is an identity and the gearbox ratio for the hip pitch is 100. So either we set the gearbox ratio to 150 either we update matrixM2J as shown above.

CC @randaz81 @valegagge @fiorisi @FabioBergonti @vibhoraggarwal @gabrielenava @traversaro @DanielePucci

Updating robot configuration for iCubGrenoble01

Hi,

We are about to update our cluster to debian 8 and replace our icubsrv
by a new laptop (debian 8 or ubuntu ?)

Before, we need to push/modify the old configuration files to the new repo/syntax/structure etc.
Can we get help / remote session to perform this task ?

Thanks in advance,
Frédéric & the Grenoble team

Clarification on syntax issue after commit a1cf818

This morning I tried to run iCubGenova01 after git pulling the latest robots-configuration and I could not run the robot due to the following issue (reporting from the output of yarprobotinterface)

2,278432 <DEBUG> (device virtualAnalogServer) (name "/icub/joint_vsens/left_arm:i") (net_VFT_LA (0 5 0 5)) (networks (net_VFT_LA)) (period 10) (robotName icub) 
 2,278554 <DEBUG> Using VirtualAnalogServer 
 2,278605 <ERROR> Check network parameters in part description. I was expecting net_VFT_LA followed by four integers 
 2,278655 <ERROR> Driver <virtualAnalogServer> was found but could not open 
 2,278716 <WARNING> Cannot open device left_arm_VFTserver 
 2,278753 <WARNING> Cannot open device left_arm_VFTserver 
 2,278783 <DEBUG> (device virtualAnalogServer) (name "/icub/joint_vsens/right_arm:i") (net_VFT_RA (0 5 0 5)) (networks (net_VFT_RA)) (period 10) (robotName icub) 
 2,278827 <DEBUG> Using VirtualAnalogServer 
 2,278864 <ERROR> Check network parameters in part description. I was expecting net_VFT_RA followed by four integers 
 2,278901 <ERROR> Driver <virtualAnalogServer> was found but could not open 
 2,278937 <WARNING> Cannot open device right_arm_VFTserver 
 2,278966 <WARNING> Cannot open device right_arm_VFTserver 
 2,278994 <DEBUG> (device virtualAnalogServer) (name "/icub/joint_vsens/torso:i") (net_VFT_TO (0 5 0 5)) (networks (net_VFT_TO)) (period 10) (robotName icub) 
 2,279033 <DEBUG> Using VirtualAnalogServer 
 2,279067 <ERROR> Check network parameters in part description. I was expecting net_VFT_TO followed by four integers 
 2,279109 <ERROR> Driver <virtualAnalogServer> was found but could not open 
 2,279144 <WARNING> Cannot open device torso_VFTserver 
 2,279173 <WARNING> Cannot open device torso_VFTserver 

After checking I found that the issue, at least on our setup, is coming from a1cf818.

Specifically, it seems that the parentheses surrounding the integers are not recognized by the parser

robots-configuration/iCubGenova01/wrappers/VFT/left_arm_VFT_wrapper.xml

Line 6 in 2bc1ca0

<elem name="net_VFT_LA">( 0 5 0 5 )</elem>

robots-configuration/iCubGenova01/wrappers/VFT/right_arm_VFT_wrapper.xml

Line 6 in 2bc1ca0

<elem name="net_VFT_RA">( 0 5 0 5 )</elem>

robots-configuration/iCubGenova01/wrappers/VFT/torso_VFT_wrapper.xml

Line 6 in 2bc1ca0

<elem name="net_VFT_TO">( 0 5 0 5 )</elem>

I wanted to ask the following: is this change wanted and I need to update YARP and/or icub-main because the parser was changed or is there something else that I am missing?

Thank you!

Nightly merge keeps failing in fork

We forked robots-configuration in our organization (https://github.com/dic-iit/robots-configuration), but the GitHub action "Nightly Merge" (https://github.com/dic-iit/robots-configuration/actions) fails every time.

I thought of modifying or removing this action, but then there would have been a discrepancy between this master branch and the one in my organization, complicating future PRs.

How can I deal with this?

Bad configuration files for the iCubNancy01 robot

Hello @pattacini and others,

I've just added the robot configuration files, but when I launch the robot, I can see there're some mistakes.

When I compare those files with other robots' configurations, I can see that sometimes the robot name is not defined, and other times, certain parameters are not the same (e.g., the canDeviceNum in hardware/skin/torso[...] or kinematicTypeConnect in the cartesian folder).

Can you correct all our robot-configuration files please?

Here is the log.

Thanks!

cc @serena-ivaldi @olivierrochel-inria

iCubLondon01 needs config file update for Head V2

Hi,
As discussed in robotology/community#167 the configuration files of iCubLondon01 need updating, as they do not consider yet that our robot has the V2 head.
I am not sure who's best to assign this to. Any ideas @pattacini?

Thanks,
Tobi

CMake default values to compile software

It would be nice to have a file containing the robot-dependent default values with which to configure cmake on the PC104.

cc @lornat75 @drdanz @barbalberto @randaz81 @mbrunettini

Update joint limits iCub3

After work done on the iCub3 gazebo model, submitted in this PR, we have updated the upper limit for the shoulder roll, from 160 to 163.

This comes after some tests and calibration performed with the real robot, in order to find both the "zero" of the joints and their limits.

I have included these limits in the icub-models-generator PR, but they should be also included in the robots-configuration.

CC @pattacini , @traversaro

all_robots.xml file is not updated

Please remember to add every new robot to the list included in the all_robots.xml file

Document attach/detach levels used for different kind of devices

For people writing new yarprobotinterface files, it would be convenient to document the leves used for attach/detach phases for different types of devices. By inspecting the configuration files, it seems that these leves are:

Type of device	Phase	Action	Level
remapper	startup	attach	5
nws	startup	attach	10
control/estimation	startup	attach	15
control/estimation	shutdown	detach	2
nws	shutdown	detach	15
remapper	shutdown	detach	20

Huge cleanup is upcoming

Hi @robotology/everyone

The robots-configuration repository has been growing wildly in terms of branches. Have a look at the current status to figure it out yourself.

Therefore, in an attempt to tidy it up, we would like to proceed as follows:

• Backup the current status by forking the repo into robotology-legacy org.
• Remove all the branches, except:
  • master
  • devel
  • those branches that are involved in open PR's will be retained and judged singularly.
• Prevent users from creating branches in order to favor forking.
• Define a maintainer who will be responsible for ensuring that the repo will stay clean.

Given that the repo is backed up, we do not expect any data loss.