KR100902662B1 - Terminal data format, communication control system using the terminal data format, and method thereof - Google Patents

Abstract

The present invention can efficiently control various types of network-based robots existing in an Ubiquitous Robtic Companion (URC) -based infrastructure, and communicate using a data format for a terminal to facilitate development according to service expansion. The present invention relates to a control system and a method thereof, wherein the data format for a terminal applied to the communication control system and method according to the present invention includes: a Protocol Discriminator field including protocol identifier information for approving interfacing between the robot, a server, and a client; A Session ID field including unique information (ID) for identifying the currently connected session; A Profile ID field including information for distinguishing a profile (control function) performed by any one of the robot, server, and client; An MSG Type field including type information of a message transmitted and received between the robot, server, and client; And a payload field including information for performing a service for a corresponding function according to data defined in the MSG Type field and profile information included in the Profile ID.

Description

Communication control system and method using terminal data format {TERMINAL DATA FORMAT, COMMUNICATION CONTROL SYSTEM USING THE TERMINAL DATA FORMAT, AND METHOD THEREOF}

1 is a diagram illustrating a network interfacing relationship between a robot and a user host for controlling a robot according to the prior art;

2 is a view showing the physical structure of the URC protocol for robot control according to the present invention,

3 is a diagram illustrating a header structure for a common message transmitted and received through a URC protocol between a robot and a URC server for controlling a robot according to a first embodiment of the present invention;

4 is a view showing a change in the message type transmitted and received between the robot and the URC server according to the present invention,

5 is a view showing a network connection relationship of the robot control system using the URC protocol in the first embodiment of the present invention.

6 is a diagram illustrating a service that can be provided to a robot and a client in a URC server and a basic message transmission / reception flow for the corresponding service when the robot and the client are connected to the URC server in the robot control system according to the present invention.

7 is a view illustrating a message flow between a robot and a URC server when providing a voice recognition service of a robot in the robot control method according to the present invention.

8 is a diagram illustrating a message transmission and reception flow between a robot and a URC server for image recognition and motion detection (tracking) service in the robot control method according to the present invention.

9 is a view showing a transmission and reception message flow between the robot and the URC server for authentication of the robot in the robot control method according to the present invention.

10 is a view illustrating a flow of transmission and reception of an authentication message with a server for remote monitoring of a robot in a remote client in the robot control method according to the present invention.

11 is a view showing the types of messages transmitted and received between the robot and the URC server for controlling the operation of the robot in the robot control method according to the present invention.

12 is a diagram illustrating a message transmission and reception flow between a remote client and a URC server for controlling a robot through a URC server in a robot control method according to the present invention.

13 is a view schematically showing a connection relationship for a robot control system according to a second embodiment of the present invention.
14 is a diagram illustrating a common header structure for a message transmitted and received between a robot, a client, and a URC server according to a second embodiment of the present invention.

FIG. 15 is a diagram illustrating a URC protocol profile structure between a robot, a URC server, and a remote client in a communication control system according to a second embodiment of the present invention.

16 is a view illustrating an event generation ACK operation when an event occurs in a robot in the communication control system according to the second embodiment of the present invention.

17 is a view showing a method for checking a connection state between a robot and a URC server in a communication control system according to the present invention.

18 is a diagram illustrating a message transmission and reception flow for controlling a robot in a remote client according to a second embodiment of the present invention.

* Description of the symbols for the main parts of the drawings *

10, 300; Client 20, 100; URC Server

30, 200; robot

The present invention relates to a communication control system and method using a data format for a terminal, and more particularly, to efficiently control various types of network-based robots existing in an infrastructure based on URC (Ubiquitous Robtic Companion). The present invention relates to a communication control system and a method using a data format for a terminal that can be usefully developed according to service expansion.

The robot is equipped with various sensors so that the program can properly accomplish the task assigned by the user by recognizable commands such as voice commands or text commands of the user.

Robots are gradually developed as human robots, such as cleaning robots, toy robots, etc., according to a task assigned by a user, and a robot can be developed to perform several functions at the same time.

These robots are being developed to provide various services through communication with humans, and various organizations and societies have proposed how to set up the interface of the robot using the Internet, an open network, and its structure. It is becoming.

One of the recently proposed Proxy-mediated human-robot interface architectures includes communication between User Interface agents (IAs) and Embedded agents (EAs) over the Internet in a way called Proxy-mediated Human Robot Interface (HRI). We suggest structure to do. 1 is a diagram illustrating a network connection relationship with respect to the architecture of a proxy-mediated human-robot interface according to the related art.

As shown in FIG. 1, the Proxy Agent reduces the communication load of the IA (User Interface agent) and the computational resources occupied by the Embedded Agent (EA) for tasks related to the interface, and dynamically links the link between the IA and the EA. Provides creation or removal and transfer of upward data asynchronously. RoboML is used here, which is a transformation of XML into the markup language for robots. XML is used for agent communication and information representation because of its suitability to be represented by a known language for programming, ease of handling and manipulation by humans, and compatibility for applications on other platforms.

Agent communication language includes AOP which can program agent to communicate and evolve, Telescript defined as environment for processing between software applications on network, Knowledge Query Manipulation language (KQML), and FIPA.

In addition, as the language of the robot, PRS (Procedural Reasoning System) based on the concept of TCA (Task Control Architecture) and Procedural reasoning expert, which combines task-level control and communication in delivering messages between processors to perform actions simultaneously. As a logical-based action language, GOLOG has been developed to program navigation manipulation, recognition, and interaction for moving.

The language of the robot thus programmed can transmit user commands by means of a transmission protocol that can be interfaced to control a robot operating remotely. Any robot can define the structure and action of the robot through the definition of the framework, and it can be used for the robot data communication using the existing communication protocol.

However, the transmission protocol for such a robot is difficult to apply to other robots because each robot is made of a custom-designed robot manufacturer, there is a problem that it is almost impossible to interwork between the robot and the server. .

In addition, since the transmission protocol for the existing robots cannot be uniformly applied to a plurality of robots, there is a problem that the generality of the protocols is inferior, and the incompatibility is inferior in development.

Accordingly, the present invention has been made to solve the above problems, and an object of the present invention is that various types of robots existing in the Ubiquitous Robtic Companion (URC) base are intelligent, active and situational to the user through the URC infrastructure. The present invention provides a communication protocol and a method for providing a communication protocol between a robot, a URC server, and a remote client to provide a suitable service, and smoothly controlling the robot using the communication protocol.

In addition, another object of the present invention, a communication control system and a method by which a service provider (remote client) can secure flexibility in service development by remotely controlling a robot through a URC server using the communication protocol described above. In providing.

According to an aspect of the present invention for achieving the above object, in the data format for transmitting from one side of the terminal and the server to the other side, Protocol Discriminator field for approving interfacing between the one side to the other side And a Session ID field for setting an ID to distinguish the terminal, a Data direction field for setting a direction for transmitting data from the one side to the other side, and at least one or more of the format and contents of the data. A data type field defined as a representative case, a service ID field for determining whether to use a service of the following message performed by one of the one side and the other side, and setting an ID to distinguish it, and data defined in the data type field And setting the available service determined in the Service ID field to the one side. And a Payload field to give the message a side to perform the service.

Here, the payload field message is divided into a picture, a voice, and a moving, the picture message is composed of a file number, a size, and image data, and a voice message is composed of a file number, a size, and voice data. For example, the moving message preferably has a command type of robot movement, robot status control, robot status report, robot error status, and camera control depending on the type of moving control.

The file number is composed of client type, client ID and file generation order, and the robot movement is composed of the X-axis movement distance of the terminal, the Y-axis movement distance of the terminal, the attitude angle of the terminal, and the camera angle to control the moving. The robot status control is composed of a status report and a reporting period of the terminal in order to check the current status of the terminal in real time, the robot status report is an unmanned alarm setting state according to the robot movement, the movement of the terminal It consists of status information such as status, monitoring status, abnormal status, identification status, warning status, message about terminal location information and action completion information, and it is a message to grasp the service result of the terminal. It is a message regarding the operating conditions of the terminal by determining whether at least one terminal itself is abnormal, and the Camera control is associated with the image transmission It is preferably a message.

In addition, the payload field is ASR (Automatic Speech Recognition) that is voice recognition data, Text To Speech (TTS) that is voice output data, Face Recognition (MD) / Motion Detection (MD), authentication for face recognition and motion detection, authentication It is preferable to further include fields of Client Type, Client ID, User ID, Authorization Code, and Massage Type in order to provide messages of authorization data, moving data, and VoIP data.

The Client Type field is a field complementary to directional information of the Data Direction field, and indicates a type of a terminal corresponding to the directional information, and the Client ID field sets an ID corresponding to at least one or more terminals. In order to distinguish terminals corresponding to directional information of a field, the User ID field is set to an ID for recognizing at least one terminal by a server, and the ID has a message corresponding to the number of registered users. The code field preferably provides authentication numbers of at least one terminal.

The message type field provides a procedure for initializing a connection, response, synchronization, authentication, and data transmission between the terminal and the server, and the message transmitted between the terminal and the server is a first connection for the connection between the terminal and the server. It is preferable to include a message group, a second message group for authentication between the terminal and the server, a message for continuity of the first message group and the second message group, a payload message transmitted between authenticated parties, and an end message.

The first message group includes a request message, an acknowledgment response message, an error acknowledgment response message, the second message group includes an authorization message, a positive authorization message, and a negative authorization message, and the message for continuity is a synchronization message. The payload message is a data message, and the end message is a close report message.

On the other hand, the terminal is preferably composed of at least one or more of at least one robot terminal and at least one control terminal. It is preferable to further include a Protocol Version field for presenting the update status of the data format.

According to an aspect of a communication control system using a data format for a terminal according to the present invention, a terminal for performing at least one service among image, voice, and moving according to the payload message content of the data format, and a user through the terminal And a server that recognizes a command and transmits and receives a packet having the data format according to the terminal and the corresponding protocol, and controls the service to be performed according to the data format in the packet.

In addition, the terminal is preferably composed of at least one or more of at least one robot terminal and at least one control terminal.

In this case, the robot terminal processes the voice message from the user into a data format for self-operation and provides the server and informs the user of the result by performing a corresponding service message, and the control terminal controls the robot terminal. In order to process the service message desired by the user into the data format, it is preferable to transmit a packet having the corresponding data format to the server, and receive the service result of the robot terminal from the server and inform the user.

The service message is a payload message, including an authentication number and a procedure message, an image recognition message, a voice recognition message, and a control message for moving. Accordingly, it is preferable to provide an unmanned security and remote monitoring service to a user. .

According to an aspect of the communication control method for transmitting a packet having the data format for the terminal from one side of at least one terminal or server according to the present invention to the other side through a corresponding protocol, according to the data format of the packet Confirming authentication according to an authentication procedure between a terminal and the server, granting a Session ID for distinguishing each of the terminals according to the data format in the packet after the authentication, and providing a user to the corresponding terminal to which the Session ID has been assigned. Sending a payload message having the voice data to the server by inputting a voice command, and analyzing the payload message to return a Service ID, and the corresponding terminal performing an operation according to the Service ID, the server receives the result Communication control room using a terminal data format comprising the step of transmitting to the payload message to To be achieved.

In addition, the service corresponding to the Service ID, it is preferable to perform unattended security, remote monitoring, voice recognition, image recognition, Moving control.

Here, the authentication procedure is a step of the terminal attempts to access the server by sequentially performing a request message, an acknowledgment response message, an error acknowledgment response message of a message type corresponding to the internal field of the payload message, and after the access It is preferable to include the step of sequentially performing the Authorization Message, Positive Authorization Message, Negative Authorization Message of the Message Type to give the authentication number according to the authentication request of the terminal.

And, if there are more than one terminal, the step of assigning the authentication number preferably further comprises the step of receiving a list of each terminal and transmitting an authentication request message to the corresponding terminal desired by the Select Message.

On the other hand, the terminal is preferably composed of at least one or more of at least one robot terminal and at least one control terminal.

A data format of a packet transmitted and received between a server, a robot, and a client for controlling a robot according to the present invention, the data format comprising: a Protocol Discriminator field including protocol identifier information for approving interfacing between the robot, server, and client; A Session ID field including unique information (ID) for identifying the currently connected session; A Profile ID field including information for distinguishing a profile (control function) performed by any one of the robot, server, and client; An MSG Type field including type information of a message transmitted and received between the robot, server, and client; The payload field includes a message for performing a service for a corresponding function according to data defined in the MSG Type field and profile information included in the Profile ID.

The profile of the server may include an authentication profile for performing authentication of the robot and the client, a remote control profile providing an interface for remotely controlling the robot from the client, and an event (robot movement) of the robot at the server or client. Control event), a voice recognition profile for voice recognition of voice commands received from the robot, a voice synthesis profile for synthesizing voice recognition data and text data, and image information transmitted from the robot. At least one profile of the image recognition profile for detecting, the motion detection profile for detecting the movement of the robot.

The profile of the robot includes a movement profile for moving the position of the robot, a navigation profile, a voice detection profile for a voice command, a voice profile for outputting data to a voice synthesis provided from a server, a motion profile for controlling the movement of the robot, and a robot. At least one profile of the emotion profile to perform the emotional expression function of.

The robot profile further includes an event providing profile that provides motion transition event information to the server or client when a motion control message of the robot is received from the server or client and the motion state of each component of the robot is transitioned. Include.

The motion transition event divides each component state of the robot into an IDLE and an ACTIVE state, and divides it into a start, end (or stop) event when a transition is made from each state to another state.

The server profile further includes an HB request profile that periodically transmits a heartbeat request message to determine the network connection status of the robot.

The robot profile further includes an HB response profile that transmits a Heartbeat response message to the server according to a Heartbeat request message periodically transmitted from the server to determine a network connection state of the robot.

In addition, according to another aspect of the communication control system according to the present invention, a robot for performing at least one service of the image, voice, moving according to the contents of the payload field of the preset data format; A server that recognizes a user command through the robot and transmits and receives a packet having the data format according to the robot and the protocol, and controls the service to be performed according to the data format of the packet; Located remotely and includes a client to perform a remote control and monitoring service of the robot through the server.

The server, when a control message for controlling each inspection component constituting the robot is received from the server or the client, drives the corresponding component, and when the movement state of the corresponding component is transitioned, the server sends the motion transition event information to the server. I serve as a client.

The motion transition event information divides each component state of the robot into IDLE and ACTIVE states, and includes start, end (or stop) event information when a transition is made from each state to another state.

The server periodically transmits a heartbeat request message to determine the network connection state of the robot, and determines the network connection state of the robot according to whether or not a heartbeat response message is received from the robot.

The robot transmits a heartbeat response message to the server according to a heartbeat request message periodically transmitted from the server.

The server performs authentication of the client for remote control of the robot at the client, provides the list information of the robots connected to the client, and when a robot to be controlled from the client is assigned, an interface between the allocated robot and the client To provide.

Meanwhile, according to an aspect of a method of controlling a robot using a client located remotely in a communication control system including a client, a robot, and a server providing an interface between the client and the robot, the client located remotely may be Requesting a plurality of robot list information connected to the server to authenticate and access the server to perform a remote control and monitoring service of the robot; After the server authenticates the client, transmitting the robot list information connected to the server to the client; The client selecting a robot to be controlled by using the robot list information transmitted from the server and transmitting the corresponding information to the server; The server includes setting a transmission / reception interface of a message for robot remote control and monitoring service between the robot selected from the client and the client.

In a state in which an interface is established between the client and the robot selected by the client, the client subscribing to various service channels for controlling the robot through a server; After joining the service channel, the client requests image information and status information of the robot to the robot through the server, and controls to control any function of the robot according to the image information and status information periodically transmitted from the robot. Sending a message; The robot performs the corresponding function according to the control message transmitted from the client through the server, and transmits event information on the operation time and the end time of the function to the client through the server; The client further includes the step of logging out the connection with the robot by sending a connection termination request message to the server when the remote control and monitoring service of the robot is terminated.

Periodically transmitting a heartbeat request message to the robot to check the network connection status of the robot at the server; The robot may further include transmitting a response message according to the Heartbeat request message transmitted from the server to notify the server of network connection status information.

Hereinafter, a communication control system using a terminal data format and a method thereof according to the present invention will be described in detail with reference to the accompanying drawings.

(First embodiment)

2 is a diagram illustrating a physical layer structure of a TCP / IP-based URC protocol for robot control according to the present invention.

As shown in FIG. 2, the URC protocol belongs to an application layer located above the TCP / IP layer, which is a network and a transport layer, based on Ethernet, and authenticates the use of a terminal, that is, a client and a robot, to a server based on the TCP / IP protocol. In this case, the robot is controlled by the identified client according to a desired service command so that the robot can perform an appropriate operation.

Here, other protocols except for the URC protocol, namely Simple Mail Transfer Protocol (SMTP), Domain Name Protocol (DNS), etc., are not related to the technical spirit of the present invention, and thus description thereof will be omitted.

The protocol is based on an embedded network for efficient operation and operation of the robot, and can easily interoperate with a URC server, a robot, a URC server, a client or other terminals, and can simply implement various service operations.

The URC protocol sends and receives data between the robot and the URC server and the URC server and the client through communication between the application layers based on TCP / IP to control the robot from the client, and the user directly inputs the command through the robot to provide the services of the robot. Allows you to perform the operation without difficulty.

The protocol is matched between the robot and the URC server and the URC server and the client, and the interface is synchronized to transmit and receive data between them, so that the user can easily perform the desired service. Here, the transmitted and received packet has a data format for interfacing between the robot and the URC server and the URC server and the client.

3 is a diagram illustrating a header structure of a packet transmitted and received through a URC protocol between a robot and a URC server for controlling a robot according to a first embodiment of the present invention.

A packet having a structure as shown in FIG. 3 is classified into a picture, a voice, a VoIP, a moving, and the like according to the information of a payload (hereinafter referred to as a payload) field in the packet, and these packets correspond to each corresponding port. Is sent through. Each port has a common header.

The common header of the packet has a plurality of fields, each of which has a protocol discriminator 41, a protocol version 42, a session ID 43, a data direction 44, and data as shown in FIG. It includes a Type 45, Service ID 46, Payload Length 47, Reserved 48, and Payload 49 fields. Here, the payload 49 field includes a payload head having a size corresponding to 2 bytes, and a client type, a client ID, a user ID, a message type, and an authorization code form an internal field of the payload.

The Protocol Discriminator 41 can be allocated with 2 bytes and is the first field value to designate that the data is a message defined in the protocol. The protocol discriminator 41 processes the data by approving the interface only when the first field value of the input data is the same Protocol Discriminator. If not, it will be ignored without processing. For example, it will have the format 0x7E7E.

The Protocol Version 42 may be allocated in 2 bytes, and is a field for the Protocol Version. The Protocol Version 42 is initially set to, for example, 0x0001 (Version 1.0), and increases by one bit each time the protocol is updated.

Session ID 43 is composed of a session number assigned to 4 bytes and the number may be initially assigned a value of 0x00000000. After the user authentication is completed, the URC server automatically assigns the robot, and the Session ID 43 is used to separately identify and identify other terminals (eg, user terminal and PDA). In this case, there is a way to use one port and several ports, and if one port is used, it is used to distinguish and identify with other robots. It can be used to identify ports in.

Hereinafter, in the first embodiment, the Session ID 43 is used to distinguish the robot using one port.

The Data Direction (44) field is used to distinguish the final destination of data with 1 byte. It is used to distinguish whether the packet is transmitted from the robot to the URC server or the client to the URC server. It can be regarded as a delimiter for identifying who is sending the packet. For example, if 0x01 is indicated in the Data Direction (44) field, it can be seen that the robot transmits to the URC server.

The Data Type (45) field has 1 byte and can be classified into various types according to the format and content of the data. That is, the data recorded in the Data Type (45) field includes Automatic Speech Recognition (ASR) which is data for speech recognition, Text To Speech (TTS) which is data for speech output (synthesis), and FR (Data for speech recognition and motion detection). Face Recognition) / MD (Motion Detection), Authorization Data for Authorization, Robot Control Data, PDA Data, VoIP Data. Packets can be transmitted according to different ports for various data types recorded in the Data Type 45 field.

The Service ID (46) field is assigned to 2 bytes and records the ID allocated from the URC server to distinguish the service session between the robot and the remote client. The service recorded in the Payload 49 field is available. It is a field in which data for judging and classifying the data is recorded. According to Service ID, it is divided into Unmanned Security Service, Remote Monitoring Service, Voice Recognition Service, and Image Recognition Service. The initial Service ID starts with 0x0000 and increases by one each time the service is started.

The Payload Length (47) field has 2 bytes and specifies the size of the actual payload (49) field except the header in the form of bytes.

The Reserved (48) field has 4 bytes and is an extra field that is not used as an additional field item to guarantee QoS of a future packet.

The payload 49 field is an additional field for an API corresponding to each service and a portion including actual video and audio data. After the common header is defined, each additional distinction is needed for packets sent to the port. The payload in the Payload (49) field is actually a data type determined by Data type (45), that is, Automatic Speech Recognition (ASR), which is speech recognition data, Text To Speech (TTS), which is data for speech output (synthesis), and face. Face Recognition (FR) / Motion Detection (MD) data for recognition and motion detection, Authorization data for authentication, data for PDA, robot control data, and data for VoIP are transmitted.

Although the payload 49 field is not shown, Automatic Speech Recognition (ASR), which is speech recognition data, Text To Speech (TTS), which is speech output data, and Face Recognition (MD) / MD (Motion), which is data for face recognition and motion detection Detection), Authorization data for authentication, Robot control data PDA data, VoIP data can be classified into a number of forms. To this end, it further includes fields of Client Type, Client ID, User ID, Authorization Code, and Massage Type.

The client type is allocated to 1 byte and represents the type of the terminal, that is, the robot or the plurality of remote client terminals as 0x01, 0x02, 0x03, and 0x04, respectively. That is, when the client terminal is the origin or destination according to the data moving direction by Data Direction (), the Client Type indicates the client terminal.

Client ID is allocated to 4 bytes, and a unique ID is assigned to each of a plurality of terminals to distinguish each client terminal. In other words, when the client terminal becomes the origin or destination according to the data moving direction by the data direction 44, the client ID means the client terminal. In the method of assigning ID, a proper ID is generated by combining the manufacturing order and the user's region and the user ID.

User ID is the ID of the user recognized by the URC server with 1 byte. It is initially set to 000000 and increases by one whenever the number of users increases. After being authenticated by the URC server, the user can assign a user ID that can be registered.

The Authorization Code is a field that contains an authentication number for the Authorization Message of the robot terminal, and has a default value when the message type field of the message head portion is not an Authorization Message. In the case of an Authorization Message, the user receives an authentication key previously given to the individual, and the service can be used only when the authentication is confirmed.

The Massage Type is allocated in 2 bytes and classifies the procedure according to whether it is to transmit data or to initiate, respond, synchronize, or authenticate the connection between the robot and the client and the URC server. According to the type of message, as shown in Fig. 4, the Request Message 50, the Acknowledgement Response Message 51, the Error Acknowledgement Response Message 52, the Synchronization Message 53, the Authorization Message 54, and the Positive Authorization Message ( 55), Negative Authorization Message (56), Data Message (57), Close Report Message (58).

4 is a diagram illustrating a change in a message type transmitted and received between a robot and a URC server according to the present invention.

As shown in FIG. 4, the Request Message 50 is a message transmitted from the robot to the URC server when the robot attempts to connect to the URC server.

The acknowledgment response message 51 is a response message transmitted from the URC server to the robot when the connection is successfully made when the robot sends the request message 50 as described above.

Meanwhile, the error acknowledgment response message 52 is a response message transmitted from the URC server to the robot when the robot and the URC server are not successfully connected.

The Synchronization Message 53 is a message for checking a continuous connection state between the URC server and the robot in the state connected between the URC server and the robot as described above.

The Authorization Message 54 is a message transmitted from the URC server to the URC server to request the authentication when an acknowledgment response message 52 is received.

Positive Authorization Message (55) is an authentication completion message sent to the robot when the authentication of the robot succeeds in the URC server.

Meanwhile, the Negative Authorization Message 56 is an authentication failure message transmitted to the robot when authentication of the robot fails in the URC server.

The data message 57 is a message used for video, audio, TTS, VoIP, control data transmission, etc. in a corresponding format for general data transmission.

The Close Report Message 58 is a connection termination message transmitted from the robot to the URC server when the user commands the robot to terminate the connection with the URC server.

Each service field for messages to be used after the common head as described above is defined will be described in more detail as follows.

First, the payload field may be divided into a payload field for image, voice, and moving.

The Payload message field for image consists of file number, size and actual binary data. The file number consists of 1 byte of Client Type, 4 bytes of Client ID, and 3 bytes of file creation order. It represents the size and consists of 4 bytes, and the data is actual data.

The payload message field for voice is composed of the same type as the image, that is, the file number and size, and the actual binary data.The file number is composed of 1 byte of Client Type, 4 bytes of Client ID, and 3 bytes of file creation order. The size represents the size of the actual voice and is composed of 4 bytes. The data is actual data.

For example, if the file number for image and sound is 0x01 (Client Type) 000000001 (Client ID) 000009 (file creation order), this means the voice and image data generated from the ninth to the robot terminals. If the data direction value at the head is 0x01, the voice and image data means data to be transmitted from the camera and microphone of the robot terminal to the server. If the data direction is 0x02, it means data transmission in the opposite direction.

The payload message field for moving consists of five command types: robot movement, robot status control, robot status report, robot error status, and camera control, depending on the type of control command.

If the command type is Robot movement, it is allocated 12 bytes in total, 4 bytes of X-axis movement distance of the robot terminal, 4 bytes of Y-axis movement distance of the robot terminal, 2 bytes of posture angle of the robot terminal, and camera angle 2 Consists of bytes.

When the command type is Robot status control, it is allocated with 5 bytes in total, and it consists of 1 byte of robot terminal status report and 4 bytes of report period.

When the command type is Robot status report, it is allocated with a total of 15 bytes, and consists of 12 bytes of current position information of the robot terminal using the robot movement information, 2 bytes of current status information of the robot terminal, and 1 byte of completion of action. have. The current state information is information indicating an unmanned guard setting state, robot terminal movement state, monitoring state, robot terminal abnormal state, identity verification state, warning state.

If the command type is Robot Error status, this is allocated as 3 bytes in total, and it is the robot terminal that has determined whether it is abnormal. It is information indicating no abnormality, failure of the robot terminal moving part, impossibility of moving due to obstacles, and battery low. .

When the command type is Camera control, it is allocated in total of 2 bytes, and is composed of 1 byte of status commanded for image data transmission start and the like, and 1 byte of image data transmission.

Let's look at the robot control system using the message format according to the first embodiment of the present invention as described above

5 is a view showing a network connection relationship for the robot control system according to the present invention.

As shown in FIG. 5, the robot control system may include a client 10, a URC server 20, and a robot 30.

The client 10, the URC server 20, the URC server 20, and the robot 30 are respectively connected through a TCP / IP-based network, and packets are transmitted and received to each other through the network to recognize voice data and image recognition data. Performs operation according to moving control data.

When the user transmits a control packet for operating the robot 30 through the client 10 through the network, the URC server 20 analyzes the payload field of the received packet, and the user's command is a voice or keyboard command. In this case, the robot 30 is controlled to perform a service corresponding to the command. Then, the robot 30 completes the service and provides a packet corresponding thereto to the URC server 20, and the URC server 20 analyzes the service completion packet received from the robot 30 and corresponds to the result. The message is provided to the client 10 requesting the service in the form of a packet.

Therefore, the client 10 is to be displayed for the user to monitor according to the result message provided from the URC server 20.

On the other hand, when a user inputs a service command by voice to the robot 30, the robot 30 converts the voice input signal input by the user into a TCP / IP packet and transmits the packet to the URC server 20. The URC server 20 analyzes the voice data in the packet received from the robot 30 to recognize a service desired by the user, converts it into a packet of a moving control command, and transmits it to the robot 30 through a network. Therefore, the robot 30 performs a service corresponding to the payload information of the packet received from the URC server 20, and transmits a response to the URC server 20, the URC server 20 is the resulting information By generating a voice packet corresponding to the transmission to the robot 30 again, the user can check the result through the voice output from the robot (30).

6 is a diagram illustrating a service that can be provided to a robot and a client in a URC server and a basic message transmission / reception flow for the corresponding service when the robot and the client access the URC server in the robot control system according to the present invention.

Referring again to the packet, it is: Protocol Discriminator (41), Protocol Version (42), Session ID (43), Data Direction (44), Data Type (45), Service ID (46), Payload Length (47), Reserved 48 and Payload 49 have fields. In particular, the Payload 49 field has an internal field of Payload in which Client Type, Client ID, User ID, Authorization Code, and Message Type.

As shown in FIG. 6, the robot 30 and the client 10 may perform a service desired by the user only when the URC server 20 is authenticated.

First, authentication data is set in the Authorization Code and Message Type among the detailed items of the Payload field of the packet, and an authentication procedure is performed according to each code and message.

That is, the robot 30 is not initially authenticated and transmits a connection request message for authentication to the URC server 20. At this time, the message transmitted from the robot 30 to the URC server has an authentication number set by default in the Authorization Code, and there is a request message for attempting to connect to each other in the Message Type of the Payload field, and initial access to the remaining fields. The data according to is set.

Upon receiving the message, the URC server 20 confirms that the message type of the payload field is a request message, and transmits an acknowledgment response message to the robot 30 indicating the successful connection. If the connection is not successful, the URC server 20 transmits an error acknowledgment response message to the robot 30. At this time, it can be seen that the network connection is continuously made between the URC server 20 and the robot 30 when the message type indicates a synchronization message in the payload of the transmitted and received messages.

The URC server 20 determines that there is no abnormality in the network and transmits an Acknowledgement response message to the robot 30. Receiving this message, the robot 30 recognizes that the connection is successful and transmits an Authorization Message requesting authentication through the Message Type of Payload in the received message to the URC server 20.

Then, the URC server 20 performs the authentication of the robot 30 according to the authentication request of the robot 30, and transmits a positive authorization message to confirm the authentication to the robot 30 when the authentication is successful. Here, the authentication number information of the robot 30 is included in the transmitted message, and the corresponding authentication number is assigned to the robot 30. If the authentication of the robot 30 fails due to an external internal factor in the URC server 20, the URC server 20 transmits a Negative Authorization Message confirming the authentication failure to the robot 30.

Therefore, after confirming the authentication between the URC server 20 and the robot 30, it is possible to perform a service, such as video, voice, moving, etc. desired by the user by sending and receiving a random service request packet to each other.

On the other hand, since the authentication process of the client 10 is also authenticated by the same process as above, the detailed description thereof will be omitted and it is assumed that the authentication of the client 10 is completed through the same method.

When the authentication procedure of the robot 30 and the client 10 is completed as described above, the URC server 20 is a plurality of clients between the client 10 and the URC server 20 and the URC server 20 and the robot 30. In order to distinguish between the robot and the robot, an ID is assigned to the Session ID field and transmitted to the robot 30 and the client 10. Accordingly, the robot 30 and the client 30 request a desired service request message or a control request message for controlling the robot 30 to the URC server 20 using the Session ID provided from the URC server 20. The URC server 20 performs the corresponding service or controls the robot 30 according to the received service request message or the robot control message.

That is, the robot 30 transmits the packet including the voice data to the URC server 20 according to the voice command of the user. The URC server 20 analyzes the voice command from the received packet, extracts the corresponding service corresponding to the analyzed voice command from the DB, and gives the corresponding service ID to the robot 30. That is, the Service ID is transmitted to the robot 30 corresponding to the Session ID of the packet.

The robot 30 having received the Service ID transmits a packet of a specific execution mode for the URC server 20 and the corresponding service, and the service corresponding to the Service ID, that is, unmanned security, remote monitoring, voice recognition, and image recognition. , Moving control is performed, and the packet for the execution result is transmitted to the URC server 20. The Service ID may also set a number of other services that the robot 30 can perform.

For example, referring to the function of the service ID, after the terminal (robot, client) authentication is completed, when the user requests a specific service by voice through the robot 30, the voice data transmitted to the URC server 20 is analyzed. Through it is recognized as a specific service call and determines whether the robot 30 has the authority to use this service. As a result of determination, when the robot 30 is the robot 30 to which the service use authority is granted, the URC server 20 grants the robot 30 to call the service ID. Then, the robot 30 granted the Service ID uses the Service ID given in using the corresponding service.

When the robot 30 transmits a packet for requesting an arbitrary service to the URC server 20 by using the received service ID, the URC server 20 transmits a service of a packet header part transmitted from the robot 30. This is to analyze the ID and to run the application to perform the service.

On the other hand, since the client 10 is not a mobile object like the robot 30, the client 10 receives a service ID corresponding to a service for remote monitoring, and a packet for the service ID is transmitted to transmit an operation state or a monitoring image of the robot 30. And it can receive and monitor the voice data from the URC server 20.

That is, the client 10 does not directly control the robot 30 by directly communicating with the robot 30 through the URC server 20, but has a function of simply monitoring the status of the robot 30 and the like. . In this case, the URC server 20 also provides packet information with the robot 30 to provide the client 10 with monitoring information such as status information of the robot 30, for example, status image information and voice information of the robot 30. This information will be obtained.

Information in the payload field of packets transmitted and received between the URC server 20 and the robot 30 in order to achieve a service corresponding to the service ID as described above is performed by voice recognition, image recognition, authentication, moving control, control terminal control, and the like. Divided by example, let us explain in detail through the accompanying drawings the message flow between the robot 30 and the URC server 20 for this service.

FIG. 7 is a diagram illustrating a message flow between a robot and a URC server for an ASR (Autimatic Speech Recognition, TTS: Text To Speech) service in a robot control method according to the present invention.

As shown in FIG. 7, first, the robot 30 transmits a message ASR_SVC_RECG_WLST to the URC server 20 to the URC server 20 in order to recognize a voice command input by the user (S101). The message includes a lexical list of user voices required for speech recognition.

The URC server 20 transmits the message ASR_SVC_RECG_FLST including the voice recognition vocabulary file name information to the robot 30 according to the message received from the robot 30 (S102).

The robot 30 transmits the ASR_SVC_RECG_PROC message including the speech recognition data to the URC server 20 (S103), and the URC server 20 analyzes the speech recognition data received from the robot 30 to recognize the recognized vocabulary and score information. The ASR_SVC_RECG_PROC_RESULT message including the will be transmitted to the robot 30 (S104).

The robot 30 requests the general synthesis of the text through the TTS_SVC_TEXT_BUFF message to the URC server 20 again (S105), and the URC server 20 sends the TTS_SVC_TEXT_BUFF_RESULT message for the text synthesis result to the robot 30. It will be transmitted to (S106).

The robot 30 transmits a TTS_SVC_TEXT_FILE message for requesting text as a specified file name to the URC server 20 according to the text synthesis result message received from the URC server 30 (S107).

The URC server 20 transmits a TTS_SVC_TEXT_FILE_RESULT message including the voice file synthesized according to the message of the robot 30 to the robot 30 (S108), and the robot 30 transmits the text to the text transmitted to the server 20. The voice synthesis is requested with the message TTS_SVC_TEXT_STREAM (S109).

Accordingly, the URC server 20 transmits the synthesized voice data and ID of the text to the robot 30 through the message TTS_SVC_TEXTSTREAM_RESULT according to the request of the robot 30 (S110).

The robot 30 requests the URC server 20 to synthesize the human name with the message TTS_SVC_NAME_BUFF (S111), and the URC server 20 transmits the data about the synthesized human name through the message TTS_SVC_NAME_BUFF_ + RESULT. 30) to be transmitted (S112).

8 is a diagram illustrating a message transmission and reception flow between a robot and a URC server for image recognition and motion detection (tracking) service in the robot control method according to the present invention.

As shown in FIG. 8, the robot 30 first transmits its Session ID, that is, the robot ID, to the URC server 20 through the message HCI_VISION_InitServer (S201).

The URC server 20 transmits authorization result result information on whether the service is available using the robot ID according to the message for the robot ID received from the robot 30 to the robot 30 through the IDHCI_VISION_InitServer_RESULT message ( S202).

The robot 30 transmits to the URC server 20 whether the face registration according to the registered user ID is possible before executing the face registration mode through the message HCI_VISION_FRCONF (S203).

When the face registration according to the user ID of the robot 30 is possible, the URC server 20 requests the robot 30 for a face image to be registered through the HCI_VISION_FRCONF_PROC message (S204).

The robot 30 transmits the image to the face image URC server 20 captured for face recognition through the HCI_VISION_FRMODE message according to the request of the URC server 20, and registers the same in the URC server 20 (S205). 20) transmits an HCI_VISION_FR_PROC message indicating that the face image has been registered to the robot 30 (S206).

The robot 30 transmits the actual face data for image recognition to the URC server 20 through the HCI_VISION_FI_MODE message (S207), and the URC server 20 determines whether the face data received from the robot 30 can be recognized. The HCI_VISION_FI_PROC message including the information is transmitted to the robot 30 (S208).

On the other hand, when the robot 30 transmits the image data for the unmanned security guard through the HCI_VISION_SV_MODE message to the URC server 20 (S209), the URC server 20 transmits the image data transmitted from the robot 30 for the unmanned security guard. The service is terminated by transmitting the HCI_VISION_SV_PROC message for the analysis result to the robot 30 (S210).

9 is a view showing a transmission and reception message flow between the robot and the URC server for the authentication of the robot in the robot control method according to the invention, Figure 10 is a robot control method in the robot control method according to the present invention, the remote of the robot from a remote client A diagram illustrating a flow of transmission and reception of authentication messages with a server for monitoring.

As shown in FIG. 9 and FIG. 10, an authentication message is transmitted upon an initial connection request, which can be divided into two types of authentication for the robot 30 and authentication for the clients 10.

First, the authentication for the robot 30 is shown in FIG. 9, the robot 30 transmits an AUTH_INITIATE message including information necessary for authentication for its authentication to the URC server 20 (S301).

The URC server 20 analyzes the information required for authentication transmitted from the robot 30 and transmits the AUTH_RESULT message including the information on the analysis result, that is, the authentication result information, to the robot 30 to perform authentication, and then the other. The service will be performed (S302).

Meanwhile, as shown in FIG. 10, the client 10 first authenticates the client 10 to the main URC server 20 when the first connection request is made through the AUTH_INITIATE message. In response to the authentication request from the client 10, the main URC server 20 transmits an AUTH_ROBOT_LIST message including list information about the connectable robots 30 and current status information of the robots 30 (see FIG. S402).

The client 10 transmits an AUTH_SELECTED_ROBOT message for authentication of the robot 30 selected by the user among the plurality of robots 30 to the main URC server 20 (S403).

The main URC server 20 transmits an AUTH_ROBOT_LOCATION message containing the corresponding URC server 21 information for allocating another URC server 21 to which the robot 30 selected by the user is connected (10). S404). In this case, the process of obtaining information about the URC server 21 to which the robot 30 to be controlled is connected may be omitted.

In addition, the client 10 may terminate the connection with the main URC server 20 by transmitting an AUTH_BYE message for terminating the connection with the main URC server 20 (S405).

In addition, the client 10 transmits an AUTH_RE_INITIATE message, which is an authentication request message, to the URC server 21 in order to access the URC server 21 to which the robot 30 selected by the user is connected and receive a desired service (S406).

In response to this, the URC server 21 transmits an AUTH_RESULT message including authentication result information to the corresponding client 10 to complete authentication and proceed to the next procedure.

11 is a diagram illustrating message types transmitted and received between a robot and a URC server for controlling the driving of a robot in the robot control method according to the present invention.

As shown in FIG. 11, the messages transmitted from the robot 30 to the URC server 20 include a Robot_Movement message requesting movement control of the robot 30, and a Robot_Report for determining a status checking period of the robot 30. It may include a Frequency message, a Robot status Report message for reporting the current status information of the robot 30, a Robot Error status message for checking the error status information of the robot 30.

Meanwhile, as a message transmitted from the URC server 20 to the robot 30, a camera control message for controlling the camera movement of the robot 30, the state of the robot 30, or the URC server 20 may be sent to the robot 30. ) May include a Status_Info Report message for notifying, and a Close_Info Report message for informing the reason for connection termination between the robot 30 and the URC 20.

These messages are used to update the data of the URC server 20, update the attribute DB of the robot transferred from the robot 30 to the URC server 20, transmit user ID and password, and authenticate the robot 30. Messages about this.

12 is a diagram illustrating a type of a message transmitted and received between a remote client and a URC server for controlling a robot through a URC server in a robot control method according to the present invention.

As shown in FIG. 12, the URC server 20 transmits a Map_Version_Req message to the client 10 for requesting map version information from the client 10.

The client 10 transmits the map version information of the URC server 20 to the URC server 20 through the Map_Version_Resp message according to the request of the client 10.

At this time, the URC server 20 compares the map version information received from the client 10 with the map version information owned by the client 10 through the Map_Version_Resp message, and compares the matching result information for the map version with the Client_For_Robot_Map message. Will be sent to.

In addition, the URC server 20 transmits the map information to the client 10 through the Client_For_Image message when the map version is not correct.

The URC server 20 first informs the client 10 about the robot status through a Client_For_Robot_Status message. In addition, the client 10 transmits the Client_Sampling_Freq, Client_For_Image, Client_For_Button_Control, Client_Map_Control, and Client_For_Robot_Camera_Control messages to the URC server 20, each of which receives image data from the server 20 and requests image data from the server 20. In this case, messages are transmitted when controlling a robot camera to be delivered to a server and when a termination request is made.

As described above, the first embodiment of the present invention proposes a data format for a terminal that enables a smooth interworking between a robot, a server, and a user terminal (client), and accordingly, the robot and the client want a service from the robot using a server. It will allow you to monitor smoothly and conveniently.

However, this first embodiment according to the present invention is intended to have a message structure specific to the service for the service implementation. This is an inconvenient problem that a message structure must be implemented or added every time for service development. In addition, the added message structure is disadvantageous that it is not suitable for implementing other applied services and cannot be recycled.

In addition, as shown in Figure 3, having a Service ID 46 field, the robot, the URC server, and the client receiving the service is implemented according to a specific service and the service ID has been given a service ID . Therefore, in order to receive a specific service, a different message structure for each service is required.

In addition, in the first embodiment, a mechanism for synchronizing service performance is not provided. If the motives of service execution are not correct, the timing of service start and end may be blurred. That is, the URC server side may provide a service at an inaccurate time point, which may cause a malfunction of the robot.

In addition, it does not provide a mechanism to cope with abnormal situations that may exist between the robot and the URC server. In other words, if the robot is disconnected while the network is unstable, the URC server does not know the situation and can recognize that the robot is continuously connected to the network. Therefore, the user may not recognize the unstable state of the network, and the URC server may not take an appropriate action such as an error message output or forced termination.

Accordingly, the second embodiment according to the present invention described below is intended to solve the problems of the first embodiment according to the present invention.

(2nd Example)

Hereinafter, a robot control system and a method thereof according to a second embodiment of the present invention will be described in detail with reference to the accompanying drawings.

FIG. 13 is a view schematically showing a connection relationship to a robot control system according to a second embodiment of the present invention. FIG.

As shown in FIG. 13, the plurality of robots 200 are connected to the URC server 100 through a network, and the plurality of remotely located clients 300 are connected to the URC server 100 through the network, respectively.

As shown in FIG. 13, the robot 200 acquires context information such as a voice command or an image input from a user or an external device, and transmits the situation information to the URC server 100.

The URC server 100 processes the voice command or image information transmitted from the robot 200 to grasp the intention of the user, and then provides the intelligent and context-sensitive URC service.

In the URC service, it is possible to provide physical services to users in addition to services such as information transfer using mobility.

In addition, the plurality of remotely located client 300 can provide a variety of forms of services by using the robot 200 and the recognition function of the remotely located in the remote 200, which is a service URC server 10 It is not only to provide services but also to allow service providers to provide services remotely so that various types of business models can be created within the URC infrastructure.

Robots 200 according to the URC standard can use a variety of services provided by the URC infrastructure, and many robots 200 that are interlocked in the URC infrastructure can provide a market that can generate revenue to service providers.

The plurality of URC robots 200 and the plurality of clients 300 remotely located to send and receive messages for communication with the URC server 100 and the plurality of clients (300) and the URC server (300) The message format used for the communication protocol between 100 is shown in FIG.

14 is a diagram illustrating a common header structure for a message transmitted and received between a robot, a client, and a URC server according to a second embodiment of the present invention.

As shown in FIG. 14, the URC protocol basically performs message-based communication using the TCP / IP protocol, and this unit message is called a URC message. Framing of these URC messages uses a message format in binary format for efficient communication. URC messages are classified into four types of URC Request, URC Response, URC Heartbeat, and URC Event messages, and all four message types have a common header format. The data format and meaning of the URC common header message header field are shown in Table 1 below.

FIELD TYPE DESCRIPTION DISCRIMINATOR short URC protocol identifier (for example 0x7e7e) VERSION byte The version of the URC protocol currently in use (eg 0x02). SESSION ID integer ID for the currently connected session PROFILE ID short ID of the profile to which the message belongs (function ID) RESERVED Reserved Field (2 bytes) MSG TYPE byte Type of message MSG LEN unsignded integer The length of the message except the size of the common header

Messages defined in the URC protocol are classified into profiles according to their functions and uses, and the profiles provided by the URC protocol are shown in FIG. 15.

FIG. 15 is a diagram illustrating a URC protocol profile structure between a robot, a URC server, and a remote client in a robot control system according to a second embodiment of the present invention.

As shown in FIG. 15, the profile of the URC server 100 provides various functions necessary for implementing intelligent services such as voice / video recognition and voice synthesis, and also remotely controls the robots by the clients 300. It is to provide an interface to do this. That is, the URC server profile may include an authentication profile, a remote interface profile, an event profile, a voice recognition profile, a voice synthesis profile, an image recognition profile, and a motion detection profile.

Meanwhile, as shown in FIG. 15, the robot common profile provides a general interface for controlling the robot 200. In the URC service, a physical service using a robot may be provided to a user by using functions provided by a robot common profile. That is, the URC robot common profile may include a movement profile, a navigation profile, a voice detection profile, a speech profile, a motion profile, and an emotion profile.

The robot common profile refers to the functions that robot developers must implement in order for URC robots to receive services through the URC infrastructure, and robots that implement the robot common file can receive the same services regardless of their form and performance. will be.

Hereinafter, the operation mechanism of the URC communication protocol between the robot, the URC server and the client in the second embodiment of the present invention will be described.

The operating mechanism of the URC protocol may include a URC message framing mechanism, a URC message encoding mechanism, a URC authentication mechanism, a URC robot ACK and an HB heartbeat.

First, regarding the URC message framing, the URC protocol basically performs a message-based communication on TCP so that this unit message is called a URC message. Framing of URC message uses binary message composition for communication efficiency, and various information contained in URC message is expressed in data format described in UDR Protocol Data Representation (UDR).

In the URC message encoding, URC messages are encoded in a "llittle-endian" format, and Korean encoding uses "KSC-5601".

In the URC authentication mechanism, all URC robots and URC clients accessing the URC infrastructure are given the necessary authority through the process of identifying the robot 200 and the user through the authentication process. The URC robot 200 performs authentication based on the ROBOT ID registered in advance, and the URC clients 300 identify themselves by performing authentication based on a pre-registered user ID and password.

The URC robot ACK mechanism is a mechanism for event notification and response (Event Nofitication / Acknowledge) when the URC robot 200 receives an event such as user voice command or motion detection acquired in the ubiquitous environment. It should be able to notify the URC server 100 asynchronously. The URC server 100 can provide the appropriate service by grasping the user's intention or situation through such asynchronous event information.

In addition, since most of the functions provided by the URC robots 200 require a certain amount of time from the start of the function to the end of the function, in order to synchronize the functions of the URC robots 200 with other functions, the operation of the URC robots 200 is performed. At the end, the corresponding Acknowledge should be notified to the URC server 100 in the form of an event. In the URC server 100 to match the synchronization necessary to perform the service through the ACK. 16 shows such a URC robot ACK operation.

As shown in FIG. 16, since the functions of the robot 200 may be defined for each component, each component constitutes a state machine, for example, as shown in FIG. 16. The operation is performed by the components present, and the corresponding event should be notified to the URC server 100 at the time when the state of the robot 200 is transitioned.

That is, since the function of the robot 200 can be defined for each component of the robot 200, each component of the robot performs an operation by a state machine and a state is transitioned. At this point, the event should be notified to the URC server 100.

In the URC protocol, each component state of the robot 200 is divided into two types, "IDLE" and ACTIVE, and when the state transitions from each state to another state, an event of "START", "END" or "STOP" is transmitted to the URC server. Therefore, the URC server 100 can easily grasp the current operation state of the robot according to an event message transmitted from the robot 200.

On the other hand, the heartbeat mechanism, basically, the URC robots 200 are connected to the URC server 100 at the same time the drive is maintained until the end of the drive of the URC robot 200. Therefore, if the connection is lost due to an abnormal network environment during the service, it is important to identify the abnormal situation quickly and take appropriate action. In order to continuously determine whether the URC server 100 and the UEC robot 200 maintains a normal network connection, the URC protocol defines a Heartbeat protocol between the URC robot 200 and the URC server 100 to define the network environment as described above. To deal with abnormal situations caused by. That is, FIG. 17 illustrates an operation for determining a connection state between the robot 200 and the URC server 100 by the network environment as described above between the URC robot 200 and the URC server 100. That is, FIG. 17 illustrates a method for checking a connection state between a robot and a URC server.

As shown in FIG. 17, the URC server 100 periodically transmits a Heartbeat request message to the robot 200 (for example, every N seconds), and the robot 200 transmits the data from the URC server 100 to the robot 200. The heartbeat response message is transmitted to the URC server 100 according to the heartbeat request message. Therefore, the URC server 100 can check the network connection state with the robot 200.

If the heartbeat response message is not received within a certain period, even though the URC server 100 transmits the heartbeat request message, it is determined that the network connection is in an abnormal state, and if the heartbeat response message is received within the predetermined period, the robot 200. It is determined that the connection status with is normal. Therefore, when the URC server 100 determines that the network connection is abnormal, it will be able to continuously control the robot 200 by attempting to reconnect for the connection with the robot 200.

A method of controlling the robot through the URC server from a remotely located client using the mechanism and the URC protocol messages as described above will be described in detail with reference to FIG. 18.

18 is a diagram illustrating a message transmission and reception flow for remotely controlling a robot in a client according to a second exemplary embodiment of the present invention.

First, the robot 200 connects to the URC server 100 and starts transmitting the situation information such as a voice command or current image information acquired by the robot 200 to the URC server 100, and from the URC server 100. It receives the control command and performs the operation defined in the URC protocol.

On the other hand, the remote client 300 is remotely connected to the URC server 100 and selects the robot 200 to be controlled by the robot 200 according to the logic of the service to implement the necessary information from the robot 200 Can be acquired or controlled remotely.

In the case of the remote control and monitoring service, the remote client 300 may request to transmit the image information and the status information to the robot 200 to check the image and status of the robot 200 remotely, and also control the robot remotely. The control may be performed by remotely moving the robot 200 or talking through the robot 200 through a command.

An operation flow for controlling or monitoring a robot in such a client will be described step by step with reference to FIG. 18.

First, as shown in FIG. 18, the URC client 300 located remotely transmits a URC_CLIENT_LOGIN message to the URC server 100 to remotely control the URC robot 200 or provide a monitoring service of the robot 300. After accessing the URC server 100, the authentication is received from the URC server 100 (S501). Here, since the client authentication procedure has been described in detail in the first embodiment of the present invention, a detailed description thereof will be omitted.

After the authentication is completed, the URC client 300 transmits a URC_GET_ROBOT_LIST message for requesting list information of the robots 200 connected to the URC server 100 to the URC server 100 (S502).

The URC server 100 transmits the robot list information to the URC client 300 by including the robot list information in the URC_ROBOT_LIST message according to the request of the URC client 300 (S503).

The URC client 300 allocates a robot to be controlled according to the robot list information transmitted from the URC server 100, and transmits a URC_ALLOCATE_ROBOT message for requesting the robot allocation information and the use authority of the robot to the URC server 100. (S504).

When the URC client 300 is authorized to control the robot from the URC server 100, each of the URC client 300 to the corresponding event channel to monitor the status information and image information necessary for the control and remote monitoring of the robot 200. SUBSRIBER_EVENT_CHANNEL (VISION, SYSTEM, ROBOT, STATUS) message to the subscription is to be transmitted to the robot 200 through the URC server 100 (S505, S506). Here, the URC server 100 simply performs a function of interfacing the corresponding message transmitted from the URC client 300 to the robot 200 allocated by the client 300.

In addition, the URC client 300 subscribes to the desired event channel, the OPEN_VISION message and OPEN_STATUS_MONITOR message to the corresponding robot 200 through the URC server 100 in order to request image information and status information from the robot 200. Transmit (S507, S508).

The robot 200 periodically transmits an EVENT_NOTOFICATION (VISION, STATUS) message including the image information and the state information photographed by the URC client 300 to the URC client 300 (S509 to S512).

The URC client 300 transmits a MOVE_ROBOT (FORWARD) message, which is a message for controlling the movement of the robot 200, by using the image information and state information transmitted from the robot 200 (S513).

The robot 200 performs a corresponding movement operation according to a request of the URC client 300. The client 300 easily checks the movement operation state of the robot 200 so that the robot 200 moves for service synchronization. The EVENT_NOTIFICATION (MOVE_START) message and the EVENT_NOTIFICATION (MOVE_END) message, which are event notification messages for accurately notifying the start time and the end time of the operation, are transmitted to the URC client 300 (S513 and S514).

Through the above method, the URC client 300 may remotely control the robot 200 in real time using image information and state information transmitted from the robot 200.

Then, when the service is terminated, that is, when the remote control of the robot 200 from the URC client 300 is terminated, the URC client 300 is remotely controlled by the URC server 100, that is, to release the assignment of the robot The URC_RELEASE_ROBOT message, which is a message, is transmitted to the URC server 100 (S516), and the URC client 300 transmits a URC_CLIENT_LOGOUT message to the URC server 100 to terminate the connection of the URC server 100 to the URC server 100. It will end.

As a result, in the second embodiment of the present invention, the service-specific message structure in the first embodiment is improved to a protocol of a common profile type, so that a service provider can develop a service logic-centric development using a protocol layer. .

This allows for more convenient service addition by providing a common interface and infrastructure without adding more new messages. In addition, the service provider can easily add a service by providing an interface for configuring service logic remotely using a profile.

In addition, in order to provide service performance synchronization not provided in the first embodiment of the present invention, the request and response structure, which is a message primitive provided in the first embodiment, is improved and an event message is added. That is, in the second embodiment of the present invention, an error message is reduced by sending an explicit acknowledgment for a service running on all robots using an event message, and service logic is more easily configured.

Lastly, in the first embodiment of the present invention, a mechanism for coping with an abnormal situation that may exist between the URC robot and the URC server is not provided, but in the second embodiment of the present invention, the URC Heartbeat message is added to the abnormal state of the robot or server. This is to check the status and take action accordingly, which makes the status check between the user and the robot server more efficient.

Network-based robots can provide intelligent and contextual services to users by utilizing various functions provided by the URC infrastructure by following the protocol proposed by the present invention.

In addition, the URC client can provide various types of services by utilizing the robot's sensing capabilities and the mobility of the robot from a remote location. Various types of business models can emerge within the URC infrastructure.

As a result, robots following the URC protocol can use various services provided by the URC infrastructure, and many robots linked with the URC infrastructure can provide a market for profitable service providers to contribute to the dissemination of intelligent robot services. There will be.

As described above, the present invention proposes a data format of a protocol for smoothly interworking between a robot, a server, and a user client, so that even a plurality of robots and clients can secure efficient compatibility and can be used universally.

In addition, since a terminal such as a robot and a user can smoothly and conveniently use a desired service from the robot using a server, there is an effect of maximizing user convenience.

In addition, an event message has been added to provide service performance synchronization. By using the added event message, explicit acknowledgments are sent for services running on all robots, reducing the occurrence of errors and making service logic easier.

Lastly, a mechanism for coping with abnormal situations in the network environment that may exist between the URC robot and the URC server, that is, the URC Heartbeat message has been added to check the abnormal state of the robot or server and to take appropriate action. This makes the status check between the user and the robot server more efficient.

In addition, network-based robots can provide intelligent and contextual services to users by utilizing various functions provided by the URC infrastructure by following the protocol proposed by the present invention.

In addition, the URC client can provide various types of services by utilizing the robot's sensing capabilities and the mobility of the robot from a remote location. Various types of business models can emerge within the URC infrastructure.

As a result, robots following the URC protocol can use various services provided by the URC infrastructure, and many robots linked with the URC infrastructure can provide a market for profitable service providers to contribute to the dissemination of intelligent robot services. There will be.

Claims (49)

delete delete delete delete delete delete delete delete delete A communication control system based on wired / wireless communication; A terminal for performing at least one service among image, voice, and moving according to payload contents of a preset data format; Recognizing a user command through the terminal and transmitting and receiving the packet having the data format according to the terminal and the corresponding protocol, and includes a server for controlling the service to be performed in the data format, The packet for transmission from one side of the terminal and the server to the other side, Protocol Discriminator field for accepting the interfacing between the one side from the other side; A Session ID field for setting an ID to distinguish the terminal; A Data direction field for setting a direction for transmitting data from the one side to the other side; A Data Type field defining at least one of a format and contents of the data as a representative; A Service ID field for determining whether to use a service of the following message performed by one of the one side and the other side, and setting an ID to distinguish the service; And a payload field for setting a data defined in the data type field and an available service determined in the service ID field and assigning a message to the one side and the other side to perform the service. Communication control system using. The method of claim 10; The terminal includes at least one robot terminal and at least one control terminal communication control system using a data format for the terminal. The method of claim 11; The robot terminal processes the voice message from the user into a packet having a data format for operating itself and provides the server to the server, and performs the corresponding service to inform the user of the result; The control terminal processes the information about the service desired by the user into a packet having the data format in order to control the robot terminal and transmits it to the server, and receives the service result of the robot terminal from the server and informs the user. Communication control system using a terminal data format, characterized in that. The method of claim 12; The information about the service is recorded in the Payload field of the packet, and the message recorded in the Payload field includes an authentication number and its procedure message, image recognition message, voice recognition message, and moving control message. Communication control system using a data format for the terminal, characterized in that to provide unmanned security, remote monitoring service. Claims [1] A communication control method for transmitting a packet having a data format for a terminal set from one side of at least one terminal and a server toward the other side in a wired / wireless communication based on a corresponding protocol; Confirming authentication according to an authentication procedure between the terminal and the server using a data format of the packet; Assigning a Session ID for identifying each of the terminals in the data format after the authentication; Inputting a user's voice command to the corresponding terminal to which the Session ID is assigned, transmitting a payload message of a packet having the voice data to a server, analyzing the payload message, and returning a service ID; And transmitting, by the corresponding terminal performing the operation according to the Service ID, the result thereof to the server. The method of claim 14; The service corresponding to the Service ID is an unmanned security, remote monitoring, voice recognition, image recognition, moving control method using a data format for the terminal, characterized in that for performing. The method of claim 14; The authentication procedure, The terminal attempting to access the server by sequentially performing a request message, an acknowledgment response message, and an error acknowledgment response message of a message type corresponding to an internal field of the payload message of the data format; After the connection, sequentially performing the Authorization Message, Positive Authorization Message, and Negative Authorization Message of the Message Type to assign an authentication number according to the authentication request of the terminal. Way. The method of claim 16, If there is more than one terminal, the step of assigning an authentication number further comprises the step of receiving a list of each terminal and transmitting an authentication request message to the corresponding terminal desired by the Select Message defined in the Message Type Communication control method using data format. The method of claim 14; And the terminal comprises at least one of at least one robot terminal and at least one control terminal. delete delete delete delete delete delete delete A communication control system; A robot that performs at least one service among images, voices, and movings according to payload contents of a preset data format; A server which recognizes a user command through the robot and transmits and receives a packet having the data format according to the robot and the protocol, and controls the service to be performed in the data format; Includes a client located remotely to perform a remote control and monitoring service of the robot through the server, The preset data format between the robot, server, and client, A Protocol Discriminator field containing protocol identifier information for approving interfacing between the robot, server and client; A Session ID field containing unique information (ID) for identifying a session that is currently connected; A Profile ID field including information for distinguishing a profile (control function) performed by any one of the robot, server, and client; An MSG Type field including type information of a message transmitted and received between the robot, server, and client; And a payload field including a message for performing a service for a corresponding function according to data defined in the MSG Type field and profile information included in the Profile ID. The method of claim 26, The robot receives a control message for controlling each component constituting the robot from the server or client using the preset data format to drive the corresponding component, and when the movement state of the corresponding component is transitioned. A communication control system for providing motion transition event information to the server or client. The method of claim 27, The motion transition event information divides each component state of the robot into IDLE and ACTIVE states, and includes start, end (or stop) event information when a transition is made from each state to another state. The method of claim 26, The server periodically transmits a heartbeat request message according to the preset data format and determines whether the robot receives the HB response message according to the preset data format to determine the network connection state of the robot. Communication control system to grasp network connection status. The method of claim 29, And the robot transmits a heartbeat response message to the server according to a heartbeat request message periodically transmitted from the server. The method of claim 26, The server performs authentication of the client for remote control of the robot at the client, provides the list information of the robots connected to the client, and when a robot to be controlled from the client is assigned, an interface between the allocated robot and the client Provide communication control system. delete The method of claim 26, Profile of the server, An authentication profile for performing authentication of the robot and the client, a remote control profile providing an interface for remotely controlling the robot from the client, and controlling an event (robot movement control) of the robot from the server or the client An event profile, a voice recognition profile for voice recognition of voice commands received from the robot, a voice synthesis profile for synthesizing voice recognition data and text data, an image recognition profile for recognizing image information transmitted from the robot, And at least one profile of the motion detection profile for detecting motion of the robot. The method of claim 26, Profile of the robot, It performs the movement profile for moving the robot's position, navigation profile, voice detection profile for voice command, voice profile outputting data to voice synthesis provided from the server, motion profile to control the robot's movement, and robot's emotion expression function. And at least one profile of said emotion profile. In a method for controlling a robot using a client located remotely in a communication control system including a client, a robot and a server providing an interface between the client and the robot, Requesting a plurality of robot list information connected to a server by connecting to a server to perform remote control and monitoring service of any robot; After the server authenticates the client, transmitting the robot list information connected to the server to the client; The client selecting a robot to be controlled by using the robot list information transmitted from the server and transmitting the corresponding information to the server; The server communication control method comprising the step of setting the transmission and reception interface of the message for the robot remote control and monitoring service between the robot selected from the client and the client 36. The method of claim 35 wherein In a state in which an interface is established between the client and the robot selected by the client, the client subscribing to various service channels for controlling the robot through a server; After joining the service channel, the client requests image information and status information of the robot to the robot through the server, and controls to control any function of the robot according to the image information and status information periodically transmitted from the robot. Sending a message; The robot performs the corresponding function according to the control message transmitted from the client through the server, and transmits event information on the operation time and the end time of the function to the client through the server; And when the client ends the remote control and monitoring service of the robot, sending a connection termination request message to the server to log out of the connection with the robot. The method of claim 36, The server periodically sending a heartbeat request message to the robot to check the robot's network connection status; The robot further comprises the step of notifying the network connection status information to the server by sending a response message according to the Heartbeat request message transmitted from the server. The method of claim 10; A message recorded in the payload field is divided into a picture message, a voice message, and a moving message. The picture message is composed of a file number, a size, and picture data. The voice message is composed of a file number, a size, and voice data. And the moving message has a command type of robot movement, robot status control, robot status report, robot error status, and camera control according to the type of controlling the moving. The method of claim 38, A file number included in the voice message and the picture message comprises a Client Type, a Client ID, and a file generation order; The robot movement is a message for controlling moving by consisting of an X-axis movement distance of the terminal, a Y-axis movement distance of the terminal, an attitude angle of the terminal, and a camera angle; The robot status control is composed of a status report and a reporting period of the terminal to check the current status of the terminal in real time; The robot status report is a message about the unmanned alarm setting state, the movement state of the terminal, the monitoring state, the abnormal state, the identification state, the warning state, the position information of the terminal, and the action completion information according to the robot movement. A message configured to determine a service result of the terminal; The Robot Error status is a message regarding an operation condition of the terminal by determining whether at least one terminal itself is abnormal, The command type of the camera control is a communication control system using a data format for a terminal, characterized in that the message associated with the image transmission. The method of claim 38; The payload field includes ASR (Automatic Speech Recognition), which is voice recognition data, Text To Speech (TTS), which is voice output data, Face Recognition (MD) / Motion Detection (MD), and authentication data, which are data for face recognition and motion detection. In order to provide messages of Authorization, Moving data, and VoIP data, a communication control system using a terminal data format further comprises fields of Client Type, Client ID, User ID, Authorization Code, and Massage Type. . 41. The method of claim 40; The Client Type field is a field complementary to the directional information of the Data Direction field, and indicates a type of a terminal corresponding to the directional information; The Client ID field is for distinguishing a terminal corresponding to the directional information of the Data Direction field by setting an ID corresponding to at least one terminal; The User ID field sets an ID for recognizing at least one terminal by a server, and ID means a number of registered users; The Authorization Code field is a communication control system using a data format for a terminal, characterized in that to provide an authentication number of each of at least one terminal. 41. The method of claim 40 The Message Type field provides a procedure for connection initialization, response, synchronization, authentication, data transmission, etc. between the terminal and the server. The message transmitted between the terminal and the server includes a first message group for connection between the terminal and the server, a second message group for authentication between the terminal and the server, a message for continuity of the first message group and the second message group, Communication control system using a data format for the terminal, characterized in that it comprises a message, the end message transmitted to each other authenticated. 43. The method of claim 42; The first message group includes a request message, an acknowledgment response message, and an error acknowledgment response message, and the second message group includes an authorization message, a positive authorization message, and a negative authorization message, and the message for continuity is a synchronization message. And the payload message is a data message and the end message is a close report message. The method of claim 10; The terminal includes at least one of at least one robot and at least one client terminal communication control system using a data format for the terminal. The method of claim 10; And a Protocol Version field for presenting the updater status of the data format. The method of claim 34, wherein The robot profile further includes an event provision profile that provides motion transition event information to the server or client when a motion control message of the robot is received from the server or client and the motion state of each component of the robot is transitioned. Communication control system. 47. The method of claim 46 wherein The movement transition event divides each component state of the robot into an IDLE and an ACTIVE state, and divides each state into a start, end (or stop) event when a transition is made from each state to another state. The method of claim 33, wherein Profile of the server, And a HB request profile that periodically transmits a Heartbeat request message to determine a network connection state of the robot. The method of claim 34, wherein Profile of the robot, And a HB response profile for transmitting a heartbeat response message to the server according to a heartbeat request message periodically transmitted from the server to determine a network connection state of the robot.

Images