<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD Journal Archiving and Interchange DTD v2.3 20070202//EN" "archivearticle.dtd">
<article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" article-type="data-paper">
<front>
<journal-meta>
<journal-id journal-id-type="publisher-id">Front. Robot. AI</journal-id>
<journal-title>Frontiers in Robotics and AI</journal-title>
<abbrev-journal-title abbrev-type="pubmed">Front. Robot. AI</abbrev-journal-title>
<issn pub-type="epub">2296-9144</issn>
<publisher>
<publisher-name>Frontiers Media S.A.</publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="doi">10.3389/frobt.2018.00098</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Robotics and AI</subject>
<subj-group>
<subject>Code</subject>
</subj-group>
</subj-group>
</article-categories>
<title-group>
<article-title>A Framework for Fast, Autonomous, and Reliable Tool Incorporation on iCub</article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<name><surname>Mar</surname> <given-names>Tanis</given-names></name>
<uri xlink:href="http://loop.frontiersin.org/people/336865/overview"/>
</contrib>
<contrib contrib-type="author">
<name><surname>Tikhanoff</surname> <given-names>Vadim</given-names></name>
<uri xlink:href="http://loop.frontiersin.org/people/9159/overview"/>
</contrib>
<contrib contrib-type="author" corresp="yes">
<name><surname>Natale</surname> <given-names>Lorenzo</given-names></name>
<xref ref-type="corresp" rid="c001"><sup>&#x0002A;</sup></xref>
<uri xlink:href="http://loop.frontiersin.org/people/36032/overview"/>
</contrib>
</contrib-group>
<aff><institution>iCub Facility, Istituto Italiano di Tecnologia</institution>, <addr-line>Genoa</addr-line>, <country>Italy</country></aff>
<author-notes>
<fn fn-type="edited-by"><p>Edited by: Alexandre Bernardino, Instituto Superior T&#x000E9;cnico, Universidade de Lisboa, Portugal</p></fn>
<fn fn-type="edited-by"><p>Reviewed by: Vishwanathan Mohan, University of Essex, United Kingdom; Jose Antonio Gaspar, Universidade de Lisboa, Portugal; Pedro Vicente, Universidade de Lisboa, Portugal, in collaboration with reviewer JAG</p></fn>
<corresp id="c001">&#x0002A;Correspondence: Lorenzo Natale <email>lorenzo.natale&#x00040;iit.it</email></corresp>
<fn fn-type="other" id="fn002"><p>This article was submitted to Humanoid Robotics, a section of the journal Frontiers in Robotics and AI</p></fn></author-notes>
<pub-date pub-type="epub">
<day>22</day>
<month>08</month>
<year>2018</year>
</pub-date>
<pub-date pub-type="collection">
<year>2018</year>
</pub-date>
<volume>5</volume>
<elocation-id>98</elocation-id>
<history>
<date date-type="received">
<day>10</day>
<month>08</month>
<year>2017</year>
</date>
<date date-type="accepted">
<day>30</day>
<month>07</month>
<year>2018</year>
</date>
</history>
<permissions>
<copyright-statement>Copyright &#x000A9; 2018 Mar, Tikhanoff and Natale.</copyright-statement>
<copyright-year>2018</copyright-year>
<copyright-holder>Mar, Tikhanoff and Natale</copyright-holder>
<license xlink:href="http://creativecommons.org/licenses/by/4.0/"><p>This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) and the copyright owner(s) are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.</p></license>
</permissions>
<abstract><p>One of the main advantages of building robots with size and motor capabilities close to those of humans, such as iCub, lies in the fact that they can potentially take advantage of a world populated with tools and devices designed by and for humans. However, in order to be able to do proper use of the tools around them, robots need to be able to <italic>incorporate</italic> these tools, that is, to build a representation of the tool&#x00027;s geometry, reach and pose with respect to the robot. The present paper tackles this argument by presenting a repository which implements a series of interconnected methods that enable autonomous, fast, and reliable tool incorporation on the iCub platform.</p></abstract>
<kwd-group>
<kwd>tool use</kwd>
<kwd>code:cplusplus</kwd>
<kwd>tool incorporation</kwd>
<kwd>affordances</kwd>
<kwd>iCub</kwd>
<kwd>3D reconstruction</kwd>
<kwd>humanoid</kwd>
<kwd>tool pose</kwd>
</kwd-group>
<contract-num rid="cn001">270273</contract-num>
<contract-sponsor id="cn001">Seventh Framework Programme<named-content content-type="fundref-id">10.13039/100011102</named-content></contract-sponsor>
<counts>
<fig-count count="3"/>
<table-count count="0"/>
<equation-count count="10"/>
<ref-count count="13"/>
<page-count count="7"/>
<word-count count="4510"/>
</counts>
</article-meta>
</front>
<body>
<sec id="s1">
<title>1. Overview</title>
<p>A critical problem in most studies of tool use in developmental robotics is that actions are performed without considering the geometry or pose of tools that the robot uses. Instead, most experiments apply standard grasps and assume pre-defined kinematic end-effector extensions that do not take into account the particular pose of the tool in the robot&#x00027;s hand (Gon&#x000E7;alves et al., <xref ref-type="bibr" rid="B4">2014</xref>; Dehban et al., <xref ref-type="bibr" rid="B2">2017</xref>). In order to overcome this limitation, this paper presents a repository which implements a series of interconnected methods that enable autonomous, fast, and reliable estimation of a tool&#x00027;s geometry, reach and pose with respect to the iCub&#x00027;s hand, in order to attach it to the robot&#x00027;s kinematic chain, thereby enabling dexterous tool use. Indeed, this methods have been successfully applied in the study presented in Mar et al. (<xref ref-type="bibr" rid="B7">2017</xref>).</p>
<p>The repository can be found at:</p>
<p><ext-link ext-link-type="uri" xlink:href="https://github.com/robotology/tool-incorporation">https://github.com/robotology/tool-incorporation</ext-link></p>
<p>We name this process <italic>tool incorporation</italic> because of its meaning referring to embodiment (literally, <italic>in-corpore</italic>), as it enables iCub to build a representation of the tool with respect to, and included in, its own body representation. The iCub is a full body humanoid robot with 53 Degrees of Freedom (DoF) (Metta et al., <xref ref-type="bibr" rid="B9">2010</xref>), including head, arms, and torso. The iCub software is structured as modules that communicate with each other using YARP middleware, which enables multi-machine and multi-platform integration (Metta, <xref ref-type="bibr" rid="B8">2006</xref>). Modules provide specific functionalities, and work together in form of applications to achieve desired behaviors on the iCub. Vision is provided by the cameras mounted in the robot&#x00027;s eyes, from which stereo matching can be applied to estimate depth (Fanello et al., <xref ref-type="bibr" rid="B3">2014</xref>). Image processing is achieved with the help of OpenCV and PCL libraries, for 2D and 3D processing respectively (Rusu and Cousins, <xref ref-type="bibr" rid="B12">2011</xref>; Itseez, <xref ref-type="bibr" rid="B5">2015</xref>). All the methods described in this paper are implemented as functions in the <monospace>toolIncorporation</monospace> module.</p>
<p>The remainder of this paper is structured according to the main methods required to incorporate tools. Section 2 describes the methods for tool recognition, or visual appearance learning if the tool has not been seen before. Section 3 presents a method that enables iCub to reconstruct a 3D representation of the tool in its hand using its stereo-vision capabilities. Section 4 explains the meaning and estimation of the tool&#x00027;s intrinsic frame and of the tooltip. Finally, section 5 details a method for faster estimation of a tool&#x00027;s pose when its model is available.</p>
</sec>
<sec id="s2">
<title>2. Tool recognition</title>
<p>The first step for tool incorporation is to recognize the tool in the robot&#x00027;s hand, so that its model can be loaded if the tool is known, or its visual appearance learned otherwise. To that end, the method applied in this work builds upon the techniques described in Pasquale et al. (<xref ref-type="bibr" rid="B10">2016</xref>). In that paper, a pre-trained CNN (AlexNet trained on imageNet, Krizhevsky et al., <xref ref-type="bibr" rid="B6">2012</xref>) learned to associate a cropped image of an object presented by the experimenter with a provided label. In this work, we extended this approach in order to reduce the need of an external teacher, so that it is only required to hand over the tool to the robot and provide its label.</p>
<p>Once the iCub robot is grasping the tool in its hand, exploration is performed by moving it to different poses, so that it can be observed from different perspectives (implemented in function <monospace>exploreTool</monospace>). These poses are predefined to utilize the range of iCub&#x00027;s wrist joints to achieve distinct perspectives.</p>
<p>On each of the considered poses iCub focuses on the tool&#x00027;s effector, understood as the part of the tool that interacts with the environment. However, at this point the robot has no information about the tool&#x00027;s geometry or pose in order to estimate where the effector might be (these are discussed in section 4.3). Therefore, in order to locate the effector, iCub initially looks just slightly over its hand (10 cm along the X axis and &#x02013;10 cm along the Y axis of the hand reference frame). Then, it locates the tooltip on the image by iteratively extracting the tool outline from the disparity map, and looking at the point in the blob further away from the hand reference frame. This process, which is implemented in function <monospace>lookAtTool</monospace>, is repeated until the position of the estimated tooltip is stable, or a given number of iterations has been surpassed.</p>
<p>Once iCub is correctly gazing at the tool effector, a series of images of the tool are obtained by cropping a region around the tool, which is determined by the bounding box of the closest blob obtained with <monospace>dispBlobber</monospace><xref ref-type="fn" rid="fn0001"><sup>1</sup></xref>, plus a margin of 10 pixels on each side. Finally the cropped images are fed to a CNN whose output feeds in turn a linear classifier which associates them to the user provided tool label. This process is performed by the <monospace>onTheFlyRecognition</monospace> application, which is called from by the <monospace>learn</monospace> function provided with the tool label.</p>
<p>This sequence &#x02013;tool effector location and subsequent cropping of the tool region to feed the CNN&#x02013; is repeated for all the exploration poses considered, which provides enough perspectives to recognize the tool in any future pose in which it might be grasped in the future.</p>
<p>After the visual appearance of the set of available tools has been learned, the process of classification is simple. After iCub is given any tool, it observes it in any of the exploratory poses and uses the same method to crop it from the rest of the image. The cropped image is in turn sent to the trained classifier (in this case, using the <monospace>recognize</monospace> function), which returns the estimated label of the tool. It should be noted that tools can be learned in either terms of instances or categories. In the first case, the user should provide a distinct label for each individual tool given to iCub, and an associated pointcloud model. In the second case, tools of the same category (e.g., rakes, sticks, shovels), should be given the generic label of that category, and a generic model of the tool category provided.</p>
</sec>
<sec id="s3">
<title>3. Tool 3d reconstruction</title>
<p>In cases where a 3D model of the tool is not available, the robot should be able to reconstruct it through exploration. In this section we describe an approach that allows iCub to achieve this, without the need of external intervention by the experimenter. Essentially, it consists of iterative segmentation, reconstruction, and merge of the tool&#x00027;s partial views from different perspectives.</p>
<p>Similar techniques have been presented in many different papers in the recent years (Ren et al., <xref ref-type="bibr" rid="B11">2013</xref>; Zhang et al., <xref ref-type="bibr" rid="B13">2015</xref>). However, most of these studies assume either a fixed camera and an object being moved externally (by the user or on a turning table), which could not be considered autonomous; or a fix scene and a moving camera/robot navigating around it, which is unfeasible on the current iCub setup. Therefore, in the present work we implemented a method by means of which iCub can reconstruct a tool&#x00027;s complete pointcloud representation by obtaining partial view reconstructions from different perspectives and incrementally merging them together.</p>
<p>The method applied to observe the tool effector is analogous to the one described in the previous section for learning the tool&#x00027;s visual appearance, and in fact, both processes can be run simultaneously (by calling the <monospace>exploreTool</monospace> function with the 2D and 3D flags active). For reconstruction, the steps performed at each exploration pose are the following:</p>
<list list-type="bullet">
<list-item><p>Segmentation:</p>
<p>After the gaze is properly oriented toward the tool effector, as described in section 2, instead of just cropping the bounding box around the tool, the tool blob is segmented with the <monospace>dispBlobber</monospace> module, which returns the pixels in the image that correspond to the tool.</p></list-item>
<list-item><p>Reconstruction:</p>
<p>This list of pixels is sent to the <monospace>seg2cloud</monospace> module, which computes the 3D coordinates of each point in the robot reference frame and returns them as a pointcloud. This pointcloud is transformed from the robot frame to the hand&#x00027;s reference frame using the robot&#x00027;s kinematics, which greatly facilitates subsequent merging, as the hand provides a coherent reference frame for all the partial reconstructions.</p>
<p>Moreover, we can safely assume that the tool is connected with the hand, and it does not extend beyond certain boundaries. Therefore, in order to remove any points on the reconstructed pointcloud that might belong to the background, the pointcloud is truncated in all three axes of the hand reference frame, removing all the points outside the (0.0, 35)cm range in the <italic>X</italic> axis, (&#x02212;30, 0.0)cm range in the <italic>Y</italic> axis, and (&#x02212;15, 15)cm range in the <italic>Z</italic> axis. Additionally, as in many cases part of the hand might also be present in the reconstructed pointcloud, it is removed by filtering out all the points in the which are inside a radius of 8 cm from the origin of the hand reference frame. Finally, the pointcloud is smoothed by applying a statistical filter for outlier removal. The described pointcloud reconstruction, transformation and filtering are performed by the <monospace>getPointCloud</monospace> function.</p></list-item>
<list-item><p>Merging:</p>
<p>Although all the partial reconstructed pointclouds are represented in a coherent reference frame, they are not perfectly aligned due to errors in depth estimation and robot kinematics. Therefore, a further refinement step is performed using the Iterative Closest Point algorithm (ICP) (Besl and McKay, <xref ref-type="bibr" rid="B1">1992</xref>). We assume that the required refinement is small and thus discard as unsuccessful those cases in which the resulting roto-translation is larger than a given threshold. Finally, in order to merge overlapping surfaces and reduce noise, the resulting pointcloud is downsampled uniformly using a voxelized grid.</p></list-item>
</list>
<p>As a result of this process, a complete pointcloud representation of the explored tool is obtained, which also reflects the pose with which the tool is being grasped by iCub. We refer to this representation as an <bold>oriented pointcloud model</bold>, that is, the available pointcloud model of the tool being held by the robot, whose coordinates match the position of the actual tool with respect to the robot&#x00027;s hand reference frame.</p>
</sec>
<sec id="s4">
<title>4. Tool reference frame and tooltip estimation</title>
<p>Although the pose of the oriented pointcloud model corresponds to that of the tool in the robot&#x00027;s hand, its orientation is not readily available for the robot, as it is only implicit in the pointcloud representation. In the present section we present a method to make this information explicit, based on the definition and estimation of a reference frame intrinsic to each tool, applicable to the vast majority of man-made tools that could be present in a robotic tool use scenario. This frame of reference, referred to as <bold>tool intrinsic reference frame</bold>, and denoted as <bold>f</bold>, identifies the effector and handle of the tool, provides its orientation with respect to the hand reference frame, and facilitates the computation of the tooltip&#x00027;s location.</p>
<sec>
<title>4.1. Tool reference frame definition</title>
<p>Given any radial tool<xref ref-type="fn" rid="fn0002"><sup>2</sup></xref>, generally we can define three orthogonal characteristic tool planes as can be observed in Figure <xref ref-type="fig" rid="F1">1</xref>, denoted together as a tool&#x00027;s <italic>L</italic> planes:</p>
<list list-type="bullet">
<list-item><p><bold>Handle plane</bold> (<italic>L</italic><sub><italic>han</italic></sub>): It is perpendicular to the handle axis, and divides the tool into the effector and the handle sides.</p></list-item>
<list-item><p><bold>Symmetry plane</bold> (<italic>L</italic><sub><italic>sym</italic></sub>): It is the plane with respect to which the tool has the maximum symmetry. It runs along the handle and divides the tool into two equal (or almost) longitudinal halves.</p></list-item>
<list-item><p><bold>Effector plane</bold> (<italic>L</italic><sub><italic>eff</italic></sub>): Orthogonal to the two previous planes, usually divides the &#x0201C;forward&#x0201D; and &#x0201C;back&#x0201D; sides of the tool, forward being the side where the effector is.</p></list-item>
</list>
<fig id="F1" position="float">
<label>Figure 1</label>
<caption><p>Planes and axes that determine the tool&#x00027;s intrinsic reference frame. <bold>(A)</bold> Tool model divided by its three characteristic <italic>L</italic> planes. <bold>(B)</bold> Handle plane <italic>L</italic><sub><italic>han</italic></sub>. <bold>(C)</bold> Symmetry plane <italic>L</italic><sub><italic>sym</italic></sub>. <bold>(D)</bold> Effector plane <italic>L</italic><sub><italic>eff</italic></sub>. The reference frame in all figures shows <bold>f</bold><sub><italic>eff</italic></sub> in red, <bold>f</bold><sub><italic>han</italic></sub> in green, and <bold>f</bold><sub><italic>sym</italic></sub> in blue.</p></caption>
<graphic xlink:href="frobt-05-00098-g0001.tif"/>
</fig>
<p>The planes&#x00027; normal vectors can be chosen so that they define a right-hand reference frame, which we refer to as the <bold>tool intrinsic reference frame</bold>,(<bold>f</bold>). To this end, the origin and orientation of the corresponding axes is chosen so that they preserve the following characteristics:</p>
<list list-type="bullet">
<list-item><p><bold>Effector axis (</bold><italic>X</italic><bold>)</bold> (<bold>f</bold><sub><italic>eff</italic></sub>): It is positive in the direction of the effector, i.e., toward the &#x0201C;forward&#x0201D; side of the tool.</p></list-item>
<list-item><p><bold>Handle axis (</bold><italic>Y</italic><bold>)</bold> (<bold>f</bold><sub><italic>han</italic></sub>): Is positive in the direction toward the handle, and negative in the direction toward the effector side of the tool.</p></list-item>
<list-item><p><bold>Symmetry axis (</bold><italic>Z</italic><bold>)</bold> (<bold>f</bold><sub><italic>sym</italic></sub>): The symmetry basis vector is obtained as the outer product of the other two to ensure orthogonality, so it is positive on the &#x0201C;left&#x0201D; side of the tool, if the effector is looking &#x0201C;forward&#x0201D;.</p></list-item>
</list>
</sec>
<sec>
<title>4.2. Tool reference frame estimation</title>
<p>Based on the previous definitions, here we propose a method to automatically estimate the tool intrinsic reference frame <bold>f</bold> of a tool&#x00027;s pointcloud representation <italic>W</italic>, relying solely on the assumption that <italic>W</italic> represents an oriented pointcloud model, that is, it is expressed with respect to the hand reference frame of the robot. The proposed procedure consists on the following steps, which can be observed in function <monospace>findSyms</monospace>:</p>
<list list-type="order">
<list-item><p>Find the pointcloud&#x00027;s main axes: The estimation of <bold>f</bold>&#x00027;s origin and direction can be achieved by computing the covariance matrix of the pointcloud <italic>W</italic>. The origin is determined at the center of mass <italic>o</italic>, and the 3 eigenvectors <bold>v</bold> with larger eigenvalues &#x003BB; correspond to the pointcloud&#x00027;s main axes:</p>
<p><disp-formula id="E1"><label>(1)</label><mml:math id="M1"><mml:mtable class="eqnarray" columnalign="right center left"><mml:mtr><mml:mtd><mml:mi>C</mml:mi><mml:mo>=</mml:mo><mml:mi>c</mml:mi><mml:mi>o</mml:mi><mml:mi>v</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>W</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<disp-formula id="E2"><label>(2)</label><mml:math id="M2"><mml:mtable class="eqnarray" columnalign="right center left"><mml:mtr><mml:mtd><mml:mi>C</mml:mi><mml:mstyle mathvariant="bold"><mml:mtext>v</mml:mtext></mml:mstyle><mml:mo>=</mml:mo><mml:mi>&#x003BB;</mml:mi><mml:mstyle mathvariant="bold"><mml:mtext>v</mml:mtext></mml:mstyle><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<disp-formula id="E3"><label>(3)</label><mml:math id="M3"><mml:mtable class="eqnarray" columnalign="right center left"><mml:mtr><mml:mtd><mml:mi>L</mml:mi><mml:mrow><mml:mo>[</mml:mo><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mo>]</mml:mo></mml:mrow><mml:mo>&#x022A5;</mml:mo><mml:mstyle mathvariant='bold-italic'><mml:mtext>v</mml:mtext></mml:mstyle><mml:mrow><mml:mo>[</mml:mo><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mo>]</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:mi>i</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow><mml:mo>}</mml:mo></mml:mrow><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>Therefore, this set of orthogonal vectors <bold>v</bold> defines a set of orthogonal planes that approximate the tool planes <italic>L</italic>, but their correspondence with the specific planes defined above, as well as their orientation, need to be determined to fully characterize <bold>f</bold>.</p></list-item>
<list-item><p>Identify the planes:</p>
<list list-type="alpha-lower">
<list-item><p>Handle plane <italic>L</italic><sub><italic>han</italic></sub>: The handle is situated along the longest tool dimension. Thus, the eigenvector with largest eigenvalue indicates the direction of the handle axis, normal to the Handle plane. That is,</p>
<p><disp-formula id="E4"><label>(4)</label><mml:math id="M4"><mml:mtable class="eqnarray" columnalign="right center left"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mstyle mathvariant="bold"><mml:mtext>v</mml:mtext></mml:mstyle></mml:mrow><mml:mrow><mml:mi>h</mml:mi><mml:mi>a</mml:mi><mml:mi>n</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mstyle mathvariant="bold"><mml:mtext>v</mml:mtext></mml:mstyle><mml:mrow><mml:mo>[</mml:mo><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mo>]</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:mtext>&#x000A0;where</mml:mtext><mml:mi>n</mml:mi><mml:mo>=</mml:mo><mml:mstyle displaystyle="true"><mml:munder><mml:mrow><mml:mo class="qopname">arg</mml:mo><mml:mo class="qopname">max</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:mrow></mml:munder></mml:mstyle><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>&#x003BB;</mml:mi><mml:mrow><mml:mo>[</mml:mo><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mo>]</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<disp-formula id="E5"><label>(5)</label><mml:math id="M5"><mml:mtable class="eqnarray" columnalign="right center left"><mml:mtr><mml:mtd><mml:mtext class="textrm" mathvariant="normal">accordingly,</mml:mtext><mml:msub><mml:mrow><mml:mi>L</mml:mi></mml:mrow><mml:mrow><mml:mi>h</mml:mi><mml:mi>a</mml:mi><mml:mi>n</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>L</mml:mi><mml:mrow><mml:mo>[</mml:mo><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mo>]</mml:mo></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p></list-item>
<list-item><p>Symmetry plane <italic>L</italic><sub><italic>sym</italic></sub>: The symmetry plane corresponds by definition to the plane with respect to which the tool has the maximum symmetry. Thus:
<disp-formula id="E6"><label>(6)</label><mml:math id="M6"><mml:mrow><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mi>s</mml:mi><mml:mi>y</mml:mi><mml:mi>m</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>L</mml:mi><mml:mo stretchy='false'>[</mml:mo><mml:mi>m</mml:mi><mml:mo stretchy='false'>]</mml:mo><mml:mo>,</mml:mo><mml:mtext>&#x000A0;where&#x000A0;</mml:mtext><mml:mi>m</mml:mi><mml:mo>=</mml:mo><mml:mtext>&#x000A0;</mml:mtext><mml:munder><mml:mrow><mml:mtext>arg&#x000A0;max</mml:mtext></mml:mrow><mml:mrow><mml:mi>j</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mo>&#x0007B;</mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn><mml:mo>&#x0007D;</mml:mo><mml:mo>&#x02260;</mml:mo><mml:mi>n</mml:mi></mml:mrow></mml:munder><mml:mtext>&#x000A0;</mml:mtext><mml:mo stretchy='false'>(</mml:mo><mml:mi>s</mml:mi><mml:mi>y</mml:mi><mml:mi>m</mml:mi><mml:mo stretchy='false'>(</mml:mo><mml:mi>L</mml:mi><mml:mo stretchy='false'>[</mml:mo><mml:mi>j</mml:mi><mml:mo stretchy='false'>]</mml:mo><mml:mo stretchy='false'>)</mml:mo><mml:mo>.</mml:mo></mml:mrow></mml:math></disp-formula>
</p></list-item>
<list-item><p>Effector plane <italic>L</italic><sub><italic>eff</italic></sub>: The effector plane is computed in relation to previous two planes, as the plane orthogonal to both the Handle and the Symmetry plane:</p>
<p><disp-formula id="E7"><label>(7)</label><mml:math id="M7"><mml:mtable class="eqnarray" columnalign="right center left"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mi>L</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi><mml:mi>f</mml:mi><mml:mi>f</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>L</mml:mi><mml:mrow><mml:mo>[</mml:mo><mml:mrow><mml:mi>k</mml:mi></mml:mrow><mml:mo>]</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:mtext>&#x000A0;where</mml:mtext><mml:mi>k</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn><mml:mo>&#x02260;</mml:mo><mml:mi>n</mml:mi><mml:mo>,</mml:mo><mml:mi>m</mml:mi></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<disp-formula id="E8"><label>(8)</label><mml:math id="M8"><mml:mtable class="eqnarray" columnalign="right center left"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mi>L</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi><mml:mi>f</mml:mi><mml:mi>f</mml:mi></mml:mrow></mml:msub><mml:mo>&#x022A5;</mml:mo><mml:msub><mml:mrow><mml:mi>L</mml:mi></mml:mrow><mml:mrow><mml:mi>s</mml:mi><mml:mi>y</mml:mi><mml:mi>m</mml:mi></mml:mrow></mml:msub><mml:mo>&#x022A5;</mml:mo><mml:msub><mml:mrow><mml:mi>L</mml:mi></mml:mrow><mml:mrow><mml:mi>h</mml:mi><mml:mi>a</mml:mi><mml:mi>n</mml:mi></mml:mrow></mml:msub></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p></list-item>
</list>
</list-item>
<list-item><p>Find the axes orientations:</p>
<list list-type="alpha-lower">
<list-item><p>Handle axis <bold>f</bold><sub><italic>han</italic></sub>: Determines the side where the handle of the tool is (opposite of the effector). Following the assumption that <italic>W</italic> is represented with respect to the hand reference frame, it follows that the handle is on the side of <italic>L</italic><sub><italic>han</italic></sub> that contains the origin of the pointcloud reference frame (i.e., the hand). Thus, the orientation of <bold>f</bold><sub><italic>han</italic></sub> is set so that the positive values correspond to the side of <italic>L</italic><sub><italic>han</italic></sub> that contains the origin.</p></list-item>
<list-item><p>Effector axis <bold>f</bold><sub><italic>eff</italic></sub>: In order to determine the direction that corresponds with &#x0201C;forward&#x0201D; in a tool, we consider the saliency of the features on each side of the effector plane. Specifically, the &#x0201C;forward&#x0201D; side of the pointcloud <italic>W</italic> is defined as the side where the effector half of the tool (determined in the previous step) contains points further away from the tool&#x00027;s intrinsic reference frame origin <italic>o</italic>. Thus, the orientation of the effector axis <bold>f</bold><sub><italic>eff</italic></sub> (perpendicular to the effector plane) is set such that the positive values are located on the salient side of the effector plane.</p></list-item>
<list-item><p>Symmetry axis <bold>f</bold><sub><italic>sym</italic></sub>: The orientation of <bold>f</bold><sub><italic>sym</italic></sub> is chosen so that the set of axes defined by <bold>v</bold> corresponds to a right-handed coordinate system. Thus, it is computed as the cross product between the handle and effector axes basis vectors:</p>
<p><disp-formula id="E9"><label>(9)</label><mml:math id="M9"><mml:mtable class="eqnarray" columnalign="right center left"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mstyle mathvariant="bold"><mml:mtext>f</mml:mtext></mml:mstyle></mml:mrow><mml:mrow><mml:mi>s</mml:mi><mml:mi>y</mml:mi><mml:mi>m</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mstyle mathvariant="bold"><mml:mtext>f</mml:mtext></mml:mstyle></mml:mrow><mml:mrow><mml:mi>h</mml:mi><mml:mi>a</mml:mi><mml:mi>n</mml:mi></mml:mrow></mml:msub><mml:mo>&#x000D7;</mml:mo><mml:msub><mml:mrow><mml:mstyle mathvariant="bold"><mml:mtext>f</mml:mtext></mml:mstyle></mml:mrow><mml:mrow><mml:mi>e</mml:mi><mml:mi>f</mml:mi><mml:mi>f</mml:mi></mml:mrow></mml:msub></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p></list-item>
</list>
</list-item>
</list>
<p>The tool intrinsic reference frame <bold>f</bold> is actually expressed on the same frame of reference that the pointcloud reconstruction from which it is estimated, that is, the hand reference frame. Thus, the equations of the frame&#x00027;s axes represent explicitly the orientation of the tool in any of its three axis.</p>
<p>One of the strengths of this approach to estimate the tool&#x00027;s frame of reference <bold>f</bold> is that it relies on very few and general assumptions to be met in order to work successfully, namely, that the tool&#x00027;s handle axis is longer that any other axis, and that the tool has a certain degree of symmetry along a plane that contains that axis. Moreover, the method is also very robust to noise in the 3D representation of the tool, since all the computations required throughout the process of determining <bold>f</bold> have a high tolerance to noise. Indeed, as most of the decisions are made in terms of comparison (symmetry between two sides of a plane, longest axis, furthest away point), if noise affects the whole pointcloud similarly, it would not modify their outcome.</p>
</sec>
<sec>
<title>4.3. Tooltip estimation</title>
<p>As stated above, one of the main advantages of estimating the tool reference frame <bold>f</bold> is that it enables to precisely locate the tooltip, required to perform the extension of the robot&#x00027;s kinematic chain to the new end-effector provided by the tool. Thus, the tool tip is defined in terms of the concepts defined and estimated above:</p>
<p><bold>Tooltip:</bold> Location on the tool represented by the point on the Symmetry plane of the tool, above the Handle plane (i.e., on the effector side), furthest away from the Effector plane, on the positive side of the effector axis.</p>
<p>The estimated tool reference frame <bold>f</bold> and tooltip for a small sample of tools can be observed in Figure <xref ref-type="fig" rid="F2">2</xref>, where it can be observed that the estimated tooltip coincides to what most people would consider to be the tooltip of those tools.</p>
<fig id="F2" position="float">
<label>Figure 2</label>
<caption><p>Results of the tooltip estimation process described in the text shown for a few example tools (top row), whose pointcloud has been achieved from from CAD models (middle row), or autonomously reconstructed (bottom row).</p></caption>
<graphic xlink:href="frobt-05-00098-g0002.tif"/>
</fig>
<p>In our code, this definition is implemented by the function <monospace>findTooltipSym</monospace>, which computes the tooltip location based on the information from the tool planes provided by the previous steps.</p>
</sec>
</sec>
<sec id="s5">
<title>5. Tool pose estimation</title>
<p>The methods described in sections 3 and 4 allow the robot to reconstruct a tool&#x00027;s geometry and estimate its pose even in the case of previously unseen tools. However, this is a time consuming approach that is not necessary if a 3D pointcloud model of the tool or tool category is already available, either from a CAD model or from a previous reconstruction. For these cases, in this section we introduce a fast and reliable method for pose estimation, based on the alignment of the available model with a single partial view reconstruction to the tool in the robot&#x00027;s hand, implemented in the function <monospace>findPoseAlign</monospace>.</p>
<p>Qualitatively, the <italic>tool pose</italic> represents the way in which the tool is being grasped with respect to the hand&#x00027;s reference frame. Numerically, we can express the tool pose in terms of the 4 &#x000D7; 4 roto-translation <bold>Pose Matrix</bold> <italic>P</italic> required to transform the hand reference frame &#x0003C; <italic>H</italic> &#x0003E; frame to any reference frame intrinsic to the tool &#x0003C; <italic>T</italic> &#x0003E;, that is,</p>
<disp-formula id="E10"><label>(10)</label><mml:math id="M10"><mml:mtable class="eqnarray" columnalign="right center left"><mml:mtr><mml:mtd><mml:mo>&#x0003C;</mml:mo><mml:mi>T</mml:mi><mml:mo>&#x0003E;</mml:mo><mml:mtext>&#x000A0;</mml:mtext><mml:mo>=</mml:mo><mml:mi>P</mml:mi><mml:mo>&#x0003C;</mml:mo><mml:mi>H</mml:mi><mml:mo>&#x0003E;</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<p>The hand reference frame &#x0003C; <italic>H</italic> &#x0003E; is defined by the robot kinematics. The tool reference frame &#x0003C; <italic>T</italic> &#x0003E; applied can be arbitrarily chosen, as long as it is coherent among all the tools that can be considered, as the Pose is expressed in relative terms.</p>
<p>This means that <italic>P</italic> can also be understood as the required transformation to align a tool 3D model from its canonical pose to the pose in which is the tool is being held by the robot, given by the oriented pointcloud model. In this work, this transformation is estimated by aligning the available model of the tool with a partial reconstruction obtained through iCub&#x00027;s disparity.</p>
<p>To that end, iCub first applies the method described in section 2 to identify the tool instance or category and load the corresponding model. Then, it fixates the gaze on the tool&#x00027;s effector and extracts a partial pointcloud reconstruction, using the same methods applied on each of the exploration poses considered for tool reconstruction, as detailed in section 3. Then, the ICP algorithm is applied in order to align the pointcloud model loaded from memory to the partial reconstruction just obtained. Finally, the alignment matrix returned by the ICP is checked to assess whether it corresponds to a feasible grasp pose in terms of translation from the origin and rotation in Z and X axes. If the alignment estimated by ICP corresponds to a feasible grasp, then the returned alignment matrix is assigned to <italic>P</italic>, and applied to transform the canonical pointcloud model available in memory in order to obtain the oriented pointcloud model. This process can be observed in Figure <xref ref-type="fig" rid="F3">3</xref>.</p>
<fig id="F3" position="float">
<label>Figure 3</label>
<caption><p>Example of the tool pose estimation through alignment process. <bold>(A)</bold> Load 3D pointcloud model on canonical pose. <bold>(B)</bold> Extract partial reconstruction using <monospace>seg2cloud</monospace> model (segmentation &#x0002B; depth estimation). <bold>(C)</bold> Find Pose Matrix <italic>P</italic> by aligning 3D model to partial reconstruction. <bold>(D)</bold> Obtain oriented pointcloud model by applying <italic>P</italic> to the 3D model.</p></caption>
<graphic xlink:href="frobt-05-00098-g0003.tif"/>
</fig>
<p>Thereby, after the pose estimation process iCub has explicit information about the precise geometry and pose of the tool in its hand. Therefore, it can apply the method described in section 4.3 to determine the position of the tooltip with respect to the robot&#x00027;s hand reference frame, and hence extend the kinematics of the robot to incorporate the tip of the tool as the new end-effector for further action execution.</p>
</sec>
<sec sec-type="conclusions" id="s6">
<title>6. Conclusion</title>
<p>In the present paper we have introduced the concept of tool incorporation, that is, the process whereby the iCub robot is able to recognize a tool, estimate its geometry, pose and tooltip, and use this information to use the tool as its new end-effector. In particular, we have introduced a repository which implements a set of interconnected methods to perform such tasks in a fast and reliable way on iCub platform. By applying these methods, the robustness of the desired tool use behaviors as well as the ease of implementation can be substantially increased, by reducing the necessity of applying predefined parameters to represent the tools.</p>
<p>Despite its clear advantages, this approach does however suffer from a few limitations. On the one hand, it only works properly with radial tools where handle and effector are clearly distinct and are grasped radially (in the direction of the iCub&#x00027;s thumb). On the other, the 3D reconstruction quality, while generally enough to estimate the tool frame and the tooltip, does yield relatively noisy models. These issues clearly demand further work on tool incorporation mechanisms in order to facilitate robotic tool use.</p>
</sec>
<sec id="s7">
<title>Author contributions</title>
<p>TM is the main author of the code and paper. VT provided technical guidance and assistance, and reviewed both the code and the paper. LN provided high-level supervision, and reviewed the paper before submission.</p>
<sec>
<title>Conflict of interest statement</title>
<p>The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest. The reviewer JAG and handling Editor declared their shared affiliation.</p>
</sec>
</sec>
</body>
<back>
<ref-list>
<title>References</title>
<ref id="B1">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Besl</surname> <given-names>P.</given-names></name> <name><surname>McKay</surname> <given-names>N.</given-names></name></person-group> (<year>1992</year>). <article-title>A method for registration of 3-D shapes</article-title>. <source>IEEE Trans. Pattern Anal. Mach. Intell.</source> <volume>14</volume>, <fpage>239</fpage>&#x02013;<lpage>256</lpage>. <pub-id pub-id-type="doi">10.1109/34.121791</pub-id></citation></ref>
<ref id="B2">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Dehban</surname> <given-names>A.</given-names></name> <name><surname>Jamone</surname> <given-names>L.</given-names></name> <name><surname>Kampff</surname> <given-names>A. R.</given-names></name></person-group> (<year>2017</year>). <article-title>A deep probabilistic framework for heterogeneous self-supervised learning of affordances</article-title>, in <source>Humanoids 2017</source> (<publisher-loc>Birmingham</publisher-loc>). </citation></ref>
<ref id="B3">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Fanello</surname> <given-names>S. R.</given-names></name> <name><surname>Pattacini</surname> <given-names>U.</given-names></name> <name><surname>Gori</surname> <given-names>I.</given-names></name> <name><surname>Tikhanoff</surname> <given-names>V.</given-names></name></person-group> (<year>2014</year>). <article-title>3D Stereo estimation and fully automated learning of eye-hand coordination in humanoid robots</article-title>, in <source>Humanoids 2014</source> (<publisher-loc>Madrid</publisher-loc>), <fpage>1028</fpage>&#x02013;<lpage>1035</lpage>. </citation></ref>
<ref id="B4">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Gon&#x000E7;alves</surname> <given-names>A.</given-names></name> <name><surname>Abrantes</surname> <given-names>J.</given-names></name> <name><surname>Saponaro</surname> <given-names>G.</given-names></name> <name><surname>Jamone</surname> <given-names>L.</given-names></name> <name><surname>Bernardino</surname> <given-names>A.</given-names></name></person-group> (<year>2014</year>). <article-title>Learning intermediate object affordances: toward the development of a tool concept</article-title>, in <source>IEEE International Conference on Development and Learning and on Epigenetic Robotics (ICDL-EpiRob 2014)</source> (<publisher-loc>Genoa</publisher-loc>), <fpage>1</fpage>&#x02013;<lpage>8</lpage>. </citation></ref>
<ref id="B5">
<citation citation-type="other"><person-group person-group-type="author"><collab>Itseez</collab></person-group> (<year>2015</year>). <source>Open Source Computer Vision Library</source>.</citation></ref>
<ref id="B6">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Krizhevsky</surname> <given-names>A.</given-names></name> <name><surname>Sutskever</surname> <given-names>I.</given-names></name> <name><surname>Hinton</surname> <given-names>G. E.</given-names></name></person-group> (<year>2012</year>). <article-title>ImageNet classification with deep convolutional Neural Networks</article-title>, in <source>Advances in Neural Information Processing Systems</source> (<publisher-loc>Lake Tahoe, NV</publisher-loc>), <fpage>1</fpage>&#x02013;<lpage>9</lpage>.</citation></ref>
<ref id="B7">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Mar</surname> <given-names>T.</given-names></name> <name><surname>Tikhanoff</surname> <given-names>V.</given-names></name> <name><surname>Natale</surname> <given-names>L.</given-names></name></person-group> (<year>2017</year>). <article-title>What can I do with this tool? Self-supervised learning of tool affordances from their 3D geometry</article-title>. <source>IEEE Trans. Cogn. Dev. Sys.</source> <fpage>1</fpage>. <pub-id pub-id-type="doi">10.1109/TCDS.2017.2717041</pub-id></citation></ref>
<ref id="B8">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Metta</surname> <given-names>G.</given-names></name></person-group> (<year>2006</year>). <source>Software Implementation of the Phylogenetic Abilities Specifically for the iCub &#x00026; Integration in the iCub Cognitive Architecture</source>. Technical Report 004370.</citation></ref>
<ref id="B9">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Metta</surname> <given-names>G.</given-names></name> <name><surname>Natale</surname> <given-names>L.</given-names></name> <name><surname>Nori</surname> <given-names>F.</given-names></name> <name><surname>Sandini</surname> <given-names>G.</given-names></name> <name><surname>Vernon</surname> <given-names>D.</given-names></name> <name><surname>Fadiga</surname> <given-names>L.</given-names></name> <etal/></person-group>. (<year>2010</year>). <article-title>The iCub humanoid robot: an open-systems platform for research in cognitive development</article-title>. <source>Neural Netw.</source> <volume>23</volume>, <fpage>1125</fpage>&#x02013;<lpage>1134</lpage>. <pub-id pub-id-type="doi">10.1016/j.neunet.2010.08.010</pub-id><pub-id pub-id-type="pmid">20864311</pub-id></citation></ref>
<ref id="B10">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Pasquale</surname> <given-names>G.</given-names></name> <name><surname>Ciliberto</surname> <given-names>C.</given-names></name> <name><surname>Rosasco</surname> <given-names>L.</given-names></name> <name><surname>Natale</surname> <given-names>L.</given-names></name></person-group> (<year>2016</year>). <article-title>Object identification from few examples by improving the invariance of a deep convolutional neural network</article-title>, in <source>2016 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS)</source> (<publisher-loc>Daejeon</publisher-loc>: <publisher-name>IEEE</publisher-name>). <pub-id pub-id-type="doi">10.1109/IROS.2016.7759720</pub-id></citation></ref>
<ref id="B11">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Ren</surname> <given-names>C. Y.</given-names></name> <name><surname>Prisacariu</surname> <given-names>V.</given-names></name> <name><surname>Murray</surname> <given-names>D.</given-names></name> <name><surname>Reid</surname> <given-names>I.</given-names></name></person-group> (<year>2013</year>). <article-title>STAR3D: Simultaneous tracking and reconstruction of 3D objects using RGB-D data</article-title>, in <source>Proceedings of the IEEE International Conference on Computer Vision</source> (<publisher-loc>Sydney, NSW</publisher-loc>), <fpage>1561</fpage>&#x02013;<lpage>1568</lpage>.</citation></ref>
<ref id="B12">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Rusu</surname> <given-names>R. B.</given-names></name> <name><surname>Cousins</surname> <given-names>S.</given-names></name></person-group> (<year>2011</year>). <article-title>3D is here: Point Cloud Library (PCL)</article-title>, in <source>Proceedings - IEEE International Conference on Robotics and Automation</source> (<publisher-loc>Shanghai</publisher-loc>).</citation></ref>
<ref id="B13">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Zhang</surname> <given-names>Y.</given-names></name> <name><surname>Gibson</surname> <given-names>G. M.</given-names></name> <name><surname>Hay</surname> <given-names>R.</given-names></name> <name><surname>Bowman</surname> <given-names>R. W.</given-names></name> <name><surname>Padgett</surname> <given-names>M. J.</given-names></name> <name><surname>Edgar</surname> <given-names>M. P.</given-names></name></person-group> (<year>2015</year>). <article-title>A fast 3D reconstruction system with a low-cost camera accessory</article-title>. <source>Sci. Rep.</source> <volume>5</volume>, <fpage>1</fpage>&#x02013;<lpage>7</lpage>. <pub-id pub-id-type="doi">10.1038/srep10909</pub-id><pub-id pub-id-type="pmid">26057407</pub-id></citation></ref>
</ref-list>
<fn-group>
<fn id="fn0001"><p><sup>1</sup><ext-link ext-link-type="uri" xlink:href="http://https://github.com/robotology/segmentation/tree/master/dispBlobber">https://github.com/robotology/segmentation/tree/master/dispBlobber</ext-link></p></fn>
<fn id="fn0002"><p><sup>2</sup>We refer as radial tools to tools consisting of clearly distinct handle and effector, which are grasped from the handle with the thumb toward the effector of the tool (called radial grip).</p></fn>
</fn-group>
</back>
</article> 