{"action":"created","issue":{"url":"https://api.github.com/repos/robotology/icub-main/issues/149","labels_url":"https://api.github.com/repos/robotology/icub-main/issues/149/labels{/name}","comments_url":"https://api.github.com/repos/robotology/icub-main/issues/149/comments","events_url":"https://api.github.com/repos/robotology/icub-main/issues/149/events","html_url":"https://github.com/robotology/icub-main/issues/149","id":76344206,"number":149,"title":"Extend SkinDynLib","user":{"login":"alecive","id":4378663,"avatar_url":"https://avatars.githubusercontent.com/u/4378663?v=3","gravatar_id":"","url":"https://api.github.com/users/alecive","html_url":"https://github.com/alecive","followers_url":"https://api.github.com/users/alecive/followers","following_url":"https://api.github.com/users/alecive/following{/other_user}","gists_url":"https://api.github.com/users/alecive/gists{/gist_id}","starred_url":"https://api.github.com/users/alecive/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alecive/subscriptions","organizations_url":"https://api.github.com/users/alecive/orgs","repos_url":"https://api.github.com/users/alecive/repos","events_url":"https://api.github.com/users/alecive/events{/privacy}","received_events_url":"https://api.github.com/users/alecive/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/robotology/icub-main/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-05-14T12:31:05Z","updated_at":"2015-05-14T14:51:02Z","closed_at":null,"body":"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.\r\n\r\nThis is the basic structure with some of the features:\r\n\r\n### CLASS 1 : `Taxel` - the basic element\r\n#### _Basic Members_\r\n| Member | Description |\r\n|--------|-------------|\r\n| `Pos`  | taxel position as read from calib file |\r\n| `Nrm`  | taxel normal direction as read from calib file |\r\n| `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` |\r\n\r\n#### _Optional Members_\r\nThey are present in my library but I can keep them there and remove them from `icub-main` (I would keep them, though).\r\n\r\n|  Member  | Description |\r\n|----------|-------------|\r\n| `WRFpos` | 3D taxel position in the Root Rereference frame |\r\n| `WRFFoR` | Same as `FoR`, but in the Root Reference Frame |\r\n| `px`     | 2D taxel position in the image plane of one of the eyes |\r\n\r\n#### _Methods_ \r\nVarious constructors, `toString()`, `print()`, copy operator, etc), but no method to assign the aforementioned members (see below).\r\n\r\n### CLASS 2 : `skinPart`\r\nIt 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?]).\r\n#### _Basic Members_\r\n\r\n|     Member      | Description |\r\n|-----------------|-------------|\r\n| `SkinPart name` | name of the skinpart (yes, it is the `enum`): something like `SKIN_RIGHT_HAND`|\r\n| `string filename` | the name of the file from which the skinPart has been created |\r\n| `vector<Taxel*> txls` | List of taxels that belong to the skinPart. |\r\n\r\n#### _Optional Members_\r\nThey 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).\r\n\r\n|     Member      | Description |\r\n|-----------------|-------------|\r\n| `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) |\r\n| `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 |\r\n\r\n#### _Methods_\r\n\r\nVarious constructors, `toString()`, `print()`, copy operator, etc)\r\n\r\n##### _Useful methods_\r\n\r\n * Construction able to build the skinPart up from the standard `skinGui` txt files\r\n * Loading and saving to ini file (it is different from the standard `skinGui` txt files because it contains more information)\r\n * Automatic conversion from local to Root Reference frame (for this one we have to discuss the function syntax)\r\n\r\n### Issues\r\n\r\n 1. Is it ok to call class 2 `skinPart`? Does anybody have a better name?\r\n 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)? \r\n\r\nI 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)."},"comment":{"url":"https://api.github.com/repos/robotology/icub-main/issues/comments/102060231","html_url":"https://github.com/robotology/icub-main/issues/149#issuecomment-102060231","issue_url":"https://api.github.com/repos/robotology/icub-main/issues/149","id":102060231,"user":{"login":"traversaro","id":1857049,"avatar_url":"https://avatars.githubusercontent.com/u/1857049?v=3","gravatar_id":"","url":"https://api.github.com/users/traversaro","html_url":"https://github.com/traversaro","followers_url":"https://api.github.com/users/traversaro/followers","following_url":"https://api.github.com/users/traversaro/following{/other_user}","gists_url":"https://api.github.com/users/traversaro/gists{/gist_id}","starred_url":"https://api.github.com/users/traversaro/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/traversaro/subscriptions","organizations_url":"https://api.github.com/users/traversaro/orgs","repos_url":"https://api.github.com/users/traversaro/repos","events_url":"https://api.github.com/users/traversaro/events{/privacy}","received_events_url":"https://api.github.com/users/traversaro/received_events","type":"User","site_admin":false},"created_at":"2015-05-14T14:51:02Z","updated_at":"2015-05-14T14:51:02Z","body":":+1: .\r\nAn initial comment:\r\n* 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."}}