The section https://icub-tech-iit.github.io/documentation/icub_operating_systems/icubos/bluetooth/#connect-to-the-bcb-board-automatically seems to apply to any icub-head with Bluetooth capabilities, but it actually refers only to iCub 2.5/2.6/2.7 (not iCub 3) that have an actually battery backpack. All other users can safely skip that section.

It is not clear what "skip in case of iCub Server" means in https://icub-tech-iit.github.io/documentation/icub_operating_systems/other-machines/generic-machine/#icub-software-repository-and-common-package.

With @Uboldi80 we were setting up a iCub Server Laptop and we were not sure if we had to skip it.

MKIT004 on WinGST is not compliant with iCub Tech Docs (missing screws):

Feedback appearing from working on this with @Uboldi80 :

• It is not clear if the initial link to robotology-superbuild needs to be followed or not.
• It is not documented anywhere that if on an icub setup, the superbuild needs to be download in /usr/local/src

In https://icub-tech-iit.github.io/documentation/icub_operating_systems/icubos/networking/#netplan, it would be convenient to provide some easy command to copy&paste on how to create the symlink, for :

sudo ln -fs <variant_that_you_actually_want_to_use>.yaml.notload 50-icub.yaml

and to check which variant is actually symlinked:

ls -la 

During the ICRA 2023 demo with ergoCub, one problem that hit us is that we wanted to debug a software problem on the ergocub-head, but it is not clear how the software was installed there. While the software installation on the ergocub-torso basically reflects the one tipically used in icub-head, so documented in:

• https://icub-tech-iit.github.io/documentation/icub_operating_systems/icubos/installation-from-scratch/
• https://icub-tech-iit.github.io/documentation/sw_installation/icub_head_superbuild/

At the moment instead the ergocub-head has some specificies that I am not sure if they are documented anywhere:

• Use of robotology-superbuild compiled against conda-forge dependencies to support ROS humble on Ubuntu 20.04
• Use of GPU-enabled librealsense
• Something else that I may be missing

It would be great to have even a simple documentation on how to setup the system in its intendend state from scratch.

I wanted to work on robotology/robots-configuration#485, but I am missing even a rough guideline related to naming. I will write one draft here, then we can migrate this to proper documentation when it is ready.

iCub YARP network wrapper server conventions

iCub exposes its functionalities (sensors and actuators) via YARP devices called YARP's Network Wrapper Servers (NWSs) that publish information over YARP ports. For historical reasons, for each type of functionality such as "controlboards" (i.e measure of joint-related sensors and capability of setting setpoints of low-level control loops), inertial measurement units, force torque sensors, multiple devices are used, one for each iCub's "part".

The "parts" of iCub are:

• head
• left_arm
• right_arm
• torso
• left_leg
• right_leg

Not all iCubs have all its six parts. There are iCub variants that are composed only by the head, or iCub variants that are composed only by the legs. In some contexts also a special part alljoints is defined and used, that is just a part that actually represents all the differents part of the iCub combined.

In the following, we will list the convention used for each type of functionality.

In the following, we will refer also to the robotPortPrefix, that is a string that can have multiple values:

• icub for physical iCub robots
• icubSim for simulated iCub robots
• ergoCub for physical ergoCub robots
• ergoCubSim for simulated ergoCub robots

ControlBoard

The ControlBoard functionality is exposed via the controlBoard_nws_yarp device. The name parameter passed to this device is: /<robotPortPrefix>/<partName>.

This means that for each part there will be a controlBoard_nws_yarp device that will open the following YARP ports:

• /<robotPortPrefix>/<partName>/state:o : that publishes encoder information for the part
• /<robotPortPrefix>/<partName>/stateExt:o : that publishes different joint-level sensors information for the part, using the structure defined in https://github.com/robotology/yarp/blob/master/src/libYARP_dev/src/idl/stateExt.thrift
• /<robotPortPrefix>/<partName>/rpc:i : that expose several information related to the part via a YARP RPC port
• /<robotPortPrefix>/<partName>/command:i : that takes in input references for the low-level control loops

Note: these YARP ports are not meant to be accessed directly, but should be accessed instead via the remote_controlboard device.

Inertial Measurements Units (IMUs)

Inertial Measurements Units functionalities are exposed via the multipleanalogsensorsserver YARP device.
The name parameter passed to this device is: /<robotPortPrefix>/<partName>/inertials.

This means that for each part there will be a multipleanalogsensorsserver device that will open the following YARP ports:

• /<robotPortPrefix>/<partName>/inertials/measures:o : that publishes sensors information for the part, using the structure defined in https://github.com/robotology/yarp/blob/master/src/devices/multipleAnalogSensorsMsgs/multipleAnalogSensorsSerializations.thrift
• /<robotPortPrefix>/<partName>/inertials/rpc:o : that expose several information related to the part via a YARP RPC port

Note: these YARP ports are not meant to be accessed directly, but should be accessed instead via the multipleanalogsensorsclient device.

This device will expose sensors related to the following Multiple Analog Sensors Interfaces:

• yarp::dev::IOrientationSensors
• yarp::dev::IThreeAxisGyroscopes
• yarp::dev::IThreeAxisLinearAccelerometers
• yarp::dev::IThreeAxisMagnetometers

Force-Torque Sensors

Force-Torque Sensors functionalities are exposed via the multipleanalogsensorsserver YARP device.
The name parameter passed to this device is: /<robotPortPrefix>/<partName>/FT.

This means that for each part there will be a multipleanalogsensorsserver device that will open the following YARP ports:

• /<robotPortPrefix>/<partName>/FT/measures:o : that publishes sensors information for the part, using the structure defined in https://github.com/robotology/yarp/blob/master/src/devices/multipleAnalogSensorsMsgs/multipleAnalogSensorsSerializations.thrift
• /<robotPortPrefix>/<partName>/FT/rpc:o : that expose several information related to the part via a YARP RPC port

Note: these YARP ports are not meant to be accessed directly, but should be accessed instead via the multipleanalogsensorsclient device.

This device will expose sensors related to the following Multiple Analog Sensors Interfaces:

• yarp::dev::ISixAxisForceTorqueSensors
• yarp::dev::ITemperatureSensors

Now that we go with the robotology-superbuild, we should align sections like the following accordingly:
https://github.com/icub-tech-iit/documentation/blob/master/docs/icub_operating_systems/other-machines/icub-server-laptop.md#software-repositories.

It's no longer necessary to clone locally those repos on an individual basis. We should thus replace that text with pointers to the the superbuild.

It would be helpful to have the Jetson Xavier boards used in iCub robot in https://icub-tech-iit.github.io/documentation/icub_cpu_boards/icub_cpu_boards/ (related to robotology/robotology-superbuild#481 (comment)).

I hope this 2021 is off to a good start for the iCub Techs. I just wanted to raise the issue that there may be broken links in the iCub wiki. For example:

• the (F/T sensors page)[http://wiki.icub.org/wiki/FT_sensor] points the user to https://icub-tech-iit.github.io/documentation/icub_firmware/ft-sensors/ft-sensors/ which is a badly formatted page with no clear way to get to the correct link (which should be (this one)[https://icub-tech-iit.github.io/documentation/ft-sensors/ft-sensors/])
• One other thing I recommend doing is to have this link https://icub-tech-iit.github.io point to the homepage of your documentation (i.e. this one https://icub-tech-iit.github.io/documentation/ ). As of now, the link above displays just a generic jekyll template and it is very hard to get to the right link unless you know it.
• Finally, some good SEO would be nice. Right now, it's basically impossible to find this new documentation website if you are not aware of it. There is a handy jekyll-seo package that is supported by github and should make the job easy!

I hope this helps. I am tagging @julijenv just because 😎

I think that old iCub users (see robotology/icub-tech-support#1129) are used to canLoader, and they should just switch to the new FirmwareUpdater. However, the documentation is a bit not clear w.r.t. to the canLoader, as there is still a first level link to canLoader in the main firmware page (see https://icub-tech-iit.github.io/documentation/icub_firmware/) and also in the firmware https://icub-tech-iit.github.io/documentation/icub_firmware/firmware/firmware/ . Furthermore, there is a full page of docs in https://icub-tech-iit.github.io/documentation/icub_firmware/canLoader/canLoader/, that starts with a small warning message "Canloader is deprecated since this PR" . However, this may be misleading, as the CanLoader tool was not just deprecated in that PR (approximately one year ago), but it was completely removed.

To avoid confusion, could it make sense to just delete the old canLoader docs? If we need any info from it, we can always recovere it from the git history or the wiki history.

problem:
the rebase operation takes ages. more than 20 minutes

#icub-tech/documentation (gh-pages)
$ git rebase master 

hence, i did tests to use lfs for images + video

however, the gh-pages do not show the lfs files (images and videos)
it is reasonable because in github there are pointers and not the real files

see: git-lfs/git-lfs#3498

The title for the page https://icub-tech-iit.github.io/documentation/configure_static_ip/configure-static-ip/
can be very misleading, please specify better that this case applies ONLY to EMS communication

The section https://icub-tech-iit.github.io/documentation/icub_operating_systems/icubos/user-env/#how-to-setup-the-enviroment-properly could be made more readable by first mentiong what it needs to be done, and only after providing an explanation on why it is done.

See robotology/icub-models-generator#202 (comment).

cc @traversaro

After an internal discussion during our board meeting, we decided to revert PR #328.

This is because the convention for the CSYS is limited to the alignment of their axes wrt a resting position of the robot, but doesn't include the directions of rotation. In practical terms, this means that the same joint angles guarantee a specular symmetry between the arms.

Reverting #328 is as simple as clicking a button, although we may need to carry out a careful review.

cc @Lawproto @Nicogene @fiorisi @traversaro

Today with @Iaxama we used the icub_operating_systems and we had a few doubts. I would be happy to go on and open a PR fixing this aspects, but I am afraid I am not sure about some information on this, as mentioned in the following.

"real" icub server

The iCub server section mentions two options, one is the "real" iCub server, while another is the "laptop used as the iCub server" .
From the context, it is not clear what is the meaning of the "real" iCub server. I guess it is meant for when the iCub server is installed not on a laptop?

iCubOS Ubuntu versions

I was not able to understand on which version of Ubuntu the iCubOS is based. From https://icub-tech-iit.github.io/documentation/icub_operating_systems/ it seems that iCubOS is used to refer to the OS image meant to be running on the icub-head machine that is the COMExpress board that is placed on the iCub head, and from https://icub-tech-iit.github.io/documentation/icub_operating_systems/icubos/icubos/ it seems that it is based on Ubuntu 18.04 .
But then in https://icub-tech-iit.github.io/documentation/icub_operating_systems/other-machines/icub-server-from-image/ it seems that the iCubOS image is also used for the iCub server, and from https://icub-tech-iit.github.io/documentation/icub_operating_systems/other-machines/icub-server-from-scratch/ it seems that this image should be based on Ubuntu 20.04.
I guess I am missing something, but I am not sure what.

Follow-up of:

• robotology/icub-firmware-models#82 (review)

As reported by @violadelbono and @Uboldi80, after the merge of #100, the bluetooth instructions here are not clear and can be improved.

Action points are:

1. @S-Dafarra organizes and hands-on session with @mbrunettini @davidelasagna @violadelbono and @Uboldi80.
2. (after collecting feedbacks) @S-Dafarra is to improve the guide.
3. @mbrunettini is to review the resulting PR before merging.

In the last days, both @Uboldi80 (robotology/ycm-cmake-modules#392) and @HosameldinMohamed reported this error when compiling the robotology-superbuild on a brand new iCubOS:

CMake Error at CMakeLists.txt:33 (find_package):
  Could not find a configuration file for package "YCM" that is compatible
  with requested version "0.13.0".

  The following configuration files were considered but not accepted:

    /usr/share/cmake/YCM/YCMConfig.cmake, version: 0.12.2

The problem is that YARP finds an old YCM installed in the system, and so it does not proceed as it requires YCM 0.13 (that would be downloaded by the superbuild if a YCM was not found in the system).
The solution is to just sudo apt update and sudo apt upgrade that updates YCM to 0.13 .

However, as this problem already affected two users in a few days, probably we should specify that sudo apt update and sudo apt upgrade is necessary, either after the iCubOS from image installation, or before the software installation?

It'd be nice to move How to set up the iCub workstation from scratch here and check whether there might be overlapping with already existing resources.

That documentation needs to be revised anyhow as we now rely on the superbuild and on a new standard setup (e.g. pc104 is now icub-head).

Finally, the original wiki page should be removed.

SiftGPU link in https://icub-tech-iit.github.io/documentation/icub_operating_systems/other-machines/cuda-workstation/#install-siftgpu-library-and-its-dependancies is broken. Not sure if that dependency is still needed or not. @xEnVrE do you know anything about this?

I observed that the details for a few of the joints in iCub 3 joints specs, in particular Motor type and Harmonic drive, are not up to date with the latest CAD model. I believe the documentation has not been updated after some of the latest upgrades on iCub 3.

I noticed mainly the following inconsistencies:

• Joint 12, 18 - left, right foot roll: Motor type should be updated from MOOG_C2900575 to MOOG_C2900576 and Harmonic drive should be updated from CSD-17-160-2A to CSD-17-100-2A.
• Joint 7, 13 - left, right hip pitch: Harmonic drive should be updated from CSD-20-100-2UH to CSD-25-100-2UH.
• Upperbody Joints specs: For all of the upperbody joints, namely yaw, shoulder_pitch, shoulder_roll, upperarm_yaw and elbow, the details on Harmonic drive are missing.

How shall we proceed in order to update the iCub 3 joints specs documentation ??
cc @fiorisi @pattacini

⚠️ We changed the original scope of this issue as per #184 (comment).

The documentation on iCub arm kinematics report slighly different values for the "1.7" arm, see https://icub-tech-iit.github.io/documentation/icub_kinematics/icub-forward-kinematics/icub-forward-kinematics-arms/ . However, in https://icub-tech-iit.github.io/documentation/icub_versions/ there is no documentation for iCub 1.7 .

The documentation in https://github.com/icub-tech-iit/documentation/blob/master/docs/icub_operating_systems/other-machines/generic-machine.md#static-ip-configuration refers to the /etc/network/interfaces file, that from what I understand (@Iaxama @2103simon) it is not supported anymore on Ubuntu 20.04 . Probably we should modify that section to be Ubuntu 20.04 .

Related issue: robotology/robotology-superbuild#481 .

After the changes decided here robotology/icub-firmware#476 (comment) in order to satisfy this request https://github.com/icub-tech-iit/tickets/issues/3343,

we need to update the documentation accordingly.

Dod

Documentation updated

We can publish this piece of info in https://icub-tech-iit.github.io/documentation/hands/.

cc @traversaro @fiorisi

Hi all,

I am trying to implement the coupling laws available in https://icub-tech-iit.github.io/documentation/hands/hands_mk5_coupling/ to make some tests (more details in robotology/gazebo-yarp-plugins#647).

Specifically, I would be interested in evaluating the expression of $q2$ as a function of the angle $q1$. That expression depends on $h(q_1)$ that in turn depends on $P_1(q_1)$. Both the $x$ and $y$ coordinates of $P_1$ depends on additional constants, $P_{0x}$ and $P_{0y}$ that I cannot find in the table comprising all parameters.

Are they missing or should I evaluate them using other available quantities given the geometry?

Thank you

cc @ale-git @mfussi66

With @lrapetti @mebbaid and @traversaro and I noticed that the variable exported in .bashrc_ergoCub were loaded twice when a new terminal is opened.

Upon further investigation, it was discovered that the following code:

  if [ "$HOME" != "" ]; then                                                                                                                                                                               
      ICUBRC_FILE="${HOME}/.bashrc_ergoCub"                                                                                                                                                                
  else                                                                                                                                                                                                     
      ICUBRC_FILE="/home/icub/.bashrc_ergoCub"                                                                                                                                                             
  fi                                                                                                                                                                                                       
  if [ -f "$ICUBRC_FILE" ]; then                                                                                                                                                                           
      source $ICUBRC_FILE                                                                                                                                                                                  
  fi  

was placed above the following block of code in .bashrc:

# If not running interactively, don't do anything                                                    
case $- in                                                                                           
    *i*) ;;                                                                                          
      *) return;;                                                                                    
esac 

so when the gui session was loading the bash it was exporting all the environment variables in .bashrc_ergoCub

To fix this we modified the .bashrc adding the following lines at the beginning of the file

if [[ $- == *i* ]] || [[ -n "$SSH_CLIENT" ]] || [[ -n "$SSH_TTY" ]]; then                                                                                                                                  
  #Load the ergoCub custom bashrc                                                                                                                                                                          
  if [ "$HOME" != "" ]; then                                                                                                                                                                               
      ICUBRC_FILE="${HOME}/.bashrc_ergoCub"                                                                                                                                                                
  else                                                                                                                                                                                                     
      ICUBRC_FILE="/home/icub/.bashrc_ergoCub"                                                                                                                                                             
  fi                                                                                                                                                                                                       
  if [ -f "$ICUBRC_FILE" ]; then                                                                                                                                                                           
      source $ICUBRC_FILE                                                                                                                                                                                  
  fi                                                                                                                                                                                                       
fi   

In this code snippet, [[ $- == *i* ]] checks if the $- variable contains the i character, which indicates an interactive shell. [[ -n "$SSH_CLIENT" ]] checks if the SSH_CLIENT environment variable is non-empty, which indicates an SSH session. Similarly, [[ -n "$SSH_TTY" ]] checks if the SSH_TTY environment variable is non-empty, which also indicates an SSH session.

If either of these conditions is true, the code inside the if block is executed. You can replace the echo command with the command you want to run.

To ensure others do not encounter this issue, we should update the documentation on how to set up a robot PC.

I am opening this issue to discuss possible missing information about the iCub PC104 live image in a scenario where we use the robotology-superbuild (but not necessarily limited to this actually).

1. CMake version

The latest robotology-superbuild requires CMake 3.16. If I am not wrong the latest PC104 image is based on Debian Buster (10) that has, by default, CMake 3.13.4. According to the robotology-superbuild documentation it is possible to update on the latest by enabling buster-backports.

My question is, then, should this step be done by the user after installing the PC104 image on the robot? Is it the case that we add something about in the documentation such that the scenario in which the user uses the superbuild is covered? Another solution, but I don't know if is feasible, would be to pre-configure the PC104 image such that backports are enabled.

2. diagnostic daemon

The superbuild, but I think this is independent from the superbuild itself, enables build of the diagnostic daemon library when the profile ROBOTOLOGY_ENABLE_ICUB_HEAD is enabled. As stated in the repository of the library, it requires libboost-system-dev. However, as per the documentation, the PC104 live image does not include this package by default.

My question is similar in this case. Should we add something in the documentation to cover this or is it the case to ship the live image pre-configured with that package?

Thank you

cc @pattacini @traversaro @mbrunettini

The Upperam Covers UKIT documentation lacks the required information about the missing sub-kits (ele and wiring), which have been already added into our management system.

cc @Elio75 @Fabrizio69 @salvi-mattia @MrAndrea

Given the output of this poll https://github.com/orgs/robotology/discussions/612 we decided to deprecate the deb packages in favour of conda ones.
We have to update the official documentation accordingly.

cc @traversaro @pattacini

The .bashrc_iCub of the icub-live image (used on pc104 systems) assumes that the build directory of the robotology superbuild on the pc104 is /usr/local/src/robot/robotology-superbuild/build-pc104, see https://github.com/icub-tech-iit/icub-os-files/blob/5084e7466524ffb8d9198fc67c72bc35b53095a4/scripts/icub-live/live-build/config/includes.chroot/etc/skel/.bashrc_iCub#L20 , as the /usr/local/src/robot/robotology-superbuild directory is tipically (or always? I am not sure on this) shared between the icub laptops and the pc104, different from system base on COM-Express boards that use the iCubOS image.

However, it seems that there is no documentation on the fact that the on pc104 the robotology-superbuild should be compiled in the build-pc104 directory. A possible solution is to add the pc104 to the system covered by the "Installation on specific systems on iCub setup" section of the documentation (see

The section to review is https://icub-tech-iit.github.io/documentation/icub_operating_systems/icubos/user-env/#required-configuration.

@traversaro

On my laptop, the rotating iCub GIFs in the main menu affects the readability of the menu:

I would personally remove it, but perhaps there is a specific reason for which the GIF was placed there.

@marcoaccame

In the 'Write the image" section in https://icub-tech-iit.github.io/documentation/icub_operating_systems/icubos/installation-from-image/#write-the-image, a few steps are missing that could confused not experience users of clonezilla (like me : ) ).

Personally, I was stopped at the last documented step, i.e. :

select the correct drive and partition for the USB drive (as in step 8) (usually partition is n.1)

I arrived at this form:

As the selected directory was the correct one, I simply pressed Enter, but this resulted in the error "The directory you choose is a Clonezilla dir"

If I typed enter again, I would be brought back to the original form, in a sort of endless loop. The way of exiting for this loop is not to press enter (that will automatically select the "Browse" option in the form), but you need to use the arrow keys to reach the "Done" option and select that one.

After that, you will see many forms, but selecting the default one is ok, except for the "select mode" one:

In Select Mode, the default option is savedisk, but the correct option to select in this case is restoredisk, that needs to be selected with arrow keys. After selecting that, continuing with the default options for the rest of the forms is fine.

In several points of the software infrastructure, joint are identified with strings, for example the joint r_shoulder_roll for iCub3 in:

• https://github.com/robotology/robots-configuration/blob/v1.21.0/iCubGenova09/hardware/mechanicals/left_arm-eb1-j0_1-mec.xml#L9
• https://github.com/robotology/icub-models-generator/blob/v1.21.1/simmechanics/data/icub3/ICUB_3_joint_all_parameters.csv#L6

However, the documentation in https://icub-tech-iit.github.io/documentation/icub3/icub3-joints/ does not report this identifier for the joints, creating confusion as the mapping between is not clear.

While debugging the iCubNancy01, I noticed that in our documentation it is not documented anywhere the fact that a single machine in the system should be designated to host the yarpserver, and all the other machines should be configured, first aligning the yarp namespace, and then setting the server address via yarp detect --write or yarp conf ip socketport. Not sure if this should be added.

Several information on how to read the low-level and high-level data from the skin sensors in iCub 2.x robots is available in the Tactile sensors (aka Skin) page from the "old" iCub wiki.

A section with these information is missing in the iCub Tech Docs website, at least I could not find it. It could probably contain an extract of what is written in the old wiki, not sure if all the information there is still up to date.

As regards iCub 3, I think the same information would also apply to the hand palm and fingertips of that robot.

Notes from discussion with @davidelasagna and @Uboldi80 :

• srv identified both a machine without yarp (when icub is delivered with rack) and laptop machine with yarp and yarpmotorgui (when icub is delivered only with laptop)

Probably it would be worth to clarify naming.

I needed to connect my laptop to the motor setup in DIC area and I discovered that we do not have public and official documentation on how to do it. In particular, I discovered that I had to set a static IP address and a certain subnet mask to the network interface to be able to communicate with the EMS board. This information is not anywhere and future users could experience problems in setting up the correct configuration.
cc @traversaro

If I search "iCub tendons" on Google, I get a link to some rather old and broken wiki pages:

• http://wiki.icub.org/wiki/Tendons_and_replacement
• http://wiki.icub.org/wiki/Assembly_instructions

Probably it could make sense to remove those old pages and just substitute them with links to https://icub-tech-iit.github.io/documentation/icub_tendons/ ?

cc @pattacini @julijenv @violadelbono

Task Description

The code to identify the global assembly (UKIT) to execute the upgrade is missing.

Definition of Done

• The documentation contains the upgrade identification code
• Each part (MKIT, EKIT, etc) that constitutes the UKIT is described and correctly identified
• The scope of the upgrade is clearly specified (for which platform)

I am working in order to fix robotology/gazebo-yarp-plugins#647, and at some point I need to use the expression

$$ \frac{\partial{q2}}{\partial{q1}} $$

provided in https://icub-tech-iit.github.io/documentation/hands/hands_mk5_coupling/#coupling-laws

I tried plotting the provided law and an alternative version obtained using finite differentiation on the positional law $q2(q1)$.

They look similar in terms of shape but they are different. Could it be that the law is incorrect? Is there any internal documentation where this law has been used / tested ?

Thank you

While updating a COMEXPRESS CONGATEC-based system (iCubGenova09, see https://icub-tech-iit.github.io/documentation/icub_cpu_boards/icub_cpu_boards/) to iCubOS 8.0 based on Ubuntu 20.04, we experienced that the icub-head was not starting and instead an error:

Missing operating system

was just printed on the screen after the BIOS.

@davidelasagna found that the problem was that the non-UEFI variant of the disk partition was put before in the BIOS Boot Sequence with respect to the UEFI one, and this caused the problem. Re-ordering the boot sequence in the BIOS to have the UEFI disk before solved the problem.

While we solved the specific problem on iCubGenova09, if this problem happens to a iCub user outside IIT, it could be quite tricky to debug and solve for an iCub user. For this reason, it could make sense to document this somewhere, for example as part of some troubleshooting section of the documentation.

On 2021/12/17, the iCubGenova04 icub-head was updated, following the docs in https://github.com/icub-tech-iit/documentation/blob/0db3f48fe41a71dfcedf93d989cc32e71f390d1e/docs/icub_operating_systems/icubos/installation-from-image.md . This is a list of issue/small annoyances experienced:

• From https://icub-tech-iit.github.io/documentation/icub_operating_systems/download/#download-table, it is not clear which version of iCub needs iCubOS.
• Among the required material, a DisplayPort cable was not listed (it is kind of implied from the monitor)
• It is not clear how to access the BIOS

Today, while reviewing the newly opened PR icub-tech-iit/ergocub-software#169, I had the chance to compare the documented parameters of the coupling law for the MK5 .1 hand and a table that can be found in https://github.com/icub-tech-iit/ergocub-design-lowerarm/issues/157#issuecomment-1674984233.

It seems that there are discrepancies for the following paremeters.

Note: green and yellow highlighed text is just coming from the screenshot of the "table" indicated above. I am not highlighting anything.

Moreover please take into account that for each "table" entry the order of numbers is "thumb", "index" and "pinky" (as index == middle == ring) while each "documentation" entry report all the 5 parameters in the order "thumb", "index", "middle", "ring", "pinky".

Parameter $q_{0off}$

table

documentation

Parameter $k$

table

documentation

Parameter $d$

table

documentation

Parameter $l$

table

documentation

Parameter $b$

table

documentation

Parameter $s$

table

documentation

Parameter $t$

table

documentation

Parameter $f$

table

documentation

Paramter $r$

table

documentation

cc @pattacini

Follow-up on robotology/icub-main#758 (comment).