JP2007157166A - Method and apparatus for providing xml-based service in server controlling mobile home service robot - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method and an apparatus for providing XML-based service in a server controlling a mobile home service robot. <P>SOLUTION: The method and the apparatus for providing an XML-based service in a server controlling a mobile home service robot comprise steps of: receiving a service instruction; interpreting the service instruction to generate at least one object; initializing the object to confirm whether to satisfy a task execution condition or not, and determining priority-based execution of tasks when the execution condition is satisfied; receiving, if data provided by the robot is needed for the execution, the data after requesting information providing to the robot and executing a task determined to be executed. A task is then formed based on XML to the home robot having an inexpensive and low-level processor, whereby robot services can be easily developed, and the inexpensive home robot can also embody the same service as a high-level robot. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a method for controlling a mobile home service robot, and more particularly, an inexpensive mobile home service robot including a motorcycle, an LCD monitor, a microphone, a speaker, an obstacle sensor, and a low-level main control processor. For the control software architecture field. More specifically, the present invention is based on the XML (extensible Markup Language) based on a user's command or a specific situation, and an inexpensive home service robot creates this as a remote robot control program. The present invention relates to a method that is executed after being installed, and relates to a method for developing a service for a robot based on a high-level text that is not a programming language such as C, C ++, or Java, and executing the service even on an inexpensive robot.

  Currently, a general method for creating a robot task takes three forms as follows.

  The first is a method of directly creating a robot task program using an object-oriented (object-oriented) language such as C ++ or Java or a C language using an interface that abstracts hardware. This method has a problem that it is difficult to create a task unless the developer is skilled in the hardware characteristics and control program of the robot. There is also a problem that it is difficult to change the attribute of the robot task once created at the execution time.

  Second, while using the first method, hardware-dependent data used in the robot task is created in XML to add flexibility. Compared with the first method, this method has an advantage that the execution time can be arbitrarily changed because the hardware characteristic information used by the robot task is created in the XML format. However, this method also has a problem that tasks can be developed only when there is specialized knowledge in the robot field because the program language is used for development as the problem pointed out in the first method.

  The third method is a method of expressing only the execution order in XML by combining robot task programs created in advance. In this method, the nature of a task coded by a method of simply specifying the execution order of a task program created in advance using XML is specified as an execution time, or various methods are used when a developer develops. There is a problem that it is difficult to create a simple form.

  The technical problem to be solved by the invention is to solve the above-mentioned problems, and in developing a service task for a home robot using an inexpensive and low-level processor. By developing a robot service using only the same high-level text-based language as XML, a service content developer who does not know the robot control program at all can develop a robot service without difficulty. Is to provide.

  In order to solve the above technical problem, an XML-based service providing method for a server controlling a mobile home service robot according to the present invention includes a step of receiving a service command, and interpreting the service command to generate at least one service command. The object is generated, the object is initialized, whether the task execution condition is satisfied, and if the execution condition is satisfied, the execution is determined according to the priority of the task, and the robot provides the execution Receiving data after requesting the robot to provide information if the data to be executed is necessary, and executing the task determined to be executed.

  In order to solve the above technical problem, an XML-based service providing apparatus for a server controlling a mobile home service robot according to the present invention interprets a service command and generates at least one object. A generation unit, an object management unit that receives the object and inspects life cycle management and execution conditions, an arbitration unit that determines execution and execution order of tasks that execute the object when the execution conditions are satisfied, and An execution unit that receives a decision of the arbitration unit and executes a task.

  An XML-based service providing method and apparatus for a server for controlling a mobile home service robot according to the present invention provides a robot service by creating a task based on XML for a home robot having a low-cost and low-level processor. A cheap home robot that can be developed without difficulty can implement the same services as a high-level robot.

  The present invention also provides a robot control module that requires real-time performance for a low-cost and low-level robot, for example, a speed or position-based robot control module and a sensor data collection and sensing module are mounted on the robot, By placing only the robot task execution module in the server, the robot can be controlled regardless of network delay.

  In addition, the present invention is inferior in computing power capable of interpreting or executing XML in the case of an inexpensive and low-level home service robot. Therefore, as a means for solving this, the XML-based service is interpreted and the service is configured. A method and apparatus for controlling a real-time robot control module mounted on a robot through a network by remotely placing a server that executes each task to be performed.

  In addition, the present invention provides a service for robots using XML even when a service developer does not have expertise in hardware and robot control in the case of a mobile home robot equipped with an inexpensive and low-level processor. By making it possible to create without difficulty, development productivity can be improved more than when an existing robot control program is created.

  In addition, since the present invention has a low computing capacity in the case of a mobile home robot equipped with an inexpensive processor, there is no ability to interpret or execute XML created by a developer. By providing a robot task execution server and proposing a method in which only a real-time robot control module is placed in the robot, the same level of service as a robot using a high-level processor can be performed.

  Then, a service developer is allowed to develop using a high-level text-based language such as XML, and to support the characteristics of the programming language that can be expressed in XML. After defining the attributes of the elements that make up the service in advance and creating them in XML, they are automatically generated and executed and managed by the object that has the code in the control program installed in the robot, and created in advance in the task XML The execution method of the robot's basic behavior and the like can be specified, and the task that is objectified at the execution time can control this.

  Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. FIG. 1 is a conceptual diagram illustrating that a server for controlling a mobile home service robot according to the present invention is linked to a robot and a task creator. FIG. 2 is a block diagram illustrating a configuration of an XML-based service providing apparatus for a server that controls a mobile home service robot according to the present invention, and FIG. 3 is a block diagram illustrating a detailed configuration of an execution unit illustrated in FIG. FIG. 4 is a block diagram illustrating in more detail that the server controlling the mobile home service robot according to the present invention is linked to the robot and the task creator. FIG. 5 is a flowchart illustrating an XML-based service providing method for a server controlling a mobile home service robot according to the present invention.

  First, the outline and background of the present invention will be described. The present invention relates to the field of robots. In particular, the present invention belongs to the field of control software architecture for an inexpensive mobile home robot equipped with a motorcycle, an LCD monitor, a microphone, a speaker, an obstacle sensor, and a low-level main control processor. Specifically, according to the present invention, a mobile home service robot using an inexpensive and low-level processor creates a service to be performed according to a user command or a specific situation using XML (extensible Markup Language), and executes a remote task. The present invention relates to a method of executing a task using a real-time control module mounted on a server and a robot. Hereinafter, the terms used will be defined as follows. First, the action refers to the basic action of the robot (position movement, TTS, Internet information search, sensing, etc.), and the task refers to the unit mission performed by the robot (approaching the user, reading the newspaper, reading the mail). , Battery charge, etc.), which consists of a set of actions. A service is a service performed by a robot (such as reading a newspaper close to a father), that is, a set of tasks.

  In the present invention, the service created by the developer is composed of tasks, and the task control server is a server that takes charge of execution by separating each task from the service XML.

  FIG. 1 is a diagram for explaining an overall flow of executing an XML-based service of a mobile home service robot according to the present invention. The server for controlling the mobile home service robot according to the present invention includes a robot and a task. Indicates that it is linked with the creator.

  As shown in FIG. 1, each component exists in a different processor and is connected to each other through a network. In particular, in the case of a task execution module and a real-time robot control module that drive a robot program, existing robots are either present in one robot or in the same server. However, in the present invention, the robot task execution module and the real-time robot control module are separated and exist as the concept of a server and a client.

  As shown in FIG. 1, the service developer creates a service through the robot task XML creator 110 existing in the client PC, and transmits it to the remote robot task execution server 120 through TCP. The transmitted service XML is interpreted by the remote robot task control server 120 and waits for execution of each task. If the task execution condition is satisfied, the task is executed by the remote task execution server 120. When motor control and sensor data acquisition are required, the robot physical hierarchy (motor) is transmitted through the real-time robot controller 131 mounted on the robot 130. / Sensor) 133 is used. At this time, the real-time robot controller 131 mounted on the robot 130 performs a function of periodically receiving data from a speed and position-based motor control module (not shown) and the robot physical layer 133. The remote robot task control server 120 basically incorporates basic robot actions such as position movement, route planning, and user recognition, and performs an objective task.

  FIG. 2 shows an embodiment of the configuration of a remote robot task execution server for objectizing and executing a task created in XML by the remote robot task control server 120. As shown in FIG. As shown in FIG. 2, the object generation unit 210 generates atleast one or more objects after receiving a service command from the outside. In particular, the object is generated for each type of task constituting the service command. The object management unit 220 receives the object generated by the object generation unit 210 and inspects life cycle management and execution conditions. The arbitration unit 230 determines whether or not to execute the task for performing the object if the inspection result of the object management unit and the execution condition are satisfied. In more detail, the life cycle including the disappearance and initialization of the object and the execution condition of the task are inspected, and if the execution condition is satisfied, the execution of the task satisfying the execution condition is arbitrated based on the priority order. The tasks to be executed are stored in a task queue 310 described below, and sequential execution is arbitrated. The execution unit 230 receives the decision of the arbitration unit and executes the task.

  A more detailed configuration of the execution unit 240 will be described with reference to FIG. First, the task queue 310 sequentially stores and outputs the tasks. The thread manager 340 determines the task execution method according to the single or multiple thread attribute of the task stored in the task queue 310. The object execution unit 320 executes the task according to the execution method determined by the thread management unit 340. The task execution state management unit feeds back the execution result of the task, and performs a function of requesting the arbitration unit 230 to perform re-execution when it is incomplete.

A more specific embodiment for objectifying and executing a task created in XML by the remote robot task control server 120 will be described with reference to FIGS. 4 and 5. FIG. As shown in FIG. 4, the service (collection of task) XML created by the task XML creator 110 is transmitted to the remote robot task control server 120 via TCP. The task XML interpretation unit 401 interprets the received service XML, and then transmits task information to the object generation unit 402. The object generation unit 402 automatically generates an object according to the type of the task. At this time, objects are generated by classifying into the following types of tasks.
-Time-type task: a task that is executed only once at a predetermined time or is executed with a certain period. For example, wake-up calls and alarms.
-Instruction type task: a task performed by a user instruction. For example, in response to an instruction “Robot! Come over here!”, The robot approaches the user.
-Event type task: A task performed when an event defined by the developer occurs.

  For example, a task that is performed when a window opening event is generated from a window opening detection sensor that is an external sensor is defined as an event type task (step S510).

  In the following, each object generated from the object generation unit 402 is transmitted to the object management units 403, 404, and 405 classified by type and initialized, and waits for execution conditions to be satisfied. The object management unit is divided into a time type object management unit 403, a command type object management unit 404, and an event type object management unit 405, as shown in FIG. (Step S520).

  The object management units 403, 404, and 405 perform functions including life cycle management including object disappearance and initialization, and task execution condition inspection. If the execution conditions for each task are satisfied, the object management units 403, 404, and 405 request the task execution arbitration unit 406 to execute the task (step S540). When performing a plurality of tasks simultaneously or sequentially, the task execution arbitration unit 406 determines what task is to be performed first, or whether the task being executed is stopped or stopped.

  For example, when a gas leak is detected when the home robot is operating in the house, the task execution arbitration unit 406 interrupts the task currently being executed for a while and starts the task corresponding to the gas leak first. It is like doing the previous use after going to.

  Also, as shown in FIG. 4, the task execution arbitration unit 406 stores the tasks to be executed in the task queue 407 and causes the tasks to be performed sequentially. Each object stored in the task queue 407 has information on whether or not it is executed in a thread form. The thread management unit 408 causes the task object of the task queue 407 to be executed by multiple threads or a single thread, and in the case of a single thread, the tasks included in the task queue 407 are sequentially executed.

  For example, assuming that the task of playing music and the task of taking a picture close to the user are in the task queue 407, the task of playing music is a task that can be executed at the same time as any task. In the second case, the different tasks associated with moving by moving the motor must not be moved at the same time, so must always be executed in a single thread. Also, since tasks are related to the movement of the motor, all tasks must be executed sequentially. Such a task is arranged by the task execution arbitration unit 406 (step S540).

  When executing the task, it is determined whether the real-time robot controller 131 needs to be called (step S550). If necessary, the real-time robot controller 131 mounted on the robot is controlled through the robot action execution unit 411. A command is transmitted to acquire necessary information (step S560). The robot action execution unit 411 incorporates basic robot actions such as robot position movement and user recognition in advance. When the execution of the task is completed, the task execution state management unit 409 determines whether the task has been executed normally. If the execution has failed, the task execution arbitration unit 406 is requested to re-execute the task. (Step S570).

The following is an embodiment related to XML DTD (Document Type Definition) that defines the task of the present invention, and an XML tag structure and description of each tag.
<? xml version = "1.0" encoding = "UTF-8"? >
<! ELEMENT services (context-info *, service +)>
<! --Service describes the tasks that make up the service. One service is composed of one or more tasks.
Used in: services
---><! ELEMENT service (service-name, task *)>
<! -Specify the name of the service.
Used in: service
---><! ELEMENT service-name (#PCDATA)>
<! -Specify the attributes of the tasks that make up the service. Each task attribute includes information on name, property, and robot action to be executed. Each task can have one or more actions.
Used in: service
---><! ELEMENT task (name, properties, behaviors *)>
<! -Specify the name of the task.
Used in: task
---><! ELEMENT name (#PCDATA)>
<! --Specify task attributes. The task attribute includes an execution method, a call instruction word, a priority order, an execution form, and a next task to be executed after completion of the execution. Detailed contents of the attribute information are described in each tag description. The task execution method means a method of executing a task, and the execution form means whether the program is driven by a single thread or a multi-thread inside the program. In each element constituting properties, an attribute to be specified varies depending on an event, instruction, and time execution method. “timertype”, “expiration”, “duration”, and “interval” are values that are used only when “expectetype” is a timer task.
Used in: task
---><! ELEMENT properties (ejecttype, command ?, priority ?, type, next-invoke ?, post-condition ?, pre-condition ?, timertype ?, firetime ?, duration ?, interval?)
<! --- Specify the task execution condition method. There are three types of task execution methods: event, command, and time.
Used in: properties
---><! ELEMENT expecttype (#PCDATA)>
<! −−? Specify the execution form to be used in the task execution arbitration module. There are three types of task execution modes: Parallel, Single, and Planned.
1) Parallel Task: Tasks that can be executed simultaneously (tasks that do not require real-time robot control, such as Moveto and Gototo)
Example) Music Play Task, E-mail Send Task, Home Appli- cation Control Task, etc. 2) Single Task: Task that can be driven by only one system eg: Follow Person Task: Path Target Task (Sequential execution in a single thread)
Example) Move To Task, Go To Task, etc. Used in: properties
---><! ELEMENT type (#PCDATA)>
<! --- When a task execution method is designated as command, an instruction word for calling a task is designated. If the event is specified, this command word is transmitted to the command type task manager to be executed.
Used in: properties
---><! ELEMENT command (#PCDATA)>
<! -Task priority specified by the developer. For tasks that do not have priority and are set to Planned Task, the task execution arbitration module dynamically assigns priorities based on the movement distance.
Used in: properties
---><! ELEMENT priority (#PCDATA)>
<! --- Specify the task to be called after execution of the currently executed task is completed.
Used in: properties
---><! ELEMENT next-invoke (#PCDATA)>
<! -Describe the success condition for the task execution result. The successful completion of the task is inspected by the Logical Sensor. The type and value of the logical sensor is specified by the user. When Post-Condition is not satisfied, the next task set by next-invoke is not executed. The logical sensor is a virtual sensor that exists in the robot execution state management module.
Used in: properties
---><! ELEMENT post-condition (logical sensor, value)>
<! --- Specify the type of Logical Sensor.
Used in: post-condition
---><! ELEMENT logical sensor (#PCDATA)>
<! --- Specify the value of Logical Sensor.
Used in: post-condition
---><! ELEMENT value (#PCDATA)>
<! -Describes the conditions for checking whether the task can be executed before the task is executed. The task execution decision is inspected by the logical sensor in the same manner as the post-condition. The type and value of the logical sensor is specified by the user. If pre-condition is not satisfied, the task is not executed.
Used in: properties
---><! ELEMENT pre-condition (logical sensor, value)>
<! -A value that is set when the task execution method is timer, and has one value of OnetimeTimer and PeriodicTimer.
1) OneTimeTimer is executed only once in a predetermined time (Absolute time)
2) PeriodicTimer is a Task (relative time) that continues to be executed at regular time intervals.
Used in: properties
---><! ELEMENT timetype (#PCDATA)>
<! --- A value that is set when the task execution method is Timer, and when Timer Task is OneTimer, it means the time from the registration to the completion of Timer.
Used in: properties
---><! ELEMENT firetime (#PCDATA)>
<! -A value that is set when the task execution method is Timer, and when it is set to PeriodicTimer, it means the time until the Timer is first fired.
Used in: properties
---><! ELEMENT duration (#PCDATA)>
<! -A value that is set when the execution method of the task is Timer, and when it is set to PeriodicTimer, it means a period in which the TimerTask is fired.
Used in: properties
---><! ELEMENT interval (#PCDATA)>
<! -Describes information on actions that constitute a task.
Used in: task
---><! ELEMENT behaviors (behavior *)>
<! -Describe information on the unit actions that make up the task.
Used in: behaviors
---><! ELEMENT behavior (sequence, type, owner ?, defined-class-name ?, normal-content ?, ab- mal_content ?, post-condition ?, goal?)>
<! -Describe the execution order of the unit actions that make up the task.
Used in: behavior
---><! ELEMENT sequence (#PCDATA)>
<! -Specify the name of the action object.
Used in: behavior
---><! ELEMENT defined-class-name (#PCDATA)>

  Also, the server-based XML-based service providing method for controlling the mobile home service robot according to the present invention can be embodied as a computer-readable code on a computer-readable recording medium. Computer-readable recording media include all types of recording devices that store data that can be read by a computer system. Examples of the computer-readable recording medium include a ROM (Read Only Memory), a RAM (Random Access Memory), a CD-ROM, a magnetic tape, a floppy disk, an optical data recording device, and a carrier wave (for example, , Transmission over the Internet). Further, the computer-readable recording medium can be distributed in a computer system connected to a network, and computer-readable code can be stored and executed in a distributed manner.

  As mentioned above, the optimal embodiment was disclosed by drawing and specification. Although specific terms are used herein, they are used merely for purposes of describing the present invention and are intended to limit the scope of the invention as defined in the meaning and claims. It was not used. Accordingly, those skilled in the art will appreciate that various modifications and equivalent other embodiments are possible from this. Therefore, the true technical protection scope of the present invention must be determined by the technical idea of the claims.

  The present invention can be suitably applied to a technical field related to a mobile home service robot.

FIG. 2 is a conceptual diagram illustrating that a server for controlling a mobile home service robot according to the present invention is linked with a robot and a task creator. 1 is a block diagram illustrating a configuration of an XML-based service providing apparatus for a server that controls a mobile home service robot according to the present invention. FIG. It is a block diagram which shows the detailed structure of the execution part of FIG. FIG. 5 is a block diagram illustrating in more detail that a server for controlling a mobile home service robot according to the present invention is linked to a robot and a task creator. 4 is a flowchart illustrating a process of an XML-based service providing method for a server controlling a mobile home service robot according to the present invention.

Explanation of symbols

210 Object Generation Unit 220 Object Management Unit 230 Arbitration Unit 240 Execution Unit 310 Task Queue 320 Object Execution Unit 340 Thread Management Unit

Claims (12)

(A) receiving a service command;
(B) interpreting the service instruction to generate at least one object;
(C) initializing the object, checking whether the task execution condition is satisfied, and determining execution according to task priority if the execution condition is satisfied;
(D) If the data provided by the robot is necessary for the execution, the information is received after requesting the robot to provide information, and the task determined to be executed is executed. An XML-based service providing method for a server that controls a mobile home service robot. The step (a) includes:
The method for providing an XML-based service for a server for controlling a mobile home service robot according to claim 1, wherein the service command created in XML is received via TCP. The step (b)
(B1) The method for providing an XML-based service for a server for controlling a mobile home service robot according to claim 1, wherein an object is generated for each type of task constituting the service command. The step (b1) includes
The object is generated by classifying a task into a task that is executed at a predetermined cycle or time, a task that is executed by a robot user's command, or a task that is executed when a preset event occurs. An XML-based service providing method for a server that controls the mobile home service robot according to claim 3. The step (c) includes:
(C1) Inspecting the life cycle including the disappearance and initialization of the object and the execution condition of the task;
(C2) if the execution condition is satisfied, arbitrating the execution of the task that satisfies the execution condition based on the priority;
The method for providing an XML-based service for a server for controlling a mobile home service robot according to claim 1, further comprising: (c3) storing a task to be executed in a queue and sequentially executing the task. The step (c3)
6. The method for providing an XML-based service for a server for controlling a mobile home service robot according to claim 5, wherein the task is executed by multiple threads or a single thread. The step (d) includes:
The mobile home service robot according to claim 1, further comprising: determining whether the task is normally executed, re-executing if the task is failed, and waiting for execution of another task if the task is successful. XML-based service providing method for servers that control the server. An object generation unit that interprets the service command after receiving the service command and generates at least one object;
An object management unit that receives the object and inspects life cycle management and execution conditions;
An arbitration unit that determines whether or not a task for executing the object is executed and an execution order when the execution condition is satisfied;
An XML-based service providing apparatus for a server that controls a mobile home service robot, comprising: an execution unit that receives a decision of the arbitration unit and executes a task. The execution unit includes a task queue for sequentially storing and outputting the tasks;
A thread management unit that determines a method for executing the task according to a single or multiple thread attribute of the task stored in the task queue;
An object execution unit for executing a task according to the determined execution method;
9. The mobile home service robot according to claim 8, further comprising: a task execution state management unit that feeds back an execution result of the task and requests the arbitration unit to re-execute when the result is incomplete. Server XML-based service providing device. The object generator is
9. The XML-based service providing apparatus for a server for controlling a mobile home service robot according to claim 8, wherein the object is generated for each type of task constituting a service command. The arbitration department
The life cycle including the disappearance and initialization of the object and the execution condition of the task are inspected, and if the execution condition is satisfied, the execution of the task satisfying the execution condition is arbitrated based on the priority order and executed. 9. The XML-based service providing apparatus for a server for controlling a mobile home service robot according to claim 8, wherein the task is stored in a queue and the sequential execution is arbitrated. (A) receiving a service command;
(B) interpreting the service instruction to generate at least one object;
(C) initializing the object, checking whether the task execution condition is satisfied, and determining execution according to task priority if the execution condition is satisfied;
(D) If the data provided by the robot is necessary for the execution, the information is received after requesting the robot to provide information, and the task determined to be executed is executed. A computer-readable recording medium having recorded thereon a program capable of executing an XML-based service providing method of a server for controlling a mobile home service robot.

Images