<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/08/2013 12:33 PM, Sylvain Joyeux
wrote:<br>
</div>
<blockquote
cite="mid:20131108113351.2AE33A679A_27CCC1FB@sea-mail.dfki.de"
type="cite">On 11/08/2013 10:35 AM, Alexander Duda wrote:
<br>
<blockquote type="cite">To not block the hole process we could
also think of creating a new
<br>
package for vision related types and deprecate the one we have
in base
<br>
(the tooling is already supporting this particular case).
<br>
</blockquote>
Doing it this way also has drawbacks, namely that we'll have
fragmentation between the components that use the new type(s) and
the components that use the old types.
<br>
<br>
But, in general, we did start talking about using as much of the
types directly from the "established libraries": opencv for
images, pcl for point clouds, ...
<br>
<br>
</blockquote>
Still pcl::Pointcloud does not have uncertainty information.<br>
<br>
I agree with it in case of well established libraries. However, I
have my doubts on how to organize it. Instead of creating optional
dependencies. One possible suggestion would be to organize the types
per package set. <br>
<ul>
<li>base would have the basic types: Time, Eigen, Temperature,
Joints, Angle, RigidBodyState, etc.. as well as current types to
support backward compatibility.<br>
</li>
<li>perception (could be a rename for image_processing) would
have opencv::Mat, pcl::Pointcloud, cv::detail::ImageFeatures,
etc...</li>
<li>slam would have dedicated slam types</li>
<li>planning would have common planning classes perhaps using some
SBPL, MoveIt types<br>
</li>
<li>control would have the correspondent control types.<br>
</li>
</ul>
Question: Is there any inconvenient to organize the types in such a
way?<br>
<br>
Javier.<br>
<br>
</body>
</html>