In version 1.1.0, razor-imu-9dof depends on dynamic-reconfigure.

On the meta-ros issue tracker, the issue #291 reports a
linking problem with rosconsole if ROS Hydro is also installed
on the host system. Kristof investigated in that, and published
a patch [1] on September 27th, 2014, which resolved the rosconsole
issue, but showed issues with urdfdom.

After reading through the discussion of issue #291, I started
initial testing with Kristof's patch. After testing Kristof's
patch, I also investigated the urdfdom problem, and came up with
the solution to revert the part of his patch, which moved
`-DCMAKE_INSTALL_PREFIX:PATH='${ros_prefix}'` to ros.bbclass.

Initially, I believed that the issue that was addressed with
the second part of Kristof's patch, has been resolved with
commit 7e2eb25e. However,
the issue remains, but is only reproducible with the Ubuntu
saucy distribution.

On my first local setup, I could reproduce the issue #291 with
rosconsole on commit 47eab426.
After applying this commit, the issue with rosconsole did not
occur anymore on a clean fresh build.
`bitbake packagegroup-ros-world` did not show any other further
issues.

On my second local setup, on a newly-installed Ubuntu 12.04
(precise) system, I checked that the proposed commit resolves
some linking problems to boost, with some latest
OpenEmbedded-Core repository and the poky-dizzy distribution.
A detailed report of the investigation of this second local
setup is at my Github Gist [2].

In the first review of the pull request #318, Kristof noticed
that on an Ubuntu 13.10 (saucy), an issue with message-filters
still occurs. I could not reproduce this and other reported
errors on the Ubuntu 12.04 system, so I believe certain errors
only appear on certain Ubuntu distributions, which makes them
difficult to pinpoint. Therefore, we decided to defer the
resolution of this problem with Ubuntu 13.10.

To adjust to the concurrent work in pull request #319, during
the rebasing, the patch has been moved from the catkin directory
to the files directory.

Kristof remains the author of the applied patch, as I have not
modified the patch. I have put myself as this author's commit,
as I take the responsibility of the modifications compared to
Kristof's original work and I have tested this commit in my
test setting.

[1] https://github.com/KristofRobot/meta-ros/commit/9ff76ffb7a5aaa076a89a378e92d41adbfeb9b38
[2] https://gist.github.com/bulwahn/a8d5b7c27550b399f866



Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>

catkin: move to files directory (fixup)

 Reduction of runtime dependencies

The catkin package has got a runtime dependency to cmake, make,
gcc and other build utilities. These dependencies, however, are
only needed if it is desired to build with catkin on the target
board. If we do not want to build on the target board, i.e., if
we just want to use ros tools like roslaunch, only a small part
of catkin (i.e., the corresponding python packages) is required
to be deployed on the target board.
Therefore, we introduce a new package called catkin-runtime.
It installs only the python packages that are required for
the ros tools to run. The roslib package now depends on
catkin-runtime (previously: catkin).

I also tried an alternative approach which just modifies catkin.bb:
- add a catkin-runtime package
- move PYTHON_SITEPACKAGES_DIR from FILES_catkin to FILES_CATKIN_RUNTIME
- make catkin_runtime RDEPEND on the python stuff
- make catkin RDEPEND on the cmake, binutils, ..., + catkin-runtime
With this setup, for some reason, bitbake thinks that
catkin-runtime still RDEPENDS on binutils. Therefore, I split up
the catkin recipe into two different recipes. Here, the
RDEPENDS are managed correctly.

If we want to deploy catkin as a build tool on the board, we can
simply add a runtime dependency to catkin. However, this should
not be the default setup.
Special thanks go to Tobias Henkel (tobias.henkel@bmw-carit.de)
who deserves most of the credits for this patch.

Signed-off-by: Andreas Baak <andreas.baak@bmw-carit.de>

When roslaunch is started, it checks the file size of the local log
directory by calling:

    disk_usage = rosclean.get_disk_usage(d) [1]

The function `get_disk_usage` [2] in rosclean creates a subprocess and
calls `du -sb` on Linux systems (cf. [3]).

However, the `du` command, which busybox usually provides on an
embedded Linux image, does not support the `-b` option, and only the
`du` command from the coreutils [4] supports this option.
This issue was first reported in April 2013 on the meta-ros issue
tracker [5]. Hence, on the first iteration of this issue, the
commit db0c8d5c [6] simply adds the dependency on coreutils to
roslaunch.

However, this has certain disadvantages:
  - coreutils is licensed under GPLv3 and must not be deployed in a
    product, which is massively distributed to customers.
  - coreutils has larger file-system foot print than busybox and makes
    the minimal Linux images considerably larger.

As a fortuitous circumstance, Alexis Ballier [7] had already observed
this disadvantage and provides a patch [8, 9] that makes
`get_disk_usage` use `du -k`, which works with busybox and coreutils.

So, on the second iteration of this issue, this commit here patches
rosclean's `get_disk_usage` function with the aforementioned patch.
This slightly modifies the semantics of this function. However, I
believe this plays only a minor role for the overall intended
functionality to check if the log usage has reached a critical file-size
limit, and it allows us to remove the dependency on coreutils, which is
much more critical.

Andreas Baak reported the disadvantages of the previous solution, which
triggered the re-investigation. The current resolution has been
discussed and worked out in collaboration with Andreas Baak.

[1] https://github.com/ros/ros_comm/blob/9da29441f32575deb90ee73c9602a5527aacc966/tools/roslaunch/src/roslaunch/rlutil.py#L63
[2] https://github.com/ros/ros/blob/c6e91f9af1410ef183cfa273a7395f896d2d2a1f/tools/rosclean/src/rosclean/__init__.py#L120
[3] https://github.com/ros/ros/blob/c6e91f9af1410ef183cfa273a7395f896d2d2a1f/tools/rosclean/src/rosclean/__init__.py#L130
[4] http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/recipes-core/coreutils/coreutils_8.23.bb?h=master
[5] https://github.com/bmwcarit/meta-ros/issues/60
[6] https://github.com/bmwcarit/meta-ros/commit/db0c8d5cd1700174888071a6f617d307a2e050e0
[7] https://github.com/aballier
[8] https://github.com/ros/ros/pull/76
[9] https://github.com/aballier/ros/commit/bbf1f945c7e3a54efca912d38fe8b1b2f5b63988



Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>
Signed-off-by: Andreas Baak <andreas.baak@bmw-carit.de>

tuning und updating

I discovered the linking issue while investigating #291.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>

work on octomap and README.md

When I investigated the issue #291 with Kristof's patch applied,
I noticed that `bitbake octomap` failed.

Due to my inspection, I believe that the inheritance on ros
was only needed as the ROS_SPN and ROS_SP variables were used in
the recipe. After simply using the default variables, BPN and BP,
I removed the inheritance on ros.

Furthermore, as meta-ros only has one recipe for octomap base
library for now, we do not need to split the recipe definition
in an include and a recipe file.
Probably, this was done as premature optimization believing
that the libraries from the octomap repository, e.g., octovis,
would be added shortly after.

Testing with `bitbake packagegroup-ros-world` reported no errors.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>

hector-mapping: initial commit

frontier-exploration: initial commit

updates and tuning until mid of January 2015