Software architecture

ViSP software architecture

Since ViSP 3.0.0, we design a new modular software architecture where ViSP capabilities are grouped in several modules (core, io, gui, vision, …). In ViSP 3.1.0 we introduced a new module called imgproc. As a result, the user will find several shared or static libraries, one for each module. The following figure highlights the module dependencies and the third-party libraries that may be used by each module. The central module is the core module. All other modules depend on core.

Diapositive1-crop
ar 3rdparty_ar blob imgproc core 3rdparty_core detection 3rdparty_detection gui 3rdparty_gui io_module 3rdparty_io klt 3rdparty_klt mbt 3rdparty_mbt me robot 3rdparty_robot sensor 3rdparty_sensor tt ttmi vf vision 3rdparty_vision vs
Figure legend

ViSP modules overview

  • core: a module defining basic data structures (image, matrices, camera). This module is used by all other modules. To enable some capabilities, this module may use optional 3rd parties libraries.
  • io: this module completely optional allows to manage image or video I/O and command line parsing. To enable some capabilities, this module may use optional 3rd parties libraries.
  • gui: this module also completely optional allows to display images on a screen window and allows also to plot in real-time the evolution of some variables. To enable some capabilities, this module may use optional 3rd parties libraries.
  • ar: augmented reality module. This module needs optional 3rd parties libraries.
  • detection: barcode and face detection. This module need optional 3rd parties libraries.
  • robot: real (Afma4, Afma6, Viper, Pioneer, Panda from Franka Emika) and simulated robot (free flying camera, Afma6, Viper, Pioneer) interfaces. This module uses optional 3rd party libraries.
  • imgproc: a module that provides image processing algorithms.
  • sensor: a module that provides interfaces with cameras (firewire, usb), RGB-D sensors (Kinect) and laser scanner (Sick). This module requires optional 3rd party libraries.
  • vision: computer vision algorithms for pose and homography computation, camera calibration and keypoint détection, description and matching. This module uses optional 3rd party libraries.
  • visual_feat.: This module defines visual-features that may be used by visual-servoing module to control a robotic system by vision.
  • vs: This module implements visual-servoing capabilities. It depends on visual_feat. module.

ViSP modules dedicated to tracking:

  • blob: module dedicated to blob tracking.
  • me: module dedicated to moving-edges tracking.
  • klt: module dedicated to Kanade-Lucas-Tomasi feature tracking. This module needs optional 3rd parties libraries.
  • mbt: markerless model-based tracking algorithms. This module depends on vision, me and visual_feat. modules and has an optional dependency with ar module for visibility computation and with klt module for hybrid tracking. To enable some capabilities, this module may use optional 3rd parties libraries.
  • tt: template tracking algorithms based on SSD and ZNCC cost functions. This module depends on vision module.
  • tt_mi: an extension of the template tracker algorithms that uses mutual information. This module depends on tt module.

ViSP exploit optional third-party libraries. The previous figure shows which are the optional 3rd parties that may be used by each module.

Comments are closed.