iCub YARP Update Problem

[baskinburak]

Hello,

We are two interns working on iCubAnkara01.

We are trying to update iCubAnkara01 in order to use YARP/ROS bridge. We set up a new icub-laptop. We moved yarp 2.3.66 source code to our nfs shared folder in new icub-laptop and compiled it in pc104. Currently "yarp version" returns 2.3.66. We copied iCub folders from old laptop to the new one. When we run icub-cluster.py in new icub laptop and iCubInterface in pc104, everything seems to be working fine.

We have written a simple test code (using a tutorial) which moves the left arm of our robot. We compiled and run it in a computer connected to the network. But, there is an error complaining about controlBoardWrapper. When we compile the code in the old icub laptop which has yarp 2.3.6svn1, the code works fine.

Can you assist us?

Here is the error message we got:

yarp: Port /test/client2/rpc:o active at tcp://10.0.0.3:10065
yarp: Port /test/client2/command:o active at tcp://10.0.0.3:10066
yarp: Port /test/client2/state:i active at tcp://10.0.0.3:10067
yarp: Port /test/client2/stateExt:i active at tcp://10.0.0.3:10068
yarp: Sending output from /test/client2/rpc:o to /icub/left_arm/rpc:i using tcp
yarp: Sending output from /test/client2/command:o to /icub/left_arm/command:i using udp
yarp: Receiving input from /icub/left_arm/state:o to /test/client2/state:i using udp
[ERROR]*** Extended port /icub/left_arm/stateExt:o was not found on the controlBoardWrapper I'm connecting to. Falling back to compatibility behaviour
[WARNING]Updating to newer yarp and the usage of controlBoardWrapper2 is suggested***
[ERROR]expecting protocol 1 5 1, but remotecontrolboard returned protocol version 0 0 0
[ERROR] please update YARP or the remotecontrolboard implementation
[ERROR]checkProtocolVersion failed
yarp: Removing output from /test/client2/rpc:o to /icub/left_arm/rpc:i
yarp: Removing output from /test/client2/command:o to /icub/left_arm/command:i
yarp: Removing input from /icub/left_arm/state:o to /test/client2/state:i
yarpdev: ***ERROR*** driver <remote_controlboard> was found but could not open
robotDevice2 not available.  Here are the known devices:
Device "test_grabber", C++ class yarp::dev::TestFrameGrabber, wrapped by "grabber"
Device "test_motor", C++ class yarp::dev::TestMotor, wrapped by "controlboard"
Device "remote_grabber", C++ class yarp::dev::RemoteFrameGrabber, wrapped by "grabber"
Device "grabber", C++ class yarp::dev::ServerFrameGrabber, is a network wrapper.
Device "sound_grabber", C++ class yarp::dev::ServerSoundGrabber, is a network wrapper.
Device "pipe", C++ class yarp::dev::DevicePipe, has no network wrapper
Device "group", C++ class yarp::dev::DeviceGroup, has no network wrapper
Device "remote_controlboard", C++ class yarp::dev::RemoteControlBoard, wrapped by "controlboardwrapper2"
Device "inertial", C++ class yarp::dev::ServerInertial, is a network wrapper.
Device "controlboardwrapper2", C++ class yarp::dev::ControlBoardWrapper2, is a network wrapper.
Device "batteryClient", C++ class batteryClient, has no network wrapper
Device "Rangefinder2DClient", C++ class Rangefinder2DClient, has no network wrapper
Device "analogsensorclient", C++ class AnalogSensorClient, has no network wrapper
Device "analogServer", C++ class yarp::dev::AnalogWrapper, is a network wrapper.
Device "virtualAnalogServer", C++ class yarp::dev::VirtualAnalogWrapper, is a network wrapper.
Device "batteryWrapper", C++ class yarp::dev::BatteryWrapper, is a network wrapper.
Device "Rangefinder2DWrapper", C++ class yarp::dev::Rangefinder2Dwrapper, is a network wrapper.
Device "clientcontrolboard", C++ class yarp::dev::ClientControlBoard, wrapped by "controlboard"
Device "controlboard", C++ class yarp::dev::ServerControlBoard, is a network wrapper.
Device "cartesiancontrollerclient", available on request (found in /usr/lib/iCub/cartesiancontrollerclient.so library), is a network wrapper.
Device "cartesiancontrollerserver", available on request (found in /usr/lib/iCub/cartesiancontrollerserver.so library), wrapped by "cartesiancontrollerclient".
Device "fakecan", available on request (found in /usr/lib/iCub/fcan.so library).
Device "gazecontrollerclient", available on request (found in /usr/lib/iCub/gazecontrollerclient.so library), is a network wrapper.
Device "skinprototype", available on request (found in /usr/lib/iCub/skinprototype.so library), wrapped by "skinWrapper".
Device "socketcan", available on request (found in /usr/lib/iCub/socketcan.so library).
Device "static_grabber", available on request (found in /usr/lib/iCub/static_grabber.so library), wrapped by "grabber".
Device "xsensmtx", available on request (found in /usr/lib/iCub/xsensmtx.so library).

[traversaro]

Hi @baskinburak ,
as you can read on icub-main release notes for release 1.1.17 [1] :

iCubInterface executable has been removed from the repo. Robot users that are still using the old configuration files (.ini format) should contact icub-support@icub.iit.it and ask for an update of their configuration files to the new format (.xml). The executable to be used to launch the robot is named yarprobotinterface.

The problem is that if you update everything (YARP & ICUB) then you don't compile a new iCubInterface, and so you are using the really old iCubInterface binary remained on your setup. You should get in contact with @robotology/icub-support-team to get your robot configuration files to be update to use the latest version of YARP & ICUB software, that uses the yarprobotinterface to launch the robot.

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

[julijenv]

Hi @baskinburak ,
unfortunately, the 2 unique people able to upgrade your files are in holiday, ASA they will be back they will do it. This task has already been assign to them.

[erolsahin]

Hi @julijenv and @traversaro ,

Sorry for pushing you guys on this, but can you let us know when they are planned to be back? We have a project deadline coming up, and need to do some planning. If needed, I can get in touch with Giorgio to let him know our urgency and give this task priority..

Thanks,

Erol

Assoc. Professor and Marie Curie IOF Fellow,
KOVAN Research Lab.
Dept. of Computer Engineering
Middle East Technical University,
Inonu Bulvari, 06531, Ankara, Turkey
http://kovan.ceng.metu.edu.tr/~erol
E-mail: erol@ceng.metu.edu.tr
Tel: (Office) +90-312-210 5539
Tel: (Lab*) +90-312-210 7372
Fax: +90-312-210 5544

[randaz81]

Dear @erolsahin,
I discussed your case you the maintenance unit. Your case is slightly complex because this is a major update and all the configuration files of your robot need to be re-written from scratch by hand. In fact, your robot is currently using the .ini format files which has been deprecated more than one year ago. We thus need time (~1 week) to prepare the new files (in .xml format). After this, we will able to proceed with the firmware upgrade of the robot (and probably the OS in the usb key). I discussed the maintenance schedule with the unit manager, @Fabrizio69. We can start preparing the configuration files around September 26th. Therefore, you'll be probably able to run your robot fully updated in the first week of October. Is this schedule ok for you?

[erolsahin]

Dear @randaz81,
Thanks for clarfying. I didn't realize that we would need such a big update. The deadline for our project is Oct 10, and it seems we cannot afford to wait. We had implemented much of our stuff on the simulator in a mixed ROS/yarp setting, and we were hoping to demonstrate them on the robot. Therefore, we will try to port what we have done to the older version in a limited setting, and get the results. Once the deadline is out of the way, we will contact you asap and schedule the full update..

Erol

[randaz81]

Dear @erolsahin,
The configuration files of your robot have been pushed to the repo (*) and are now ready to be tested. Please tell me when you are ready to schedule a remote session for your robot update @julijenv
Cheers,
MarcoR

(*) robot configuration files are not stored anymore in the icub-main repo, all the robots have been moved to the new repo robots-configuration. robotology/community#143.

[erolsahin]

Thanks a lot @randaz81 ,

[cc: @baskinburak ]
We have a deadline on October 10th and are working with the old version to get some demos out. We hope to proceed with the update by the middle of the next week and will schedule a remote session to handle the upgrade.. Thanks a lot..

Erol

[baskinburak]

Hello,

Can we schedule a remote session at 19th of October 15:00 (utc +3) or 21st of October 14:00 (utc +3) for our icub update?

cc: @erolsahin

[baskinburak]

Hello,

I think you were busy.

Can we schedule a remote session at 26th of October 15:00 (utc +3) or 28th of October 14:00 (utc +3) for our icub update?

[randaz81]

26 is ok for me. @julijenv is ok for you too?

[julijenv]

ok for me just come and fetch me @randaz81 . thx in advance

[julijenv]

Hi @baskinburak ,
our skype ID is : icub.support
just ring us and we will kick off.

[baskinburak]

Hello,

We have updated icub, yarp and the firmware. After update process head, torso and arms of the robot worked properly. But fingers of robot did not work. With the fellow in icub-support, we theorized that the problem was with configuration files. He said that he will ask the person who has written the configuration files to check it. Just to remind you, can you check the configuration files of iCubAnkara01 to make sure they are correct?

Our head, neck and arms are V1.
we have skin sensors in palm and fingertips.

[randaz81]

Hi, I just pushed an updated version of your files in robots-configuration repository.
Can you give it a try?

PS: Since it's the first time that you run the hands calibration, keep the red fault button close to you for extra safety.

[julijenv]

Hi @baskinburak ,
Any news?

[baskinburak]

Hello,

We tried the new configuration. Right hand fingers seems to be working properly. But, I think there is a problem with left hand fingers. In calibration left hand thumb stucks in bended form. Also, in yarpmotorgui, l_thumb_distal, l_index_distal, l_middle_distal and l_pinky joints are yellow.

Here is the calibration video: https://www.youtube.com/watch?v=jm-YRYigUF4
Here is the screenshot of left arm in yarpmotorgui: http://i.hizliresim.com/GPERB7.jpg
Here is the screenshot of right arm in yarpmotorgui: http://i.hizliresim.com/2ny1Ev.jpg

In addition, since we were not going to use legs; we just omitted them with icub-support. In calibration phase, if legs are enabled, they hit each other. Therefore, we commented them in xml file that is provided to yarprobotinterface. Can you check them as well? New people that will work with iCub after us may want to use them.

Thanks a lot :)

[randaz81]

I just updated left hand calib file. Can you tell me if left thumb is now ok?
Regarding the legs, instead, I was not able to find any configuration issue. Can you send me a picture of the problem? Probably we'll need to connect remotely to your robot and check it @julijenv @davidetome

[baskinburak]

Hello,

Have you pushed it into robots-configuration repo? Last commit was pushed 6 days ago: https://github.com/robotology/robots-configuration/commits/master/iCubAnkara01

Regarding to legs, they hit each other in the beginning of the calibration. Therefore, we hit the red button. Here is the video(you need sound to hear the moment of hit): https://www.youtube.com/watch?v=b4JN3Anmc6Y

By the way, we are editing the icub_all.xmls calibrator files by hand to make it work. They are given as head-calib.xml, torso-calib.xmletc. But there are no such files. The calibration files arehead_calib.xml torso_calib.xml` etc.

[randaz81]

for the hands: sorry, yesterday I committed but if forgot to push. now is ok.

[randaz81]

filenames fixed.
legs (hopefully) fixed.

[baskinburak]

okay, they are fixed. thank you very much.

I think the update of our iCub is over. Thanks a lot for your help :)

I think we can close this issue.