Extend SkinDynLib

[alecive]

Currently, there is no standard high-level API for the skin on the iCub. What I'm referring to, is a set of classes that ease and standardize the process of handling single taxels / skin parts / file management. To this end, I would like to collect feedback about a proposal of extending the skinDynLib library with some tools I implemented in https://github.com/alecive/periPersonalSpace and might be useful for other users.

This is the basic structure with some of the features:

CLASS 1 : Taxel - the basic element

Basic Members

Member	Description
Pos	taxel position as read from calib file
Nrm	taxel normal direction as read from calib file
FoR	Frame of Reference: 4x4 matrix with Pos as translational component; z-axis coincident with Nrm; x-axis and y-axis are chosen arbitrarily on the plane normal to Nrm

Optional Members

They are present in my library but I can keep them there and remove them from icub-main (I would keep them, though).

Member	Description
WRFpos	3D taxel position in the Root Rereference frame
WRFFoR	Same as FoR, but in the Root Reference Frame
px	2D taxel position in the image plane of one of the eyes

Methods

Various constructors, toString(), print(), copy operator, etc), but no method to assign the aforementioned members (see below).

CLASS 2 : skinPart

It is a collection of taxels (it is way too similar to the SkinPart enum (cf. http://wiki.icub.org/brain/namespaceiCub_1_1skinDynLib.html#ad9eb09d94574e8020c27676ca5e9bdfc ) already used in the library, but I don't know how to call it better [any help?]).

Basic Members

Member	Description
SkinPart name	name of the skinpart (yes, it is the enum): something like SKIN_RIGHT_HAND
string filename	the name of the file from which the skinPart has been created
vector<Taxel*> txls	List of taxels that belong to the skinPart.

Optional Members

They are used in order to remap the taxels to the center of the triangle they belong to. We used it to reduce an unnecessary high computation (for our [mine and @matejhof 's] tasks).

Member	Description
vector<int> Taxel2Repr	Indexing variable used in the case of reducing the resolution - e.g. taking only triangle centers. The index into the vector is the taxel ID, the value stored is its representative (i.e. the ID of the taxel in the center of the triangle)
map<unsigned int, list<unsigned int> > Repr2TaxelList	Mapping in the opposite direction. Indexed by representative taxel IDs, it stores lists of the taxels being represented - e.g. all taxels of a triangle

Methods

Various constructors, toString(), print(), copy operator, etc

Useful methods

• Construction able to build the skinPart up from the standard skinGui txt files
• Loading and saving to ini file (it is different from the standard skinGui txt files because it contains more information)
• Automatic conversion from local to Root Reference frame (for this one we have to discuss the function syntax)

Issues

1. Is it ok to call class 2 skinPart? Does anybody have a better name?
2. Do I add only the basic functionalities (e.g. only Pos and Nrm for the Taxel class) or can I add also all of the fancy functionalities I developed over the time for my own purposes (such as, e.g., the mapping between single taxels and the triangle they belong, and so on)?

I have the code already done in my repository (i.e. https://github.com/alecive/periPersonalSpace ), so it is only a matter of porting it to icub-main. I'll wait a few days for feedback on issue 1 and 2 and I'll start coding on my own (feel free to interrupt me whenever you would like to).

[traversaro]

👍 .
An initial comment:

• Just a matter of taste: I would go in general for more verbose (and thus readable) method/attribute names (for example Nrm --> Normal) but if it is for preserving backward compatibility, I understand.

[alecive]

@traversaro there is no previous standard, so I think we can safely move Nrm and Pos to Normal and Position :)

[alecive]

Update: the skinPart class will have two modalities:

• "full" in which each taxel will be read as it is (e.g. the leftForearm will have 276 taxels)
• "mapping" in which each taxel is remapped to the center of the patch it belongs to, thus reducing the number of taxels by a factor of 12 (e.g. the leftForearm will have 23 taxels). It is useful for reducing complexity and in case of heavy computational tasks.

Problem is : now the member that handles this is called "modality", which is not great. Any suggestions? I'm not happy with "full" and "mapping" either.

[pattacini]

"modality" ➡️ "spatial_sampling"?

Then, something like:

• "mapping" ➡️ "downsampled"

[pattacini]

..or even "full" becomes "1:1" and "mapping" becomes "12:1"

[traversaro]

Mh... I missed the modalities part. In mapping/downsampled mode, the size of the txls element will be reduced?

[alecive]

Let me summarize it (with the new names, let us assume the right hand as taken from skinGui/positions/left_hand_V2_1.txt ):

• if spatial_mapping == "1:1"
  • skinPart.size = 192 (i.e. the actual number of taxels available - useful to handle compatibility with the skinGui that expects a fixed number of double to be fed with)
  • taxels.size = 48 (i.e. only the taxels that have a Position and Normal in the txt file, their ID field keeps the information about their position in the list)
• if spatial_mapping == "12:1"
  • skinPart.size = 192 (same as before)
  • taxels.size = 5 (i.e. what we call the "representative" taxels)

As you can imagine, especially in the case of the hands (that have no physical triangles in them -> we cannot group them by simply doing a 12:1 mapping), this mapping is hardcoded, since there is no way for us to reliably perform this task generically.

[traversaro]

The mapping is hardcoded with respect to what? The SkinPart enum?
Consider that while hardcoding (over loading configuration files) is clearly more efficient in the short term, it can be an issue when we will need to support multiple robots with different skin configurations (i.e. CER robot).

[alecive]

Sorry, I didn't make the point: the hardcoding is made in order to associate each taxel to its respective center (ie in the 12:1 case), for many reasons:

• for the hands we don't have an actual 12:1 grouping, and so we hardcoded them by explicitly deciding which taxel was supposed to be the center of which set of taxels (documentation available, but not online yet - there should be something in my thesis). For example, these are the IDs of the centers of the right hand and left hand respectively:
  • LEFT_HAND 99 101 109 122 134
  • RIGHT_HAND 101 103 118 137 124
• the forearms seem to follow an usable rule up to a certain point. Until the 15th patch, the central taxel is the 3rd one (e.g. for the 15th patch the central taxel has ID=12*14+3=183), but then the rule changes: e.g. the 16th patch has a jump of 24 instead of 12 (thus its ID is 207), the 17th patch has a jump of 48 (ID 255), the 18th jumps by 36 (ID 291) and so on. It is mainly due to the fact the under the soft fabric there are some places without patches I think (but for that @matejhof has better grip since he made the hard work on this).

[pattacini]

Two comments:

1. "12:1" should be "1:12" in the end (remember bburago 1:18?)
2. If "1:12" is not that generic we should come up with a different notation.

I'd propose then the following:

• parameter's name: "spatial_sampling";
• parameter's options: "taxel" / "patch".

[alecive]

Now, whilst we can think about a streamlined convention and overcome this issue, I'd rather keep this approach and try to handle the existing convention the best that we can. Hence, here comes the hardcoding. I hope that other body parts will not be that difficult, but I don't have any idea whatsoever.

[alecive]

@pattacini your option names are becoming better and better! I don't know if to stick with the latest one or wait for another great idea from your side (not kidding 👍 )

[pattacini]

😃 I think I won't be more creative than that.

[traversaro]

@alecive

That was my point: hardcoding this kind of information will be not maintainable in the long term, and even in the short term it would lead to rather complicate code. A possible alternative (but feel free to reject it, given that you are the one actually doing the work 😄 ) is to have a new file for encoding this "patch" center information. For the sake of KISS, it can be simply a txt format similar to the one already used for encoding position and normals. but encoding which taxel is the "patch center" taxel.

For example, this could come together with https://github.com/robotology/icub-main/blob/master/app/skinGui/conf/positions/left_arm_mesh.txt in the simple form of a file in this format:

3
3
3
3
3
3
3
3
3
3
3
3
15
15
15
15
15
15
15
15
15
15
15
15
27
.
.
.

[alecive]

I got you covered: I have already this kind of format in my code in the form of an ini file (see one of them here, it is the Mapping field: https://github.com/alecive/periPersonalSpace/blob/master/app/conf/taxels1D_learned.ini ). I also have the loading and saving functions. Problem is that this is still hardcoded , and putting it into a file does not mean that we don't have to hard code it :D
Further, the problem is how we interface with the already available files. I would not increase the number of files in the skinGui folder, but I'd rather add this information to the same file(s).
Something like:

[general]
(puthere some more info if needed)
spatial_sampling    taxel
mapping (3 3 3 3 3 3 3 3 3 3 3 3 15 15 15 15 15 15 15 15 15 15 15 15 27 27 27 27 27 27 27 27 27 27 27 27 39 39 39 39 39 39 39 39 39 39 39 39 51 51 51 51 51 51 51 51 51 51 51 51 63 63 63 63 63 63 63 63 63 63 63 63 75 75 75 75 75 75 75 75 75 75 75 75 87 87 87 87 87 87 87 87 87 87 87 87 99 99 99 99 99 99 99 99 99 99 99 99 111 111 111 111 111 111 111 111 111 111 111 111 123 123 123 123 123 123 123 123 123 123 123 123 135 135 135 135 135 135 135 135 135 135 135 135 147 147 147 147 147 147 147 147 147 147 147 147 159 159 159 159 159 159 159 159 159 159 159 159 171 171 171 171 171 171 171 171 171 171 171 171 183 183 183 183 183 183 183 183 183 183 183 183 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 207 207 207 207 207 207 207 207 207 207 207 207 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 255 255 255 255 255 255 255 255 255 255 255 255 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 291 291 291 291 291 291 291 291 291 291 291 291 303 303 303 303 303 303 303 303 303 303 303 303 315 315 315 315 315 315 315 315 315 315 315 315 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 339 339 339 339 339 339 339 339 339 339 339 339 351 351 351 351 351 351 351 351 351 351 351 351 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1)
[calibration]
-0.031 -0.075  0.008 -0.976  0.065  0.146
-0.031 -0.079  0.005 -0.739  0.078  0.105
-0.031 -0.075  0.004 -0.600  0.054  0.068
...
-0.030 -0.071  0.010 -0.979  0.135  0.098
-0.030 -0.086  0.014 -0.975  0.068  0.185
-0.031 -0.084  0.010 -0.994  0.052  0.097
-0.030 -0.083  0.013 -0.974  0.064  0.176
-0.030 -0.081  0.018 -0.953  0.090  0.245

This would have the downside of changing the skinManager (not a big deal), but we don't know how much this would affect other sw.

[traversaro]

Perfect! You call it "hardcoding", but I call it "writing model information in a file", that clearly generalizes much better then source code hardcoding, because adding/modifying taxel is just a matter of modifying configuration files. : )

A solution that has less the tast of "hardcoding" would be to introduce in the structure the concept of "patch" that has a center taxel, then the file would map each taxel to its patch.. but I guess it is better to KISS.

I like the idea of improving the skin structure configuration file... the only problem is that I don't know if the format you are proposing is a valid .ini file.

[alecive]

The "valid .ini file" issue can be sorted out (e.g. by putting the ID of the taxel as a key, and the subsequent double(s) as the value of the key:

[calibration]
1    (-0.031 -0.075  0.008 -0.976  0.065  0.146)
2    (-0.031 -0.079  0.005 -0.739  0.078  0.105)
3    (-0.031 -0.075  0.004 -0.600  0.054  0.068)
...

My main concern was about the fact that probably this might affect some other code that reads from that file. Honestly, I don't think that there is any sw apart from the SkinManager, but who knows. Any comment @pattacini @lornat75 ?

[pattacini]

@alecive as far as you're about to introduce new keys/options in the file, I'd expect there won't be any impact on the existing code.

[alecive]

@pattacini there will be because the configuration file will move from a non-standard txt file like this one:

-0.031 -0.075  0.008 -0.976  0.065  0.146
-0.031 -0.079  0.005 -0.739  0.078  0.105
-0.031 -0.075  0.004 -0.600  0.054  0.068
...
-0.030 -0.071  0.010 -0.979  0.135  0.098
-0.030 -0.086  0.014 -0.975  0.068  0.185

to a standard ini file like this one:

name              skin_left_forearm
spatial_sampling    taxel
mapping        (3 3 3 3 3 3 3 3 3 3 3 3 15 15 15 15 15 15 15 15 15 15 15 15 27 27 27 27 27 27 27 27 27 27 27 27 39 39 39 39 39 39 39 39 39 39 39 39 51 51 51 51 51 51 51 51 51 51 51 51 63 63 63 63 63 63 63 63 63 63 63 63 75 75 75 75 75 75 75 75 75 75 75 75 87 87 87 87 87 87 87 87 87 87 87 87 99 99 99 99 99 99 99 99 99 99 99 99 111 111 111 111 111 111 111 111 111 111 111 111 123 123 123 123 123 123 123 123 123 123 123 123 135 135 135 135 135 135 135 135 135 135 135 135 147 147 147 147 147 147 147 147 147 147 147 147 159 159 159 159 159 159 159 159 159 159 159 159 171 171 171 171 171 171 171 171 171 171 171 171 183 183 183 183 183 183 183 183 183 183 183 183 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 207 207 207 207 207 207 207 207 207 207 207 207 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 255 255 255 255 255 255 255 255 255 255 255 255 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 291 291 291 291 291 291 291 291 291 291 291 291 303 303 303 303 303 303 303 303 303 303 303 303 315 315 315 315 315 315 315 315 315 315 315 315 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 339 339 339 339 339 339 339 339 339 339 339 339 351 351 351 351 351 351 351 351 351 351 351 351 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1)
[calibration]
-0.031 -0.075  0.008 -0.976  0.065  0.146
-0.031 -0.079  0.005 -0.739  0.078  0.105
...
-0.030 -0.071  0.010 -0.979  0.135  0.098
-0.030 -0.086  0.014 -0.975  0.068  0.185

Anyhow, it is a change for the better, hence I would be more than pleased to do that :)

[pattacini]

We could consider that as an improvement of the implementation, thus fine with me.

[alecive]

Update 1

• This file is a valid ini file (so I will stick to this convention):

name              skin_left_forearm
spatial_sampling  taxel
taxel2Patch       (3 3 3 3 3 3 ... -1 -1)
[calibration]
-0.031 -0.075  0.004 -0.600  0.054  0.068
...
-0.030 -0.071  0.010 -0.979  0.135  0.098
-0.030 -0.086  0.014 -0.975  0.068  0.185

• I created a new class called iCubSkin that simply has a std::vector<skinPart> skin. I made this in order for the skin to be populated with the same interface used for the skinmanager, i.e. a --from SkinGui --context skinManForearms.ini (or whatever). This class will take care of the rest.
• I changed the mapping field to taxel2Patch that I think makes more sense.

[alecive]

Update 2

Now the files in https://github.com/robotology/icub-main/tree/master/app/skinGui/conf/positions are txt files. Yarp can seamlessly work with them with no problem at all, but they do not comply with the standard .ini suffix we usually append to configuration files.
Two solutions:

• keep them as they are -> this would not be standard but it would keep the previous convention as well as let us overwrite the old files in the build/install directory, thus having no obsolete files in it
• change them to .ini -> this would create new files in the build/install directories, and might create inconsistencies because the old txt files will stil be there - unless we remove them via CMake

I will go with the first one, please tell me if you have anything against it.

[alecive]

Update 3

In agreement with @traversaro , we decided to modify the array called SkinParts_s and available in https://github.com/robotology/icub-main/blob/master/src/libraries/skinDynLib/include/iCub/skinDynLib/common.h to what described in #124 (the Link Name field) and #57 . By doing so, we explicitly relate a skinPart to its link, and we remove redundancies throughout the codebase.
So, I moved from this:

const std::string SkinPart_s[] = {
    "unknown_skin_part", 
    "skin_left_hand", "skin_left_forearm", "skin_left_upper_arm", 
    "skin_right_hand", "skin_right_forearm", "skin_right_upper_arm", 
    "skin_front_torso", "skin_left_leg_upper",  "skin_left_leg_lower", "skin_left_foot",
    "skin_right_leg_upper",  "skin_right_leg_lower", "skin_right_foot",
    "all_skin_parts", "skin_part_size"
};

to this:

const std::string SkinPart_s[] = {
    "unknown", 
    "l_hand", "l_forearm", "l_upper_arm", 
    "r_hand", "r_forearm", "r_upper_arm", 
    "chest",
    "l_upper_leg", "l_lower_leg", "l_foot",
    "r_upper_leg", "r_lower_leg", "r_foot",
    "all_skin_parts", "skin_part_size"
};

[pattacini]

Any impact on the user code?
For instance the touch classification se employ in funny-things?

[alecive]

@pattacini

1. I controlled the awareTouch module in wysiwyd repo before commenting and committing 😛 , and it does not seem to use it (it rather uses the bodyPart instead) - I might be wrong, though
2. My modules are using the enum currently
3. SkinManager uses it only for visualization and printouts
4. I don't know any other module that explicitly uses it

[pattacini]

Good guy :)
Risky though, but if it's necessary...

[lornat75]

I just skimmed through this discussion; I may have misunderstood some parts so take these purely as comments.

In general these seem good improvements. Concerns:

• You use the name 'patch' to refer to a grouping that corresponds to triangles; we usually call 'patch' a set of triangles that are interconnected (it could be a part or a subpart).
• I am unsure about the 'downsampling', what is the reason for it? I am skeptical about introducing a source of API variability unless really needed.
• Andrea used enum bc they could be used as integral indexes. How is this going to change? Will these id become strings?

[alecive]

Question 1

I used patch to refer to the triangular patches the skin is composed of. I can go on and change it to triangle, but in that case there might be a misunderstanding since the downsampling that takes place at the hand level does not connect to the physical triangular patches because there is none of them in the palm. If you find a better name, please tell me :)

Question 2

I needed the downsampling for my own purposes: for the PPS, creating visuo-tactile receptive fields for all of the taxels was:

1. an unnecessarily high density
2. a computationally heavy task (less than 15fps)

To this end, we decided to use only the central taxel of the triangular patch as a reference for its nearby "friends".It might be not useful for most of the users, but I need it :) Furthermore, by default the behavior is (obviously) the 1:1 sampling, and this feature is completely transparent to the user.

Question 3

The enum is still there and is kept as it is (although me and @traversaro are still not that happy with that). Andrea used both this enum:

enum SkinPart { 
    SKIN_PART_UNKNOWN=0, 
    SKIN_LEFT_HAND, SKIN_LEFT_FOREARM, SKIN_LEFT_UPPER_ARM, 
    SKIN_RIGHT_HAND, SKIN_RIGHT_FOREARM, SKIN_RIGHT_UPPER_ARM, 
    SKIN_FRONT_TORSO, LEFT_LEG_UPPER, LEFT_LEG_LOWER, LEFT_FOOT,
    RIGHT_LEG_UPPER, RIGHT_LEG_LOWER, RIGHT_FOOT,
    SKIN_PART_ALL, SKIN_PART_SIZE
};

and this array (that is mapped onto that enum):

const std::string SkinPart_s[] = {
    "unknown_skin_part", 
    "skin_left_hand", "skin_left_forearm", "skin_left_upper_arm", 
    "skin_right_hand", "skin_right_forearm", "skin_right_upper_arm", 
    "skin_front_torso", "skin_left_leg_upper",  "skin_left_leg_lower", "skin_left_foot",
    "skin_right_leg_upper",  "skin_right_leg_lower", "skin_right_foot",
    "all_skin_parts", "skin_part_size"
};

I simply changed the latter in order to comply with the new names introduced with @traversaro in #57 . So, the string array changed to:

const std::string SkinPart_s[] = {
    "unknown", 
    "l_hand", "l_forearm", "l_upper_arm", 
    "r_hand", "r_forearm", "r_upper_arm", 
    "chest",
    "l_upper_leg", "l_lower_leg", "l_foot",
    "r_upper_leg", "r_lower_leg", "r_foot",
    "all_skin_parts", "skin_part_size"
};

It is not a big deal since the string is not explicitly used in the code (at least the code I reviewed, I don't know about external projects).

[alecive]

It is worth noting that, albeit its utility seems doubtful, I think that the downsampling feature might be of interest for many users (now or in the future). The skin system is intrinsically heavy from a computational point of view, and pull request #151 basically does the following:

• provides an API for the taxel calibration (that previously was not available at all)
• automatically handles this complexity if needed. Furthermore, it does this via .ini files, so eventually one can remap a whole skinPart onto a single taxel by simply changing a line in a file, if needed.

[matejhof]

Hi everyone,
I also skimmed over the discussion and am putting some comments. I can join more intensively next week when I'm back. Some comments at this point:

• Class Taxel
  • taxelID - I would add this member? Is already used by skinDynLib, is also needed for skinContact structs...
  • FoR - what is that? That is the transform matrix w.r.t. link FoR (w.r.t which the taxel is always in the same pose?)
  • WRFpos, WRFFoR - these are dependent on the current joint angles, that is need to be updated with every new joint configuration of the robot, right? That is, they are not invariant for the taxel. And the user will be responsible for filling this up himself, otherwise the member will have invalid info. Perhaps that should be emphasized.
• Class skinPart
  • I would also choose a different name - skinPartContainer?

As for the taxel positions files etc., I am concerned about the "invalid taxels". As detailed under http://wiki.icub.org/wiki/Tactile_sensors_%28aka_Skin%29 Reading compensated tactile data, there two types of these:

• dummy triangles - if the skin patch (N.B. skin parts may be composed of multiple patches) is not complete, i.e. has less than 16 triangles, there are whole dummy sections on the port with no information. These are 0s in the positions files.
• thermal pads - within each triangle, 7th and 11th taxel are thermal pads and do not deliver pressure information. For the arm and forearm positions files, these do not have 0s but "valid" positions - for the, now irrelevant, reasons that Andrea Del Prete was calibrating using the older triangle version with 12 taxels. See Getting 3D skin data files #93 (comment)
  Therefore, we need to decide how to handle this. For example, if we choose that the .ini files will contain all relevant info, we may need to add some columns that would carry the info whether the taxel is normal, dummy, or thermal pad. In the class, we may choose not to represent these (but we will need the taxelID member).
  We could also choose to filter these on a lower level, but that would require major changes.

[alecive]

Here are my answers (that were updated in #151, so please refer to the pull request rather than this issue):

• taxelID is there, I simply forgot to write it down here (but I put it in Extend SkinDynLib (fixes #149) #151) :)
• yes, FoR is the transform matrix w.r.t. the link (it's like the library on PPS, so it's exactly the same)
• yes and yes, and this is why I actually got rid of WRFFoR but I kept the WRFPosition. It needs to be user generated (as I said), but at least one can use it as a place to store everything related to a taxel in the same place.
• I don't like skinPartContainer either, it reminds me of a container of skinparts, rather than a collector of taxels.

Regarding the latter comments about the invalid taxels, in my opinion belong to a completely different issue. It's not the library's fault if we use wrong position files :) Anyhow:

• dummy -> these are ok, no problem with that. The taxel array present in skinpart will simply skip them (since the skinPart is a class made for handling positions, there is no reason to occupy memory for taxels with no position at all).
• thermal -> for them, it would be better to remove them from the file(s) (i.e. the termal pads' lines would be filled with zeros). It does not make any sense to put positions for things that were not even there when these positions were acquired. The same applies to the taxels, that at least theoretically should be calibrated again, because actually their positions are different to the respective positions on the skin.

[lornat75]

patch --> face in computer graphics terminology

[traversaro]

I guess documentation for the new positions/*.txt parameters (spatial_sampling, taxel2repr) can be added to the SkinManager documentation [1], in particular in the documentation of the taxelPositionFiles parameters, that described the old format.

[1] : http://wiki.icub.org/brain/group__icub__skinManager.html

[alecive]

Agreed. Done in 327d9d0 .