Repository Template

Generalities

This page illustrate the structure of the AIRLab Subversion repository of source code for robots (and other devices).

The repository is subdivided into two separate sections:

1. generic_libraries containing software packages that implement single robot functionalities in the form of libraries for general use. Each library must be a stand-alone package with its own Makefile, to be compiled separately.
2. specific_modules, containing software packages that are dedicated to specific robots (or other devices). Each package can take one of the following forms:
   1. A complete [Ros Howto | ROS] package implementing all the functionalities of the device, able to operate on its own as a ROS system (including launchfiles);
   2. One or more Ros Howto | ROS nodes implementing one of the functionalities of the device, ready for integration into larger ROS systems but not able to operate on their own as ROS systems;
   3. a special-purpose software library which is dedicated to the device, the function of which is too specialized for inclusion in the generic_libraries section of the repository. In this case it is mandatory to provide, along with the library, a ROS wrapper in the form of one or more ROS nodes: the ROS wrapper is the only allowed method to access the library.

Design criteria

Whoever develops software for AIRLab must comply with the following criteria for software design and inclusion in the Subversion repository.

1. Everything must be sufficiently documented.

Software is considered "sufficiently documented" if the following condition is verified.

Any person with generic experience in robotics and programming but no idea whatsoever of what the software does is able, after reading only the files available within the software (including accompanying documents and comments at the head of source code files) to do all of the following:

• understand what the software is for;
• understand what each individual file belonging to the software is for;
• understand how the functionalities of the software can be used (by other software);
• compile the software.

1. A full-functionality test application must be provided.

• compile and execute a test application that is part of the software;
• verify if every functionality of the software is correctly operating, using only the test application.

Structure of the repository

The following is a template for the structure of the AIRLab Subversion source code repository. Elements in italic are examples (some of them are actual software modules developed in AIRLab, other are placeholders for "legacy" packages which do not comply with the repository's structure and will be replaced with newer versions and/or newer software).

• generic_libraries
  • behavior
  • brian
  • fuzzy
    • fuzzy_library1
  • obstacle
    • fuzzy_library1
  • logging
    • logging_library1
  • motor_control
    • logging_library1
  • multi-robot
    • scare
  • odometry
    • odometry_library1
  • planning
    • spike
  • play_media
    • media_library1
  • pose
    • ARToolKit-based_library1
  • safety
    • radio_remote
  • sensor
    • laser
      • hokuyo
    • sonar
      • AIRLab_sonar_board
    • vision
      • AIRLabProsilica

• specific_modules
  • wheelchair
  • Triskar2