Ⅰ. INTRODUCTION

MULTI-ROBOTS cooperation technique can use the advantages of group collaboration to deal with the disadvantages of individual robot and complete the tasks that individual robot cannot complete. It is an inevitable trend for robots to imitate human society. It is also an important topic in the research field of artificial intelligence and robotics^[1]. The universal integration on the basis of existing robotics research faces a lot of technical problems,such as hardware heterogeneity, software heterogeneity and sensor heterogeneity^[2].

Service-oriented technology concept comes from the application of Web^[3]. We have experienced several generations of robot research and design work,and in this development process, each research institute set its own standards. Each generation of robots,even each robot has incompatibility problems due to heterogeneous hardware and software. Currently we can build intelligent robot platform and common component library to achieve multi-robot interconnection,interoperability and mutual understanding. For those heterogeneous robots,we need to build up a common architecture to achieve a common interaction,just like we develop html5 technology to replace variety of traditional Web video browsers.

To research multi-robot systems,from small groups to large groups,even a robots’s society,the best reference is on the basis of interpersonal behavior and activities of human society. Service is one of the basic behavioral activities of human society. Regardless of the human species,in addition to the diversity of object and form,all human behaviors can be attributed essentially to provide services and consume services. So,it is significant to bring service-oriented architecture (SOA) into multi-robot cooperation.

Compared with the traditional object-oriented robot architecture^[4],SOA can make robot’s underlying functional components be transparently encapsulated and the services in upper layer be transparently invoked,which will effectively avoid the impact of heterogeneous characteristics in multirobot cooperation and be beneficial to system construction, expansion,restructuring and maintenance.

In this paper,combined with the human social service, the service of multi-robot has been elaborated in detail. The service definition,classification,stratification and data model are proposed. The concept of minimum service is defined. The relational operators and logic algorithms for robot services are established. For a practical application purpose,the serviceoriented multi-robot layered architecture has been designed. In this architecture,the interaction process of robot service registry,service pretreatment,and service scheduling method are all designed in detail. Finally,the specific multi-robot service cases are organized to illustrate the superiority of our architecture theory.

Ⅱ. RELATED WORKS

Many types of architectures have been constructed to meet the commands of multi-robotic cooperation. A multi-level service-oriented robotic swarm framework is designed in ^[5]. Easy composition of services and primitive virtual services are considered into workflows to accomplish users tasks. An intelligent vehicle control architecture (IVCA) is proposed to enable multiple collaborating air vehicles to autonomously carry out airspace missions^[6]. The architectural foundation to achieve the IVCA lays on the flexibility of service-oriented computing and agent software technology. The SOA is used in distributed sensor network for robot localization^[7]. All kinds of independent sensors are as service entities. Communication data of service is combined and distributed through standard web protocols. It is actually a kind of robot underlying functional component-level service architecture. Service entities were also introduced into robot software architecture development^[8],in which various software functional modules are as basic services. Service-oriented computing and serviceoriented middleware architecture are used in multiple unmanned aerial vehicles (UAVs)^[9] for collaborative UAV operations. Individual network robot is used as independent service entity in ^[10],which combines service-oriented with distributed peer-to-peer architecture. Robot control information can pass each node freely and adaptively with the deployment and migration of services.

Beside these,there are many other robotics researches focusing on service-oriented method[11,^[12],but they are not involved in multi-robot cooperation architecture.

From the existing research achievements,a phenomenon is found that SOA concept has been gradually combined with multi-robot cooperation technology. There are several advantages of SOA compared to traditional multi-robot architectures which are described in next section.

Ⅲ. SERVICES IN MULTI-ROBOTS WORLD A. The Technical Advantages of SOA

SOA is a particular kind of software architectures which is designed to create a dynamically organized environment of services that are decomposable and inter-operable^[13]. Distributed SOA architecture entirely changes the traditional construction method. It constructs more advanced and integrated applications which make full use of the existing services as well as those can be shared and used repeatedly^[14].

Services of SOA have the following characteristics^[15]:

1) Services are self-contained and modular;

2) Services support interoperability;

3) Services are loosely coupled;

4) Services are location-transparent;

5) Services are composite modules,comprised of components.

The state-of-the-art SOA infrastructure is illustrated in Fig.1. First,the service providers publish their types and descriptions of services. The service registry center manages these received service information and waits for service applications from service consumers. If one service application has been accepted,the service registry center searches for suitable service from service management database according to current serving situation. The best suitable one is selected and allocated. Then the basic information of the service provider, the address of communication,and the service license are sent to the service consumer,who will then bind the provider and invoke the service by above authority information.

In SOA,individual function in application is modularized and presented as a service to consumers. Researchers can construct an application by combining one or more services without paying attention to their underlying implementation.

Since,SOA has been a new concept to robot and lacking of uniform standard definitions so far. If we like to introduce SOA into robotics,some robot SOA basic concepts should be unified.

B. Service Definition and Classification

Definition 1. Service is a kind of behavior or a set of behaviours for robots to get help or other benefits from each other,which can be transferred among robots.

According to the development of current research,the robot service can be divided into four types: information service,behavioral service,functional service,and intermediary service.

Information service refers to that the robots or modules of robots exchange information among themselves. Most robots cooperation includes this service,which involves multi-robots information fusion,cloud computing and other technologies.

Behavioral service refers to interactive spatial behaviors through the mechanism of transmission among robots or robot modules,which exists in cooperative transportation, collaborative formation,and so on.

Functional service is due to integrated service requirements, which need the robot provide some functional modules to participate in the cooperation,every functional module is required to provide its specified service,but do not need the entire robot to work in it. This service is usually in distributed web robotics,smart sensor networks.

Intermediary service is to gather all kinds of service information and transmit them among robots. This service does not have explicit form of service goods,which appears in service registry center in SOA,the central management unit in the central cluster architecture.

In the process of multi-robots cooperation,one or more kinds of above services will be included. There is no strict distinction among them.

Assuming that: the information service is defined as S$_{ a}$,behavior service S$_{ b}$,functional service S$_{ c}$ and intermediary service S$_{ d}$.

Theorem 1. For any form of service set S occurred during multi-robots cooperation,${ S}=\bigcup \nolimits_{i \in a,b,c,d}{ S_i}$. C.Service Layers

As shown in Fig.2,the complex service composition would be divided into four layers: service granular layer,service convergence layer,service composition layer and service application layer. These four layers individually refer to four service steady states: atomic state,molecular state,entity state and logic state.

The atomic state is the minimal existing form,which cannot be split continually. It retains all feature attributes of the minimal service sub-items. Any form of split will destroy its essential character. The set of atomic services form the bottom service granular layer.

On the basis of atomic state,molecular state gathers some minimal service sub-items to meet the needs of special service properties, which forms the service convergence layer and meets the needs of a simple small-scale collaboration service. Services in molecular state have more flexible aggregation form. The particle activity and diversity are stronger than those services in atomic state.

The entity service is a physical space polymer of molecular services,which must be attached to certain functional entities. The entity service is not only a simple aggregation of molecular services,but also orderly assembled in physical space according to certain regulations. If the regular contact among molecular services in the entity service is constructed,this entity service can meet the needs of simple robots collaboration.

Logic state in service application layer is the highly existent form of service,which has exceeded the constraints of physical space. It considers the overall demands of users,the abstract relationship among entity services and the final existence,so as to accurately undertake most complex collaboration tasks.

As shown in Fig.3,each service with stable structures all has follow four active characteristics: death state,dormant state, ready state and active state. Services in death state will be discarded and logged off from service registry center. The service in dormant state will be reserved as alternative one. When all services in ready state cannot meet the demand,the service in dormant state will be awakened and put into ready state. The service in ready state is in quasi-working state and waiting to be activated. As soon as the service is invoked by consumer,it will work in active state. Once a service is in active state,it cannot be invoked repeatedly.

D.Service Data Model

A full service mathematical form is defined as follows:

1) ID: service ID (SID);

2) ActiveType: death,dormant,ready,active (SAT);

3) ServiceType: information,behavioral,functional,intermediary (SST);

4) ServiceScale: atomic,molecular,entity,logic (SSS);

5) SubServiceIDSetNumber: the element number of sub-SID set (SISN);

6) SubServiceIDSet: the set of the sub-SID (SIS);

7) PropertySetNumber: the element number of service feature attributes set (SPSN);

8) PropertySet: the service feature attributes set (SPS).

Any services $S$ corresponding to the items of above service mathematical model are abbreviated as: SID,SAT,SST,SSS,SISN, SIS,SPSN and SPS.

In the following,the corresponding service attributes abbreviated name is formed with the service name plus an attribute name abbreviation in Table Ⅰ. E.g.,service $A$'s property set is abbreviated as APS.

Given a service $S$: SID is 0x662f; the active state is ready state, SAT is 0x02; the service is a mobile manipulator removal service, which belongs to behavioral service,SST is 0x02; this is a physical manipulator,so it is a entity service,SSS is 0x03; it consists of five sub-services,SISN is 5; SIS{0x0105,0x0112,0x0211,0x13fe, 0x1380},0x0105 means tactile sensing service,0x0112 means binocular vision service,0x0211 means range finder service,0x13fe means robotic manipulation service and 0x1380 means universal mobile platform service; S has five feature attributes,SPSN is 5, SPS{0x03,0x05,0x20,0x33,0x54},0x03 means tactile,0x05 means vision,0x20 means laser detection,0x33 means two-finger clamp manipulation and 0x54 means small tracked mobile platform. Then the only unique identification is given: 0x662f0202030501050112021113fe1380050305203354.

The bit length of $S$ can be flexibly expanded according to the actual situation,such as collaboration size,number of robots and complexity degree of collaboration.

E.Relational Operators of Service

1)The relationship of "Contain"

Definition 2. For any services $A$ and $B$,if AIS is the (true) subset of BIS,APS is the (true) subset of BPS,we call service $B$ (true) contains service $A$,denoted as $B \supseteq A$(contain) and $B\supset A$ (true contain).

Theorem 2. For any services $A$ and $B$,if AIS is the (true) subset of BIS,APS is the (true) subset of BPS.

If AIS is an empty set,APS is not empty,then service $A$ is called atomic state service.

If the APSN of the atomic state service $A$ is equal to 0,APS is an empty set,then $A$ is called pseudo service,denoted by $\Phi _s$.

2) The relationship of "Belong"

Definition 3. For any service $A$ and $B$,if $A$ is an element of BIS,it will be called $A$ "service belongs to" $B$, denoted as $A \in B$.

For any service characteristic property p,if p is an element of BPS,it will be called p "property belongs to" $B$,denoted as $p$ $\tilde{\in}$ $B$.

Theorem 3. For any services $A$ and $B$,if $A \in B$,for any $p$,$ p$ $\tilde{\in}$ $A$,there must be $p$ $\tilde{\in}$ $B$.

This property belonging relationship caused by service belonging relationship is called inheritance relationship. If $A$ $\in$ $B$, $A$ is called parent service,$B$ is called son service,son service inherits all of parent's characteristic properties.

3) The relationship of "Common"

Definition 4. For any services $B$ and $C$,if there is a non-pseudo service $A$,$A \in B$ and $A \in C$,it is called $B$ is "service common" with $C$,denoted as $B \otimes C$.

For any service $B$ and $C$,if there is a characteristic property $p$,$p$ $\tilde{\in}$ $B$ and $ p$ $\tilde{\in}$ $C$,then we may call $B$ is "property common" with $C$,denoted as $B \tilde{\otimes} C$.

Theorem 4. For any services $B$ and $C$,if there is a non-pseudo service $A$ which causes $B$ $\otimes$ $C$,there must be a property $p$ which causes $B$ $\tilde{\otimes}$ $C$.

Corollary 1. For any services $B$ and $C$,if $B\subseteq C$ or $B \in C$,then $B \otimes C$ and $B$ $\tilde{\otimes}$ $C$.

4) The relationship of "Exclusion"

Definition 5. For any services $B$,$C$ and non-pseudo service $A$,if $A \in B$ then $A \notin C$; if $A \in C$ then $A \notin B$,we define that $B$ "service excludes" $C$,denoted as $B \propto C$ or $C \propto B$.

For any services $B$,$C$ and property $ p$,if $p$ $\tilde{\in}$ $B$ and $p$ $\tilde{\notin}$ $C$; if $ p$ $\tilde{\in}$ $C$ and $p$ $\tilde{\notin}$ $ B$; we define that $B$ "property excludes" $C$,denoted as $B$ $\tilde{\propto}$ $C$ or $C$ $\tilde{\propto}$ $B$.

Theorem 5. For any services $B$ and $C$,if $B$ $\tilde{\propto}$ $C$,then $B$ $\propto$ $C$.

F.Logical Operators of Service

1) "And" operator

Definition 6. The "and" operation of service means that if and only if the sub-service and its characteristic properties both are involved in two computing services,those will be retained in the resulting service. $C=F(A,B)=AB =$ {CID,CAT,CST,CSS, CISN,CIS(AIS $\cap$ BIS),CPSN,CPS(APS $\cap$ BPS)}.

2) "Or" operator

Definition 7. The "or" operation of service means that any sub-service and its properties involved in any one of the two computing services will be retained in the resulting service. $C=F(A,B)=A+B=$ {CID,CAT,CST,CSS,CISN,CIS(AIS $\cup$ BIS), CPSN,CPS(APS $\cup$ BPS)}.

3) "Subtract" operator

Definition 8. The "subtract" operation of service indicates that if and only if the sub-service is existing in minuend service and not in subtrahend service,this sub-service will be retained in the result service. $C=F(A,B)=A-B=$ {CID,CAT,CST, CSS,CISN,CIS(AIS $-$ (AIS $\cap$ BIS),CPSN,CPS (inherit from CIS)}.

4) Arithmetic laws

a) Commutative law

$ \begin{align} &AB = BA,\end{align} $

(1)

$ \begin{align} &A+B = B+A. \end{align} $

(2)

b) Associative law

$ \begin{align} &(AB)C = A(BC),\end{align} $

(3)

$ \begin{align} &(A+B)+C = A+(B+C),\end{align} $

(4)

$ \begin{align} &A-B-C = (A-C)-B = A-(B+C),\end{align} $

(5)

$ \begin{align} &A+B-C = (A-C)+(B-C).\end{align} $

(6)

c) Distributive law

$ \begin{align}&A+BC = (A+B)(A+C),\end{align} $

(7)

$ \begin{align}&A(B+C) = AB+AC,\end{align} $

(8)

$ \begin{align}&A(B-C)=AB-AC. \end{align} $

(9)

Ⅳ. LAYERED ARCHITECTURE AND INTERFACE PROTOCOLS A.SOA-based Cooperative Architecture

On the basis of the research results of the cooperative layered architecture of individual robot,a layered multi-robots cooperative architecture is developed with SOA. As shown in Fig.4,another layer named cooperative service layer (CSL) is designed. From top to bottom,it includes three sub-layers: standard SOA interface layer (SSIL),service translation layer (STL) and service invocation layer (SIL). Multi-robots communicate with each other and request services via the standard SOA interface in SSIL. STL is responsible to translate dissimilar communication language into corresponding service description with a uniform format. Then the uniform description is sent to SIL to invoke the basic service of robot. In other words,SSIL allows heterogeneous robots to speak,STL allows heterogeneous robots to understand what the other robots say and SIL allows heterogeneous robots understand what they should do.

The multi-robot cooperative serving process in SOA is described as follows:

Step 1. Robots broadcast their service information to service registry center (who am I,where I am,what time I can provide what services).

Step 2. The service applicant submits its descriptions of application service characteristics to service translation layer to get standard descriptions.

Step 3. Service translation layer submits the standard descriptions to SOA interface layer,where the descriptions and the other application information will be packaged and submitted to service registry center to apply for the specified services.

Step 4. When service registry center receives the application, it will query the service list and find the most convenient service providers for this application by efficient scheduling algorithm, then,the service providers' information and the service licenses are sent to the service applicant.

Step 5. The service applicant tries to connect with service providers by information received from service registry center. When the attempt is successful,the service applicant will give the service providers its service licenses,and inform that it will enjoy their services in a certain period of time.

Step 6. The service providers accept the licenses,obey the applicant's commands and supply the certain services.

Step 7. At the end of the service,the applicant releases the permission for service providers. The service licenses are automatically invalid. The service applicant and providers broadcast their latest information to the service registry center separately.

B.Protocols of Multi-robot SOA Interfaces

SOA needs a set of protocols to support it. In this study,a set of simple SOA protocols are designed ( Table II). "SOA_INTERFACE_SERVICE_CONTENT" is the data structure of service invocation layer protocol (SILP),which is used to obtain the robot's original and basic service information and then send this information to STL. "SOA_ INTER-FACE_SERVICE" is the data structure of service translation layer protocol (STLP),which is responsible to translate various programming languages into a uniform language and encapsulate them with uniform format. After adding some core sections of service description,the data is submitted to SSIL. "SOA_INTERFACE" is the data structure of standard SOA interface protocol (SSIP) which is responsible to add service address into the data package then send it by networks. Here we use robot's IP address as its ID. To receive and analyze service data is an opposite unpacking process.

Ⅴ. BEHAVIORS OF SERVICE A.Service Minterm

1) Service physical minterm

Service is just an abstract concept,its existence form and activity behavior must be attached to a substance entity,it cannot be alive alone separated from objective entity. The basic elements of service behavior include service content,service entity and service received entity. When a service entity supplies its service,it sometimes is able to provide more than one service. Assuming that the service entity can provide a set of services,when one service is supplied,the other service belonging to same service entity may not have an effect,but service entity cannot physically peel off them,therefore,these set of services that rely on the same service entity are called service physical minterm.

The service physical minterm is different from the atomic service, which may contain any one or more of the four states that are illustrated in Fig.2. Assuming a scene monitoring robot (Fig.5) can provide video capture,video storage,audio capture, target tracking and localization services. The various services are dependent on the respective sensor module,the sensor modules are mounted on the platform of robot. As long as any one of the services is to be used,the other ones are physically accompanied. Therefore,the robot shown in Fig.5 belongs to an entity service,whose service physical minterm is video capture service,video storage service,audio capture service,target tracking service and localization service.

The service physical minterm of robot is used to check the reusability and cost-effectiveness of services. Each service has its own corresponding physical minterm.

2) Service logic minterm

There are various relationships among services,such as causal relationship,dependencies,inheritance relationship and coupling relationship. Due to the presence of a variety of relationships, when using a service,it has to involve other related services. Fig.6 shows the relationships of a service robot with video surveillance function: the video data captured by video capture service must be back transmitted by communication service,to ensure video capture service to track a dynamical target,the camera requires a PTZ service,the PTZ would better to work on a mobile platform,and all above services cannot run properly if they lack of electricity.

Therefore,when a robot service is applied for,the service applicant or service registry center must identify all related services,and through recursive search,find all needed and related services layer by layer. Fig.6 shows the dynamic target video monitoring service's logic minterm video capture service,PTZ service,mobile platform service,communication service and electricity service.

Robot service logic minterm is used to ensure the integrity of the service. Each service has its corresponding logic minterm.

B.Service Registry

In this section,service registration process is specifically standardized according to the robot service mathematical model. As shown in Fig.7,after the service registry center has accepted the service provider's service registration request,it asks the service provider in detail about the service parameters to prepare for the service pretreatment. The service provider must provide accurate and detailed response to every inquiry,just like given as follow.

C.Service Pretreatment

Studies have shown that if the service registry center provides the pretreatment for newly registered service and gives reasonable suggestions and tips,when the service consumers are applying for services,to improve the overall quality and utilization of services and reduce service costs.

The newly registered service pretreatments consist of service fragmentation and reassembly,priority assessment & sorting, minterms marked,features extraction,and multi-index construction. The flexibility of services combination will be improved by a detailed breakdown of the composition of the structure. The accuracy of services selection will be improved by features extraction. The hit rate of searching quality services will be enhanced by multi-index. The ultimate goal of service pretreatments is to accurately and quickly find the most reasonable services combination and achieve the equivalent service effect with the least and most economical resources.

Here a simple method of service pretreatment is briefly described. Assumed that,the service registry center already has a registered service set $S$,there just comes a new registered service $A$,for any service $B$ in set $S$,the following process steps are proposed.

Step 1. FIND all $B$ where $A \in B$or $A \subseteq B$,if the set $B$ is not empty,the items of $A$ will be lumped into the search index of set $B$,and sorted by minterm size. RETURN. Otherwise jump to Step 2.

Step 2. FIND all $B$ where $B \in A$ or $B \subseteq A$,if $B$ is present,$A$ will be split into sub-services by $A-B$ under the constraints of service minterm algorithm rules. If a solution exists,$A-B=A'$,$A'$ is a new service object which will be processed back to Step 1; if no B satisfies the condition, the process will jump to Step 3.

Step 3. DO ${AB=C}$,if C is not a pseudo one,A will be split into sub-services by $A-C=A'$ under the constraints of service minterm algorithm rules. If a solution exists,$A'$ is a new service object which will be processed back to Step 1; if no $C$ satisfies the condition,the process will jump to Step 4.

Step 4. ADD item of service $A$ into the primary index,ADD the characteristic attributes into sub-index. RETURN.

D.Service Scheduling

i) Regional entities scheduling

The regional entities scheduling refers to that,in the designated area,mobilizing some service providers (the physical minterms) to participate in a specific mission,providing specified services and completing the assigned tasks. In the process of regional entities scheduling,the service provider usually needs to move a distance to service locations. So the geographical distances are as an important reference factor in service selection and scheduling.

In addition,to provide the same service,the number of service entities should be as little as possible. The following steps describe a simple service entity selection method. Assuming that, the service registry center has received a request for service $A$:

1) The service registry center uses a geographical filter to pick out a service set $S$ whose services are all close to the serving area. These services will take precedence over the other service.

2) In accordance with the logic minterm principles,the service $A$ will be split into $n$ sub-services $\{A_1,A_2,...,A_n\}$,and $S=A_1+A_2+\cdots+A_n$.

3) Search from $S$ to get service physical minterm set $\{S_1$, $S_2,... S_m\}$,any $S_i$ contains the number of elements of $\{A_1$,$A_2,...,A_n\}$ more than $N$.

4) Calculate the percentage of the number of $A_i$ that $S_i$ contains than the total number of SIS of $S$,and select the $S_j$ with the largest percentage.

5) Remove the elements that ${ S_j}$ have from $\{A_1,A_2,...$, $A_n\}$,$S=S-S_j$; if $ S$ is a pseudo service,the process stops, or goes back to 3).

By above five steps,the service registry center can provide the number of service entities as little as possible to cover all asked service items. This method can reduce the service cost and improve utilization of services. There are other better regional entities scheduling optimization methods to create and improve in practical applications.

ii) Cloud service scheduling

Cloud service is different from regional entity service,in which the service consumer does not take care of the service provider's physical location. It can use network communication to achieve transparent service provision. Consumers cannot see the serving process and only the results in cloud service provisions. All intermediate interactive processes are transparent for consumers.

As shown in Fig.8,assuming that the service registry center has accepted a consumer's request for service $A$ and finding that service $A$ can be supplied by cloud service.

1) In accordance with the logic minterm principles,the service $A$ will be split into $n$ sub-services $\{A_1,A_2,...,A_n\}$,and $S=A_1+A_2+\cdots+A_n$.

2) Find $n$ services $\{S_1,S_2,...,S_n\}$,corresponding to $A_i \in S_i$ or $A_i \subseteq S_i$.

3) Set an intermediary service $B$.

4) $B$is responsible for receiving all users' requests and return the service results to them.

iii) Scheduling algorithm designing

Several rules of the algorithm are formulated: a) Current service consumer robot (SCR) cannot be as a service provider robot (SPR) for other SCRs simultaneously. b) One SPR can be only invoked by one SCR simultaneously. c) SCR can invoke more than one services from one SPR or invoke more than one service from more than one SPRs simultaneously. d) SCR can reject the service allocation scheme of the service registry center (SRC) and also SPR can reject the SCR's service requirements. e) To prevent deadlock and resource monopolies,the same service cannot be consecutively requested two times and the time of the service that the SCR takes up should not exceed Tout. f) Each robot has the right to apply for services and the obligation to provide services.

Fig.9 illustrates the service scheduling algorithm of SRC. SRC monitors all robot signals within its network coverage area. It is responsible to dispatch services. The scheduling algorithm is consisted of following five steps:

Step 1. a) Waiting robot RI for a service connection request SI. b) Checking the service request record in free time to find the items with recording time less than $Tr$,and if the related service is free then send the SPR's ID and the license. The item is then deleted. c) Have a search on the recording table and delete all time-out items.

Step 2. Accept the request of SCR and determine the type of the request: a) Request for releasing the service SI: release the SI and record the assessment of QoS,modify the state parameters of RI and RII,back to Step 1. b) Request for services: go to Step 3.

Step 3. Check the existence of SI: a) No: Add the request into record table; tell RI no SI exists,back to Step 1. b) Yes: list all existing SIs; go to Step 4.

Step 4. Check that whether robots RIIs who supply the service SI all are busy? a) Yes: add the request into record table; tell RI SIs are all busy. b) No: list all idle RIIs; go to Step 5.

Step 5. Calculate the service cost,combined with QoS records, find the RII with lower cost and better QoS; Send RII's ID and service license to RI; establish the association between RI and RII; modify the state parameters of them; back to Step 1.

Ⅵ. SERVICE CASE I A.Evaluation of Service Cost

Currently,our research focuses on ground mobile robots,especially tracked robots. The service cost can be generated by distance through the serving process.

The odometer distance can be translated into following equation:

$ \begin{align} \begin{cases} u_t = (v_L,v_R)^{\rm T},\\ D_L = v_L{\rm d}t,&v_L \ge 0,\\ D_R = v_R{\rm d}t,&v_R \ge 0. \end{cases} \end{align} $

(10)

Here $u_t$ denotes the control vector,$v_L$ and $v_R$ are the velocities of the left and right wheels. After the termination of the iteration algorithm,the total service cost will be achieved according to the number of the iterations.

$ {T_{{\rm{cost}}}} = \sum\limits_{i = 1}^N {\frac{{{v_{i,L}} + {v_{i,R}}}}{2}} \Delta {t_i}. $

(11)

B.Illustration of Mission Model

As shown in Fig.10,a mission is designed that robot $A$ is commanded to perform the mission of reconnaissance and topographic survey (Simultaneous localization and mapping,SLAM) through the 1st street. But $A$ does not think that it can ensure the completion of the mission only by its own poor sensors. Multi-robots cooperative online SLAM (MRCO-SLAM) should be required. So $A$ calls SRC for help. SRC receives the request and attempts to find if there are some free services to invoke by service scheduling algorithm. Finally,robot $B$ and $C$ both meet the requirements and are going to be dispatched to $A$. SRC sends $A$ the IDs and service licenses of $B$ and $C$. $B$ and $C$ accept the service requests from $A$ and arrive at the required place as soon as possible to cooperate with $A$ to complete the mission.

In MRCO-SLAM,$A$ receives GPS data,gyro data and relative observation LIDAR data from $B$ and image data from $C$. By the fusion of these extra sensors data,$A$can reduce its observation errors and get more accurate posterior estimations of mapping.

In the mission process,$C$ has a sudden mechanical failure and cannot move any more,$C$must exit from the mission. Then $A$ needs another one to replace $C$ for environment image data. $A$ sends its requirement to SRC again; SRC finds robot $E$ meets the requirement. But $E$ is far from $A$ and in front of $A$. Then $E$ is ordered to wait in the designated place until $A$ arrives.

Robot $D$ is a spy robot,who has been familiar to the situation of the 2nd street. When $A$ is coming,$D$ reports what he knows about $A$ to complete the global map. When $A$ arrives at the other end of the street,the mission is accomplished. All localization and mapping data will be processed in detail offline.

C.Results Analysis

VC++ 6.0 is used as the software platform for our simulation. Each robot is represented by one independent process. These processes are running in different computers. The main robot is set to perform the mission of SLAM. The other robots would like to supply their services and follow the hypothesis circumstances illustrated in the mission model to test the flexibility of the architecture. The independent processes communicate with each other by TCP/IP protocol. The main information stream is consisted of LIDAR data, GPS data,gyroscope data and especially image data.

The system delay caused by large amount of data transmission in general centralized architecture will seriously affect the system real-time performance. It is shown in our simulation results that the system timeliness is affected by the QoS of the network and the capability of the center server. As shown in Fig.11,in the cooperative process of 7400 ms,the system total delay is up to 9616 ms in the centralized system and only 2416 ms in SOA-based architecture. At the end of the SLAM process,the system will give its service evaluation for robot $B$,$C$,$D$ and $E$. In this simulation,the normalized service evaluation is given: $B$ (0.86), $C$ (0),$D$ (0.94) and $E$ (0.82).

Fig.11 gives the comparison analysis of data stream between SRC and general centralized server. The large amounts of dense points in central region are sampled from general centralized server which is always in a state of high-load operation because of large amounts of data forwarding (Image data is not considered). So each robot will be dependent on the general centralized server with the amount of data increase. If the general centralized server crashes,then the entire system crashes. This situation is improved in SOA-based architecture,when SRC crashes,the system will degenerate into a distributed architecture. The system can still run until a new SRC is constructed again. The bottom sets of points with uniform distribution are caused by the service broadcasts from robots who can supply services. The points near the time 60 s,300 s,600 s and 720 s are caused by $A$'s service application for $B$,$C$,$E$ and $D$. From the comparison of the amount of data stream,we can see,the proposed architecture of this study can reduce the dependence between robots and SRC,which can be good to improve the robustness of the cooperative systems.

The micro-ground-tracked robots are used for the physical test. Each robot is equipped with LIDAR LMS291、gyroscope odometer and differential GPS. For the experimental conditions,the test is divided into three parts: a) $C$ is released from the formation for its mechanical failure. b) $E$ is invoked to wait to serve in the designated area. c) The spy $D$ reports its map of the 2nd street to $A$. The experimental results show that,under the coordination of SRC,the SLAM member robots accomplish their individual task successfully. And the system has greater flexibility and practicality.

Ⅶ. SERVICE CASE II A.Illustration of Mission Model

This chapter focuses on testing handling functions and operational flow of the service registry center. The simulation test is similar to analog strategic game running in a normal PC. The service operation process is simulated through scheduling algorithm,player roles and tasks setting. Suppose there is a large number of services managed by the service registry center: I-reconnaissance services A-Visible,B-Infrared,II-positioning and navigation services C-GPS/Beidou,D-navigation,E-target ranging,III-combat service F-sniper,G-grenade,H-rocket,I-machine gun,IV-fuel security services J-electric power,K-oil,V-communication support services L-microwave communication,M-satellite communication, VI-ammunition transportation and loading service,VII-combat assessment service,VIII-IFF service.

As shown in Fig.12,it is assumed that according to intelligence,terrorists are staying together in a remote secluded small house,robot commander must need to call multiple robots to kill dangerous target through collaboration.

First,the commander robot applies for the new service "collaboration attack". The service registry center accepts the request and split the service by logic minimization principles into five logic state child services: reconnaissance,positioning, attack,attack assessment and support. According to the service description for the environment,more explicit sub-services are determined: I-A-visible light reconnaissance service, I-B-infrared imaging reconnaissance,III-H-rocket service, VII-combat assessment services,IV-J-power service and VL-distance wireless communication service. The service registry center attempts to find some service entities that contain all the above listed services and the maximum services utilization entities. All selected service entities must be in their effective combat radius. Assuming that following four robots are determined: Robot $A$ and $B$ with III-H-rocket,Robot $C$ with I-A-visible camera, I-B-infrared camera,II-C-GPS,II-E-distance detection and V-L-long range wireless communication,robot $D$ with attack assessment.

The reconnaissance Robot $C$ first arrived at the designated area and located the target. Robots $A$ and $B$ reached the designated areas and announced $C$ their coordinates and headings. Then Robot $C$ tells $A$,$B$ and $D$ the target coordinate. Robots $A$ and $B$ adjust their shoot states and angles. After receiving the fire order from $C$,$A$ and $B$ attack the target. $D$ sends the attack assessment report to $C$,and $C$ sends this report to the captain. The mission is completed,all robots are commanded to be back.

B.Physical Robot Test

We uses another five self-developed tracked robots to test this case. Thanks to the research results of other projects,each robot is equipped with different equipments.

As shown in Fig.13,it is navigation robot (No.1),equipped with GPS,Velodyne 32-lines and LMS 291 Lidar,CrossBow gyroscopes and other auxiliary sensors. The 2nd robot carries a long-range visible light reconnaissance system,the 3rd robot carries a long rang-finder infrared reconnaissance system,the 4th robot carries a long-range target positioning system,and the 5th robot carries a combat system. For some reason,they cannot be described in detail here. The multi-robots cooperative service is carried by the design of Fig.12 (no UAV),each robot is placed at the same starting point in each experiment. Table III shows the experimental results of two mission modes.

Due to the limitations of the number and function of robots,our study has only tested the basic functions of service-oriented multi-robots cooperation. From the process and results,it can be seen that service-oriented multi-robots system has better flexibility and scalability in free combinations.

Ⅷ. CONCLUSION

In this paper,service of multi-robots cooperation is deeply researched in theory and engineering,to find a robot social service architecture like human society. In this robot society,all of the collaborations are presented and operated through service consumption.

We presented a new multi-robots architecture named robot SOA. This architecture is constructed by the service-based concept of SOA and the loosely coupled center service scheduling strategy. These methods make robot underlying function realization be transparent in cooperation. The impact of robots heterogeneous characteristics is avoided,that will be beneficial to the system construction, expansion,restructuring and maintenance.

In the architecture,all sensor data and communication commands are treated as the basic service units of function realization. The SRC is only responsible for service scheduling,and do not act as a data transit center like it does in the centralized architecture. The process time of SRC then will not affect the cooperative timeliness between two robots,and it can avoid huge amounts of computation and system delay. So it is beneficial to improve the system stability. The dependency between robots and SRC is weakened. When SRC crashes,the system will automatically degenerate into a distributed architecture. When a robot is in trouble,it will be automatically released from serving or consuming and removed from the system until it is repaired. From the above advantages,we may see,this loosely coupled system construction method is ideal for multi-robots systems.

In the service-oriented cooperative architecture,resources can be further deeply split in logic on the basis of service centralized process. The traditional concept that physical entities are treated as smallest unit has been broken out. Any robots cooperation will all be translated into service optimal combination problems.

The development of object-oriented and middleware technique gives birth to the platform. The development of platform provides necessary conditions to the rise of SOA. Currently,robot operating system has been developed,which will provide the best basic condition for SOA. On the general-purpose robot platforms,just like ROS,researchers and developers can create variety of robot applications to form a robot "apple store". All of these applications will eventually form various colorful services. All above will prompt us to go further.