Update iCub with pc104, midterm solution

[julijenv]

Dear iCubTeam,
we are currently updating our iCub (iCubOsaka01 - which will become iCubTokyo01 in the near future).
As we are updating both the server side (new desktop PC that will work as laptop server for the settings) and we may have to do a lot of changes as you can imagine and as we also want to be able to still boot up the old desktop PC to continue still showcasing our robot demos in the meanwhile of the update, I'm currently asking for advice on how being able to do that without falling into some problem with the USBkey that is mounting from the server?
My idea was to create a new USBkey to start completing the association in between new desktop-new USBkey to finally got done the update and whenever we have demos, swap back the old USBKeys (the current one we are using now) and the old desktop PC.
Can you confirm that it is the best way to go? Is there any drawbacks? Will I run into trouble or will it be a flawless swap?
let me know,
best,
Julien J.

[kt10aan]

Hey @julijenv. I am sure the iCub team will reply with a more accurate answer, but regarding the old desktop with demos that I have some knowledge of:

• In the past I was successfully using two USB sticks and two servers to maintain the ability for new demos, to experiment with new YARP features and to test compatibility of old demos with new YARP/iCub versions. Usually the second server (running YARP/iCub HEAD) would be my own laptop. Actually, in most cases, one USB was enough, but as YARP/iCub software and some things were deprecated, I started using two USB sticks.
• Some of the old demos require small changes in the source code of YARP/iCub software before compiling (one example that I can think of immediately is in the iKin module). Since the old desktop server PC must be falling apart by now, I would suggest to clone its disk just for making sure you can run the demos in the future. The same with the USB stick.
• Also, the old demos require quite a few config changes here and there in the iCub but also in some of the modules config files. (.e.g, the red ball demo was using a green ball...) You can find these changes by using diff against the config files of the iCub and the modules from the main branch.
• Also, some demos used YARP modules that have been removed from the main YARP distributions and have moved to the legacy YARP repository.

[kt10aan]

I forgot one more thing. The eye-tracking/blinking demo, if you still use it, is using a custom compiled specific version of opencv with CUDA support and also specific version of dlib (all these in the desktop server machine. If you want to avoid having to update the code of the old demos, you still have to use the old server system (or disk image at least).

[julijenv]

Hi @kt10aan ,
good to hear from you and thank you for your insights about the specificities of the demos themselves it will be of great help later in the way of my update.
I guess the first point of your first comment beholds the real answer to my question but I would like to ask you as I am not 100% sure of your explanation what it implies and therefore consequences of my update:

• Were the 2 servers aligned softwarely, Firmwarely, OSly and most importantly uptodate?

From what I can understand you probably created an image of the server desktop PC and run it onto your laptop (meaning perfect alignment in SW, FW and OS) and later probably try to update icub and yarp and it is where the changes and problems start to arise. But Still, it looks like you did not have to flash new FW on boards though. Could you give me more insights about that please?

In my case, my idea is to start with a new Ubuntu 20.04 system as suggested by the iCub wikipage and update everything possible to run the old demos in a brand new environment. So I already think that I should even open a brand.

So my question was more about it is safe, as long as I don't make any changes internally to the robot (FW honestly, that the only things I think will need to be update or at least that what I think, please let me know if something else) to swap the USBkey until I get to a point where unfortunately I will have to face the update of the internal board of icub?

thanks for your ideas,
best,
Julien

[pattacini]

Hi @julijenv

Managing the SW upgrade by switching back and forth between two pairs of PC104_LIVE_USB + ICUB_DEDICATED_SERVER is doable and safe, as @kt10aan also reported 👍🏻

To produce the second pair, please refer to https://icub-tech-iit.github.io/documentation/icub_operating_systems/pc104/icub-live/ and stick to Debian 10 (Buster), which is the last version we support for the live USB.

I've checked it out with @traversaro and the ROBOTOLOGY_SUPERBUILD still builds up with Debian Buster 👍🏻

Regarding the FW running on the iCub, ideally, one should jot down the version of the binaries currently flashed on the boards to be able then to bring the system back to its previous state, as upgrading the SW entails, generally, an upgrade of the FW too.

Nonetheless, we verified with @marcoaccame that your robot sports boards whose FW binaries haven't been upgraded for years. Therefore, you may not even need to change the FW.

(iCubOsaka01 - which will become iCubTokyo01 in the near future).

Done via robotology/robots-configuration#474.

[julijenv]

Dear @pattacini ,
I was kind of worried about the FW on controlling boards to be updated in order to cope with the new calibration /config files to boot the robot BUT now that I read your lines I am a little bit more hopeful, I will give it a go, and let you know.
thx.

[kt10aan]

@julijenv, no, I did not created an image of the server disk and USB stick and upgraded the second set. I used a clean YARP/iCub install on the 2nd laptop and a clean YARP/iCub install on a second USB stick. As @pattacini said, thankfully the firmware changes during that period did not affect any functionality, so I was not worried about FW compatibility.

If you want to update the code of the old demos though, be warned! It can be as simple as changing some YARP methods or it can be some insane change in some dependent library (e.g. Qt). Also, as you have already noticed, some of the demos from the past were written with no regards to proper directory trees or YARP good programming practices (in short, they are a huge mess :) ) and its better to just run them on the old USB/image of the old server disk. But in any case, text me at Skype with any future question about the demos.

[pattacini]

Hi @julijenv, please consider marking one of these posts as the answer.

[EliseiFrederic]

Can we assume that the "no anticipated firmware problem" would also apply to iCubGrenoble01, with its specific talking head (and atom processor in the PC104), since we were redirected here from robotology/icub-tech-support#1532 ?

[pattacini]

cc @marcoaccame @sgiraz

[pattacini]

Hi @EliseiFrederic

Checking this with @marcoaccame, it turned out that you can proceed without updating the FW.
In any case, we're here to give you support.