Stéphane Magnenat's profile - activity

Hello,

As already discussed in question #2701, I am working on the release of the modular_cloud_matcher package.

This package depends on libnabo and libpointmatcher, for which I provide Ubuntu packages for the last 4 releases (from Lucid to Oneiric) on my PPA. As there is currently no way to tell rosdep to fetch packages from a PPA, in a previous discussion with Tully Foote we agreed that the user will have to install these packages by hand.

The question then is whether I should add these as package dependency in the rosdep.yaml, and if so, what to do with non-ubuntu systems. Should I provide a script that fetches the packages and "cmakes/makes/makes install" them? If so, is there a way to provide an "other" or "default" target in rosdep.yaml? Or should I leave these dependencies out and let the user install libnabo and libpointmatcher by hand?

I will be happy to hear your opinion on the best practice in this context. Thank you!

The modular_cloud_matcher package requires yaml-cpp, which is installed in the ros-wide rosdep.yaml in electric but not in diamondback. For the latter, I had put an entry in our rosdep.yaml:

yaml-cpp:
ubuntu: yaml-cpp0.2.6-dev

This entry solves the problem for diamondback, but creates a conflict in electric:

[ rosmake ] rosdep install failed: QUITTING: due to conflicting rosdep definitions, please resolve this conflict.
Rules for yaml-cpp do not match:
{'apt': {'packages': ['yaml-cpp0.2.6-dev']}} [/opt/ros/electric/stacks/common_rosdeps/rosdep.yaml]
yaml-cpp0.2.6-dev [/opt/ros_addons/electric/stacks/ethzasl_mapping/rosdep.yaml]

Is there a way to specify rules specific to different ros releases in rosdep.yaml?

The answer given by Patrick works, but misses the point of teer. A better solution would be to have self.move_base_done as a ConditionVariable, so that the co-routine is automatically un-paused when this variable becomes true. Please see this tutorial page for more informations about condition variables.

The links are:

• http://www.ros.org/wiki/ethzasl_icp_mapping
• http://www.ros.org/wiki/ethzasl_icp_mapper

The names of this package have changed, now they are:

• https://github.com/ethz-asl/ethzasl_icp_mapping
• http://www.ros.org/wiki/ethzasl_icp_mapping
• http://www.ros.org/wiki/ethzasl_icp_mapping

The error link is broken.

http://answers.ros.org/question/33622/openni_launch-not-working-in-fuerte-ubuntu-precise/ discusses the question in details...

After some more in-depth experiments, it seems that openni_camera is crashing often here on fuerte/12.04

I have the same problem under fuerte/12.04. I also get the boost assert (also mentioned in http://answers.ros.org/question/11925/ros-kinect-roslaunch-openni_launch-opennilaunch/). Before this assert, I get one threading-related python exception per process:

Exception AttributeError: AttributeError("'_DummyThread' object has no attribute '_Thread__block'",) in <module 'threading' from '/usr/lib/python2.7/threading.pyc'> ignored

The problem seems to be a conflict with the Linux driver. Removing it with

sudo modprobe -r gspca_kinect

and

sudo modprobe -r gspca_main

solves the problem.

Does it mean that in the future, rosdep 2 will not be included in the deb and therefore should always be installed by pip? What will happen for the "normal" user?

Thanks for the answer. It would be good if during the time the deb packages are in shadow, debbuild report would not show the package as "broken" as it does now.

I am trying to release executive_teer into unstable, but the build system does not create a debian package, for a reason I cannot explain. See for instance this log.

Hello,

I am the maintainer of modular_cloud_matcher, and while I'm aware of ROS' repulsion of the use of C++0x, I decided to use it nevertheless because it made the code much cleaner and worked for the main ROS platforms starting from GCC 4.4 (Ubuntu Lucid). I did not use any features not explicitly supported and tested with GCC 4.4. Moreover, I think that it is good people begin testing ROS with C++0x as it will help with the eventual transition.

I did not expect too much problems such as this one to happen, as C++0x is supposed to be highly backward compatible, but it does happen sometimes.

I have created patches that fix these issues, see the related ticket

Thank you for the answer. I am now using git submodules to fetch the upstream teer in a subdirectory inside teer_ros. That should solve the issue nicely.

Could you try again? Without any addition information it is difficult to help you trace the source of the problem.

Hello,

I am using git_chekout.mk in http://www.ros.org/wiki/teer to fetch teer's source code into ROS. Currently, there is no "Code API" generated for it; is it because the generator is busy/overloaded or because it is not supposed to index fetched code? If the latter explanation is the right one, what is the best practice to document inside ROS code fetched from outside (be it with git_checkout, svn_checkout or tarball's import)?

Thank you, kind regards

We've been moving away from wrapping system-installable libraries in ROS packages. It leads to less portable code, as you end up using ROS-specific linking methods to use these libraries.

Instead, as much as possible, we are now trying to:

• provide debs for these libraries on Ubuntu (we will hopefully make this toolchain available for packages.ros.org, but it still needs a lot of work)
• provide an exemplar 'source rosdep' (REP 112) that is somewhat equivalent to the download_and_unpack-style builds, except they attempt to do system installs.

A valid criticism of source rosdeps is that they don't come with an uninstall mechanism. That said, the main role of the source rosdeps, IMHO, is to provide a starting point to people on other platforms. They are generally equivalent to what that user would have done if they had to manually download the source and install on their own.

We try to shy away from PPAs for libraries, as Ubuntu does, as they lack safety guards to prevent downstream issues.

Hello!

Well, this is certainly one way, but it has some disadvantages: using distro packages allows to fix bugs and add API-compatible features (for instance new filters in libpointmatcher) without requiring a recompilation of the ROS package. The problem is that the reality of the research landscape is complex and that one often wants to use a lib with ROS in a project and as a standalone utility in another project. But I agree that providing only Ubuntu packages is not so nice. Fedora packages of libnabo and libpointmatcher would be very welcomed, but this is another question.

So I see three solutions:

• Using rosdep.yaml to fetch and install the libraries in /opt/ros, possibly using apt-add-repository without rosdep.yaml on Ubuntu.
• Providing a wrapper ROS package.
• Using system package on Ubuntu and manual installation on other distros.

None of these solutions please me, as they all have major drawbacks.

Also, my question remains open: Is there a way to provide an "other" or "default" target in rosdep.yaml? Also it seems that rosdep's documentation is a bit outdated, for instance there is currently nothing in /opt/ros/lib or /opt/ros/include and ROS does not seem to use these locations.