ArmMover

From Wiki for iCub and Friends
Jump to navigation Jump to search
The correct title of this article is armMover. The initial letter is shown capitalized due to technical restrictions.

Author: Lorenzo Natale and Francesco Nori


Move the arm to random positions; used to learn the reaching maps.


Back to iCub YARP module specifications


Compiler & Linker Dependencies

None

Include files

YARP


Libraries

YARP libs

Run-time Dependencies

Module arguments

None


Ports accessed

Ports that are assumed to exist prior to instantiation of the module (i.e. some other module must create them)

/headtracker/fixation/o
/headtracker/inhibition/i
/icub/arm/rcp:i

Ports created

Ports that are instantiated by the module and are then available for other modules to use (using yarp connect)

/armMover/inhibition/o
/armMover/data/o
/armMover/arm/o

Input data files

A set of safe positions for the arm: data.ini.

This file is not specified as a parameter (i.e. module argument) but hardcoded. It is a .txt file in the same directory of the module. This will probably change in the iCub implementation.

The positions are joint angles, specified in degrees.

Output data files

None

Configuration files

None


User interface mechanism

Run-time modification of module parameters

None


OS on which the module was developed

Windows, Linux


OS on which the module was tested

Windows, Linux


Operating system dependencies

None


Example instantiation of the module

Run & port connection commands

None


iCub Capabilities

iCub capability

C3 Learn to reach towards a fixation point

Refer to iCub capabilities for a complete list of iCub capabilities.

Other Yarp modules required to effect this capability

???

Example instantiation

None.

Note on Ports Accessed and Ports Created

In the specification of iCub YARP modules, we distinguish between ports that are created by the module and ports that are accessed by the module. This might be confusing but the distinction is an important one. Accessed ports are not actually used literally in the module but are assumed to exist so that then can be connected to the created ports: listing them allows us to validate all module dependencies. Strictly speaking, accessed ports are NOT part of the specfication of the module but form part of the specification of how the module is normally used, typically using YARP connect directives.


For example, if you want to access from module "my_test" the port /icub/head/command:i created in "controller_v1", you need a port inside "my_test", for example /my_test/head/command:o to "write to". This means that inside my_test there will be some piece of code that would look like:

  Port outPort;
  outPort.open("/my_test/head/command:o");
  Vector v;
  outPort.write(v);
  ...

So in the contex of my_test I would call /my_test/head/command:o the "created port" and /icub/head/command:i the "accessed one". In addition there would be ports opened so that other processes can access them. So for example my_test could create a port named /my_test/start:i to receive a start/stop message from another port in process B /processB/start:o (or from the console). Now /my_test/start:i could be listed as an "accessed" port in processB and so forth. An exception could be that ports are not monodirectional, so there is not a strict difference between "accessed" ports (meaning input ports) and "accessing" ports (output ports).


Back to iCub YARP module specifications