robotology / robots-configuration Goto Github PK
View Code? Open in Web Editor NEWContains robots configuration files
License: GNU General Public License v2.0
Contains robots configuration files
License: GNU General Public License v2.0
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 ?
Please remember to add every new robot to the list included in the all_robots.xml
file
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 .
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
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 matrixM2J
,
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
It would be nice to have a file containing the robot-dependent default values with which to configure cmake on the PC104
.
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.
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.
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
Complete list of robots that need a fix:
iCubGenova02
https://github.com/robotology/robots-configuration/blob/master/iCubGenova02/calibrators/head-calib.xmliCubGenova06
https://github.com/robotology/robots-configuration/blob/master/iCubGenova06/calibrators/head-calib.xmliCubNancy01
https://github.com/robotology/robots-configuration/blob/master/iCubNancy01/calibrators/head-calib.xmliCubTwente01
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
See (for example, there are others):
The official ordering (from http://wiki.icub.org/wiki/ICub_joints#Head_2.0) should be "eyes_version" "eyes_vergence".
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.
master and devel branches are dangerously not aligned.
@davidetome Please always merge master in devel every time you push a new commit in master.
Historically, the robots-configuration has been used to host two kind of 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.
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
...
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
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
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.
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.
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.
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
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.
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?
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:
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.
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:
In the mechanicals xml file of each robot I believe we need to do some corrections:
Gearbox_M2J
=100 --> matrixJ2M(1,1)
=1.5 and matrixM2J(1,1)
=1/1.5=0.667Gearbox_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!
Setup:
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!
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:
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.
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.
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
@valegagge pointed out that we should update the manual containing the robots configuration information and the templates
cc @marcoaccame
So,
YARP_ROBOT_NAME
is available, althoughiKinGazeCtrl
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)
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
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.
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
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
For iCubGenova02 currently we have the following branches:
Now that the strain2 FT have been installed probably we can clean up a bit.
Proposed approach:
if possible:
Once the new soles (15 [deg] offset) have been fully tested, we could merge into devel.
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 Zeros
values.
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
Right now, this does not affect the position control loop, but it may be an issue for other types of controllers.
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?
Thanks!
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 |
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
eg: eyes_version
r_little_finger
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
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
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!
We should add a gh for the continuous integration
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:
robotology-legacy
org.master
devel
Given that the repo is backed up, we do not expect any data loss.
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.
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:
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:
In particular I have several findings/doubts.
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.
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:
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 .
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
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()
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
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)
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
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.