This GUI displays plans as tree and streams. It also stroe all the requests sent
to HATP.

This library includes a server and client definition. It should be used in
any software that has to communicate with HATP.
When a client starts, it registeres itself to the server. Then when another
client wnats to communicate it needs to use the name of the first client,
the server will relay the message to the correct client. There must not
be two clients with the same name because if one leaves then when the second
will leave ther server will crash.

It provide tools to handle a plan generated with HATP. It includes a parser
that build a plan from a string (the one returned by HATP as answer to a
plan request).

All ros-fuerte packages have been moved to robotpkg

Following the author's advice, re-enable this package but disable parallel
jobs, because some files make gcc grow up to 1GB during compilation. This is an
issue with the current setup for bulk builds.

This raises too many issues with the current bulk + virtualbox setup.

gcc eats more than 1GB, especially for a couple of source files, and it either
segfaults after reaching the datasize/stacksize limit or compiles for hours,
preventing the rest the bulk from being properly tested.

This template produces encoding and decoding functions in a module
(which can be loaded by an Openprs kernel), as well as basic OPs to
have OpenPRS to be a client of a genom3 module (using the
{ros,pocolibs}/client/c library.

tcl-genomix package provides a TCL package that interacts with the genomix HTTP
server and can control GenoM3 components.

It can prompt interactively for arguments of services. Services can be invoked
synchronously or asynchronously and callbacks can be triggered whenever
services complete.

tcl-genomix is best used in combination with the interactive eltclsh shell.

The genomix HTTP server is a generic interface between clients and genom
components (using the generic genom C client template). Control is done be the
mean of specific HTTP GET requests (not yet documented...).

The genom3-ros template (see meta-pkgs/ros-base) provides a GenoM3
template for generating ros-based components.

The genom3-pocolibs template (see middleware/pocolibs) provides a GenoM3
template for generating pocolibs-based components.

The Generator of Modules GenoM is a tool to design real-time software
architectures. It encapsulates software functions inside independent
components. GenoM is more specifically dedicated to complex on-board systems,
such as autonomous mobile robots or satellites, that require:

. The integration of heterogeneous functions with different real-time
  constraints and algorithm complexities (control of sensors and actuators,
  data processings, task planification, etc.).

. An homogeneous integration of these functions in a control architecture which
  requires coherent and predictable behaviors (starting, ending, error
  handling), and standard interfaces (configuration, control flow, data
  flow).

. The management of parallelization, physical distribution and portability of
  the functions.

. Simple procedures to add, modify or (re)use the functions by non-specialists

GenoM generates the source code of components by using:

. A generic template, common for all components. This guarantees that all
  components share the same consistent behaviour. The template itself is not
  part of GenoM, so that different template kind can be developped easily.

. A formal description of the components interface. This description is based
  on a simple language using OMG IDL for data types definitions and a custom
  syntax for the description of a more detailed component model.

The project is released under an open-source, BSD-like license.

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

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.

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.

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.