[ros-users] Importing / including a new library into ROS (OctoMap)

[Tully Foote]

Armin,

Another option would be to simply add the manifest to octmap/trunk to make
it a proper ROS package itself and put the octmap_server package into
alufr-ros-pkg.  This is an unobtrusive way to convert the existing source.
And it keeps the octomap package clean of ROS specific stuff, except the
manifest which all other systems will ignore.  And the server package is in
a ROS repo, which doesn't add any extra dependencies there either.

For simplicity the octomap package could be added to alufr-ros-pkg with an
svn external then, however as convenient as externals are they make it
harder to understand the structure of a system for newer users.  If one of
the servers is down you won't get all your code, but it won't be obvious
why, because it's talking to another server the user didn't know about.  Of
course this does require one more explicit checkout if you don't, so there's
a trade off.  However if you create a standard rosinstall file to install
from it should not be a high overhead.

Tully






On Fri, Apr 23, 2010 at 9:09 AM, Brian Gerkey <gerkey at willowgarage.com>wrote:

> hi Armin,
>
> This is an interesting case.  To date, we've brought in non-ROS
> libraries via shell packages that download the source for one of two
> reasons:
>  * we don't control the external repo (e.g., Eigen, GMapping); or
>  * we do control the external repo, but prefer not to put anything
> ROS-specific in it (e.g., Gazebo, Stage, OpenCV).
>
> In your case, you control the external repo, and are happy to put ROS
> "bindings" in it.  I can see the argument for putting the ROS packages
> in the octomap repo.  But I think that, at least for now, it would be
> better to keep them separate (i.e., put the ROS packages in your alufr
> repo).
>
> The reason is that our tools assume that the top-level directories of
> a ROS repo are all either stacks or packages.  As it's currently
> organized, the octomap code lives outside of any package or stack.
>
> E.g., to retrieve octomap via rosinstall, you'd have to specify /trunk
> of your repo, so that it would get octomap itself, plus the 'ros'
> subdirectory.  But rosinstall would add /trunk to ROS_PACKAGE_PATH,
> because it doesn't know any better.  In practice, this would likely
> only cause minor performance issues (because rospack would dive into
> the octomap source tree looking for packages whenever it did a crawl).
>
> You'd also have problems using our toolchain to build binary (e.g.,
> Debian) packages; I don't know wheter the octomap part of the tree,
> not being inside a package, would carry over into the binaries.  And
> if this works now, it probably won't later, once rosbuild learns how
> to do an 'install'.
>
> But if you prefer to keep it the way you have it now, we don't
> certainly don't mind adding a small repository to our list.
>
>        brian.
>
> On Fri, Apr 23, 2010 at 1:56 AM, Armin Hornung
> <HornungA at informatik.uni-freiburg.de> wrote:
> > Hi!
> >
> > I was wondering what the right "ROS way" would be to include an
> > opensource library (complete with Doxygen documentation) into ROS. With
> > my colleagues, we developed a 3D mapping framework based on octrees
> > (http://octomap.sf.net/, will be presented at the BRICS workshop at
> > ICRA) which is available under GPL in its own Sourceforge repository.
> >
> > In the source tree (see
> > http://octomap.svn.sourceforge.net/viewvc/octomap/trunk/), there's a
> > "ros" directory which can be added to the ROS_PACKAGE_PATH. In there,
> > there's a sort of "virtual" octomap package that provides the flags for
> > linker and compiler. That all works nice and the library can be used in
> > other ROS nodes as well. But how would that be correctly integrated into
> > the ROS repository structure? Does that nearly empty "virtual" package
> > in a subdirectory pose a problem? Would you mind adding a repository to
> > the list of ROS repositories that just contains one library?
> >
> >  From what I've seen with other external libraries (e.g. Eigen, OpenCV),
> > the ROS package is a similar forwarding package which in addition
> > downloads and installs the library from an external location. That would
> > also work, we could put the ROS octomap in our existing "alufr-ros-pkg"
> > ROS repository, which would then pull the code from the "real"
> > octomap-SVN at sourceforge. It just didn't seem the right thing to do to
> > create another step for installing and downloading when you have control
> > over the original repository anyways. Plus, we would need to take care
> > that the code in the two repositories stays in sync in terms of the API,
> > instead of changing things only in one place.
> >
> > Maybe there are other ideas on what to do (e.g. with svn:externals?), or
> > is the current repository / folder structure the way to go?
> >
> > Cheers,
> > Armin
> >
> > --
> > Armin Hornung                              Albert-Ludwigs-Universität
> > www.informatik.uni-freiburg.de/~hornunga<http://www.informatik.uni-freiburg.de/%7Ehornunga>  Dept. of Computer Science
> > HornungA at informatik.uni-freiburg.de        Humanoid Robots Lab
> > Tel.: +49 (0)761-203-8010                  Georges-Köhler-Allee 79
> > Fax : +49 (0)761-203-8007                  D-79110 Freiburg, Germany
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users at code.ros.org
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>



-- 
Tully Foote
Systems Engineer
Willow Garage, Inc.
tfoote at willowgarage.com
(650) 475-2827
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100423/a7f561a3/attachment-0003.html>