iCub "cloning"

[kt10aan]

We want to replicate a demo we have running on our iCub (let's call it iCub01) on another iCub elsewhere (say iCub02).

The thing is, iCub02 and its cluster are not updated for a significant amount of time (~2 years), and since our demo is using very recent modules from icub-main and yarp, it won't work directly on iCub02.

For various reasons, (mostly time) the option of fully upgrading iCub02 right now is not an ideal option. Thus, we have thought to go with the following cloning procedure.

Cloning procedure

1. Clone the USB stick from iCub01 (and changing YARP_ROBOT_NAME to iCub02). Changing the name to iCub02 will allow the config and calibration files from iCub02 to be used.
2. Setup a laptop as icubsrv, with fully updated yarp/icub software, with robot name iCub02. On this laptop, the iCub02 config files will also be updated to include the AxisType, AxisName etc new parameters.
3. Put the cloned usb stick to iCub02.
4. Connect the laptop (and assuming the network configuration is fine on the icubsrv and the cloned usb stick).
5. Upgrade the firmware.
6. Run the demo.

Questions

1. Will the above procedure work or does something additional need to be done?
2. Is the order correct, especially regarding the firmware upgrade?
3. Is it safe?
4. Is there an even simpler way to achieve the "cloning"?

Both iCubs have the same hardware version.

cc @lschilli

[pattacini]

Hi @kt10aan

Focusing on PC104, what would the net result be in terms of saved time with respect to a clean solution entailing a full upgrade from scratch? In the end, you have to make sure that the robot will start with fresh software and up-to-date config files.

The rest of your plan regarding the cluster should be doable and somewhat risk free 😏.

[lschilli]

Two additional points: The demo will only control the iCub head. Time saving will also include saving testing time, because network config / software versions have already been tested on one iCub including all config files / patches etc. Of course in the end there has to be at least one test.

[kt10aan]

@pattacini, the net result in time saving will be positive. As @lschilli pointed above, it will be mostly testing time that will be saved. There is also the issue of which side (iCub01 or iCub02) performs the updates/upgrades. As we will be visiting iCub02, we don't want, in relatively short notice, to make them perform a full upgrade of their platform.

With the cloning solution the robot will start with fresh software and up-to-date config files (residing in the icubsrv laptop, in ~/.local/share/yarp/robots/iCub02).

[pattacini]

What is still unclear to me is how you did test the iCub02 config files without having that specific robot at your disposal yet. You said it has a ~2 years old configuration, so I imagine you somehow updated those files, or did anyone from the Facility do that?

I understand you're trying to spare them the burden of upgrading the system, which is a crucial task. However, my point is that the most time consuming stage in upgrading a robot is to test its new configuration and I think this must be still done. Is that right? I don't see how you could skip this critical check. Having iCub01 as a template, because it shares the same HW version of iCub02, does not mean that much in the end, since some of the values written in the config files (e.g. the zeros) are completely different.

Therefore, once you'll have to go through this step, why don't you choose to neatly upgrade that PC104 straightaway? Consider also that if you flash a new FW, then you cannot simply unplug your usb stick and leave iCub02 as it would be.

Let me put in CC also @randaz81 @maggia80 @julijenv and @robotology/icub-support-team to collect more viewpoints on this.

[kt10aan]

@pattacini, the config files from iCub02 have been updated in the last batch of mass config updates, by @randaz81. The commit was robotology/icub-main@dba955a. So I assume that these config files are safe. The only things missing (as was the case for quite a few robots) are the AxisType, AxisName and motorPwmLimit parameters, which have the same values for the CAN robots.

Also, we will start the iCub02 with only the torso and head enabled. The only modules running (from icub-main) will be robotInterface, the two dragonfly2 cameras, two camCalib and a positionDirectControl controlling only 3 of the head`s joints. Our demo module is not opening any device, just using the output from the above modules.

I know that if we flash the new FW they will have to update their cluster afterwards to use the robot, but that is not the issue. The issue is for them to not have to update their cluster within the next 7 days, but at a later time at their convenience.

[pattacini]

If this is the context, that should be ok then, and I don't see any potential pitfall at the moment in your cloning procedure, although you may want to wait for others' advises before proceeding.

[barbalberto]

I'm taking this QA to espress a general rule of thumb, do not take it personally.
The best way to have a robot working is to keep it constantly updated.

A 2 years update in one step is inherently risky.

Some piece of code your demo rely on, may be completely removed or changed in the meantime.

As we will be visiting iCub02, we don't want, in relatively short notice, to make them perform a full upgrade of their platform.

The point is they should not be in this such a situation. I know I'm rude and they have a lot of good reasons for this, but laziness is always going to backfire sooner or later.

Personally, I don't see any advantage in the solution you propose with respect to just updating the set-up you already have. Once the firmware is updated, you can't come back and your cluster will be unusable until they get updated as well.

Coming to your question:

1. Will the above procedure work or does something additional need to be done? Update server/cluster SW + pc104 image and its repos + firmware is all you need to update. Feel free to use a laptop if you think it is easier.
2. Is the order correct, especially regarding the firmware upgrade? Yes, the update of the firmware has to be done after your repo containing the binaries have been updated.
3. Is it safe? No.
4. Is there an even simpler way to achieve the "cloning"? Imho just update everything you have.

[kt10aan]

@barbalberto, I do agree that the preferred method for the iCub would be to be continuously updated.

And while a 2 year delay in updating the robot is tooo long and makes things inherently risky, many labs operate differently than IIT: For a start, there may be gaps with people leaving and gaps between new projects, when new people are coming. Quite often labs are without an "iCub person" for months or more at a time. There is also the issue that when the iCub is used for long experiments, people prefer to not touch the setup, to ensure everything is working.

I personally try to keep the iCub updated with maximum a 2 month-delay. However, that adds quite a bit of extra work for me, so I understand some labs that are not updating so often.

Having said that, the demo to be run is not an old one, it has been developed and tested with new versions of yarp/icub-main.

The advantage in the solution I was proposing is that I can setup the machines at my lab, and take them with me on the trip (this why I said that I will use a laptop). In essence having a portable icub-cluster plus usb stick. It's all about easing the other lab's workload :)

In that case, and given the parameters of use I described in the previous post, I think it would be quite safe. Except the occasional teething problems of course :) Well, only one way to find out I suppose!

By the way, your post reminded me of something I had proposed quite sometime ago, regarding posting of incompatibilies of newer version of the software. I will open an new Discussion issue for that :)

[pattacini]

@kt10aan report here the outcome of your experiments, so we could in turn tell you

• either "hey, we told you not to do that"
• or "well done and thumb up for your smart bravery"

😏

[randaz81]

Looking at the procedure, I think that you'll also need to run ccmake .. in $ICUB_DIR on the pc104, in order to regenerate the $ICUB_DIR/share/iCub/robots/<robot name> folder, which is the default path searched by robotInterface for the robot configuration files.

[kt10aan]

After going through all the pain of the "cloning procedure", I had a closer look at the config files of iCub02, which is iCubBielefeld0x and I realized that despite the fact that they were included in the recent mass update of files, their structure is the old one for iCubInterface.

• I will assume that the old format config files do not work with robotInterface (or yarprobotinterface
• What is the safest way to convert the old config files to the new format? Well, is there a safe way (apart from waiting the iCub Facility people to update them)?
• Why are there 3 Bielefeld iCubs when there is only one robot?
  After setting up so many things and packing so much equipment to transport, this is a big letdown. I am hoping that there is a way to convert the config files myself :(

P.S. Only the head and the torso need to be functional. Also, no cartesian controllers etc.

cc @lschilli

[lschilli]

We will use iCubBielefeld03. Ok, there was some misunderstanding about the config file state, which is old ini: https://github.com/robotology/icub-main/tree/master/app/robots/iCubBielefeld03/conf
Anyway the plan remains the same. However, we will use the OsakaConfig files as template and try to run only the head and torso after adaption the the Bielefeld iCub.

[pattacini]

Closing for now. Feel free to contribute further on this.