Difference between revisions of "Modules - Standard v0.1"

From Asibot & HOAP3 & TEO Wiki
Jump to navigation Jump to search
(Created page with 'This page should contain guidelines for designing new modules for the software architecture. The intention of this is to keep internal coherence and compatability with RoboticsLa…')
 
Line 10: Line 10:
 
** The description of the module implementation.
 
** The description of the module implementation.
 
** The short-nomenclature data type identifier.
 
** The short-nomenclature data type identifier.
** The port I/O identifier: 'i' for input, 'o' for output, 'io' for input/output.
 
 
* Each internal variable related with communication (bottle, int...) should contain:
 
* Each internal variable related with communication (bottle, int...) should contain:
 
** The descriptor such as 'bottle', 'int'...
 
** The descriptor such as 'bottle', 'int'...
 
** The short-nomenclature data type identifier.
 
** The short-nomenclature data type identifier.
** The port I/O identifier: 'i' for input, 'o' for output, 'io' for input/output.
+
** The I/O identifier: 'i' for input, 'o' for output, 'io' for input/output.
  
 
  \** Example **\
 
  \** Example **\
 
  Parent Directory: drivers
 
  Parent Directory: drivers
 
   Module: drv_fake
 
   Module: drv_fake
   Ports: fake_q_io
+
   Ports: fake_q
 
   Internal Parameters: bottle_q_i, bottle_q_o, double_q_i[], double_q_o[]...
 
   Internal Parameters: bottle_q_i, bottle_q_o, double_q_i[], double_q_o[]...
  
 
== Recommended module folder structure ==
 
== Recommended module folder structure ==
  
Each module directory should contain the following structure (full implementation is not necessary):
+
The intention of defining this should be (cada proyecto sea autocontenido). Each module directory should contain the following structure (full implementation is not necessary):
 
* extern/
 
* extern/
 
** bin/
 
** bin/

Revision as of 17:33, 24 December 2009

This page should contain guidelines for designing new modules for the software architecture. The intention of this is to keep internal coherence and compatability with RoboticsLab robot modules who follow this standard. A list of available modules can be found at the description of modules page.

  • Each directory in the trunk folder structure should contains modules that represent the same single block in the control block diagram.
  • Interfaces should be the same throughout all the modules in the same directory, to assure interchangability.
  • When the module is a hardware interface, it is recommended to create a dummy (fake) module too for debugging purposes of other modules in absence of hardware component or simulator equivalent.
  • Each module name should contain (in order, lower-cased, and separated by underscores):
    • A three letter prefix that represents the name of the parent directory.
    • A description of its implementation.
  • Each port should contain:
    • The description of the module implementation.
    • The short-nomenclature data type identifier.
  • Each internal variable related with communication (bottle, int...) should contain:
    • The descriptor such as 'bottle', 'int'...
    • The short-nomenclature data type identifier.
    • The I/O identifier: 'i' for input, 'o' for output, 'io' for input/output.
\** Example **\
Parent Directory: drivers
 Module: drv_fake
 Ports: fake_q
 Internal Parameters: bottle_q_i, bottle_q_o, double_q_i[], double_q_o[]...

Recommended module folder structure

The intention of defining this should be (cada proyecto sea autocontenido). Each module directory should contain the following structure (full implementation is not necessary):

  • extern/
    • bin/
      • linux-x86/
      • win32/
      • ...
    • include/
    • lib/
      • linux-x86/
      • win32/
      • ...
  • mk/
    • msvc9/
    • linux-x86/
    • ...
  • out/
    • data/
    • win32/
    • linux-x86/
    • ...
  • src/
  • AUTHORS
  • INSTALL
  • install-win32.txt

Notes:

  • extern/ is intended for 3rd party libraries.
  • data/ is intended for inclusion of multiplatform (shared) data for execution of the program, such as 3d models, etc...
  • out/win32/, out/linux-x86, etc, must contain the platform-specific shared libraries and other complements necesary for the execution of the resulting application or library.