The rx stack contains GUI-related tools for using ROS, including:

 . rxbag: ROS bag recording, playback and visualization

 . rxgraph: ROS graph visualization

 . rxplot: ROS topic data visualization

 . rxconsole: ROS/rosout logging output

Install .msg files generated from .action under the correct path.

actionlib generated messages are in "build" directory. Without the patch, the
cmake rules for message generation would install those generated .msg under a
wrong path.

Simply add an optional parameter to add_message_file() and add_service_file()
that allows to specify both the source and destination dir of input files,
instead of considering they are the same. This is only used by actionlib and
has no side effect on other packages.

The actionlib package provides a standardized interface for interfacing with
preemptible tasks. Examples of this include moving the base to a target
location, performing a laser scan and returning the resulting point cloud,
detecting the handle of a door, etc.

In any large ROS based system, there are cases when someone would like to send
a request to a node to perform some task, and also receive a reply to the
request. This can currently be achieved via ROS services.

In some cases, however, if the service takes a long time to execute, the user
might want the ability to cancel the request during execution or get periodic
feedback about how the request is progressing. The actionlib package provides
tools to create servers that execute long-running goals that can be
preempted. It also provides a client interface in order to send requests to the
server.

common_msgs contains messages that are widely used by other ROS packages. These
includes messages for actions (actionlib_msgs), diagnostics (diagnostic_msgs),
geometric primitives (geometry_msgs), robot navigation (nav_msgs), and common
sensors (sensor_msgs), such as laser range finders, cameras, point clouds.

The ros_comm stack contains the ROS middleware/communications packages. This
packages are collectively known as the ROS "Graph" layer. They provide
implementations and tools for topics, nodes, services, and parameters. This
includes the supported ROS client libraries: roscpp, rospy, and roslisp.

Some ros python packages require py-setuptools instead of using vanilla
distutils. This has the side effect of installing so called EGG_INFO
directories that behave differently depending on the platform (sometimes the
directory is zipped, sometimes not). The PLIST may then be broken.

Instead of fighting with this, just use distutils instead of setuptools since
setuptools does not bring anything useful in robotpkg (does it?). This is done
via a SUBST stage in setup.py for packages that declare using it.

Affected packages are, so far:
 - ros-gencpp
 - ros-genlisp
 - ros-genpy

Factor out the following:
 - PKGNAME with ros- prefix. This is overrided for a few base pkgs only
 - MAINTAINER
 - LICENSE

These can still be overriden on a per pkg basis.

std_msgs contains common message types representing primitive data types and
other basic message constructs, such as multiarrays. For common, generic
robot-specific message types, please see common_msgs.

std_msgs contains wrappers for ROS primitive types, which are documented in the
msg specification. It also contains the Empty type, which is useful for sending
an empty signal.

This package also contains the "MultiArray" types, which can be useful for
storing sensor data.

Meta package modeling the build-time dependencies for language bindings of
messages in ROS.

Meta package modeling the build-time dependencies for language bindings of
messages in ROS.

Lisp code generator for ros .msg and .srv files

python code generator for ROS .srv and .msg files

C++ code generator for ROS .msg and .srv files

Project genmsg exists in order to decouple code generation from ROS .msg & .srv
format files from the parsing of these files and from impementation details of
the build system (project directory layout, existence or nonexistence of
utilities like rospack, values of environment variables such as
ROS_PACKAGE_PATH): i.e. none of these are required to be set in any particular
way.

This module provides a simple interface to record some trajectory and
then replay it.

The CmakeFile of catkin is able to find either the standalone script, or the
python package. It looks like catkin is happy with both.

- Adapt to newest ros18-base/Makefile.common
- Add a depend.mk
- Fix PLIST

py-rospkg is not available from the same repositories as the rest of ros-base,
so use a standard Makefile for fetching it from github.org/ros

While here, update to 1.0.7 (changes unknown).

http://packages.ros.org/ros/ubuntu/pool/main/r/ seems to contain at least the
latest release tarball of ros-base. Go for it, until there is yet another new
location.

It makes the link between hyper, the supervision framework, and genom
modules that it must control.

Hyper is an implementation of the ROAR supervision framework.

API change since RC2 can cause a "issues"...

Final version, warning API change since RC2

	- new gyroTypes.{h,idl} headers and common init function.
	- renamed pkg-config file

This unifies gyroKVH1000 and gyroKVH5000 packages.