KR100914249B1 - 네트워크 기반 로봇 제어를 위한 통신 시스템 및 방법 - Google Patents

네트워크 기반 로봇 제어를 위한 통신 시스템 및 방법 Download PDF

Info

Publication number
KR100914249B1
KR100914249B1 KR1020070066561A KR20070066561A KR100914249B1 KR 100914249 B1 KR100914249 B1 KR 100914249B1 KR 1020070066561 A KR1020070066561 A KR 1020070066561A KR 20070066561 A KR20070066561 A KR 20070066561A KR 100914249 B1 KR100914249 B1 KR 100914249B1
Authority
KR
South Korea
Prior art keywords
robot
packet
server
facility
control
Prior art date
Application number
KR1020070066561A
Other languages
English (en)
Other versions
KR20080050959A (ko
Inventor
장철수
서범수
정승욱
권우영
김중배
Original Assignee
한국전자통신연구원
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 한국전자통신연구원 filed Critical 한국전자통신연구원
Publication of KR20080050959A publication Critical patent/KR20080050959A/ko
Application granted granted Critical
Publication of KR100914249B1 publication Critical patent/KR100914249B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities

Landscapes

  • Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Manipulator (AREA)

Abstract

본 발명은 네트워크 기반 로봇 제어를 위한 통신 시스템 및 방법에 관한 것으로서, 로봇에 있어서는 로봇에 구성되며 제어 서버로 패킷을 송신하고 제어 서버로부터의 패킷을 수신하는 로봇 프로토콜 프록시와, 서버 프로토콜 프록시가 로봇의 로봇 내부 프로그램을 호출할 수 있도록 구성되고 로봇에 구성된 로봇API로 구성되는 것을 특징으로 하며, 로봇을 제어하는 제어 서버에는 제어 서버에 구성되며, 로봇으로 패킷을 송신하고 로봇으로부터의 패킷을 수신하는 서버 프로토콜 프록시와, 로봇 프로토콜 프록시가 제어 서버의 로봇 제어 프로그램을 호출할 수 있도록 하며, 제어 서버에 구성된 서버API로 구성되는 것을 특징으로 하므로, 로봇 제어의 순차성을 보장하면서도 다른 패킷과 병행하여 수행할 수 있는 패킷에 대해서는 동시에 처리할 수 있도록 병행성을 제공하여 로봇 제어에 있어서 안정적인 제어가 가능한 효과가 있다.
로봇, 네트워크, 로봇제어서버, 통신프로토콜, 순차성, 병행성

Description

네트워크 기반 로봇 제어를 위한 통신 시스템 및 방법{Communication System and method for network based robot control}
본 발명은 네트워크 기반 로봇 제어를 위한 통신 시스템 및 방법에 관한 것으로서, 더욱 상세하게는 로봇서버와 통신하는 로봇 간에 전송되는 데이터를 처리하는 특성에 따라 구분하여 처리하여 로봇 또는 로봇 서버에서 요청 또는 명령(command)의 지연이 발생하지 않도록 구성한 네트워크 기반 로봇 제어를 위한 통신 시스템 및 방법에 관한 것이다.
도 1은 일반적인 네트워크 기반 로봇의 구성을 나타낸 시스템 구성도이며, 도 2 내지 도 5는 일반적인 네트워크 기반 로봇에서 요청, 명령, 또는 이벤트 등을 처리하는 과정을 나타낸 도면이다.
도 1 내지 도 5를 참조하여 보면, 일반적으로, 네트워크 기반 가정용 정보 서비스 로봇(100)은 도 1과 같이 네트워크(250)를 통해 로봇 제어 서버(200)와 연결되어서, 로봇(100)의 제어부분, 즉 지능을 제어 서버(200)와 분할하여 갖고 있 다. 즉, 로봇(100)의 컴퓨팅 능력이 부족하여 로봇(100) 스스로 처리할 수 없는 경우에는 원시 데이터(Raw Data)를 제어 서버(200)에게 보내어 컴퓨팅 능력이 우수한 제어 서버(200)가 해당 기능을 대신 처리하도록 한다. 그리고, 로봇(100) 자신이 갖고 있지 않은 데이터에 대해서는 제어 서버(200)가 갖고 있는 큰 데이터베이스로부터 필요한 데이터를 가져와서 사용자에게 제공한다.
한편, 네트워크(250)기반 로봇(100)은 제어 서버(200) 및 원격 사용자의 제어 명령을 통해 원격 홈 모니터링 서비스와 같이 원격에서 이동 및 동작을 제어받는 로봇(100)이다. 이를 위해서, 네트워크(250) 기반 로봇(100)은 로봇(100)의 컴퓨팅 능력이 부족하여 제어 서버(200)의 힘을 빌려야 하는 경우에는 도 2와 같이 로봇(100)에서 제어 서버(200)로 요청 패킷(101)을 만들어 보내어 서버가 요청 패킷을 처리한 후 응답 패킷(102)을 만들어 보낸다. 반대로 제어 서버(200)에서 원격으로 로봇(100)을 제어하고자 하는 경우에는 도 3과 같이 제어 서버(200)에서 로봇(100)으로 요청 패킷(103)을 보내어 로봇(100)이 요청을 처리하고 응답(104)을 보낸다.
도 4에서와 같이 제어 서버(200)에서 로봇(100)으로 일방적으로 명령(105)을 보내고 제어 서버(200)는 로봇(100)으로부터 응답을 기다리지 않고 계속 다음 작업을 수행할 수도 있다.
또한, 도 5에서와 같이 로봇의 센서 정보를 통해 특정 이벤트가 발생된 경우에는 로봇(100)에서 제어 서버(200)로 일방적으로 해당 이벤트(106)를 보내어 제어 서버(200)가 적절히 대응할 수 있도록 해줘야 한다.
도 1 내지 도 5를 참조하여 설명한 기존의 분산 클라이언트/서버 방식의 통신 미들웨어는 CORBA(Common Object Request Broker Architecture)나 RMI(Remote Method Invocation), RPC(Remote Procedure Call)와 같은 보통 request/response 방식을 따른다. 보충하여 설명하면, 분산 클라이언트/서버 방식의 통신미들웨어에서 본 발명에 준하여 본다면, 클라이언트는 로봇(100)과 대응되며, 서버는 제어 서버(200)와 대응된다.
이와 같은 방식은 클라이언트가 뭔가 요청을 하고 그에 대한 응답을 받는 방식이다. 따라서, 요청을 보낸 클라이언트는 그에 대한 응답을 받을 준비를 하고 있다. 마찬가지로 클라이언트의 요청을 처리하고 응답을 보낸 서버는 새로운 요청을 기다릴 준비를 한다.
만약, 하나의 소켓 연결(socket connection) 및 쓰레드(Thread)로 양방향의 요청/응답(request/response) 방식을 모두 지원하는 경우, 로봇(100)과 서버(200)가 서로 동시에 상대방에게 요청을 보내게 된다면, 요청을 보낸 양쪽은 모두 그에 대한 응답이 올 것으로 예상하여 프로그램될 것이므로, 상대방이 보낸 요청을 응답으로 여기고 처리하려 할 것이다. 하지만, 전달된 요청에 대해 상호 잘못된 응답으로 판단할 것이고, 계속 제대로 된 응답을 기다리거나 아니면, 요청이 실패한 것으로 판단할 것이다.
게다가, 양쪽에서 이벤트(event)나 명령(command)을 푸쉬(push)하는 경우도 있으므로 하나의 연결로 이런 모든 경우를 처리하는 것은 로봇(100)의 동작에 있어서 복합동작을 수행 중에 문제가 발생할 수 있으므로 순차적인 동작을 수행해야 하는 동작 특성상 그리 쉬운 것은 아니다. 그렇다고, 로봇(100)의 방향별로 모두 연결을 만들어 여러 개의 연결을 유지한 상태로 복합적으로 관리하는 것은 연결 관리 측면에서 어려우며, 또한 서로 다른 연결을 통해 들어온 요청에 대해 로봇 바퀴와 같이 공통으로 사용되는 자원에 대해 동시에 명령을 내릴 수도 있어서 로봇(100)을 비정상적으로 동작시킬 수 있는 문제점이 있다. 여기서, 자원이란 로봇의 구동을 위한 구동부들을 의미한다.
이와 같이, 네트워크(250) 기반 로봇(100)을 제어하기 위해서 동작 제어 패킷, 서비스 제어 패킷, 영상 패킷, 로봇 상태 패킷, 서비스 컨텐츠 패킷 등 다양한 종류의 통신 패킷이 혼재하는 상황에서, 기계적 움직임을 수반하는 동작 패킷과 같이 응답속도가 오래 걸리는 패킷의 경우 그 수행 결과를 돌려받을 때까지 제어 서버측의 프로그램은 로봇에게 동시에 수행할 수 있는 다른 패킷을 전달할 수 없어서 로봇 제어가 자연스럽지 않게 보일 수 있으며, 반대로 로봇의 수행 결과를 돌려받지 않고 계속 로봇에게 제어 패킷을 전달하는 경우 제어 패킷의 정상적인 처리 결과를 알기 힘들고 이전 동작이 완료되지 않은 상황에서 새로운 동작 패킷을 내려보내게 되는 경우 로봇 동작의 순차성을 해치게 되므로, 로봇이 자연스럽지 않게 동작하는 문제점이 있다. 즉, 로봇(100)에게 보내는 명령이나 제어 서버(200)에게 보내는 요청들은, 로봇 전진 동작과 로봇 후진 동작과 같이 바퀴와 같은 동일한 자원을 사용하는 경우에는 순차적으로 실행되어야 하며, 자동 음성 인식(ASR: Automatic Speech Recognition)이나 음성 합성 (TTS : Text-To-Speech)과 같이 순차적으로 실행될 필요가 없는 경우에는 다른 명령과 함께 병행적으로 빨리 수행시킬 필요성이 있다.
본 발명은 전술한 종래기술의 문제점을 해결하고 전술한 필요성을 충족시키기 위하여 제안된 것으로서 그 목적은, 로봇 제어의 순차성을 보장하면서도 다른 패킷과 병행하여 수행할 수 있는 패킷에 대해서는 병행성을 제공하여 로봇이 안정적이면서 자연스럽게 동작하도록 구성한 네트워크 기반 로봇 제어를 위한 통신 시스템 및 방법을 제공하는 데에 있는 것이다.
또한, 본 발명의 다른 목적은 로봇 제어의 순차성을 보장하면서도 다른 패킷과 병행하여 수행할 수 있도록 패킷을 구분하고 이에 따라서 패킷을 처리할 수 있도록 하여 처리속도를 향상시킨 네트워크 기반 로봇 제어를 위한 통신 시스템 및 방법을 제공하는 데에 있는 것이다.
상기와 같은 목적을 달성하기 위한 네트워크 기반 로봇 제어를 위한 통신 시스템은, 로봇에 구성되며 제어 서버로 패킷을 송신하고 상기 제어 서버로부터의 패킷을 수신하는 로봇 프로토콜 프록시와, 서버 프로토콜 프록시가 상기 로봇의 로봇 내부 프로그램을 호출할 수 있도록 구성되고 상기 로봇에 구성된 로봇API를 포함하여 이루어진 것을 특징으로 한다.
한편, 본 발명의 네트워크 기반 로봇 제어를 위한 통신 시스템은, 로봇을 제어하는 제어 서버에는 제어 서버에 구성되며, 로봇으로 패킷을 송신하고 로봇으로 부터의 패킷을 수신하는 서버 프로토콜 프록시와, 로봇 프로토콜 프록시가 제어 서버의 로봇 제어 프로그램을 호출할 수 있도록 하며, 제어 서버에 구성된 서버API를 포함하여 이루어진 것을 특징으로 한다.
한편, 본 발명의 네트워크 기반 로봇 제어 방법은, 상기 로봇의 동일한 자원을 사용하는 함수들끼리 분류하여 묶고 이를 응용프로그램 쓰레드로 구성하는 제1 단계와, 제1 단계에서 분류된 종류별로 명령을 처리하기 위한 응용프로그램 쓰레드를 구동시키는 제2 단계와, 패킷 송신과 수신을 전담하는 퍼실리티 쓰레드를 구동시키는 제3 단계와, 퍼실리티 쓰레드를 이용하여 응용프로그램 쓰레드별로 제어 패킷을 상대편으로 송신하는 제4 단계와, 제4 단계에서 송신된 제어 패킷을 수신하여 상기 제어 패킷의 메시지 타입이 요청인지의 여부를 판단하는 제5 단계와, 제5 단계에서 판단하여 제어 패킷의 메시지 타입이 요청인 경우면 그에 대한 응답을 수신하고 제어 패킷을 분류된 종류대로 구동시키는 응용프로그램 쓰레드(302)로 전송하는 제6 단계와, 제어 패킷을 전달받은 상기 응용프로그램 쓰레드가 로봇의 자원을 사용하여 제어 패킷의 메시지 타입에 따른 요청, 응답, 명령 또는 이벤트를 처리하는 제7 단계를 포함하여 이루어진 것을 특징으로 한다.
따라서, 본 발명은 로봇 제어의 순차성을 보장하면서도 다른 패킷과 병행하여 수행할 수 있는 패킷에 대해서는 동시에 처리할 수 있도록 병행성을 제공하여 로봇을 안정으로 제어하는 효과가 있다.
또한, 본 발명은 로봇 제어에 있어서 순차적으로 처리하면서 동시에 함께 처리할 제어부분에 대해서는 동시에 처리할 수 있도록 하여 자연스러운면서 빠르게 동작하는 로봇을 제작할 수 있는 효과가 있다.
이하, 본 발명의 네트워크 기반 로봇 제어를 위한 통신 시스템 및 방법에 대하여 첨부된 도면을 참조하여 상세히 설명하기로 한다.
도 6은 본 발명의 일실시예에 따른 네트워크 기반 로봇 제어를 위한 개략적인 시스템 구성을 나타낸 블록 구성도이다.
도 6을 참조하여 보면, 본원 발명은 크게 로봇(300)과 제어 서버(400)로 구성되며, 로봇(300)은 로봇 내부 프로그램(301), 로봇프로토콜프록시(robot protocol proxy)(500) 및 이 둘 간에 인터페이스를 제공하는 로봇API(robot Application Programming Interface)(501)로 구성되고, 제어 서버(400)는 로봇 제어프로그램(401), 서버프로토콜프록시(server protocol proxy)(600) 및 이 둘 간에 인터페이스를 제공하는 서버API(601)로 구성된다.
먼저, 로봇(300)에서 제어 서버(400)로 요청을 전달하는 개략적인 과정에 대하여 살펴보면 다음과 같다. 로봇(300)과 제어 서버(400) 양쪽에 패킷의 송수신을 담당하는 각각에 로봇 프로토콜 프록시(500)와 서버 프로토콜 프록시(600)를 구성한다. 각각의 로봇 프로토콜 프록시(500)와 서버 프로토콜 프록시(600)의 통신에 의해 로봇 프로토콜 프록시(500)는 제어 서버(400)의 제어 프로그램(401)을 로 컬(local)에 있는 서버API(601)를 통해 호출할 수 있으며, 또한, 서버 프로토콜 프록시(600)는 로컬에 있는 로봇API(501)를 통해 로봇(300) 내부의 로봇 내부 프로그램(301)을 호출할 수 있다.
각각의 프로토콜 프록시의 API(501,601)를 통해 각각의 프로그램(301, 401) 호출하기 위해 각각의 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)는 원격지에 있는 상대편 프록시(600, 500)에게 요청 패킷을 만들어서 해당 요청을 전달한다.
로봇(300)과 제어 서버(400) 양쪽에 패킷의 송수신을 담당하는 각각의 프로토콜 프록시(500, 600)를 포함하고 있다.
먼저, 로봇(300)에서 제어 서버(400)로 요청을 송신하는 과정을 살펴보면 다음과 같다. 로봇(300) 내부의 로봇 내부 프로그램(301)이 자신의 로컬(local)에 있는 로봇API(501)를 호출하고 이를 통해 로봇 프로토콜 프록시(500)에 연결하고 로봇 프로토콜 프록시(500)는 요청 패킷을 만들어서 원격지에 있는 상대방인 서버 프로토콜 프록시(600)에게 요청을 전송한다.
반대로, 제어 서버(400)에서 로봇(300)으로 요청을 송신하는 과정을 살펴보면 다음과 같다. 제어 서버(400)의 제어 프로그램(401)은 자신의 로컬에 있는 프로그램의 해당 서버API(601)를 호출하고 이를 통해 서버 프로토콜 프록시(600)에 연결하고 서버 프로토콜 프록시(600)는 요청 패킷을 만들어서 원격지에 있는 상대방인 로봇 프로토콜 프록시(500)에게 요청을 전송한다.
전술한 과정을 통해 요청을 전달받은 각각의 서버 프로토콜 프록시(600) 및 로봇 프로토콜 프록시(500)는 각각 제어 서버(400)나 로봇(300)의 자원에 접근하여 요청된 명령을 수행하고, 그 수행된 결과를 포함하는 응답 패킷을 만들어 요청을 보낸 프로토콜 프록시(500, 600)에게 전송한다. 응답을 받은 해당 프로토콜 프록시(500, 600)는 처음 API(501,601)를 호출한 프로그램에게 API 호출 결과를 만들어서 리턴(return)시킨다.
여기서, 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)는 각각의 로봇(300) 내의 로봇 내부 프로그램(301)과 제어 서버(400)의 로봇 제어 프로그램(401)이 여러 개의 쓰레드(thread)로 구성되어 있어서, 여러 개의 쓰레드로부터 여러 API를 동시에 호출할 수도 있다. 이때 요청을 보낸 쪽의 프로토콜 프록시(500, 600)는 이전에 보낸 요청에 대한 응답이 오지 않은 상태에서도 새로운 요청을 상대방의 프로토콜 프록시에 보내어 명령을 수행하도록 하여야 로봇의 여러 장치를 동시에 제어할 수 있으며, 또한 응답을 필요로 하지 않는 이벤트나 단방향 명령에 경우에는 다른 API의 실행중 여부와 상관없이 프로토콜 프록시의 API를 호출하여 이벤트 패킷이나 명령 패킷을 보낼 수 있어야 한다.
도 7은 본 발명의 일실시예에 따른 네트워크 기반 로봇 제어를 위한 통신 시스템의 일실시예를 나타낸 블록 구성도이다.
도 7을 참조하여 보면, 로봇의 자원에 대해 서로 충돌되지 않도록 자원에 따라 메시지 종류를 구분하고 해당 프로토콜 메시지 종류를 처리할 전담 쓰레드를 각각의 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)에 각각 대응하도록 구성하고 수신된 프로토콜 메시지를 각 전담 쓰레드에게 디스패치(dispatch)하여 해당 쓰레드가 처리하도록 구성한다. 예컨대, 청소 메시지와 로봇 전진 메시지는 각각 다른 메시지 종류로 구별된다. 이는 이동하는 것은 모터와 바퀴에 관련된 자원이지만, 청소하는 것은 펌프에서 구동하는 것으로 각각 그 자원이 다르다, 따라서 청소 메시지와 로봇 전진 메시지는 각각 다른 메시지로 구별되며 각각 동시에 처리할 수 있다. 하지만, 전진 메시지와 후진 메시지는 같은 모터와 바퀴 자원을 활용하므로 같은 메시지 종류로 구분되며 동시에 처리할 수 없다.
이를 위해 메시지 종류별로 프로토콜 메시지를 처리할 퍼실리티(facility) (511, 512, 513, 514, 515, 516, 611, 612, 613, 614, 615, 616)라는 클래스를 각각 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)에 구성하고, 각각의 퍼실리티(511, 512, 513, 514, 515, 516, 611, 612, 613, 614, 615, 616)는 응용프로그램에게 API를 제공하여 상대방의 프로토콜 프록시에게 해당 명령을 전송하도록 한다.
여기서, 퍼실리티(511, 512, 513, 514, 515, 516, 517, 518, 611, 612, 613, 614, 615, 616, 617, 618)는 자신이 수행할 메시지가 온 경우 로봇이나 제어 서버에 접근하여 요청된 명령을 수행하는데, 각 퍼실리티는 자신만의 독립적인 쓰레드를 갖고 있어서 다른 퍼실리티(511, 512, 513, 514, 515, 516, 517, 518, 611, 612, 613, 614, 615, 616, 617, 618)와 병행하여 동작하기 때문에 서로 충돌되지 않는 자원에 대해서 동시에 제어가 가능하도록 구성한다. 즉, 하나의 퍼실리티에서는 순차적인 처리를 하지만, 퍼실리티와 퍼실리티 간에는 동시에 일을 처리할 수 있다. 예컨대, 청소 퍼실리티(515, 615) 및 이동 퍼실리티(513, 613)에 입력되는 요청, 응답, 명령 및 이벤트를 각각 동시에 처리할 수 있다. 그러나, 청소 퍼실리티(515, 616)에 입출력되는 요청, 응답, 명령 및 이벤트는 순차적으로 처리된다.
본 발명의 일실시예에서는 로봇과 제어 서버 간의 인증을 위한 명령을 처리하기 위해 각각 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)에 구성한 인증 퍼실리티(Authentication facility)(511, 611), 로봇이 실행하는 서비스를 전환하기 위한 명령을 처리하기 위해 각각 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)에 구성한 서비스 퍼실리티(Service facility)(512, 612), 로봇(300)의 이동에 관련된 명령을 처리하기 위하여 각각 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)에 구성한 이동 퍼실리티(Move facility)(513, 613), 카메라를 이용하여 사진을 찍고 앨범을 관리하는 명령을 수행하기 위하여 각각 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)에 구성한 카메라 퍼실리티(Camera facility)(514, 614), 로봇이 가정 내를 청소하는 진공청소 흡입기를 제어하기 위하여 각각 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)에 구성한 청소 퍼실리티(Cleaning facility)(515, 615), 로봇(300)과 제어 서버(400)가 이상 상황에 의해서 멈추거나 네트워크 연결이 끊겼는지를 서로 주기적으로 점검하기 위하여 각각 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)에 구성한 메시지 퍼실리티(Message facility)(516, 616), 로봇이 엔코더 또는 기타 유선 또는 무선의 인식수단을 이용하여 집안의 지도(map)를 만들도록 하기 위하여 각각 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)에 구성한 지도 퍼 실리티(Map facility)(517, 617), 로봇의 센서 상태들을 계속 추출하기 위하여 각각 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)에 구성한 상태 퍼실리티(Status facility)(518, 618) 등의 퍼실리티(511, 512, 513, 514, 515, 516, 517, 518, 611, 612, 613, 614, 615, 616, 617, 618)로 구성된다. 기타 기능적인 추가에 의해 추가적인 퍼실리티가 추가될 수 있음을 당업자라면 쉽게 이해할 수 있을 것이다.
전술한 각각의 퍼실리티(511, 512, 513, 514, 515, 516, 517, 518, 611, 612, 613, 614, 615, 616, 617, 618) 들은 각각 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)를 통해 API를 요청한 쪽, 즉 호출한 쪽은 소스(source)가 되며 프로토콜 프록시(500, 600)를 통해 요청을 전달 받은 측은 싱크(sink)가 된다. 소스 및 싱크는 각각의 로봇 프로토콜 프록시(500) 및 서버 프로토콜 프록시(600)에 구성된 메시지 송수신기(520, 620)를 통해 각각의 요청 및 요청에 대한 응답을 각각 송신하고 수신한다. 한편, 앞서 기술한 바와 같이 로봇(300)이나 제어 서버(400)는 소스 역할을 하기도 하며 싱크 역할을 할 수도 있다.
도 8은 본 발명의 일실시예에 따른 네트워크 기반 로봇 제어를 위한 로봇 프로토콜 프록시 내부 구성의 일실시예를 도시한 블록 구성도이다.
도 8을 참조하여 보면, 프로토콜 프록시에서 요청/응답(request/response) 방식과 역방향의 요청/응답 및 이벤트(event) 방식 혹은 명령(command) 방식을 모두 지원하기 위해서 메시지를 송수신하는 쓰레드와 메시지를 처리하는 쓰레드를 분리한다.
로봇(300)의 로봇 프로토콜 프록시(500)의 메시지 송수신기(520) 내부의 메시지 수신기(522)는 퍼실리티와 별도의 쓰레드로 동작하면서 소켓(320)을 통해 제어 서버(400)의 서버 프로토콜 프록시(600)로부터 들어오는 패킷을 수신하여 메시지 라우터(523)를 통해서 해당 퍼실리티의 수신버퍼에 전송받은 패킷을 전달해주고 해당 퍼실리티(511, 512, 513, 514, 515, 516, 517, 518)에게 패킷 전송 사실을 통보하여 준다. 이때 퍼실리티(511, 512, 513, 514, 515, 516, 517, 518)에게 통보해주는 방식은 퍼실리티 별로 뮤택스(mutex)(525)와 조건 변수(conditional variable)(532)를 사용하여 메시지 라우터(523)가 해당 뮤택스(525)와 조건 변수를 이용하여 대응시켜 그 뮤택스(525) 조건에 맞으면 메시지 송신기(521) 및 소켓(320)을 통해 제어 서버(400)의 프로토콜 프록시(600)로 통보해주는 방식이다.
패킷 전송 사실을 통보받은 프로토콜 프록시(600) 내의 대응하는 퍼실리티(611, 612, 613, 614, 615, 616, 617, 618)는 자신의 수신 버퍼로부터 전달받은 패킷에서 메시지에 해당하는 기능을 수행하고 응답을 보내야 할 경우 응답 메시지를 만들어서 전송한다. 요청을 처리한 퍼실리티(611, 612, 613, 614, 615, 616, 617, 618)는 전달 받은 패킷이 더 있는지 수신 버퍼를 조사하여 패킷이 더 있는 경우 순차적으로 추출하여 해당 명령을 실행한다. 더 이상 처리할 패킷이 없는 경우에는 다음 패킷이 수신되어서 조건 변수에 의해 통보될 때까지 휴면(sleep) 상태가 된다. 여기서 퍼실리티(611, 612, 613, 614, 615, 616, 617, 618)는 수신 버퍼에 있는 패킷을 순차적으로 추출하여 처리를 완료한 후 그 다음 패킷을 추출하여 처리하므로, 하나의 퍼실리티(611, 612, 613, 614, 615, 616, 617, 618) 내에서는 자원의 충돌 없이 순차적으로 명령을 수행할 수 있다.
도 9는 본 발명의 일실시예에 따라 특정 퍼실리티에서 API를 호출한 쓰레드에게 응답 메시지를 전달하는 과정을 도시한 블록 구성도이다.
도 9를 참조하여 보면, 프로토콜 프록시를 통해 API(501)를 호출한 응용프로그램 쓰레드(302)는 자신의 쓰레드 정보를 해당 퍼실리티(511)의 대기 리스트(534)에 넣어 놓고 응답이 올 때까지 응용프로그램에서 지정한 일정 시간 동안 대기하고 있으며, 퍼실리티 쓰레드(533)가 응답 메시지를 받은 경우 퍼실리티의 대기 리스트(534)에서 응용프로그램 쓰레드(302)를 검색하여 조건 변수를 통해 API에 대한 응답이 왔음을 API(501)를 호출한 해당 응용프로그램 쓰레드(302)에게 통보하여 응용프로그램이 계속 동작하도록 한다.
응용프로그램 쓰레드(302)가 퍼실리티(511)의 적절한 API(501)를 통해 요청 메시지를 보내야 하거나, 요청받은 명령을 모두 수행하여 퍼실리티 쓰레드(533)가 요청에 대한 응답 메시지를 보내야 하거나, 혹은 단방향의 이벤트나 명령과 같이 메시지를 상대방에게 보내야 할 경우에는 별도의 쓰레드로 구동하고 있는 메시지 송신기(521)의 출력 버퍼(524)를 통해 메시지를 전송한다. 이때, 출력 버퍼(524)를 뮤택스(525)를 이용하여 임계 영역(critical section)으로 설정하고 여러 개의 퍼실리티(511)에서 동시에 출력하려는 상황을 방지한다.
도 10은 본 발명의 일실시예에 따른 통신 시스템에서의 패킷구조를 나타낸 패킷 구성도이다.
도 10을 참조하여 보면, 프로토콜 프록시 사이에 주고 받는 패킷 구조가 도 시되어 있다. 디스크리미네이터 필드(discriminator field)는 2byte가 할당되며 패킷의 시작을 표시한다. 버전 필드는 1 bite가 할당되며 패킷의 버전을 표시한다. 세션ID는 랜덤하게 부여되는 통신을 구성하는 세션의 ID 필드를 나타내며 4byte가 할당된다. 퍼실리티 ID 필드(Facility ID field)는 메시지 종류별로 구분한 퍼실리티의 고유번호이다. 펑션 ID 필드(Function ID field)는 해당 퍼실리터에서 고유한 함수에 대한 고유번호이다. 일례로, 01번이라는 고유번호를 가진 이동 퍼실리티(513)에는 01번의 고유번호를 가진 순방향 함수(Forward Function)와 02번의 고유번호를 가진 역방향 함수(Backward Function)와 같이 퍼실리티 및 해당 함수에 대한 고유번호를 할당하고 있다. 퍼실리티 쓰레드(533)는 패킷을 생성할 때마다 계속 증가하는 일련 번호를 시퀀스 ID 필드(Sequence ID field)에 할당하여 메시지의 유일성을 보장하도록 한다. 다만, 퍼실리티 쓰레드(533)가 요청에 대한 응답 보낼 때에는 요청받은 메시지의 시퀀스 ID 값을 그대로 사용하여 응답 메시지를 만든다. 이렇게 하는 이유는 앞에서 설명한 바와 같이 퍼실리티의 API(501)를 호출한 응용프로그램 쓰레드(302)는 요청한 시퀀스 ID를 키(Key)로 하여 대기 리스트(534)에서 응답이 오기를 기다리기 때문에, 응답 메시지를 받은 퍼실리티 쓰레드(533)가 어떤 응용프로그램 쓰레드(302)에게 전달해야 할지를 응답 메시지의 시퀀스 ID 필드를 보고 판단하기 위해서이다. 메시지 타입 필드에는 다음의 종류에 해당하는 값 중 어느 하나가 올 수 있다.
1. 요청 : 상대편, 즉 로봇 또는 제어 서버로 자원에 대한 사용을 요청하는 신호이다. 요청 메시지를 보낸 경우 일정시간 이내에 반드시 응답 메시지를 받는 다. 일정시간 이후에는 시간경과(Timeout)로 간주하여 요청이 실패한 것으로 보며, 그 시간 이후에 온 응답 메시지를 폐기처분한다.
2. 응답 : 요청에 대한 응답이다.
3. 명령 : 상대편에게 명령을 보내기만 하고 상대편에서의 그 명령에 대한 성공 여부는 신경쓰지 않는다. 명령에 대한 성공 여부는 request/response를 이용하여 상태를 질의(query)하여 알아낸다.
4. 이벤트 : 자신의 상태 변화를 상대편에게 통보한다. 명령과 마찬가지로 단방향이며 상대편이 이벤트에 대해서 어떻게 대응할지는 상대편이 알아서 판단하고 이벤트를 보낸 쪽은 신경 쓰지 않는다.
메시지 길이(Message Length) 필드는 4byte를 할당하고 메시지의 길이를 나타낸다. 메시지 필드(Message Field)는 함수에 특화된 파라미터를 추가하여 같이 보내도록 한다. 메시지 필드는 가변적이므로 메시지 필드는 그 길이를 한정하지 않는다.
상기의 패킷을 전달받은 프로토콜 프록시는 퍼실리티 ID를 보고 목적지 퍼실리티(511, 512, 513, 514, 515, 516, 517, 518, 611, 612, 613, 614, 615, 616, 617, 618)의 수신 버퍼(531)에 패킷을 넣어주고 해당 퍼실리티(511, 512, 513, 514, 515, 516, 517, 518, 611, 612, 613, 614, 615, 616, 617, 618)에게 패킷 도착 사실을 통보한다. 패킷 도착 사실을 통보받은 퍼실리티(511, 512, 513, 514, 515, 516, 517, 518, 611, 612, 613, 614, 615, 616, 617, 618)는 자신의 수신 버퍼(531)에서 패킷을 꺼내어 메시지 파라미터 블록에 있는 데이터를 이용하여 함수 ID에 해당 하는 함수를 호출하여 로봇을 동작시킨다.
도 11은 본 발명의 일실시예에 따른 네트워크 기반에서 로봇 제어를 위한 통신 방법을 도시한 순서도이다.
도 11을 참조하여 보면, 제어 서버(400)를 이용하여 네트워크 기반 가정용 정보 서비스 로봇을 제어하는데 있어서, 로봇의 동일한 자원을 사용하는 함수들끼리 분류하여 묶고 이를 응용프로그램 쓰레드(302)로 구성한다(S701).
S701에서 분류된 종류별로 명령을 처리하기 위한 응용프로그램 쓰레드(302)를 구동시킨다(S702).
S702에서 구동된 응용프로그램 쓰레드(302)와 별도로 패킷 송신과 수신을 전담하는 퍼실리티 쓰레드(533)를 구동시킨다(S703).
S703에서의 퍼실리티 쓰레드(533)를 이용하여 S701에서 구성된 응용프로그램 쓰레드(302)별로 제어 패킷을 상대편, 즉, 로봇(300) 또는 제어 서버(400)로 송신한다(S704). 제어 패킷의 메시지 타입은 전술한 바와 같이 요청, 응답, 명령 또는 이벤트 중 어느 하나일 수 있다.
S704에서 전송된 제어 패킷의 메시지 타입이 요청인지 또는 그 이외의 응답 명령 및 이벤트인지의 여부를 판단한다(S705).
S705에서 판단하여 제어 패킷의 메시지 타입이 요청인 경우면 그에 대한 응답에 대응하는 제어 패킷을 송신하고 제어 패킷을 S701에서 분류된 종류대로 구동되는 S702의 응용프로그램 쓰레드(302)로 전송한다(S706).
S705에서 판단하여 제어 패킷의 메시지 타입이 요청이 아닌 경우, 즉 응답, 명령 또는 이벤트 중 어느 한 경우이면, 싱크, 즉 상대편의 로봇(300) 또는 제어 서버(400)의 응용프로그램 쓰레드에서 처리한다(S707). 즉, S707에서는 제어 패킷을 전달받은 S701의 응용프로그램 쓰레드(302)에 의해서 로봇의 자원을 사용하여 제어 패킷의 메시지 타입에 따른 응답, 명령 또는 이벤트를 처리한다.
S707에 대해서는 도 12에서 보다 상세하게 설명하고자 한다. 그리고, 도 12에서는 요청, 응답, 명령 또는 이벤트의 처리과정에 대해서도 보다 상세하게 설명하고자 한다.
도 12는 본 발명의 일실시예에 따른 통신 시스템에서의 쓰레드가 제어 패킷을 처리하는 과정을 도시한 순서도이다.
도 12를 참조하여 보면, 보다 이해를 돕기 위해 소스는 로봇(300)으로 가정하고 싱크는 제어 서버(400)로 가정하여 설명하기로 하고 제어 패킷의 메시지 형태는 요청에 대한 응답을 처리하는 것으로 가정하여 설명하며, 제어 패킷, 즉 응답이 싱크인 로봇(300)으로 전송되어 로봇(300)에서 처리하는 것으로 가정하여 설명한다. 그러나, 앞서 설명한 바와 같이 소스는 로봇(300)이 될 수도 있고, 제어 서버(400)가 될 수도 있으며, 마찬가지로 로봇(300) 또는 제어 서버(400)가 모두 싱크가 될 수도 있다. 또한, 제어 패킷의 메시지 형태도 요청, 응답, 명령 및 이벤트 모두 가능하다.
먼저, 로봇 내부프로그램(301)의 응용프로그램 쓰레드(302)가 요청에 대한 응답을 생성하기 위해 API(501)를 호출한다(S801).
응용프로그램 쓰레드(302)는 호출한 해당 API(501)를 통하여 자신의 쓰레드 정보를 해당 퍼실리티(511)의 대기 리스트(534)에 기록한다(S802).
로봇(300)의 퍼실리티(511)는 응용프로그램 쓰레드(302)에 의해 요청을 처리하고 이에 대한 응답을 형성하기까지 응용프로그램 쓰레드(302)에서 지정한 일정 시간 동안 대기한다(S803).
퍼실리티(511) 내의 퍼실리티 쓰레드(533)가 제어 서버(400)의 서버 프로토콜 프록시(600)로부터 대응하는 퍼실리티(611)가 요청을 처리하였고 그에 대응하는 응답을 생성하여 퍼실리티 쓰레드(533)로 전송하였는지의 여부를 판단한다(S804).
S804에서 판단하여 퍼실리티 쓰레드(533)가 응답을 수신하지 못한 것으로 판단되면, S803로 리턴하고, S804에서 판단하여 퍼실리티 쓰레드(533)가 응답 메시지를 수신한 것으로 판단되면, 대기 리스트(534)의 쓰레드 ID란에 기록된 쓰레드 ID를 검색하여 대응하는 응용프로그램 쓰레드(302)를 찾는다(S805).
상기 응용프로그램 쓰레드(302)는 메시지 송신기(523)의 출력 버퍼(524)를 뮤택스(525)를 이용하여 임계 영역(critical section)으로 설정한다(S806). 전술한 바와 같이 출력 버퍼(524)를 뮤택스(525)를 이용하여 임계 영역으로 설정함으로써, 여러 개의 퍼실리티(511)에서 동시에 출력하려는 상황을 방지한다.
S805에서 검색시에 조건 변수(532)가 뮤택스(525) 조건에 맞는 지의 여부를 판단한다(S807).
S807에서 판단하여 조건 변수(532)가 뮤택스(525) 조건에 맞으면 응용프로그램 쓰레드(302)로 조건에 맞음을 알리고(S808) 메시지 송신기(521) 및 소켓(320)을 통해 제어 서버(400)의 프로토콜 프록시(600)로 응답을 전송한다(S809).
이상에서 설명한 본 발명은, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 있어 본 발명의 기술적 사상을 벗어나지 않는 범위내에서 여러가지 치환, 변형 및 변경이 가능하므로 전술한 실시예 및 첨부된 도면에 한정하는 것이 아니다.
제 1도는 일반적인 네트워크 기반 로봇 제어를 위한 네트워크 구성도.
제 2도는 로봇에서 서버로의 요청/응답 방식에서 요청을 처리하는 과정을 설명하기 위한 블록 구성도.
제 3도는 서버에서 로봇으로의 요청/응답 방식에서 요청을 처리하는 과정을 설명하기 위한 블록 구성도.
제 4도는 푸쉬 방식으로 명령을 로봇에게 일방적으로 내려주는 방식을 설명하기 위한 블록 구성도.
제 5도는 푸쉬 방식으로 이벤트를 서버로 올려주는 과정을 설명하기 위한 블록 구성도.
제 6도는 본 발명에 의한 네트워크 기반 로봇 제어를 위한 구성도.
제 7도는 본 발명에 의한 네트워크 기반 로봇 제어를 위한 통신 시스템의 일실시예.
제 8도는 본 발명에 의한 네트워크 기반 로봇 제어를 위한 통신 시스템 내부구성의 일실시예를 도시한 블록 구성도.
제 9도는 본 발명에 의한 통신 시스템에서의 API를 호출한 쓰레드에게 응답 메시지를 전달하는 과정을 도시함.
제 10도는 본 발명에 의한 통신 시스템에서의 패킷구조를 도시함.
<도면의 주요부분에 대한 부호의 간단한 설명>
300 : 로봇 301 : 로봇 내부 프로그램(301),
302 : 응용프로그램 쓰레드 400 : 제어 서버
401 : 로봇 제어프로그램 500 : 로봇프로토콜프록시
501 : 로봇API
511, 512, 513, 514, 515, 516, 517, 518, 611, 612, 613, 614, 615, 616, 617, 618 : 퍼실리티
520 : 메시지 송수신기 521 : 메시지 송신기
522 : 메시지 수신기 523 : 메시지 라우터
524 : 출력버퍼 525 : 뮤택스
532 : 조건변수 533 : 퍼실리티 쓰레드
600 :서버프로토콜프록시 601 : 서버API

Claims (27)

  1. 삭제
  2. 삭제
  3. 삭제
  4. 삭제
  5. 로봇에 구성되며 제어 서버로 패킷을 송신하고 상기 제어 서버로부터의 패킷을 수신하는 로봇 프로토콜 프록시와,
    서버 프로토콜 프록시가 상기 로봇의 로봇 내부 프로그램을 호출할 수 있도록 하며, 상기 로봇에 구성된 로봇API를 포함하며;
    상기 로봇 프로토콜 프록시는 동작이 행해지는 로봇의 구동부들에 접근하여 요청된 명령을 수행하고, 그 수행된 결과를 포함하는 응답 패킷을 만들어 요청을 보낸 서버 프로토콜 프록시로 전송하고 상기 응답 패킷을 수신한 상기 서버 프로토콜 프록시는 처음 API를 호출한 프로그램에게 API 호출 결과를 리턴시키며,
    상기 로봇 프로토콜 프록시는 상기 로봇 내의 상기 로봇 내부 프로그램을 다수개의 쓰레드로 구성하고 다수개의 쓰레드로부터 다수의 API를 동시에 호출할 수 있도록 구성하는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  6. 제어 서버에 구성되며, 로봇으로 패킷을 송신하고 상기 로봇으로부터의 패킷을 수신하는 서버 프로토콜 프록시와,
    로봇 프로토콜 프록시가 상기 제어 서버의 로봇 제어 프로그램을 호출할 수 있도록 하며, 상기 제어 서버에 구성된 서버API를 포함하며;
    상기 서버 프로토콜 프록시는 제어 서버에 접근하여 요청된 명령을 수행하고, 그 수행된 결과를 포함하는 응답 패킷을 만들어 요청을 보낸 로봇 프로토콜 프록시로 전송하고 상기 응답 패킷을 수신한 상기 로봇 프로토콜 프록시는 API를 호출한 프로그램에게 API 호출 결과를 리턴시키며,
    상기 서버 프로토콜 프록시는 상기 제어 서버의 상기 로봇 제어 프로그램을 다수개의 쓰레드로 구성하고 다수개의 쓰레드로부터 다수의 API를 동시에 호출할 수 있도록 구성하는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  7. 로봇에 구성되며 제어 서버로 패킷을 송신하고 상기 제어 서버로부터의 패킷을 수신하는 로봇 프로토콜 프록시와,
    서버 프로토콜 프록시가 상기 로봇의 로봇 내부 프로그램을 호출할 수 있도록 하며, 상기 로봇에 구성된 로봇API를 포함하며,
    동작이 행해지는 로봇의 구동부들에 대해 서로 충돌되지 않도록 로봇의 구동부들에 따라 프로토콜 메시지 종류를 구분하고 해당 메시지 종류를 처리할 전담 쓰레드를 각각의 로봇 프로토콜 프록시 및 서버 프로토콜 프록시에 각각 대응하도록 구성하는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  8. 로봇에 구성되며 제어 서버로 패킷을 송신하고 상기 제어 서버로부터의 패킷을 수신하는 로봇 프로토콜 프록시와,
    서버 프로토콜 프록시가 상기 로봇의 로봇 내부 프로그램을 호출할 수 있도록 하며, 상기 로봇에 구성된 로봇API를 포함하며;
    로봇 프로토콜 프록시는,
    프로토콜 메시지 종류별로 프로토콜 메시지를 대응하여 처리하고, 상기 로봇 제어 프로그램에게 API를 제공하여 상기 서버 프로토콜 프록시에게 해당 명령을 전송하도록 하는 다수의 퍼실리티와,
    상기 서버 프로토콜 프록시로부터 상기 요청 및 요청에 대한 응답을 각각 송신하고 수신하며, 상기 퍼실리티로 요청 및 요청에 대한 응답을 전송하는 메시지 송수신기로 구성되는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  9. 제어 서버에 구성되며, 로봇으로 패킷을 송신하고 상기 로봇으로부터의 패킷을 수신하는 서버 프로토콜 프록시와,
    로봇 프로토콜 프록시가 상기 제어 서버의 로봇 제어 프로그램을 호출할 수 있도록 하며, 상기 제어 서버에 구성된 서버API를 포함하며;
    상기 서버 프로토콜 프록시는,
    프로토콜 메시지 종류별로 프로토콜 메시지를 대응하여 처리하고, 상기 서버 제어 프로그램에게 API를 제공하여 로봇 프로토콜 프록시에게 해당 명령을 전송하도록 하는 다수의 퍼실리티와,
    상기 로봇 프로토콜 프록시로부터 상기 요청 및 요청에 대한 응답을 각각 송신하고 수신하며, 상기 퍼실리티로 요청 및 요청에 대한 응답을 전송하는 메시지 송수신기로 구성되는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  10. 제8항에 있어서,
    상기 메시지 송수신기는,
    상기 퍼실리티와 별도의 쓰레드로 동작하면서 상기 서버 프로토콜 프록시로 부터 패킷을 수신하는 메시지 수신기와;
    상기 로봇의 퍼실리티의 수신버퍼에 전송받은 상기 패킷을 전송하고 상기 제어 서버의 퍼실리티에게 패킷 전송 사실을 통보하는 메시지 송신기와;
    상기 로봇의 퍼실리티 별로 조건변수와의 조건에 맞으면 패킷을 상기 메시지 송신기로 전송하고 상기 퍼실리티로 패킷 전송 사실을 통보하고 조건변수와의 조건에 맞지 않으면 패킷을 제어 서버로 전송하지 않도록 구성한 뮤택스로 구성되는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  11. 제9항에 있어서,
    상기 메시지 송수신기는,
    상기 퍼실리티와 별도의 쓰레드로 동작하면서 상기 로봇 프로토콜 프록시로부터 패킷을 수신하는 메시지 수신기와;
    상기 제어 서버의 퍼실리티의 수신버퍼에 전송받은 패킷을 전달하고 상기 로봇의 퍼실리티에게 패킷 전송 사실을 통보하는 메시지 송신기와;
    상기 제어 서버의 상기 퍼실리티 별로 조건변수와의 조건에 맞으면 패킷을 상기 퍼실리티로 전송하고 패킷 전송 사실을 통보하고 조건변수와의 조건에 맞지 않으면 패킷을 전송하지 않도록 구성한 뮤택스로 구성되는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  12. 제8항 또는 제9항에 있어서,
    상기 퍼실리티는,
    상기 로봇과 상기 제어 서버 간의 인증을 위한 명령을 처리하는 인증 퍼실리티와;
    상기 로봇이 실행하는 서비스를 전환하기 위한 명령을 처리하는 서비스 퍼실리티와;
    상기 로봇의 이동에 관련된 명령을 처리하는 이동 퍼실리티와;
    카메라를 이용하여 사진을 찍고 앨범을 관리하는 명령을 수행하는 카메라 퍼실리티와;
    상기 로봇이 가정 내를 청소하는 진공청소 흡입기를 제어하는 청소 퍼실리티와;
    상기 로봇과 상기 제어 서버가 이상 상황에 의해서 멈추거나 네트워크 연결이 끊겼는지를 서로 주기적으로 점검하는 메시지 퍼실리티와;
    로봇이 집안의 지도를 만들도록 하기 위한 제어를 하는 지도 퍼실리티와;
    로봇의 센서 상태들을 계속 추출하는 상태 퍼실리티로 구성되는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  13. 로봇에 구성되며 제어 서버로 패킷을 송신하고 상기 제어 서버로부터의 패킷을 수신하는 로봇 프로토콜 프록시와,
    서버 프로토콜 프록시가 상기 로봇의 로봇 내부 프로그램을 호출할 수 있도록 하며, 상기 로봇에 구성된 로봇API를 포함하며;
    상기 패킷은,
    상기 패킷의 시작을 표시하는 디스크리미네이터 필드와,
    상기 패킷의 버전을 표시하는 버전 필드와,
    랜덤하게 부여되는 통신을 구성하는 세션의 ID를 나타내는 세션ID 필드와,
    메시지 종류별로 구분한 퍼실리티의 고유번호를 나타내는 퍼실리티 ID 필드와,
    해당 퍼실리티에의 함수에 대한 고유번호를 나타내는 펑션 ID 필드와,
    상기 패킷을 생성할 때마다 계속 증가하는 일련 번호를 나타내는 시퀀스 ID 필드와,
    메시지의 형태를 나타내는 메시지 타입 필드와,
    메시지를 포함하며, 함수에 특화된 파라미터를 포함하는 메지시 필드로 이루어진 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  14. 제13항에 있어서,
    응답을 받은 퍼실리티 쓰레드가 어떤 응용프로그램 쓰레드에게 전달해야 할지를 응답 메시지의 시퀀스 ID 필드로 확인하는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  15. 제13항에 있어서,
    상기 메시지 타입 필드는,
    상대편 로봇 또는 제어 서버로 로봇의 구동부들을 포함하는 로봇의 자원이용을 요청하는 요청과;
    상기 요청에 대한 응답인 응답과;
    상기 상대편 로봇 또는 제어서버로 자원을 동작시키킬 명령하는 명령과;
    자신의 상태 변화를 상대편 제어 서버 또는 로봇으로 통보하는 이벤트 중 어느 하나인 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  16. 제15항에 있어서,
    상기 명령과 상기 이벤트는 단방향 신호인 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  17. 제어 서버를 이용하여 네트워크 기반 가정용 정보 서비스 로봇을 제어하는 네트워크 기반 로봇 제어를 위한 통신 방법으로서,
    로봇의 구동부들을 포함하는 로봇의 자원중에서 로봇의 동일한 자원을 사용하는 함수들끼리 분류하여 묶고 이를 응용프로그램 쓰레드로 구성하는 제1 단계와;
    상기 제1 단계에서 분류된 종류별로 명령을 처리하기 위한 응용프로그램 쓰레드를 구동시키는 제2 단계와;
    패킷 송신과 수신을 전담하는 퍼실리티 쓰레드를 구동시키는 제3 단계와;
    상기 퍼실리티 쓰레드를 이용하여 응용프로그램 쓰레드별로 제어 패킷을 상대편으로 송신하는 제4 단계와;
    상기 제4 단계에서 송신된 제어 패킷을 수신하여 상기 제어 패킷의 메시지 타입이 요청인지의 여부를 판단하는 제5 단계와;
    상기 제5 단계에서 판단하여 제어 패킷의 메시지 타입이 요청인 경우면 그에 대한 응답을 수신하고 제어 패킷을 분류된 종류대로 구동시키는 응용프로그램 쓰레드(302)로 전송하는 제6 단계와;
    상기 제어 패킷을 전달받은 상기 응용프로그램 쓰레드가 로봇의 자원을 사용하여 제어 패킷의 메시지 타입에 따른 요청, 응답, 명령 또는 이벤트를 처리하는 제7 단계를 포함하여 이루어지는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 방법.
  18. 제17항에 있어서,
    상기 제7 단계는,
    먼저, 소스 내부프로그램의 응용프로그램 쓰레드가 요청, 응답, 명령, 이벤트에 대한 응답을 생성하기 위해 소스의 API를 호출하는 호출단계와;
    상기 소스의 응용프로그램 쓰레드가 호출한 소스의 해당 API를 통하여 자신 의 쓰레드 정보를 소스 퍼실리티의 대기 리스트에 기록하는 기록단계를 더 포함하는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 방법.
  19. 제18항에 있어서,
    상기 소스의 응용프로그램 쓰레드가 싱크로 요청을 전송하여 그에 대한 응답을 수신하는 경우이면,
    소스의 응용프로그램 쓰레드가 대기 리스트에 등록되고 대기하는 대기단계와;
    상기 요청을 수신한 싱크의 응용프로그램 쓰레드가 요청을 완료하고 응답 패킷을 생성하여 응답 패킷을 전송하는 전송단계와;
    상기 응답 패킷을 수신하면, 이를 소스의 응용프로그램 쓰레드에게 상기 응답 패킷이 도착하였음을 통보하는 통보단계를 더 포함하는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 방법.
  20. 제19항에 있어서,
    상기 전송단계는
    상기 소스의 퍼실리티가 상기 싱크로부터 응답 패킷을 수신하였는지의 여부를 판단하는 제1 판단단계와;
    상기 제1 판단단계에서 판단하여 소스의 퍼실리티 쓰레드가 싱크로부터 응답 메시지를 수신한 것으로 판단되면, 상기 소스의 대기 리스트의 쓰레드 ID란에 기록된 쓰레드 ID를 검색하여 대응하는 조건변수를 이용하여 소스의 응용프로그램 쓰레드를 찾는 검색단계와;
    상기 조건 변수가 소스의 뮤택스 조건에 맞는 지의 여부를 판단하는 제2 판단단계와;
    상기 제2 판단단계에서 판단하여 상기 조건 변수가 상기 뮤택스 조건에 맞으면 소스의 응용프로그램 쓰레드로 조건에 맞음을 알리고 상기 싱크의 프로토콜 프록시로 응답을 전송하는 전송단계로 이루어 지는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 방법.
  21. 제19항에 있어서,
    상기 제1 판단단계에서 판단하여 싱크로부터 요청, 응답, 명령, 또는 이벤트에 대응하는 응답 메시지를 수신하지 못한 것으로 판단되면, 대기단계로 리턴하는 리턴단계를 더 포함하는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 방법.
  22. 제17항에 있어서,
    상기 패킷은,
    상기 패킷의 시작을 표시하는 디스크리미네이터 필드와;
    상기 패킷의 버전을 표시하는 버전 필드와;
    랜덤하게 부여되는 통신을 구성하는 세션의 ID를 나타내는 세션ID 필드와;
    메시지 종류별로 구분한 퍼실리티의 고유번호를 나타내는 퍼실리티 ID 필드와;
    해당 퍼실리티에의 함수에 대한 고유번호를 나타내는 펑션 ID 필드와;
    상기 패킷을 생성할 때마다 계속 증가하는 일련 번호를 나타내는 시퀀스 ID 필드와;
    메시지의 형태를 나타내는 메시지 타입 필드와;
    메시지를 포함하며, 함수에 특화된 파라미터를 포함하는 메지시 필드로 이루어진 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 방법.
  23. 제어 서버에 구성되며, 로봇으로 패킷을 송신하고 상기 로봇으로부터의 패킷을 수신하는 서버 프로토콜 프록시와,
    로봇 프로토콜 프록시가 상기 제어 서버의 로봇 제어 프로그램을 호출할 수 있도록 하며, 상기 제어 서버에 구성된 서버API를 포함하며;
    동작이 행해지는 로봇의 구동부들에 대해 서로 충돌되지 않도록 로봇의 구동부들에 따라 프로토콜 메시지 종류를 구분하고 해당 메시지 종류를 처리할 전담 쓰레드를 각각의 로봇 프로토콜 프록시 및 서버 프로토콜 프록시에 각각 대응하도록 구성하는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  24. 제어 서버에 구성되며, 로봇으로 패킷을 송신하고 상기 로봇으로부터의 패킷을 수신하는 서버 프로토콜 프록시와,
    로봇 프로토콜 프록시가 상기 제어 서버의 로봇 제어 프로그램을 호출할 수 있도록 하며, 상기 제어 서버에 구성된 서버API를 포함하며;
    상기 패킷은,
    상기 패킷의 시작을 표시하는 디스크리미네이터 필드와,
    상기 패킷의 버전을 표시하는 버전 필드와,
    랜덤하게 부여되는 통신을 구성하는 세션의 ID를 나타내는 세션ID 필드와,
    메시지 종류별로 구분한 퍼실리티의 고유번호를 나타내는 퍼실리티 ID 필드와,
    해당 퍼실리티에의 함수에 대한 고유번호를 나타내는 펑션 ID 필드와,
    상기 패킷을 생성할 때마다 계속 증가하는 일련 번호를 나타내는 시퀀스 ID 필드와,
    메시지의 형태를 나타내는 메시지 타입 필드와,
    메시지를 포함하며, 함수에 특화된 파라미터를 포함하는 메지시 필드로 이루어진 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  25. 제24항에 있어서,
    응답을 받은 퍼실리티 쓰레드가 어떤 응용프로그램 쓰레드에게 전달해야 할지를 응답 메시지의 시퀀스 ID 필드로 확인하는 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  26. 제24항에 있어서,
    상기 메시지 타입 필드는,
    상대편 로봇 또는 제어 서버로 로봇의 구동부들을 포함하는 로봇의 자원이용을 요청하는 요청과;
    상기 요청에 대한 응답인 응답과;
    상기 상대편 로봇 또는 제어서버로 자원을 동작시키킬 명령하는 명령과;
    자신의 상태 변화를 상대편 제어 서버 또는 로봇으로 통보하는 이벤트 중 어느 하나인 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
  27. 제26항에 있어서,
    상기 명령과 상기 이벤트는 단방향 신호인 것을 특징으로 하는 네트워크 기반 로봇 제어를 위한 통신 시스템.
KR1020070066561A 2006-12-04 2007-07-03 네트워크 기반 로봇 제어를 위한 통신 시스템 및 방법 KR100914249B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20060121363 2006-12-04
KR1020060121363 2006-12-04

Publications (2)

Publication Number Publication Date
KR20080050959A KR20080050959A (ko) 2008-06-10
KR100914249B1 true KR100914249B1 (ko) 2009-08-26

Family

ID=39806109

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020070066561A KR100914249B1 (ko) 2006-12-04 2007-07-03 네트워크 기반 로봇 제어를 위한 통신 시스템 및 방법

Country Status (1)

Country Link
KR (1) KR100914249B1 (ko)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170027820A (ko) * 2014-07-03 2017-03-10 아틀라스 콥코 인더스트리얼 테크니크 에이비 툴 통신 네트워크의 방법, 노드 및 컴퓨터 프로그램
WO2017126768A1 (ko) * 2016-01-20 2017-07-27 (주)유진로봇 이동로봇을 원격으로 제어하는 원격 제어 장치 및 시스템과 그의 수행방법

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050032315A (ko) * 2003-10-01 2005-04-07 엘지전자 주식회사 청소로봇과 연동되는 홈 네트워크 시스템
KR20060059159A (ko) * 2004-11-26 2006-06-01 한국전자통신연구원 네트워크 기반 로봇 시스템 및 그 실행 방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050032315A (ko) * 2003-10-01 2005-04-07 엘지전자 주식회사 청소로봇과 연동되는 홈 네트워크 시스템
KR20060059159A (ko) * 2004-11-26 2006-06-01 한국전자통신연구원 네트워크 기반 로봇 시스템 및 그 실행 방법

Also Published As

Publication number Publication date
KR20080050959A (ko) 2008-06-10

Similar Documents

Publication Publication Date Title
US10826979B2 (en) Apparatus and method for logically grouping client nodes in an IoT environment using client identifiers
CN103197968B (zh) 一种融合同步异步特点的线程池处理方法及系统
JP3382953B2 (ja) 有限メモリコンピュータシステム上におけるクライアント管理フロー制御方法及び装置
US6697876B1 (en) Distributed kernel operating system
KR100902662B1 (ko) 단말용 데이터 포맷을 이용한 통신 제어 시스템 및 그 방법
CN1881944B (zh) 改进型分布式核心操作系统
US6415315B1 (en) Method of moving objects in a computer network
WO2005124549A1 (ja) 処理管理装置、コンピュータ・システム、分散処理方法及びコンピュータプログラム
RU2605918C2 (ru) Способ предоставления функций в промышленной системе автоматизации и промышленная система автоматизации
JP5541292B2 (ja) 分散システム、通信手段選択方法および通信手段選択プログラム
EP3554037A1 (en) Downlink media transmission control method and related device
US6466963B1 (en) Agent system with prioritized processing of mobile agents
KR100914249B1 (ko) 네트워크 기반 로봇 제어를 위한 통신 시스템 및 방법
KR20070061075A (ko) 네트워크 기반 로봇 제어 장치 및 그 방법
KR100630052B1 (ko) 실시간 전송 프로토콜 데이터의 전송을 위한 처리 시스템 및 방법
CN111782417B (zh) 一种基于消息的多进程共享串口资源的实现方法
US6519653B1 (en) Method of communicating between agent objects in a computer network
CN109408251A (zh) 消息发送方法与装置、消息接收处理方法与装置
CN113111666A (zh) 一种实现应用程序的多语言翻译的系统及方法
CN115361348B (zh) 由数据采集设备执行的与web浏览器通信的方法
KR100571520B1 (ko) 일원화된 통합 미들웨어를 이용한 홈네트워크 시스템에서의 자원공유방법
US20150081774A1 (en) System and method for implementing augmented object members for remote procedure call
CN113992740B (zh) 一种基于自主可控的中间件及数据传输方法
KR102693536B1 (ko) 전송 제어 프로토콜 연결 처리 장치 및 방법
CN116244099B (zh) 嵌入式系统内进程通讯方法、装置、电子设备和存储介质

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
AMND Amendment
J201 Request for trial against refusal decision
E902 Notification of reason for refusal
B701 Decision to grant
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20121221

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20130814

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20140820

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20150819

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20170519

Year of fee payment: 8

R401 Registration of restoration
FPAY Annual fee payment

Payment date: 20170818

Year of fee payment: 9

FPAY Annual fee payment

Payment date: 20190819

Year of fee payment: 11