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.

Nothing really working here, just committing WIP.

Add configure/Makefile scripts, and try to make this robust.
This needs testing.

This package implements new geometry types in Kineo that can be used
in collision checking and proximity queries.

New geometries:
  * Capsule (Cylinder with two half-sphere caps)
  * Segment

  Low pass filters and Bayesian filters for sensor fusion: vision
  and forces

- Delete stackoftasks from toplevel SUBDIR
- Comment out an include of delete stackoftasks file in wip/sot-gui. Should
  wip/sot-gui be removed too?

Given the continuous control trajectory provided by the navigation module (MPC
avoidObs), the MPC controller is aimed at cheking if the control trajectory is
still valid and admissible for the robotic system (respects its motion
constraints) and computing a command to provide as input of the robotic system.