[Rock-dev] changes for base::type::PointCloud

Alexander Duda Alexander.Duda at dfki.de
Mon Oct 10 16:06:52 CEST 2011


On Mon, 2011-10-10 at 14:44 +0200, Jakob Schwendner wrote:
> Hi Alex,
> 
> On 10/10/2011 02:36 PM, Alexander Duda wrote:
> > I looked into the base type point cloud and I missing the ability to
> > save informations for each point. Because of that and a different naming
> > conventions than we use, I would like to do the following changes:
> >
> > * rename pointcloud.h to point_cloud.h
> > * rename base::samples::Pointcloud to base::samples::PointCloud
> envire also uses Pointcloud instead of PointCloud. Should stay as it is 
> for consistency.

I think it is more important to be consistent over all base types than
to be consistent between envire::Pointcloud and
base::samples::PointCloud.

Furthermore so far there is no relation between envire::Pointcloud and
base::samples::PointCloud. I looked into the implementation of envire,
the following types can be stored with each point:
--> Eigen::Vector3d (vertex color, vertex normal)
--> double (vertex variance)
--> enum (vertex attribut)

For me this are attributes that does not relay belong to a point in a
point cloud. Envire is using the point cloud to store vertex information
which should probably better be stored in a more specialized class
(PolyData for example).  

Nevertheless I agree it would be nice to to use a more generalized 
way to save channel information. I do not really like the copy overhead
for a function like getChannel<Type>(name ), but on the plus side, we
could reduce the message size dramatically for information which does
not need float. Therefore I think it is a good way to store the data,
like you said, as uint8_t.

> > * move base::Point to base::samples::point_cloud::Point
> > (otherwise Point should go into its own header)
> ok.
> > * add a new vector field for channel informations
> >
> > OLD VERSION:
> > namespace base {
> >      typedef base::Vector3d    Point;
> >
> >      namespace samples {
> >          struct Pointcloud
> >          {
> >              Time time;
> >
> >              std::vector<base::Point>  points;
> >          };
> >      }
> > }
> >
> > NEW VERSION:
> > namespace base{ namespace samples {
> >      namespace point_cloud {
> >          struct Channel
> >          {
> >              std::string name;
> >              std::vector<float>  values;
> >          };
> >          typedef base::Vector3d Point;
> >      }
> >
> >      struct PointCloud
> >      {
> >          base::Time time;
> >          std::vector<point_cloud::Point>  points;
> >          std::vector<point_cloud::Channel>  channels;
> >      };
> > }}
> >
> > I talked to the guys which are using the type and it is fine for them
> > therefore I am going to push the changes at the end of the day if no one
> > is yelling ;-).
> About the channel information, the problem is, that you most likely want 
> very different types (or at least this was the case in envire). One way 
> would be to use a uint8_t instead of the float and provide some 
> functions to convert the data to your type, like e.g. getChannel<Type>( 
> name ).
> It's doubling the metadata mechanism in envire, but then I don't have a 
> good solution right now, to combine envire and orogen types better, 
> without rewriting a lot.
> 
> Jakob

-- 
Dipl.-Ing. Alexander Duda 
Unterwasserrobotik

DFKI Bremen
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-456620
Fax:   +49 (0)421 178-454150
E-Mail: alexander.duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3



More information about the Rock-dev mailing list