Rundown of debug.cfg

73 views
Skip to first unread message

Mansfield Mark

unread,
Mar 25, 2014, 2:13:55 AM3/25/14
to rap...@googlegroups.com
Could somebody give a rundown of the meaning of all of the contents in the debug.cfg that is used in Test?

From what I understand, it looks like the various RCE message types, requesting things get started up. I was able to piece together an understanding for most things, but the "interfaces" section really trips me up.

Dominique Hunziker

unread,
Mar 25, 2014, 8:35:06 PM3/25/14
to Mansfield Mark, rap...@googlegroups.com
Hi,

So, I don't know whether you have already seen this, but all the
elements of an interface definition (same goes for all the other types)
correspond to arguments of the method to add an interface (or the
equivalent method for the other types). The docstring for these methods
can be found in rce.comm.client.RCE (which are also available in
rce.client.connection.Connection using help()). These arguments in turn
are pretty similar to the the actual rce messages as you already noticed.

Also did you already have a look at the web page?
http://rapyuta.org
Have a look at the Rapyuta 101 - Communication Protocol - Developer
Resources. Also checkout the paper which is linked on the homepage.

As for a rundown... I guess this is a bit difficult, but here some
explanations of the various elements of the sample config file
(unfortunately standard JSON does not allow comments, therefore, a bit
of hack here):

{
# URL of the cloud engine (this is the HTTP server of the master process
responsible for assigning a robot process to a robot; if you checkout
the vis_hack or demo_mod branch you will also have an HTTP server where
a web browser can get a visualization of the cloud engine)
"url" : "http://localhost:9000/",

# User ID & password is used to authenticate the user (new users can be
added using the rce-console, but I recommend to use Rapyuta just in the
developer mode for now, as there is no real reason for having multiple
users. The "user" in Rapyuta is similar to a "group" on a unix operating
system, bit of a misnomer here)
"userID" : "testUser",
"password": "testUser",

# The robot ID is used to identify the robot which is important to
establish connections (using interfaces); the robot ID is later referred
to as endpoint tag. (The "robot" in Rapyuta is similar to a "user" on a
unix operating system, bit of a misnomer here)
"robotID" : "testRobot",

# This list contains the declarations of all containers (i.e., the
computing environments; each container has its own roscore and (in
theory is isolated by a firewall (not yet used)).
"containers" : [

# First container
{

# This is the container tag which is important to establish connections;
the container tag is later referred to as endpoint tag.
"cTag" : "cTag_01"
},

# Second container
{
"cTag" : "group_01",

# This optional argument allows to add the container to a group of
containers. All the containers in an group should have a second virtual
network interface, such that they are able to communicate directly
between each other without the requirement of using Rapyuta; however,
this feature is not well tested and there are some issues there...
"group" : "testGroup"
}, {
"cTag" : "group_02",
"group" : "testGroup"
}
],

# This list contains the declarations of all nodes (i.e., the ros nodes
which should be executed inside of a container) - (analogous containers)
"nodes" : [
{

# Container tag; identifying the container in which the node should be
started
"cTag" : "cTag_01",

# Node tag used to identify the node
"nTag" : "strEcho",

# ROS package where the executable which has to be launched is located
"pkg" : "Test",

# Executable which has to be launched
"exe" : "stringEcho.py"
}, {
"cTag" : "cTag_01",
"nTag" : "paramTest",
"pkg" : "Test",
"exe" : "paramTest.py",

# One of the optional arguments: the string is passed to the executable
as a command line argument. Other optional arguments are name and
namespace which can be used to change the name and namespace of the ROS
node (see __name:= and __ns:= in the ROS documentation on command line
arguments for nodes for further details)
"args" : "argument"
}
],

# This is a list of parameter which should be added to ROS parameter
server; Note that parameters are added before the nodes are launched, in
case the node requires the parameter - (analogous containers)
"parameters" : [
{

“ Container tag: identifying the container (i.e., the ROS environment
inside the container) where the ROS parameter should be added
"cTag" : "cTag_01",

# Parameter name (corresponds to the name used in the parameter server).
There can't be two different declarations using the same name;
therefore, to change the value the old declaration has to be deleted.
Changes made to the parameter by nodes in the computing environments are
not recognized (might be problematic if the parameter is deleted by node
and Rapyuta tries to delete the parameter later on - never tested what
happens in this case)
"name" : "str",

# Value of the parameter
"value" : "Hello World"
}, {
"cTag" : "cTag_01",
"name" : "int",
"value" : 99
}, {
"cTag" : "cTag_01",
"name" : "float",
"value" : 3.14
}, {
"cTag" : "cTag_01",
"name" : "bool",
"value" : true
}, {
"cTag" : "cTag_01",
"name" : "array",

# It is also possible to add an array of mixed type (I don't know if
this is actually valid in ROS, I don't know how this is handled in C++)
"value" : ["one", 2, "three", "true"]
}
],

# This list contains the declarations of all interfaces. The interfaces
are necessary to communicate between robots & containers. Without the
declaration of interface & and connecting these interfaces no data can
be exchanged. - (analogous containers)
"interfaces" : [
{
# The endpoint tag identifies the container/robot where the interface
should be created
"eTag" : "cTag_01",

# The interface tag is used to identify the interface
"iTag" : "stringEchoService",

# The type of the interface: Have a look at
http://rapyuta.org/Developer_Resources#Interfaces for more details
"iType" : "ServiceClientInterface",

# The message type / service type of the interface corresponds to a
msg/srv definition of ROS topic/service (format should be known from ROS)
"iCls" : "Test/StringEcho",

# Address is the topic name / service name which will be used inside the
container / robot (in this case it's a container endpoint so it will be
the address in the ROS environment running inside the container
"addr" : "stringEchoService"
}, {
"eTag" : "testRobot",
"iTag" : "stringEchoService",
"iType" : "ServiceProviderConverter",
"iCls" : "Test/StringEcho",

# This is a robot endpoint; this address is only used by the rce-ros
client and not by Rapyuta per se.
"addr" : "stringEchoService"
}, {
"eTag" : "cTag_01",
"iTag" : "stringEchoReq",
"iType" : "PublisherInterface",
"iCls" : "std_msgs/String",
"addr" : "stringEchoReq"
}, {
"eTag" : "testRobot",
"iTag" : "stringEchoReq",
"iType" : "SubscriberConverter",
"iCls" : "std_msgs/String",
"addr" : "stringEchoReq"
}, {
"eTag" : "cTag_01",
"iTag" : "stringEchoResp",
"iType" : "SubscriberInterface",
"iCls" : "std_msgs/String",
"addr" : "stringEchoResp"
}, {
"eTag" : "testRobot",
"iTag" : "stringEchoResp",
"iType" : "PublisherConverter",
"iCls" : "std_msgs/String",
"addr" : "stringEchoResp"
}, {
"eTag" : "cTag_01",
"iTag" : "parameterTest",
"iType" : "ServiceClientInterface",
"iCls" : "Test/ParameterTest",
"addr" : "parameterTest"
}, {
"eTag" : "testRobot",
"iTag" : "parameterTest",
"iType" : "ServiceProviderConverter",
"iCls" : "Test/ParameterTest",
"addr" : "parameterTest"
}
],

# This list contains declarations of connections between interfaces.
Note that a subscriber always has to be connected to a publisher and
vice versa (analogous for service client & service provider).
Additionally a service provider can be connected to at most one service
client at any given time.
"connections" : [
{

# The Rapyuta internal address of the first interface (internal address
consists of "endpoint tag" / "interface tag")
"tagA" : "cTag_01/stringEchoService",

# The address of the second interface
"tagB" : "testRobot/stringEchoService"
}, {
"tagA" : "cTag_01/stringEchoReq",
"tagB" : "testRobot/stringEchoReq"
}, {
"tagA" : "cTag_01/stringEchoResp",
"tagB" : "testRobot/stringEchoResp"
}, {
"tagA" : "cTag_01/parameterTest",
"tagB" : "testRobot/parameterTest"
}
]
}

Dominique
Reply all
Reply to author
Forward
0 new messages