iLab Neuromorphic Robotics Toolkit  0.1
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
Directory structure and module manifests

Core NRT files

Core NRT files are in:

  • /usr/include/nrt/ include files
  • /usr/lib/libnrt*.so core libraries
  • /usr/bin/ core executables, name of most of them starts with nrt (e.g., nrtDesigner, nrtLoader, etc)

NRT modules

NRT modules can in principle be installed anywhere. You just need to follow the general directory structure described here and set your NRTMODULEPATH environment variable. See The NRT Designer for how to set NRTMODULEPATH. Modules that have been installed through the NRT module management system (e.g., installed from the http://nrtkit.org web site are organized as follows):

/usr/share/nrt/modules/<category>/<subcategory>/[optional-additional-subcategs]/<ModuleName>/<version>

where

  • category and subcategory and additional sub-categories are discussed in Packaging System and Contributing Your New NRT Modules
  • ModuleName is the name of your module
  • version is the version number of the module
  • The entire path shown above is world-wide unique and must be negoatiated with the core NRT management team (usually, that simply means that you need to request a unique name in a given category an subcategory).

Then, the contents of each directory is organized as follows:

  • manifest.yaml is the module's manifest (details below)
  • ModuleName.<distro>.<arch>.so is the module's executable object compiled for a particular NRT distribution/release and on a particular architecture (e.g., i386, amd64, etc)
  • ModuleName.<distro>.<arch>.yaml describes the compiled module and its dependencies over other software packages, for a given NRT distribution and on a given architecture. See details below.
  • additional files may include icon.png, screenshots, videos, etc and are described in the manifest

Module manifest.yaml file

A module's manifest describes the module to the outside world. The information provided in the manifest is used both to organize the module repository at http://nrtkit.org and to allow users of the NRT designer to quickly locate a module that achieves some functionality they want. The manifest is formatted using the YAML very simple markup language. Some of the manifest entries can be populated automatically by running a script that will extract information from the source code of your module. Other information can be manually typed in. The manifest contains the following:

general: 
  displayname: Quiver 
  classname: QuiverModule 
  category: /ImageProc/Motion
  synopsis: Quiver plot
  relates: /ImageProc/Motion/MotionField, /ImageProc/IO/DisplaySink
  description: > 
    Quiver plots flow field (velocity vectors) as arrows with components. The
    input flow field is considered as two components. The flow field on x
    and y direction on the image. The background image, if provided, must
    have the same size as the flow fields.
 
  keywords: 
    - quiver
    - flow field
    - optical flow
 
  subscriberports: 
    - name: FlowField
      inmsg: GenericImageSetMessage
      retmsg: void
      description: "Flow Field Image Set"

  checkerports: 
    - name: BackgroundImage
      msg: GenericImageMessage
      description: "Quiver Background Image"

  posterports: 
    - name: OutputImage
      outmsg: GenericImageMessage
      retmsg: void
      description: "Output Image"
 
authorship: 
  author: Pezhman Firoozfam
  email: 
  mainurl: 
  supporturl: 
  otherurl: 
  address: 
 
licensing: 
  copyright: 
  license: 
  distribution: 
  restrictions: 
 
files: 
  icon: icon.png 
  screenshots: 
  videos:
  other: 

Compiled module ModuleName.<distro>.<arch>.yaml file

A module may be compiled for different versions of NRT (and of the underlying operating system, here we call this the distro), and for different architectures (e.g., i386, amd64, etc we call this the arch). Dependencies are packages which are required for the module to run. These will typically be libraries or programs that are used by the module. For example, a module may include a Support Vector Machine classifier and would thus require that the corresponding library be installed on your system.

To each distro/arch combination corresponds a possibly distinct set of dependencies.

os: 
  depends: 
  recommends: 
  suggests: 
  conflicts: 
  replaces: 
  breaks: 
  provides: 
 
package: 
  signature: 
  md5: 

Module localization

Localization is supporting different human languages (e.g., English, French, Chinese). This applies to messages your module may issue and also to the manifest.yaml file. Some fields in the manifest can exist in several languages.

Manifest localization is achieved through localized names for the

  • synopsis
  • description
  • keywords

additional fields can be provided, with language suffixes, for example synopsis_es, synopsis_fr, etc

Related macro-modules

The relation between macro-modules and modules is not hand-coded. Rather, the NRT web server scans macro-modules for modules they contain, and then displays the discovered links.