Robotics in Concert- A multi-master paradigm (ROCON)
The framework is similar to the LAN networks that we have at our homes or offices. There is a central server called the ‘hub’. Structurally hub is a form of local ReDiS (Remote Dictionary Server) similar to the one used in LAN connections. The purpose of this hub is to collect all the data coming from the different nodes and direct them to the desired nodes thus preventing high traffic by not sending the messages to all the nodes and also keeps all the nodes decoupled thus regulating the message passing. Between the connection of node’s master and the hub there is a ‘gateway’ which is similar to a public interface for the hub to interact with. Whenever a message is received by the hub, the hub checks something called gateway’s ‘switch’. If this switch is flipped by the user or the node the hub passes on the message to this node. If the switch is not flipped then the message is not sent to the node. The gateways of other nodes can also interact with the gateways of other nodes. If a node wants a service from a particular node, the gateway of the former will request a ‘pull’ from the gateway of the latter.
Figure: Rocon implementation example. Multimaster setup with conductor as hub
Implementing ROCON
Rapps are just packages which are taken as arguments in the ROCONs abstract package called as ROCON Capabilities package. After we create RAPPS, the Capabilities take the launch files of the Rapps and launch them in a file called concertclient.launch.
The Rapps basically is a package of four files. They are as follows
1. Launch file
2. Interface file
3. Rapps file
4. Parameters file
The launch file is just like any other launch file where we launch all the nodes we desire and also we mention the remappings of the topics as they will be different in the HUB namespace (HUB a master which regulates the communication of all the other masters and also is responsible to launch them).
An interface file is where you define the topics the master or the nodes within that master would subscribe or publish. This file is of YAML format as it is used during compilation period which is when you do Catkin_make. We can also enter services if we are using client/server response method of two way communication.
A parameter file is the one in which we can import parameters to the Parameter server that is local to one particular master in a multimaster setup. Here we can initiate the variables with different values for example the robot name or node name or port number etc.
A Rapp file is where we mention the names of the three other files along with their paths relative to this file on the machine. This file is actually taken as an argument in the Capabilities package launch file called concert_client.launch.
Figure: Detection subsystem over ROCON setup. Three masters collaboratively determining the expression of the person
Figure : Navigation subsystem over ROCON. Three Turtlebots collaboratively moving towards the person of interest in the form of flock. Note that only one robot has detected the persons location. Others are communicated over the network.