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

From Asibot & HOAP3 & TEO Wiki
Jump to navigation Jump to search
Line 1: Line 1:
The intention of this standard is to keep internal coherence and compatability with RoboticsLab robot modules who follow this standard. It is intended to be a description of existing and future modules, their interfaces and data flow representation. For a debate on open issues, go to the [http://roborepo.uc3m.es/w/index.php/Talk:A_Standard_for_Modules discussion tab]. Port interface is referred to TCP/UDP/MCAST/SHMEM ''cloud'' side, not CAN or USB (that can coexist in hardware-related modules).
+
The intention of this standard is to keep internal coherence and compatability with RoboticsLab robot modules who follow this standard. It is intended to be a description of existing and future modules, their interfaces and data flow representation. For a debate on open issues, go to the [http://roborepo.uc3m.es/w/index.php/Talk:A_Standard_for_Modules discussion tab]. Port interface is referred to TCP/UDP/MCAST/SHMEM ''cloud'' side, not CAN or USB (that can coexist in hardware-related modules). Current dependencies are on YARP 2.2.6 compiled with ACE 5.7.6.
  
 
  Nomenclature: D for double, I for integer, S for string.
 
  Nomenclature: D for double, I for integer, S for string.

Revision as of 13:06, 23 March 2010

The intention of this standard is to keep internal coherence and compatability with RoboticsLab robot modules who follow this standard. It is intended to be a description of existing and future modules, their interfaces and data flow representation. For a debate on open issues, go to the discussion tab. Port interface is referred to TCP/UDP/MCAST/SHMEM cloud side, not CAN or USB (that can coexist in hardware-related modules). Current dependencies are on YARP 2.2.6 compiled with ACE 5.7.6.

Nomenclature: D for double, I for integer, S for string.

drivers

These modules should recieve joint commands. Ideally, commands should be setup as callbacks. On one hand, the module is always receptive a Stop command; on the other hand, the module should send a message when a command has been performed (w/ info on degree of accomplishment).

Module: drv_name
Ports: name_q_io 
 - Data: bottle_q_i "I:code S:tag1 D:Q1pos ... S:tagn D:Qnpos D:Qgenvel"
 - Data: bottle_q_i "I:code D:Q1vel ... D:Qnvel"
 - Data: bottle_q_o "I:code D:Q1pos ... D:Qnpos"
 - Data: bottle_q_o "I:code I:Q_to_sync"
Units: Degrees, ¿¿degrees per second??.
I:code:
 - -1: Stop
 - 0: Encoder read
 - 1: Absolute position
 - 2: Relative position
 - 3: Velocity
 - 4: Syncronize motor

dynamics

Module: dyn_name
Ports:

hmi

This groups GUIs, voice recognition modules...

Module: hmi_name
Ports: any input and output from other modules

trajectory

This module should be able to take the description from a file and generate joint solutions for proposed cartesian goal.

Module: trj_name
Port: name_xi_io
 - Data: bottle_xi_io "I:code D:X D:Y D:Z D:ROLL D:PITCH D:YAW D:genvel"
Port: name_q_io
 - Data: bottle_q_o "I:code D:Q1pos ... D:Qnpos D:Qgenvel"
 - Data: bottle_q_o "I:code D:Q1vel ... D:Qnvel"
 - Data: bottle_q_i "I:code D:Q1pos ... D:Qnpos"
Code:
 - 10: Read absolute position, base coordinate
 - 11: Absolute position with wait, base coordinate
 - 12: Relative position with wait, base coordinate
 - 13: Relative position with wait, tool coordinate
 - 14: Absolute position without wait, base coordinate
 - 15: Relative position without wait, base coordinate
 - 16: Relative position without wait, tool coordinate

planning

Module: pln_name
Ports:

stabilizer

Module: stb_name
Ports:

tools

Module: tol_name
Ports:

vision

The output of this module is a cartesian goal (derived from a distance and orientation).

Module: vis_name
Ports: name_xg_o
 - Data: bottle_xg_o "D:X D:Y D:Z D:ROLL D:PITCH D:YAW"