KR20090088112A

KR20090088112A - 로봇 통신 미들웨어 플랫폼 및 그 통신 방법

Info

Publication number: KR20090088112A
Application number: KR1020080013468A
Authority: KR
Inventors: 홍순혁; 박종호; 박지현; 백승현
Original assignee: 삼성전자주식회사
Priority date: 2008-02-14
Filing date: 2008-02-14
Publication date: 2009-08-19

Abstract

본 발명은 로봇을 구성하는 장치를 클래스 라이브러리로 구성하는 로봇 팩토리 클래스를 구비하는 어플리케이션 인터페이스, 상기 로봇 장치에 따라 대응하는 별도의 큐를 구비하는 가상 메시지 큐와, 상기 어플리케이션 인터페이스에서 특정 서비스 함수 호출 시 상기 호출된 서비스 함수를 분석하고 함수 호출 메시지를 생성하여 상기 가상 메시지 큐의 대응하는 큐에 저장하는 서비스 프록시와, 상기 가상 메시지 큐에 저장된 함수 호출 메시지를 분석하고 상기 호출된 서비스 함수에 대응하는 로봇 함수를 전송하는 서비스 디스패쳐를 구비하는 데이터 통신 모듈, 상기 로봇 팩토리 클래스에서 호출된 서비스 함수에 대응하는 로봇 함수를 실행하는 GRIS 드라이버 어댑터를 구비하는 디바이스 인터페이스 및 상기 로봇이 구비하는 장치에 관한 구성 정보를 포함하는 팩터 데이터 베이스를 구비하는 디바이스 설정 정보 모듈을 포함하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼에 관한 것이다.

가상 메시지 큐, GRIS 드라이버 어댑터, 로봇 팩토리 클래스, 팩터 데이터 베이스

Description

로봇 통신 미들웨어 플랫폼 및 그 통신 방법{Communication middleware platform for robot and method for communication thereof}

본 발명은 로봇 소프트웨어 개발을 위한 통신 미들웨어 및 API에 관한 것이다. 특히 본 발명의 로봇 통신 미들웨어는 프로그래밍 시 활용할 수 있는 로봇 팩토리 클래스, 드라이버 개발 시 활용할 수 있는 GRIS 드라이버 어댑터, 서비스 어플리케이션과 로봇 하드웨어 드라이버 간의 통신을 가능하게 하는 가상 메시지 큐(VMQ)를 포함하며, 이에 따라 개발자들은 로봇의 기능에 대한 정보만을 가지고 로봇을 제어, 개발할 수 있다.

일반적으로 내장형 시스템 (Embedded System)은 특정 시스템 및 환경에서 동작되도록 특수하게 개발되어, 어플리케이션 S/W가 해당 시스템에서만 실행되거나 타 시스템과의 호환이 잘 되지 않는 경우가 대부분이다. 로봇 혹은 로봇 시스템의 경우에도, 기존의 산업용 로봇 혹은 특수 목적으로 제작된 로봇의 경우에 그 제작 목적에 따라 로봇의 형태 및 기능, S/W 개발 등이 각기 다르다.

최근에는 로봇이 기존의 산업용 로봇의 용도와는 달리, 주어진 작업만을 반복하기 보다는 자체적으로 지능을 갖추어 사람의 일상생활에 도움이 되는 서비스를 제공하도록 하는 요구들이 증가하고 있다. 또한 사회적으로도 서비스 로봇에 대한 일반인들의 이해 및 기대치가 높아지고 있다. 따라서, 이러한 기대에 부응하기 위해서는 기존의 로봇 하드웨어 및 컴포넌트 기술들을 활용하여 실제적인 서비스를 제공할 수 있는 로봇 어플리케이션 개발이 필요하며, 로봇을 이용한 고수준의 서비스를 개발하기 위한 S/W 플랫폼, 개발 환경 및 인프라 시스템 등이 필요하게 된다.

일반적으로 로봇 S/W 들은 로봇의 제작 목적 또는 제공 기능에 따라 로봇의 형태 및 구성이 각기 다르고 로봇 제작 업체마다 고유의 개발환경 (OS, H/W component, 개발언어 등)에서 개발되고 있다. 따라서, 각 업체마다 공통이 되는 기능을 개발하여 사용하고 있다 하더라도 서로 호환이 되지 않거나 혹은 구현 방식이 모두 다르게 된다.

만약, 형태 및 구성이 각기 다른 로봇을 가지고 공통의 서비스를 제공하고자 할 시에는 로봇에 따라 공통 서비스를 제공하기 위한 로봇 S/W를 각각 개발해야 한다. 또한, 기존 로봇의 하드웨어 구성이 업그레이드 혹은 변경에 의해 달라지게 될 경우에는 그에 따른 S/W 수정도 하드웨어와 관련된 부분의 수정 뿐만 아니라 상위 어플리케이션 부분도 수정이 가해져야 할 수도 있다.

따라서 로봇의 하드웨어적, 기능적 특성을 고려하여 로봇 서비스 어플리케이션 개발을 용이하도록 하기 위한 로봇 S/W 플랫폼을 개발할 필요성이 대두된다.

본 발명이 이루고자 하는 기술적 과제는 로봇의 하드웨어적 기능적 특성을 고려하여 로봇 서비스 어플리케이션 개발을 용이하도록 하기 위한 로봇 통신 미들웨어 플랫폼을 개발하는 것이다.

이와 같은 목적을 달성하기 위한 본 발명의 로봇 통신 미들웨어 플랫폼은 로봇을 구성하는 장치를 클래스 라이브러리로 구성하는 로봇 팩토리 클래스를 구비하는 어플리케이션 인터페이스, 상기 로봇 장치에 따라 대응하는 별도의 큐를 구비하는 가상 메시지 큐와, 상기 어플리케이션 인터페이스에서 특정 서비스 함수 호출 시 상기 호출된 서비스 함수를 분석하고 함수 호출 메시지를 생성하여 상기 가상 메시지 큐의 대응하는 큐에 저장하는 서비스 프록시와, 상기 가상 메시지 큐에 저장된 함수 호출 메시지를 분석하고 상기 호출된 서비스 함수에 대응하는 로봇 함수를 전송하는 서비스 디스패쳐를 구비하는 데이터 통신 모듈, 상기 로봇 팩토리 클래스에서 호출된 서비스 함수에 대응하는 로봇 함수를 실행하는 GRIS 드라이버 어댑터를 구비하는 디바이스 인터페이스 및 상기 로봇이 구비하는 장치에 관한 구성 정보를 포함하는 팩터 데이터 베이스를 구비하는 디바이스 설정 정보 모듈을 포함하는 것을 특징으로 한다.

또한, 상기 가상 메시지 큐는 로깅 설정 및 글로벌 설정을 위한 로컬 프로파일과, 서버 설정 및 상기 가상 메시지 큐 설정을 위한 서버 정보를 포함하는 것을 특징으로 하고, 상기 팩터 데이터 베이스는 상기 로봇의 하드웨어 정보를 포함하는 프로덕트 설정과, 프로그램에서 사용되는 설정 정보를 포함하는 파트 설정과, 상기 로봇을 구성하는 장치들 상호간의 구성을 기술하는 컨피그 설정을 포함하는 것을 특징으로 하며, 상기 파트 설정은 상기 로봇 팩토리 클래스와 상기 GRIS 드라이버 어댑터의 연결 방법을 설정 가능하고, 상기 연결 방법은 상기 로봇 팩토리 클래스와 상기 GRIS 드라이버 어댑터를 상기 가상 메시지 큐를 이용하여 연결하거나 또는 직접 연결하는 것을 특징으로 한다. 또한 상기 파트 설정은 상기 로봇의 장치마다 서로 다른 가상 메시지 큐를 설정하거나 또는 복수의 로봇 장치에 동일한 가상 메시지 큐를 설정 가능한 것을 특징으로 한다.

그리고 상기 서비스 프록시는 상기 로봇 팩토리 클래스에 로봇 장치 클래스가 등록되면, 서비스 프록시 객체를 생성하여 상기 로봇 장치 클래스를 식별하는데 필요한 파트 ID 와, 상기 파트 ID에 대응하는 서비스 프록시 객체에 관한 정보를 서비스 프록시 객체 테이블에 저장하고, 상기 서비스 프록시는 상기 서비스 프록시 객체 테이블에서 파트 ID를 검색하고 이에 대응되는 서비스 프록시 객체를 확인하여, 상기 확인된 서비스 프록시 객체가 상기 팩터 데이터 베이스에서 상기 파트 ID에 대응되는 가상 메시지 큐를 확인하고, 상기 확인된 가상 메시지 큐에 함수 호출 메시지를 생성하여 저장하도록 하는 것을 특징으로 한다.

또한, 상기 서비스 디스패쳐는 상기 가상 메시지 큐에 저장된 상기 함수 호출 메시지를 수신하고, 파트 ID 및 서비스 이름을 확인하여 상기 로봇 팩토리 클래스에서 호출된 서비스 함수에 대응되는 서비스 함수를 상기 GRIS 드라이버 어댑터 에서 검색하여 실행하는 것을 특징으로 한다.

그리고 본 발명의 가상 메시지 큐는 상기 서버 설정에서 원격에 있는 상기 GRIS 드라이버 어댑터가 위치하는 시스템의 IP 어드레스를 지정하여, 서로 다른 네트워크에 위치한 상기 로봇 팩토리 클래스와 상기 GRIS 드라이버 어댑터를 연결할 수 있고, 상기 가상 메시지 큐는 로봇 장치간 우선 순위를 설정하여 상기 로봇 팩토리 클래스와 상기 GRIS 드라이버 어댑터를 연결하는 것을 특징으로 한다.

또한, 상기 어플리케이션 인터페이스는 상기 로봇에 장치 또는 기능이 부가되면, 상기 로봇 팩토리 클래스에 대응하여 추가되는 GRI 스터브를 더 포함하고, 상기 디바이스 인터페이스는 상기 로봇에 장치 또는 기능이 부가되면, 상기 GRIS 드라이버 어댑터에 대응하여 추가되는 GRI 스켈레톤을 더 포함하는 것을 특징으로 한다. 이 경우, 상기 GRI 스터브 또는 상기 GRI 스켈레톤은 추가되는 인터페이스에 대한 서비스 함수의 정의가 기술된 GRI 다큐멘트가 GRI 파서에 입력되면, 상기 로봇 팩토리 클래스 또는 GRIS 드라이버 어댑터에 대응하는 소스 코드가 자동으로 생성되는 것을 특징으로 한다.

그리고 이와 같은 목적을 달성하기 위한 본 발명의 로봇 통신 미들웨어의 통신 방법은 로봇의 장치에 대한 로봇 팩토리 클래스 객체를 생성하는 단계, 상기 생성된 로봇 팩토리 클래스 객체를 서비스 프록시에 등록하는 단계, 함수 호출 방식과 지정된 가상 메시지 큐를 팩터 데이터 베이스에서 조회하여 함수 호출 메시지를 생성하고, 대응하는 가상 메시지 큐에 저장하는 단계를 포함하는 것을 특징으로 한다.

또한, 이와 같은 목적을 달성하기 위한 본 발명의 로봇 통신 미들웨어의 통신 방법은 GRIS 드라이버 어댑터 클래스 객체를 생성하는 단계 ,상기 생성된 GRIS 드라이버 어댑터 객체에 대한 서비스 디스패쳐를 생성하는 단계, 가상 메시지 큐에 저장된 함수 호출 메시지를 분석하여, 상기 로봇 팩토리 클래스에서 호출된 서비스 함수에 대응하는 로봇 함수를 실행하는 단계를 포함하는 것을 특징으로 한다.

본 발명의 로봇 통신 미들웨어를 사용할 경우, 로봇 개발이 명확하게 로봇 서비스 어플리케이션 개발, 로봇 하드웨어 플랫폼의 개발 부분으로 분리될 수 있다. 이로 인하여 로봇 하드웨어 플랫폼 부분의 변경 사항이 발생하더라도 해당 하드웨어의 의존적인 부분만을 수정하여 이를 반영할 수 있으므로, 이에 따른 소프트웨어의 불가피한 수정을 피할 수 있다.

또한, 로봇의 상위 어플리케이션 개발자들은 로봇의 기능에 대한 정보만으로 로봇을 손쉽게 제어할 수 있어 로봇 서비스 개발이 용이해 질 수 있다.

또한, 로봇 서비스 어플리케이션이 로봇 하드웨어와 서로 다른 시스템인 경우, 원격에서 상기 로봇 서비스 어플리케이션과 로봇 하드웨어를 상호 연동시킬 수 있다.

이하, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 본 발명을 용이하게 실시할 수 있을 정도로 본 발명의 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명하면 다음과 같다.

도 1은 본 발명의 실시예에 따른 로봇 통신 미들웨어 플랫폼의 상세 구조를 나타내는 도면이다. 이하, 본 발명의 실시예에서는 상기 도 1에 도시된 로봇 통신 미들웨어 플랫폼을 GRIS(General Robot Infra Structure)라고 칭하기로 한다.

도 1에 도시된 바와 같이, 본 발명의 실시예에 따른 로봇 통신 미들웨어 플랫폼은 어플리케이션 인터페이스(110), 데이터 통신 모듈(130), 디바이스 인터페이스(150), 디바이스 설정 정보 모듈(165)를 포함할 수 있다. 이 경우, 상기 어플리케이션 인터페이스(110)는 가동 실행기(Behavior Interpreter, 115), 로봇 팩토리 클래스(Robot Factory Class, 120)(이하 'RFC'라 한다), GRI 스터브(GRIS Remote Interface Stub, 125)를 포함할 수 있다. 또한 상기 데이터 통신 모듈(130)은 가상 메시지 큐(Virtual Message Queue, 135)(이하 'VMQ'라 한다), 서비스 프록시(Service Proxy, 140), 서비스 디스패쳐(Service Dispatcher, 145)를 포함할 수 있다. 그리고 상기 디바이스 인터페이스(150)는 GRIS 드라이버 어댑터(GRIS Driver Adapter, 155)(이하 'GDA'라 한다), GRI 스켈레톤(GRIS Remote Interface Skeleton, 160)을 포함할 수 있다. 마지막으로 상기 디바이스 설정 정보 모듈(165)은 팩터 데이터 베이스(Factor Database, 170)를 포함할 수 있다.

그리고 본 발명의 로봇 통신 미들웨어 플랫폼의 상위 클래스에는 로봇 서비스 어플리케이션(105)이 존재할 수 있다. 또한 본 발명의 로봇 통신 미들웨어 플랫폼의 하위 클래스에는 운영 체제(175) 및 로봇 하드웨어(180)가 존재할 수 있다.

어플리케이션 인터페이스(110)는 로봇 하드웨어의 구성 및 장치 정보에 상관없이 로봇 서비스 어플리케이션(105)을 개발할 수 있도록 로봇의 하드웨어 장치 인 터페이스를 추상화한 로봇 개발 API(Application Programming Interface)이다. 상기 추상화란 특정 기능을 상위 클래스에서 직접 구현하지 않고, 하위 클래스에서 구현하는 것을 의미한다.

가동 실행기(Behavior Interpreter, 115)는 로봇의 기본 기능들(Primitive function)을 스크립트(script)로 작성하여, 런 타임 시 별도의 컴파일 없이 로봇을 동작시킬 수 있는 인터페이스이다. 다시 말해, 상기 가동 실행기(115)는 로봇 제어를 위한 소프트웨어를 작성하여 이것을 컴파일하여 실행코드로 만들어 사용하는 것이 아니라, 스크립트 형태의 언어로 로봇이 수행해야 하는 일련의 행위들을 기술하여 이것을 컴파일 없이 로봇 소프트웨어 실행 시에 즉각적으로 실행할 수 있도록 하는 실행기이다. 즉, 로봇의 행위를 기술하는 스크립트가 입력되고 로봇 서비스 어플리케이션에서 상기 스크립트를 호출하면, 상기 가동 실행기(115)가 상기 스크립트를 분석하고 RFC(120)에 정의된 기본 기능들을 이용하여 행위를 수행하게 된다. 이를 위해 로봇의 일련의 행위들, 다시 말해 특정 상황에서 로봇이 취해야 하는 행위는 미리 설정되고 이는 스크립트로 작성된다. 예를 들어 사람이 로봇의 머리 부분의 센서를 터치하면 로봇이 특정 음성을 출력하고, 사람의 방향으로 머리를 움직이는 행위를 미리 설정하고 스크립트로 작성될 수 있다. 그리고 상기 스크립트에서는 로봇의 기본 기능(primitive function)들을 이용하여 작성할 수 있는데, 이러한 기본 기능들은 RFC(120)에서 정의되어 있으므로, 스크립트에서 이를 이용할 수 있도록 구성된다.

RFC(120)는 로봇 서비스 어플리케이션 개발자가 프로그래밍 시 활용할 수 있 는 프로그래밍 API(Application Programming Interface)로서, 로봇의 구성 요소와 이를 응용한 디바이스들을 일반화한, 추상화된 클래스 라이브러리를 말한다.

GRI 스터브(GRIS Remote Interface Stub, 125)는 RFC(120)에서 제공하는 인터페이스 이외에 사용자가 특정 목적에 맞도록 RFC(120) 이외에 새로운 인터페이스를 추가한 부분으로 별도의 사용자 라이브러리로 구성된다. 그러면 어플리케이션 인터페이스(110)는 GRIS에서 제공하는 모든 로봇에 공통으로 적용되는 인터페이스(즉, RFC)와 사용자가 직접 추가한 인터페이스(즉, GRI 스터브)를 모두 포함하며, 로봇 서비스 어플리케이션(105)에서는 로봇을 제어하기 위해 RFC(120) 및 GRI 스터브(125)를 모두 사용할 수 있다.

데이터 통신 모듈(130)은 어플리케이션 인터페이스(110)와 디바이스 인터페이스(150)간의 통신을 가능하도록 하며, 상기 어플리케이션 인터페이스(110)에서의 오퍼레이션(함수 호출, 데이터 전송 등)에 대해서 실제 오퍼레이션이 수행될 수 있도록 해당 메시지를 전달해주는 기능을 한다. 이로 인해 로봇 서비스 어플리케이션 개발자들은 로봇의 기능이 어떠한 것인지에 대한 정보만을 가지고 로봇을 손쉽게 제어할 수 있다. 즉, 상기 데이터 통신 모듈(130)은 로봇 서비스 어플리케이션과 로봇 하드웨어 의존적 하위 소프트웨어를 분리하여 로봇 소프트웨어 개발을 로봇 하드웨어에 구애받지 않고 할 수 있도록 한다.

VMQ(135)는 통신 방식으로 메시지 큐(Message Queue) 방식을 사용하며 로봇 서비스 어플리케이션의 로봇 하드웨어 의존성을 제거하기 위한 부분으로, 어플리케이션 인터페이스(110)와 디바이스 인터페이스(150) 양단 간의 통신을 담당한다. (보다 구체적으로는 RFC과 GDA와의 통신을 담당한다)

서비스 프록시(Service Proxy, 140)는 RFC(120)로부터 서비스가 호출되면 호출된 서비스에 관한 정보를 포함하는 함수 호출 메시지를 생성하여 VMQ(135)를 통하여 GDA(155)로 전달해 주며, 상기 GDA(155)로부터 서비스 실행에 대한 응답 결과를 수신하면, 이를 RFC(120)로 전달해 주는 역할을 수행한다.

서비스 디스패쳐(Service Dispatcher, 145)는 VMQ(135)를 통하여 RFC(120)로부터의 서비스 호출을 받기 위한 것이다. 다시 말해, 상기 서비스 디스패쳐(145)는 VMQ(135)를 통해서 전달된 RFC(120)의 서비스 호출을 수신하고, 상기 서비스에 대응하는 GRIS 드라이버 어댑터(155) 함수를 호출한다. 그리고 상기 서비스 디스패쳐(145)는 다시 상기 VMQ(135)를 통하여 상기 서비스 호출에 대한 응답 결과를 상기 RFC(120)에 전달한다.

디바이스 인터페이스(150)는 실질적으로 로봇 하드웨어와 의존적인 부분, 즉 로봇 장치들을 직접 제어하는 부분으로 VMQ(135)를 통하여 로봇 서비스 어플리케이션과의 데이터 교환 및 요청을 수락하고 그에 대한 응답을 수행한다.

GDA(155)는 서비스 디스패쳐(145)가 VMQ(135)를 통하여 전달받은 함수 호출 메시지에 포함된 RFC(120)에서 호출된 함수에 상응하는 실제 로봇 함수를 실행한다.

GRI 스켈레톤(GRIS Remote Interface Skeleton, 160)은 GRI 스터브(125)에 대응되며, 사용자가 GRI 스터브(125)에서 정의한 새로운 인터페이스에 대해 실제 구현을 하는 부분이다.

디바이스 설정 정보 모듈(165)은 서로 다른 로봇의 장치 및 구성 정보를 관리하는 부분이다. 데이터 통신 모듈(130)은 어플리케이션 인터페이스(110)와 디바이스 인터페이스(150)간의 통신을 담당하고, 메시지 전송이나 함수 호출을 위하여 VMQ(135)를 사용하는데, 이 경우 어플리케이션 인터페이스(110)가 디바이스 인터페이스(150)의 어떤 인터페이스와 연결이 되어야 하는지 알려줄 필요가 있다. 이러한 어플리케이션 인터페이스(110)와 디바이스 인터페이스(150)간의 연결 관계를 설정하고 있는 부분이 디바이스 설정 모듈(165)이다.

팩터 데이터 베이스(170)는 어플리케이션 인터페이스(110)와 디바이스 인터페이스(150)간 통신방법과 VMQ(135)의 이름 등을 설정하며, 또한 로봇의 하드웨어 디바이스 구성 정보를 XML 형태의 하드웨어 장치 기술서(H/W Device Descriptor)로 기술한다. 다시 말해, 상기 팩터 데이터 베이스(170)는 로봇이 가지고 있는 각 장치들, 예를 들어 카메라, 모터, 스피커, 마이크, 각종 센서에 대한 정보를 XML 형태로 기술하여 저장한다. 이하에서는 팩터 데이터 베이스(170)의 설정 파일의 구체적인 구성에 대해 살펴보도록 한다.

팩터 데이터 베이스(170)의 설정 파일은 'Product', 'Part', 'Config'의 3 부분으로 분리하여 작성될 수 있다.

상기 'Product' 부분은 로봇의 하드웨어적인 정보를 포함하고 있는 부분으로서, 로봇을 구성하는 하드웨어의 각 회사, 제품명 등에 관한 정보를 설정할 수 있다.

또한 상기 'Part' 부분은 상기 'Product' 부분에 포함된 정보 이외에 프로그 램에서 사용되는 설정 정보를 포함할 수 있다. 즉, 실제 로봇을 구성하는 장치들로서의 하드웨어적인 특성은 'Product'에서 설정될 수 있으며, 그 이외의 설정은 'Part'에서 기술될 수 있다.

그리고 상기 'Config'는 로봇의 각 부분의 기계적 연결 관계를 나타낸다. 예를 들어 양팔, 휠, 머리로 이루어진 로봇이 있다면, 양팔에는 모터가 1개씩 부착되어 있고, 휠은 모터가 2개로 구성되며, 머리의 움직임도 '상하'와 '좌우'의 두 가지 움직임이 존재할 수 있으므로 2 개의 모터로 구성된다는 것을 계층적 구조로 나타낸 것이 바로 'Config'이다.

이하 구체적인 예를 들어 팩터 데이터 베이스(170) 설정 파일을 설명하도록 한다.

우선, 'Product' 설정에 대해 살펴보기로 한다.

[표 1]

<MOTOR> <NAME>MOTOR1</NAME> <COMPANY>SAMSUNG</COMPANY> <MAX_ANGLE>1800</MAX_ANGLE> <MIN_ANGLE>-450</MIN_ANGLE> <MAX_SPEED>6500</MAX_SPEED> <ANGLE_TOLERANCE>100</ANGLE_TOLERANCE> <SPEED_TOLERANCE>100</SPEED_TOLERANCE> <ACC_INTERVAL>5</ACC_INTERVAL> <DCC_INTERVAL>5</DCC_INTERVAL> </MOTOR>

상기 표 1은 '모터 Product'를 설정한 실시예이다. 'PRODUCT' 이름은 'MOTOR1'이고, 상기 'MOTOR1'에 대한 회사('<COMPANY>' 참조), 최대 이동 각('<MAX_ANGLE>' 참조), 최소 이동각('<MIN_ANGLE>' 참조), 최대 이동 속도('<MAX_SPEED>' 참조), 각도 허용 오차('<ANGLE_TOLERANCE>' 참조), 속도 허용 오차('<SPEED_TOLERANCE>' 참조) 등의 'MOTOR1'이라는 이름의 모터의 특성을 기술한다.

다음으로 'Part' 설정에 대해 살펴보기로 한다.

[표 2]

<DEFAULT_CONFIG> <CALL_METHOD>VMQ</CALL_METHOD> <QUEUE_NAME>DD_Q</QUEUE_NAME> </DEFAULT_CONFIG> <INSTALLED_MOTOR> <NAME>D_MOTOR_HEAD_PAN</NAME> <PRODUCT_NAME>MOTOR1</PRODUCT_NAME> <OFFSET>1080</OFFSET> <DIRECTION>RIGHT</DIRECTION> </INSTALLED_MOTOR>

상기 표 2는 실제 로봇에 장착되는 모터에 대한 설정 정보를 포함하고 있다. 로봇에는 여러 개의 모터가 서로 다른 위치에 설치될 수 있다. 이 때 설치되는 모터의 종류를 'PRODUCT'에서 정의한 모터를 사용하고('<PRODUCT_NAME>' 참조), 설치된 모터의 실제 이름('<NAME>' 참조), 설정 값('<OFFSET>', '<DIRECTION>' 참조)에 관한 설정을 포함한다.

또한 상기 'Part' 설정은 RFC(120)와 GDA(155)와의 연결 방법을 정의할 수 있는데, 이하 이에 대하여 기술하기로 한다.

RFC(120)와 GDA(155)의 연결 방법에는 VMQ(135)를 이용하여 연결하는 방법과 직접 연결하는 방법이 있다. 만약, 데이터의 즉시성 즉 실시간적인 측면이 중요하다면, 예를 들어 근접 센서(PSD 센서 등)와 같은 센서 정보를 가장 빠르게 수신해 야 하고, 로봇 서비스 어플리케이션과 GDA(155)가 모두 한 시스템에서 동작되는 시스템인 경우에는 GDA(155)로의 접근 방식을 VMQ(135)가 아닌 직접 연결 방식으로 설정할 수 있다. 상기와 같이 직접 연결 방식이 설정되면 VMQ를 사용하지 않으므로 데이터의 즉시성을 만족시킬 수 있다.

상기의 표 2의 실시예에서는 RFC(120)와 GDA(155)와의 연결 방법을 공통으로 설정하는 방법 대해서 기술하고 있는데, 이는 VMQ 방식을 사용하고('<CALL_METHOD>' 참조), 사용되는 VMQ의 이름은 'DD_Q'라는 것('<QUEUE_NAME>' 참조)을 알 수 있다.

RFC(120)와 GDA(155)와의 연결 방법을 설정하는 또 다른 실시예는 다음의 표 3와 같다.

[표 3]

<INSTALLED_MOTOR> <NAME>D_MOTOR_HEAD_PAN</NAME> <PRODUCT_NAME>MOTOR1</PRODUCT_NAME> <OFFSET>1080</OFFSET> <DIRECTION>RIGHT</DIRECTION> <CALL_METHOD>VMQ</CALL_METHOD> <QUEUE_NAME>MOTOR_Q</QUEUE_NAME> </INSTALLED_MOTOR>

상기 표 3 의 실시예에서는 RFC(120)와 GDA(155)와의 연결 방법은 VMQ를 사용하고('<CALL_METHOD>' 참조), 'D_MOTOR_HEAD_PAN'라는 파트 ID를 갖는 모터 디바이스를 위해서('<NAME>', '<PRODUCT_NAME>' 참조) 'MOTOR_Q'라는 이름('<QUEUE_NAME>' 참조)의 VMQ를 사용한다는 의미이다.

다시 말해, 본 발명의 실시예에서는 통신 미들웨어로 VMQ를 사용할 것인지 또는 직접 연결 방식을 사용할 것인지 여부는 팩터 데이터 베이스(170)에서 설정되 므로, RFC(120)와 GDA(155)의 연결 방법을 변경하기 위해 로봇 소프트웨어를 재구성할 필요가 없다.

팩터 데이터 베이스 설정 파일은 로봇의 하드웨어 디바이스 구성 정보를 포함하고, 또한 RFC(120)와 GDA(155)의 연결 방법을 설정할 수 있다. 이로 인하여 로봇 서비스 어플리케이션과 로봇 하드웨어에 의존적인 하위 소프트웨어 모두 상기 팩터 데이터 베이스를 참조하여 로봇에 설치된 상기 디바이스에 대한 스펙 및 RFC(120)와 GDA(155)의 연결 방법 등을 알 수 있다. 따라서 사용자는 로봇의 하드웨어 디바이스마다 서로 다른 VMQ(135)를 지정할 수도 있고, 또는 동일한 VMQ(135)를 사용하여 복수의 디바이스를 상호 연결할 수도 있다. 이는 상기에서와 같이, 팩터 데이터 베이스 설정 파일에서 RFC(120)와 GDA(155)의 연결 방법을 설정함으로써 해당 시스템에 적합한 VMQ(135)를 설정할 수 있다.

다음으로 'Config' 설정에 대해 살펴보기로 한다.

[표 4]

<CONFIG> <TYPE>POLARIS</TYPE> <CONFIG_HEAD> <PAN>D_MOTOR_HEAD_PAN</PAN> <TILT>D_MOTOR_HEAD_TILT</TILT> </CONFIG_HEAD> <CONFIG_LEFT_ARM> <ITEM>D_MOTOR_ARM_LEFT</ITEM> </CONFIG_LEFT_ARM> <CONFIG_RIGHT_ARM> <ITEM>D_MOTOR_ARM_RIGHT</ITEM> </CONFIG_RIGHT_ARM> <CONFIG_WHEEL> <LEFT>D_MOTOR_WHEEL_LEFT</LEFT> <RIGHT>D_MOTOR_WHEEL_RIGHT</RIGHT> </CONFIG_WHEEL> <CONFIG_PSD> <ITEM>D_PSD</ITEM> </CONFIG_PSD> <CONFIG_PIR> <ITEM>D_PIR</ITEM> </CONFIG_PIR> <CONFIG_BATTERY> <ITEM>D_BATTERY</ITEM> </CONFIG_BATTERY> </CONFIG>

상기 표 4의 실시예에서는 POLARIS라는 로봇('<TYPE>POLARIS</TYPE> ' 참조)이 머리('<CONFIG_HEAD> ' 참조), 왼 팔('<CONFIG_LEFT_ARM> ' 참조), 오른 팔('<CONFIG_RIGHT_ARM> ' 참조), 휠('<CONFIG_WHEEL> ' 참조), 센서('<ITEM>D_PSD</ITEM> 및 <CONFIG_PIR> ' 참조), 및 배터리('<CONFIG_BATTERY> ')로 구성되어 있다는 것을 계층적 구조로 기술하고 있음을 알 수 있다.

도 2a 및 도 2b는 본 발명의 실시예에 따른 GRIS(General Robot Infra Structure)를 구성하는 각각의 구성 요소들간의 연결 관계 및 상기 GRIS를 이용하는 경우 로봇 서비스 어플리케이션(105)이 로봇 하드웨어(180)에 서비스를 호출하고, 이에 따른 데이터를 교환하는 과정을 개략적으로 나타내는 도면이다.

본 발명의 실시예에 따른 VMQ(135)는 도 2a에서 보여지는 바와 같이 RFC(120)의 각 클래스에 대해(로봇의 구성 장치에 따라) 공통의 VMQ를 사용할 수 있지만, 본 발명의 또 다른 실시예에 따르면 도 2b에서 보여지는 바와 같이 RFC(120)의 각 클래스에 대해 별도의 지정된 VMQ를 사용할 수도 있다.

이하에서는, 본 발명의 실시예에 따른 GRIS(General Robot Infra Structure)를 구성하는 각각의 구성 요소들간의 연결 관계를 기술하도록 한다.

사용자는 로봇 서비스 어플리케이션(105)를 통하여 RFC(120)에 로봇의 장치(예를 들어, 카메라) 클래스를 생성한다. 도 2a 에서 도시되는 바와 같이 상기 RFC(120)에는 카메라, 사운드, 모터 등에 대한 로봇의 장치 클래스가 각각 생성될 수 있고, 상기 로봇의 장치 클래스에는 이를 식별할 수 있는 식별자인 파트 ID를 포함할 수 있다.

그리고 상기 생성된 RFC(120)의 로봇 장치 클래스가 서비스 프록시(140)에 등록되면, 이와 동시에 서비스 프록시 객체(Service Proxy Object)(210)가 생성되어 로봇 장치 클래스를 식별하는데 필요한 파트 ID와, 상기 파트 ID에 대응하는 서비스 프록시 객체 포인터(서비스 프록시 객체가 저장된 메모리 주소)에 관한 정보가 서비스 프록시 객체 테이블에 등록된다. 그러면 상기 서비스 프록시(140)는 상기 서비스 프록시 객체 테이블에서 주어진 파트 ID를 검색하고, 이에 대응되는 서비스 프록시 객체(210)를 확인하여, 확인된 서비스 프록시 객체(Service Proxy Object)(210)에 서비스를 요청한다. 그러면 상기 요청을 수신한 서비스 프록시 객체(Service Proxy Object)(210)는 팩터 데이터 베이스(170)에서 파트 ID에 대응되 는 VMQ(135)를 확인하고, 해당 VMQ(135)에 파트 ID, 서비스 이름 등에 관한 정보를 포함하는 함수 호출 메시지를 생성하여 저장한다. 이 경우 상기 함수 호출 메시지에 포함된 정보는 함수 이름(서비스 이름), 입력 버퍼 주소, 입력 버퍼 크기, 출력 버퍼 주소, 리턴 형태(함수만 호출하는지 또는 결과 값을 가져올 것인지 여부에 대한 옵션 등), 타임 아웃 시간(이 시간내에 응답이 없으면 에러 처리), 메시지 타입, 쓰기 모드(기존 메시지를 삭제하고 쓸 것인지 또는 기존 메시지를 저장하고 쓸 것인지 여부)가 될 수 있다.

그러면 서비스 디스패쳐(145)는 상기 VMQ(135)에 저장된 함수 호출 메시지를 수신하여 파트 ID 및 서비스 이름을 확인하여 RFC(120)에서 호출된 함수에 대응되는 함수를 GDA(155)에서 검색하여 해당 함수를 실행시킬 수 있다.

또한 상기 서비스 디스패쳐(145)는 상기 호출에 대한 응답 결과를 메시지 형태로 변환하여 VMQ(135)를 통하여 RFC로 전달할 수 있다.

또한, 도 2a에서 보여지는 이벤트 프록시(220)는 로봇 하드웨어(180)에서 주기적으로 획득되는 데이터를 RFC(120)로 전송하기 위해 사용된다.

상기와 같은 내용을 로봇 서비스 어플리케이션(105)이 로봇의 카메라 디바이스를 사용하는 구체적인 예를 들어 도 2a에 도시된 VMQ(135)를 통한 RFC(120)와 GDA(155)간 데이터 교환 및 서비스 호출 관계를 설명하도록 한다.

이 경우 도 2a의 RFC(120)의 역할은 사용자에 의해 작성된 GRI 스터브(125)에 대해서 동일하게 적용되며 또한, 도 2a의 GDA(155)의 역할은 사용자에 의해 작성된 GRI 스켈레톤(160)에 대해서도 동일하게 적용된다.

먼저, 로봇 서비스 어플리케이션(105)에서 카메라 인터페이스를 실행시키려면, GDA(155)에서 해당 카메라 인터페이스의 구현을 서비스로 등록하고 있어야 한다. 따라서, 전체 흐름을 설명하기 위해서 우선, GDA(155)에서 로봇의 카메라 디바이스를 사용할 수 있도록 실제 카메라 서비스 함수를 등록하는 과정을 설명하도록 한다.

이를 위해서는 우선 로봇 하드웨어(180) 구현 부분에서 카메라 GDA 인터페이스를 이용하여 카메라 제어 클래스를 생성해야 하는데, 카메라 제어 클래스는 다음의 표 5와 같이 정의할 수 있다.

[표 5]

Class MyCamera : public CntrCamera { public: int onSetProperty(const GRIS::CAMERA_PROPERTY &); int onGetProperty(GRIS::CAMERA_PROPERTY &); int onStartCapture(); int onStopCapture(); int onTakePicture(IMAGE_DATA &); int onOpenCamera(); int onCloseCamera(); int onSetFrameRate(int rate); }

'MyCamera' 클래스는 GDA 인터페이스인 'CntrCamera'를 상속받아 구현된다. 그러면 GRIS에서 제공하는 카메라 인터페이스인 'onTakePicture(IMAGE_DATA &)' 등을 구현하면 된다. 이와 같이 생성된 'MyCamera' 클래스를 이용하여 작성한 'onTakePicture' 등의 함수들을 등록하기 위해서는 다음의 표 6과 같은 순서로 GDA 인터페이스를 구현해야 한다.

[표 6]

MyCamera * m_MyCamera = new MyCamera("D_CAMERA_FRONT"); // (1) m_MyCamera->activate(); // (2) enableRunningEnv(); // (3)

상기 표 6에서 (1)의 경우에 'MyCamera' 인스턴스를 생성할 시에 인자로 "D_CAMERA_FRONT"라는 문자열을 주어야 하는데, 이것이 m_MyCamera 클래스가 사용하는 파트 ID가 되고, 이 파트 ID는 팩터 데이터 베이스(170) 설정 파일에 기술되어 있어야 한다. 팩터 데이터 베이스(170)에 설정된 카메라 정보의 예는 다음의 표 7과 같다 .

[표 7]

<INSTALLED_CAMERA> <NAME>D_CAMERA_FRONT</NAME> <= 파트 ID <PRODUCT_NAME>CAMERA1</PRODUCT_NAME> <CALL_METHOD>VMQ</CALL_METHOD> <= callMethod <QUEUE_NAME>FRONT_CAMERA_Q</QUEUE_NAME> <= VMQ 이름 </INSTALLED_CAMERA>

이 경우, 상기 파트 ID를 토대로 모든 VMQ 관련 실행을 하게 된다. 상기 파트 ID와 함께 설정된 VMQ 이름('<QUEUE_NAME>' 참조), CallMethod(VMQ를 사용하는지 또는 직접 호출을 사용하는지), 지정된 파트에 설정된 설정값 등을 팩터 데이터 베이스(170)로부터 획득할 수 있다.

표 6에서 (2)에서는 'activate()' 함수를 실행하게 되는데, 상기 함수를 실행시키면 카메라 GDA가 제공하는 인터페이스에 대한 서비스 디스패쳐 함수들을 등 록하게 된다. 여기서는 내부적으로 'registServiceDispatcher'함수를 이용하여 해쉬 테이블에 서비스 이름과 그에 대응하는 서비스 디스패쳐 함수를 등록하게 되는데, 이는 다음의 표 8에서 보여지는 서비스 디스패쳐 테이블과 같다.

[표 8]

svc(서비스 이름 : 문자열)	disp(서비스 디스패쳐 함수 : 함수 포인터)
"onSetProperty"	_COnSetProperty(this) 클래스의 인스턴스 포인터
"onTakePicture"	_COnTakePicture(this) 클래스의 인스턴스 포인터
- -	- -

상기 표 8에서 'svc' 문자열은 GRIS 내부에서 미리 정의되어 있으며, 'disp(디스패쳐 클래스)' 또한 미리 정의되어 있다. '_COnSetProperty(this)'의 'this'는 'MtCamera' 클래스의 인스턴스 포인터이다.

다시 말해, 상기 표 6의 (1)에서 GDA 인터페이스를 상속받아 클래스 객체를 생성하고, (2)에서 상기 생성된 클래스 객체의 'activate()' 함수를 실행하면, 작성한 클래스의 서비스 함수들을 서비스 디스패쳐(145)에서 관리하는 서비스 디스패쳐 테이블(표 8)에 등록하는 것이다.

또한, (2)에서 내부적으로 실행되는 오퍼레이션에는 카메라의 파트 ID("D_CAMERA_FRONT")와 해당 클래스 객체(구현된 'MyCamera' 클래스)의 포인터를 해쉬 테이블에 등록하는데, 상기 해쉬 테이블은 다음의 표 9과 같다.

[표 9]

파트 ID(문자열)	GDA 구현 클래스의 포인터
"D_CAMERA_FRONT"	CMyCamera 클래스의 인스턴스 포인터
"D_SOUND"	CMySound 클래스의 인스턴스 포인터
- -	- -

또한, 'MyCamera' 클래스의 파트 ID("D_CAMERA_FRONT")에 대한 CallMethod 방식을 팩터 데이터 베이스(170)로부터 조회하고, VMQ(135) 사용시 VMQ 메시지 전달을 위한 공유 메모리를 만든다.

따라서, 서비스 디스패쳐(145)는 파트 ID의 문자열과 'svc(서비스 이름)'의 문자열을 통해서 RFC(120)에서 전달받은 메시지에서 지정한 파트 ID 및 서비스 이름을 분석하여 이에 대응하는 서비스 함수를 확인하여 실행할 수 있다.

상기 표 6의 (3)에서 실행되는 'enableRunningEnv()' 함수는 팩터 데이터 베이스(170)를 조회하여 VMQ(135)를 이용하는 모든 장치에 대하여 대응하는 VMQ(135)들을 오픈하고, 각 VMQ(135)에 대한 메시지를 받아 처리할 수 있도록 쓰레드를 형성한다. 상기 형성된 쓰레드, 예를 들어 카메라의 VMQ(135)의 메시지를 처리하는 쓰레드는 VMQ 메시지가 전달되는 것을 감지하여 내부적으로 '_execEntryFunc()' 함수를 호출한다. 상기 함수가 호출되면 서비스 디스패쳐 테이블(표 8)에서 대응되는 함수를 찾아내어 이를 실행시킨다.

상기와 같은 과정에 의해 GDA(155)에 카메라 객체가 생성된 경우, RFC(120)에서는 다음과 같은 과정에 의해 GDA(155)에 등록된 서비스를 호출하여 실행시킬 수 있다.

우선 로봇 서비스 어플리케이션(105)은 카메라에 관한 RFC 클래스를 생성해야 하는데, 생성하는 과정은 다음의 표 10과 같다.

[표 10]

initVMQ("Polaris"); // (1) CAbsCamera *camera = new CImplBasicCamera("D_CAMERA_FRONT"); // (2) camera->attach(); // (3) IMAGE_DATA image; camera->takePicture(image); // (4)

상기 표 10의 (1)에서 실행되는 'initVMQ("Polaris")' 함수는 GRIS를 사용하는 모든 어플리케이션에서 VMQ(135)를 사용하기 위해 반드시 실행시켜야 하는 부분으로, VMQ(135) 설정파일에서 설정한 VMQ들을 생성하기 위한 공유 메모리를 초기화 한다. 'initVMQ' 함수의 인자는 임의의 문자열을 받을 수 있다.

그리고 (2)에서는 RFC(120)를 이용하여 카메라 객체를 생성하는 부분이다. 여기서도 GDA(155)와 마찬가지로 카메라 RFC(120) 클래스의 인자로 문자열인 파트 ID("D_CAMERA_FRONT")를 입력해야 한다. 이 경우 역시, "D_CAMERA_FRONT"는 팩터 데이터 베이스(170) 설정파일에 설정되어 있어야 하며, 연결하고자 하는 GDA(155)단의 구현 클래스의 파트 ID와 동일해야 한다. 본 발명의 실시예에서는 'MyCamera'의 생성 시 설정했던 "D_CAMERA_FRONT"를 사용해야, 여기서 생성한 카메라 인스턴스의 함수 호출을 'MyCamera'에 등록된 GDA(155)의 서비스 함수로 연결할 수 있다.

(3)의 'attach' 함수는 카메라 클래스의 서비스 프록시 객체(Service Proxy Object)를 생성하고, 또한 생성된 서비스 프록시 객체(Service Proxy Object)를 파트 ID에 대응되도록 서비스 프록시 객체 테이블에 등록하는데, 상기 서비스 프록시 객체 테이블(Service Proxy Object Table)은 다음의 표 11과 같다.

[표 11]

파트 ID	서비스 프록시 객체 포인터
"D_CAMERA_FRONT"	CPartPortal("D_CAMERA_FRONT")의 인스턴스 포인터
"D_SOUND"	CPartPortal("D_SOUND")의 인스턴스 포인터
- -	- -

상기 표 11와 같이 서비스 프록시 객체(Service Proxy Object)가 생성 및 등록이 되면, 표 10의 (4)에서 'takePicture'를 실행함으로써 카메라 클래스에서 등록된 서비스를 호출할 수 있다. 즉, 'camera->takePicture(image)'를 실행하면 내부적으로 다음의 표 12과 같은 함수가 실행된다.

[표 12]

int GRIS::CImplBasicCamera::takePicture( IMAGE_DATA &image) { CParameter in; UBuffer out; int result = requestService(CCameraMethods::takePicture.c_str(), in.base(), in.size(), out, true); image.unpack(out.buffer(), out.bufsize()); return result; }

상기 표 12의 'requestService' 함수의 인자를 보면, 'CCameraMethods::takePicture.c_str()' 이 포함되어 있는데, 이는 GRIS 내부에서 카메라 클래스의 인터페이스로 미리 정의되어 있는 'takePicture'라는 함수를 나타내는 문자열로써, 실제로 'takePicture'라는 문자열 값이다. 이에 따라 'camera->takePicture'라는 함수의 호출은 'requestService'에 'TakePicture'라는 문자열을 설정하는 것이다. 그러면 'requestService'는 내부적으로 표 11의 서비스 프록시 객체 테이블에서 카메라에 설정된 파트 ID("D_CAMERA_FRONT")를 검색하고, 이에 대응되는 서비스 프록시 객체(Service Proxy Object)를 찾아서 서비스를 요청한다. 그러면 카메라에 대응되는 서비스 프록시 객체(Service Proxy Object)는 팩터 데이터 베이스에서 파트 ID에 대응되는 VMQ(135)를 검색하고, 해당 VMQ(본 발명의 실시예에서는 카메라 VMQ)에 파트 ID("D_CAMERA_FRONT")와 'TakePicture'라는 서비스 이름, 그리고 필요한 파라미터들을 저장하는 함수 호출 메시지를 생성한다.

상기 함수 호출 메시지가 생성되면, 서비스 디스패쳐(140)에서 카메라 VMQ에 함수 호출 메시지가 생성된 것을 감지하고 상기 메시지를 수신하여 내부적으로 '_execEntryFunc()'를 호출한다. 그러면 상기 '_execEntryFunc()'는 상기 표 8 및 표 9에서 대응되는 GDA 구현 클래스의 포인터와 서비스 디스패쳐 함수를 실행하게 된다.

상기에서 본 발명의 또 다른 실시예로서 RFC(120)와 GDA(155)와의 연결 방법에는 VMQ(135)를 사용하는 방법과 직접 연결하는 방법이 가능함을 기술하였다. 이 경우, VMQ(135)를 사용할지 또는 직접 연결 방식을 사용할지 여부를 설정하는 부분은 팩터 데이터 베이스(170)의 설정에 따라 달라진다.

다시 말해, RFC(120)에서 GDA(155)로의 함수 호출에 있어서 함수 호출 메시지를 생성하거나 함수를 호출하는 부분은 서비스 프록시(140)와 서비스 디스패쳐(145)에서 이루어지는데, 이하 상세하게 설명하도록 한다.

상기 표 10에서 'camera->takePicture'를 실행하면 내부의 'requestServeice' 함수를 호출하고, 'requestServeice' 함수의 내부 구현은 서비스 프록시 객체에 구현되어 있다. 따라서, 'requestServeice'에서 팩터 데이터 베 이스(170)를 조회하여 해당 파트 ID의 'call method'가 VMQ(135)이면 VMQ 함수 호출 메시지를 생성하는 함수를 호출하며, 'call method'가 직접 연결일 경우에는 상기 표 9의 해쉬 테이블을 참조하여 GDA(155)에서 생성된 파트 ID에 대한 클래스 인스턴스의 포인터를 직접 사용할 수 있다. 또한, 직접 연결일 경우에 해당 파트 ID에 등록된 서비스 디스패쳐 함수를 표 8의 서비스 디스패쳐 함수 테이블에서 검색하여 이를 내부의 'runDispatcher' 함수를 이용하여 실행시킬 수 있다.

도 3a 내지 도 3c는 로봇 서비스 어플리케이션과 로봇 하드웨어 의존적 하위 소프트웨어를 연결 시켜주기 위한 VMQ(135)의 3 가지 동작을 설명하는 도면이다.

우선 도 3a는 VMQ(135)의 데이터 교환 기능(Data Driven Processing)을 설명하는 도면이다. VMQ(135)는 로봇 서비스 어플리케이션과 로봇 하드웨어 의존적 소프트웨어의 연결에 있어서, 양 단 간의 데이터 교환 기능을 수행할 수 있다. 본 발명의 일 실시예에 따르면 도면에 도시된 peer1은 로봇 서비스 어플리케이션이 될 수 있고, peer2는 로봇 하드웨어 의존적 소프트웨어가 될 수 있다. VMQ(135)는 로봇 서비스 어플리케이션과 로봇 하드웨어 의존적 소프트웨어의 양 방향으로 데이터를 읽고 쓸 수 있다.

도 3b는 VMQ(135)의 서비스 콜 프로세싱(Service Call Processing)을 설명하는 도면이다. 본 발명의 실시예에서, 로봇 서비스 어플리케이션에서 RFC(120)의 함수를 호출하면 VMQ(135)는 상기 RFC(120)의 함수에 대응하는 실제 하드웨어 의존적 소프트웨어의 함수를 GDA(155)에서 호출하여 준다.

도 3c는 VMQ(135)의 객체 세션 프로세싱(Object Session Processing)을 설명 하는 도면이다.

VMQ(135)는 로봇 서비스 어플리케이션에서 실제 하드웨어 의존적 소프트웨어의 객체 아이디(Object ID)를 획득하여 객체(Object)의 함수를 실행시킬 수 있다.

상기 객체 세션 프로세싱은 상기 서비스 콜 프로세싱과 마찬가지로 GDA(155)에서 구현된 인터페이스를 실행하는 것은 외부 동작상으로는 차이점이 없다. 다시 말해, 상기 객체 세션 프로세싱은 이미 구현된 RFC(120)를 사용하면 되므로, RFC(120)를 이용한 상위 레벨 어플리케이션을 작성할 때는 서비스 콜 프로세싱과 차이점이 없다.

그러나 객체 세션 프로세싱과 서비스 콜 프로세싱은 내부 동작에서 차이점이 있다. 즉, 서비스 콜 프로세싱 방식은 GDA(155)에서 구현된 클래스의 아이디를 참조하지 않고 VMQ 메시지를 생성하는 반면, 객체 세션 프로세싱은 GDA(155)에서 구현된 클래스의 아이디를 참조하여 이를 바탕으로 VMQ 메시지를 생성한다. 다시 말해, 상기 객체 세션 프로세싱은 GDA(155)의 특정 객체(클래스)를 지칭하여 상기 객체가 지원하는 함수를 사용를 사용하도록 지정할 수 있는 것이다. 상기 객체 세션 프로세싱은 GDA(155)에서 서로 다른 두 개의 클래스가 같은 이름의 서비스로 등록된 경우, 이를 구별하기 위해 특정 클래스의 함수를 직접 지정할 수 있도록 객체 아이디를 참조하고, VMQ 메시지에도 이를 포함하여 보내게 된다.

그러면 이하에서는 VMQ(135)의 구성 파일에 대해 상세히 기술하도록 한다.

VMQ 구성 파일은 '.cfg' 파일로 작성될 수 있으며, 로컬 프로파일(이하 'LOCAL_PROFILE')과 서버 정보(이하 'SERVER INFO') 부분으로 구성될 수 있다. 본 발명의 실시예에 따른 VMQ(135)를 사용하는 경우 내부적으로 GDA(155)를 개념상 서버로, RFC(120)를 클라이언트로 가정할 수 있다. 따라서 로봇 서비스 어플리케이션 개발자는 RFC(120)를 클라이언트 인터페이스와 같이 사용하여 GDA(155)에 임의의 서비스를 요청하고, 그 서비스의 수행 결과를 리턴 받는 형식으로 동작된다. 다시 말해, 특정 로봇 하드웨어에 접근하기 위해서는 상기 특정 디바이스에 지정된 특정 VMQ(135)를 통해서 서비스를 받는 방식이 되는 것이다. 본 발명의 일 실시예에 따른 VMQ(135) 구성 파일에 대한 본 발명의 일 실시예는 아래의 표 13a 및 표 13b와 같다.

[표 13a]

[LOCAL-PROFILE] <LOG-ATTR> WRITE = @YES FORWARD = @YES FWRDPORT = 5077 DMQTYPE = @IPC IPCKEY = 0x5077 MAXSLOT = 500 FILEPATH = D:\2007_hsh\SVN_GRIS\GRIS_PRJ\bin\win32\release FILESZ = 100 FILECNT = 7 </LOG-ATTR> <GLB-ATTR> VMQSERVER = VMQCOMPMGR = VMQLOGD = "D:\2007_hsh\SVN_GRIS\GRIS_PRJ\bin\win32\release\vmqlogd.exe" VMQAGENT = "D:\2007_hsh\SVN_GRIS\GRIS_PRJ\bin\win32\release\vmqagent.exe" QBRDTYPE = @IPC QBRDKEY = 0x5777 </GLB-ATTR> </GLB-ATTR> [/LOCAL-PROFILE]

[표 13b]

[SERVER-INFO] SERVERNAME = ANYROBOT2 SERVERPATH = /root/pol2 IPADDR = 127.0.0.1 PORT = 30000 PROTOCOL = @TCP DMQTYPE = @PIPE <QUEUE-INFO> QUEUENAME = TTSFWRD_Q IPCKEY = 0x06000 MAXSLOT = 1000 DLLPATH = NUMQTHREAD = 1 DOWNLOAD = @NO STARTUP = @NO </QUEUE-INFO> ..... [/SERVER-INFO] [SERVER-INFO] SERVERNAME = IMAGE SERVERPATH = /root/pol2 IPADDR = 127.0.0.1 PORT = 30001 PROTOCOL = @TCP DMQTYPE = @PIPE <QUEUE-INFO> QUEUENAME = FRONT_CAMERA_Q IPCKEY = 0x06018 MAXSLOT = 3000 DLLPATH = NUMQTHREAD = 1 DOWNLOAD = @NO STARTUP = @NO </QUEUE-INFO> <QUEUE-INFO> QUEUENAME = TOP_CAMERA_Q IPCKEY = 0x06019 MAXSLOT = 10000 DLLPATH = NUMQTHREAD = 1 DOWNLOAD = @NO STARTUP = @NO </QUEUE-INFO> [/SERVER-INFO]

상기 표 13a 및 표 13b는 연속되는 소스코드이다. 상기 표 13a에 도시된 VMQ(135) 구성 파일에서 'LOCAL PROFILE'은 '[LOCAL-PROFILE]'로 시작하여 '[/LOCAL-PROFILE]'로 설정이 종료된다. 또한 상기 'LOCAL PROFILE'은 로깅 설정 부분인 '<LOG-ATTR>'과 글로벌 설정 부분인 '<GLB-ATTR>'로 구성된다. 본 발명의 실시예에 따른 VMQ 구성 파일에 상기 'LOCAL PROFILE'은 1 개만 존재할 수 있다.

상기 표 13에 기재된 VMQ 구성 파일에서, 'Server Information'은 VMQ 정보를 서버 단위로 관리하고자 하는 것이다. 'SERVER-INFO'는 SERVER 속성과 VMQ 설정 정보인 '<QUEUE-INFO>'로 구성된다. 상기 'SERVER-INFO'는 VMQ 구성 파일 내에 복수 개로 존재할 수 있다. 본 발명의 실시예에서는 2 개의 'SERVER-INFO'가 기술되어 있고 그 내용은 아래의 표 14과 같다.

[표 14]

SERVERNAME : 서버명 SERVERPATH : 서버 PATH IPADDR : 서버 IP 주소. 로컬일 경우기재하지 않거나 0.0.0.0 또는127.0.0.1 를 입력 PORT : VMQ Agent 의 포트 번호 PROTOCOL : 현재 @TCP 만지원 DMQTYPE : VMQ 의 메모리 타입

상기 'SERVER-INFO'의 'IPADDR'는 RFC(120)와 GDA(155)가 서로 다른 네트워크 상에 연결된 다른 시스템일 경우, 상기 VMQ(135)가 원격 수행을 수행하기 위함이다. 이 경우, 상기 'IPADDR'에는 서버로 동작할 시스템의 IP address를 지정할 수 있다.

그리고 하나의 'SERVER'에 대해서는 복수 개의 VMQ(135)를 설정할 수 있는 데, '<QUEUE-INFO>'에서 기술할 수 있는 내용은 아래의 표 15과 같다.

[표 15]

QUEUENAME : VMQ 네임 IPCKEY : VMQTYPE 이 @IPC 일경우 메모리 KEY 값 MAXSLOT : 최대 메시지 슬랏 DLLPATH : 사용자 shared object path NUMQTHREAD : 최대 쓰레드 개수 DOWNLOAD : 다운로드 여부 STARTUP : VMQ server 에 의하여 자동 실행 여부

상기 표 15에서 보여지는 바와 같이, 각 로봇 하드웨어 디바이스에 접근하기 위한 VMQ 설정은 다양하게 구성될 수 있다.

본 발명의 또 다른 실시예에 따르면 VMQ(135)를 디바이스별로 설정할 수도 있고 또는 모든 디바이스에 대한 공통의 VMQ(135)를 설정할 수도 있다. 다시 말해, 적은 양의 빠른 데이터들이 교환될 필요가 있고 데이터의 일관성 유지가 필요하다면, 각 디바이스마다 VMQ(135)를 별개로 설정할 수 있다. 그러나 이와 반대로 데이터의 교환 주기가 길고, 빈번하게 발생하지 않는다면 VMQ(135)를 별도로 설정하지 않고 하나의 VMQ(135)를 공유하여 사용할 수 있다.

이에 관한 설정은 상기 팩터 데이터베이스(170)의 설정파일에서 'PART'의 해당 디바이스 속성에서 VMQ의 이름('<QUEUE_NAME>' 참조)을 명시하지 않으면 해당 디바이스에 대해서는 공통의 VMQ를 사용하게 된다.

도 4는 본 발명의 실시예에 따른 GRIS에 구현된 RFC(120)와 GDA(155)의 구조를 나타내는 도면이다.

도 4에 도시된 'CComponent(405)'와 'CEventListener(410)', 'CEventObject(415)' 클래스들이 실질적으로 로봇 서비스 어플리케이션 개발자들이 사용하는 RFC(120)이며, 'CGrisDriverAdapter(420)' 클래스는 로봇 하드웨어 개발자들이 로봇 하드웨어 의존적인 하위 소프트웨어를 구현하기 위해 사용할 수 있는 GDA(155)이다.

본 발명의 일 실시예에 따르면, RFC(120)의 'CAbsCamera::takePicture()'라는 함수(425)를 호출하면 'takePicture()' 함수는 내부적으로 VMQ(135)를 통해서 GDA(155)의 'CCntrCamera::onTakePicture()' 라는 함수(430)를 호출하게 된다.

또한, 본 발명의 또 다른 실시예에 따르면, 'CEventListener(410)'를 사용하여 GDA(155)로부터의 주기적 데이터 또는 이벤트 데이터를 RFC(120)에서 이벤트 방식으로 수신할 수 있다.

예를 들어, 카메라의 경우 'CAbsCamara::startCapture()' 함수(425)를 호출하게 되면, 'CCntrCamera::onStartCapture()' 함수(430)에서 카메라 이미지를 캡쳐하는 쓰레드를 실행하면서 캡쳐가 발생할 때마다 , 획득한 카메라 이미지를 RFC(120)에 연속적으로 전송하게 된다. 그러면 RFC(120)에서는 'CCameraListener(435)'를 등록하여 상기 캡쳐된 카메라 이미지를 전달받을 수 있다.

이하에서는 로봇에 설치된 카메라를 이용하여 사진을 획득하는 구체적인 예를 들어, 로봇 서비스 어플리케이션 개발자의 측면에서 RFC(120)를 실제로 사용하는 방법과, 로봇 하드웨어 개발자 관점에서 GDA(155)를 실제로 구현하는 방법을 설명하기로 한다.

우선, 로봇 서비스 어플리케이션 개발자가 로봇에 설치된 카메라 장치를 제어하기 위해서는 로봇 서비스 어플리케이션에서 사용할 카메라 객체를 생성하는 제1 단계, 상기 생성된 카메라 객체를 서비스 프록시(140)에 등록하는 제2 단계, 카메라 파라미터를 설정하는 제3 단계, 사진찍기 명령을 실행하는 제4 단계의 절차를 거쳐야 한다. 상기 제1 단계 내지 제4 단계에 대한 구체적인 구현은 아래의 표 16과 같다.

[표 16]

CAbsCamera *camera = new CImplBasicCamera("D_CAMERA"); If( camera->attach() < 0) { printf("service proxy에 attach 안됨"); return false; } CAMERA_PROPERTY property; property.nWidth = 320; property.nHeight = 240; camera->setProperty(property); IMAGE_DATA image; camera->takePicture(image);

우선 개발자는 제1 단계에서 구현 클래스인 'CImplBasicCamera'를 이용하여 어플리케이션에서 사용할 카메라 객체를 생성('CAbsCamera *camera' 참조) 한다. 이 경우 생성자 인수인 'D_CAMERA'에 관한 정보는 팩터 데이터 베이스(170)에 미리 설정되어 있어야 한다. 그리고 제2 단계에서 상기 생성된 카메라 객체가 서비스 프록시(140)에 등록되는데 'camera->attach()'가 상기 등록 절차를 나타낸다. 그리고 제3 단계에서는 카메라의 파라미터를 설정('Ccamera->setProperty' 참조)하게 되는데, 상기 실시예에서는 이미지의 크기를 320*240으로 설정('property.nWidth = 320; property.nHeight = 240' 참조) 하였다. 그러면 제4 단계에서 실질적으로 카메라를 구동시키는 명령을 실행('camera->takePicture' 참조) 하게 된다.

여기서 상기 제3 단계 및 제4 단계의 'setProperty' 와 'takePicture' 함수는 RFC(120)에서 실행되지 않고, GDA(155)의 카메라 구현 클래스인 'onSetProperty' 와 'onTakePicture'에서 실행된다. 이 경우 상기 'onSetProperty' 와 'onTakePicture'는 로봇 하드웨어 개발자에 의하여 GDA(155)로 구현되어야 하는데, 이는 이하에서 살펴보도록 한다.

그 다음으로는 로봇 하드웨어 개발자가 GDA(155)를 실제로 구현하는 방법을 설명하도록 한다. 로봇 하드웨어 개발자가 본 발명의 실시예에 따른 카메라를 제어하는 루틴을 작성하는 방법은 카메라 GDA 인터페이스를 이용하여 카메라 제어 클래스를 생성하는 제1 단계, 카메라를 제어하기 위한 실제 함수를 구현하는 제2 단계, 상기 구현된 카메라 클래스를 생성하여 활성화 시키는 제3 단계를 포함할 수 있다. 상기 제1 단계 내지 제3 단계에 대한 구체적인 구현은 아래의 표 17와 같다.

[표 17]

class CMyCamera : public CCntrCamera { public: int onTakePicture(IMAGE_DATA &); int onOpenCamera(); int onCloseCamera(); }; int CMyCamera::onTakePicture( GRIS::IMAGE_DATA &data ) { _pImage ->capture_scene(); data.img.replace( _pImage->get_jpeg_data() , _pImage->get_jpeg_size() ); data.format = "jpeg"; return 0; } ... MyCamera* GDA_camera = new MyCamera("D_CAMERA_FRONT", ) GDA_camera->activate();

우선, 제1 단계에서 카메라에 관한 GDA 클래스를 상속 받은 사용자 클래스를 선언('class CMyCamera : public CCntrCamera' 참조)한다. 그리고 제2 단계에서 카메라를 제어하기 위한 실제 함수들, 예를 들어 'onTakePicture', 'onOpenCamera', 'onCloseCamera' 등의 함수를 정의된 기능에 맞게 구현하는데, 상기 본 발명의 실시예에서는 'onTakePicture'에 관한 함수('int CMyCamera::onTakePicture' 참조)를 구현하였다. 상기 실시예에서 'onTakePicture' 함수는 지정된 카메라 장치에서 한 장의 이미지를 캡쳐하여 파라미터 이미지 데이터에 저장('( GRIS::IMAGE_DATA &data )' 참조)하도록 설정되었다. 그리고 제3 단계에서 상기 구현된 카메라 클래스를 생성하여 활성화('MyCamera* GDA_camera = new MyCamera("D_CAMERA_FRONT", )' 및 'GDA_camera->activate()' 참조) 시킨다. 이 경우, 상기 활성화 함수 'activate()'는 로봇 하드웨어 개발자가 구현한 실제 카메라 제어 함수('onTakePicture', 'onOpenCamera', 'onCloseCamera' 등)를 서비스 디스 패쳐(145)에 등록하도록 설정한다. 다시 말해, 상기 서비스 디스패쳐(145)에 대한 등록은 로봇 서비스 어플리케이션에서 'camera -> takePicture' 함수가 호출되면, 이에 대한 실질적인 처리는 GDA(155)의 'GDA_camera -> onTakePicture' 함수에서 실행되도록 실제 서비스를 처리하는 함수를 등록한다는 의미이다.

도 5는 본 발명의 또 다른 실시예에 따라, 로봇 서비스 어플리케이션이 GDA(155)와 서로 다른 시스템인 경우, VMQ 에이전트를 이용하여 원격에서 상기 로봇 서비스 어플리케이션과 GDA(155)를 상호 연동시키는 방법을 나타내는 도면이다.

서로 원격에 있는 RFC(120)와 GDA(155)를 연동시키기 위해서 로봇 서비스 어플리케이션 시스템에 존재하는 VMQ(135) 구성 파일에서 'SERVER-INFO'의 'IPADDR'에 GDA(155)로 작동하는 시스템의 IP 어드레스를 지정할 수 있다. 상기와 같은 경우에는 VMQ(135) 기본 설정 이외에 네트워크를 통한 VMQ(135) 상호간의 연결을 구성하기 위해서 별도의 프로세스로 VMQ 에이전트(VMQ agent, 510)를 작동시켜야 한다.

우선, 도 5에 도시된 바와 같이 로봇 서비스 어플리케이션이 개발 시스템(예를 들어, PC)에서 실행되고, 실제 로봇 서비스가 수행되는 GDA(155)는 타켓 시스템(예를 들어, 로봇)에 설치되어 실행된다고 가정한다. 이를 위해서는 상기 개발 시스템과 상기 타켓 시스템에 VMQ가 실행될 수 있는 환경, 즉 GRIS가 설치되어야 하며 서로 다른 시스템에 존재하는 VMQ 상호 간의 원격 연결을 위해서 VMQ 에이전트(510)가 실행되어야 한다. 그러면 상기 VMQ 에이전트(510)는 VMQ의 역할을 TCP/IP 연결을 통해서 원격 연결 역할로 확장시켜 준다.

도 6은 VMQ 에이전트를 이용하여 개발 시스템과 타켓 시스템을 원격에서 연동하는 구체적인 실시예를 나타내는 도면이다.

종래의 TCP/IP를 이용하고, 같은 포트로 서로 다른 데이터가 전송되는 경우에는 상기 서로 다른 데이터간의 우선순위를 지정하여 원하는 목적대로 전송할 수 없다는 문제점이 존재하였다.

상기와 같은 문제점을 해결하기 위해 도 6에 도시된 본 발명의 실시예에 따르면, 데이터양이 많은 카메라 큐(queue) 1(635) 및 카메라 큐 2(640)는 VMQ 에이전트 1(610)을 통하여 타겟 시스템의 카메라 큐 1(635) 및 카메라 큐 2(640)와 연동될 수 있다. 이와 마찬가지로 모터 큐 1(655), 모터 큐 2(660) 및 센서 큐 1(665)는 상기 VMQ 에이전트 1(610)과는 서로 다른 VMQ 에이전트 2(620)를 통하여 타겟 시스템의 모터 큐 1(655), 모터 큐 2(660) 및 센서 큐 1(665)와 연동될 수 있다.

본 발명의 또 다른 실시예에서 상기 VMQ 에이전트는 서로 다른 VMQ 에이전트간의 우선순위 지정이 가능하다. 따라서 도 6의 실시예에서 카메라 큐 1(635) 및 카메라 큐 2(640)의 우선순위 및 모터 큐 1(655), 모터 큐 2(660), 센서 큐 1(665)의 우선순위 지정이 가능하다.

도 7은 본 발명의 실시예에 따른 실제 로봇 서비스 어플리케이션이 실행되면서 RFC(120)를 호출하고 이에 따라 GDA(155)를 구현한 드라이버가 실행되는 경우, RFC(120)에서 상기 호출이 실행되는 과정을 나타내는 순서도이다.

우선, S710 단계에서 로봇 서비스 어플리케이션에서 사용할 로봇의 특정 장 치(예를 들어 카메라, 센서 등)에 대한 RFC 객체를 생성한다. 이 경우 상기 로봇의 특정 장치에 관한 RFC 객체에는 이를 식별할 수 있는 식별자인 파트 ID가 포함될 수 있다. 그리고 S720 단계에서 상기 생성된 RFC 객체에 대하여 'attach method' 를 호출하면, 상기 생성된 RFC 객체가 서비스 프록시(140)에 등록된다. 상기 RFC 객체가 서비스 프록시(140)에 등록되면, RFC(120)는 RFC(120)의 서비스 호출 및 서비스 실행에 대한 응답 결과에 대한 데이터를 GDA(155)와 상호 교환할 수 있다. 그리고 S730 단계에서 상기 서비스 프록시(140)는 상기 파트 ID를 이용하여 팩터 데이터 베이스(170)에 저장된 설정 파일에서, 함수 호출 방식 및 상기 RFC 객체에 대해 버스(bus) 역할을 담당하는 VMQ(135)를 조회한다. 그리고 S740 단계에서 파트 ID, 호출되는 함수의 이름, 입력 버퍼 주소, 입력 버퍼 사이즈, 출력 버퍼 주소, 리턴 형태, 타임 아웃 시간, 메시지 타입, 쓰기 모드에 대한 정보를 포함하는 함수 호출 메시지를 생성한다.

그리고 S750 단계에서 상기 생성된 함수 호출 메시지는 지정된 VMQ(135)에 저장된다. 그리고 S760 단계에서 상기 GDA(155)로부터 실행 결과가 수신되었는지 여부를 판단하고, 만약 실행 결과가 수신되었다면 S770 단계에서 로봇 서비스 어플리케이션에 실행 결과를 리턴한다.

도 8은 본 발명의 실시예에 따른 실제 로봇 서비스 어플리케이션이 실행되면서 RFC(120)를 호출하고 이에 따라 GDA(155)를 구현한 드라이버가 실행되는 경우, GDA(155)에서 실제 함수가 실행되는 과정을 나타내는 순서도이다.

우선 S810 단계에서 GDA(155) 클래스에 대한 객체들을 생성한다. 그리고 S820 단계에서 상기 생성된 GDA 클래스 객체들의 활성화(activate) 메소드가 호출되면, 상기 생성된 GDA 클래스 객체들에 대해 서비스 디스패쳐(145)가 생성된다. 그리고 S830 단계에서 상기 서비스 디스패쳐(145)는 RFC(120)으로부터 함수 호출 메시지가 수신되었는지 여부를 판단하여, 만약 함수 호출 메시지가 수신되었다면 수신한 함수 호출 메시지를 S840 단계에서 분석한다. 그리고 S850 단계에서 RFC 단에서 상기 함수 호출 메시지에 포함된 파트 ID 및 서비스 함수에 관한 정보를 이용하여 호출된 함수에 대해 드라이버 링크를 실행한다. 그리고 S860 단계에서 실행결과가 리턴되면 상기 실행 결과를 S870 단계에서 VMQ의 지정된 큐에 저장한다.

도 9는 로봇에 특수 장치 또는 새로운 기능이 부가되는 경우 RFC(120) 및 GDA(155)에 새로운 인터페이스를 추가하는데 사용되는 GRI 스터브(125) 및 GRI 스켈레톤(160)을 나타내는 도면이다.

GRIS의 RFC(120)는 로봇의 공통된 기능에 대한 추상화된 클래스라고 할 수 있다. 따라서 로봇에 특수 장치 또는 새로운 기능이 부가되는 경우, 이에 대한 인터페이스를 RFC(120) 및 GDA(155)에 추가해야 한다. 이 경우 새로운 인터페이스가 RFC(120) 및 GDA(155)에 모두 추가되어야 하므로 로봇 소프트웨어의 각 계층에, 이에 대한 인터페이스를 추가해야 한다. GRIS 확장 인터페이스(GRIS Remote Interface, 이하 'GRI'라 한다)는 이러한 번거로움 및 개발자의 실수를 최소화할 수 있도록 하는 인터페이스 추가를 위한 도구라고 할 수 있다.

GRI는 사용자가 GRIS에서 제공하는 RFC(120) 및 GDA(155) 인터페이스 이외의 새로운 사용자 인터페이스를 추가하기 위한 인터페이스 정의 언어(Interface Definition Language, IDL)의 한 종류로써, 추가하고자 하는 인터페이스에 대하여 클래스 및 함수, 파라미터 등을 GRI Document(910)로 기술한다. 사용자가 작성한 상기 GRI Document(910)를 GRI 파서(920)에 입력하면 GRI 파서(920)는 GRI Document(910)를 분석하여 RFC(120) 및 GDA(155)에 대응하는 C++ 소스 코드를 자동으로 생성한다. 상기 GRI 파서(920)는 새로운 인터페이스를 추가하기 위한 프로그램 툴로써 GRIS 라이브러리를 확장할 때 사용될 수 있다. 자동으로 생성되는 C++ 소스 코드 중 RFC(120)에 대응되는 부분을 GRI 스터브(125)라 하고, GDA(155)에 대응되는 부분을 GRI 스켈레톤(160)이라고 한다. 생성되어 라이브러리화된 GRI 스터브(125) 및 GRI 스켈레톤(160)은 RFC(120) 및 GDA(155)가 동작하는 방식대로 서비스 프록시(140) 및 서비스 디스패쳐(145)를 통하여 서로 연동할 수 있다.

이하 구체적인 예를 들어 GRI를 이용하여 새로운 인터페이스를 생성하는 과정을 설명하도록 한다.

우선, 아래의 표 18과 같은 형태의 GRI Document(910)를 작성하였다고 가정한다.

[표 18]

< Motor.gri > #include "rbtpart_motorimpl.h" // RFC 코드에서 참조해야할 헤더 파일 -#include "cntpart_motor.h" // GDA 코드에서 참조해야할 헤더 파일 module GRIS { interface CMyMotorImpl : CImplBasicMotor <CMyMotorListener : CMotorListener> // RFC에서 생성되어야 할 클래스 - 1) - CCntrMyMotor : CCntrMotor // GDA의 생성되어야할 클래스 -2) { construct CMyMotorImpl(char *compId) : CImplBasicMotor(compId); // RFC의 생성자 -CCntrMyMotor(char *compId) : CCntrMotor(compId); // GDA의 생성자 int getStatus( out GRIS::MOTOR_STATUS &status); // 사용하고자 하는 함수 int eventStatusChanged( in GRIS::MOTOR_STATUS &status) event CEventMotorStatus // 사용하고자 하는 이벤트 } }

상기와 같은 'Motor.gri'의 파일 이름을 갖는 GRI Document(910)를 작성하여 GRI 파서(920)에 입력하면 RFC(120)에 대응하는 코드로서 'motor_fc.h' 및 'motor_fc.cpp'가 생성되고, GDA(155)에 대응하는 코드로서 'motor_da.h' 및 'motor_da.cpp'가 생성되며, 이벤트에 관련된 코드로서 'motor_el.h' 및 'motor_el.cpp'가 생성되는데, 해당 코드는 다음과 같다.

[표 19]

// This is automatically generated by GRI parser. // if you like to update this // update GRI source and generate this again. // ------------------------------------------------------------------------- #ifndef motor_fc_1201334976_h #define motor_fc_1201334976_h #include "rbtpart_motorimpl.h" #include "rbtpart.h" #include "motor_el.h" namespace GRIS { class CMyMotorImpl : public CImplBasicMotor { public: CMyMotorImpl(const char *compId) :CImplBasicMotor(compId) { } virtual ~CMyMotorImpl() { } virtual int getStatus(GRIS::MOTOR_STATUS &status); int addEventListener(CMyMotorListener *l) { return GRIS::CComponent::addEventListener(l); } int delEventListener(CMyMotorListener *l) { return GRIS::CComponent::delEventListener(l); } }; } // end of namespace #endif // motor_fc_1201334976_h

상기 표 19는 RFC(120)에 대응되는 코드로서 'motor_fc.h'를 나타낸다. 상기 표 19에서 'CImplBasicMotor'는 생성된 'motor_fc.h'가 RFC(120)에 대응되는 클래스라는 것을 나타낸다.

또한, RFC(120)에 대응되는 코드로서 생성되는 'motor_fc.cpp'는 다음의 표 20과 같다.

[표 20]

// This is automatically generated by GRI parser. // if you like to update this // update GRI source and generate this again. #include "motor_fc.h" #include "su_parameter.h" #include "su_ubuffer.h" #include <string> #include <vector> // CMyMotorImpl Implements int GRIS::CMyMotorImpl::getStatus(GRIS::MOTOR_STATUS &status) { GRIS::CParameter _inp GRIS::UBuffer _outb int _result; _result = requestService("getStatusOT", _inp.base(), _inp.size(), _outb); if( _result < 0) return _result; if( _outb.bufsize() > 0) { GRIS::CParameter _outp(_outb); status.unpack(_outp); } return _result; }

그리고 GDA(155)에 대응되어 생성된 'motor_da.h'에 해당하는 소스 코드는 다음의 표 21과 같다.

[표 21]

// This is automatically generated by GRI parser. // if you like to update this // update GRI source and generate this again. #ifndef motor_da_1201334976_h #define motor_da_1201334976_h #include "cntpart_motor.h" #include "cntrpart.h" namespace GRIS { class CCntrMyMotor : public CCntrMotor { public: CCntrMyMotor(const char *compId) :CCntrMotor(compId) { } virtual ~CCntrMyMotor() { } virtual int onGetStatus(GRIS::MOTOR_STATUS &status) = 0; int eventStatusChanged(const GRIS::MOTOR_STATUS &status); int activate(); }; } // end of namespace #endif // motor_da_1201334976_h

상기 표 21에서 'CCntrMotor'는 생성된 'motor_da.h'가 GDA(155)에 대응하는 클래스라는 것을 나타낸다.

또한, GDA(155)에 대응되는 코드로서 생성되는 'motor_da.cpp'는 다음의 표 22와 같다.

[표 22]

// This is automatically generated by GRI parser. // if you like to update this // update GRI source and generate this again. #ifndef motor_da_1201334976_h #define motor_da_1201334976_h #include "cntpart_motor.h" // This is automatically generated by GRI parser. // if you like to update this // update GRI source and generate this again. #include "motor_da.h" #include "cntrpart.h" #include "su_parameter.h" #include "su_ubuffer.h" #include <string> #include <vector> // CDispatcher Implements namespace _motor { class _CgetStatus : public GRIS::CDispatcher { public: explicit _CgetStatus(GRIS::CCntrPart *p) : GRIS::CDispatcher(p) { } ~_CgetStatus() { } int callback(const void *_in, int _inSize, GRIS::CParameter &_out); };

그리고 이벤트에 관련된 코드로서 생성된 'motor_el.h' 에 해당하는 코드는 다음의 표 23과 같다.

[표 23]

// This is automatically generated by GRI parser. // if you like to update this // update GRI source and generate this again. #ifndef motor_el_1201334976_h #define motor_el_1201334976_h #include "rbtpart_motorimpl.h" #include "rbtlistnr.h" #include "rbtevent.h" namespace GRIS { class CMyMotorListener : public CMotorListener { public: explicit CMyMotorListener(const char *compId, bool sync=false) : CMotorListener(compId, sync) { initialize(); } class CEventMotorStatus : public GRIS::CEventObject { public : CEventMotorStatus(const GRIS::CComponent* comp, GRIS::CEventObject::EventType etype, sutime_t etime) : CEventObject(comp, etype, etime) { } GRIS::MOTOR_STATUS &status; }; virtual int onEventStatusChanged(CEventMotorStatus &evt) = 0; protected: int initialize(); }; } // end of namespace #endif // motor_el_1201334976_h

상기 표 23에서 'CMotorListener'는 생성된 'motor_el.h'가 이벤트에 해당하는 소스 코드라는 것을 나타낸다.

또한, 상기 'motor_el.h'와 더불어 생성되는 'motor_el.cpp'는 다음의 표 24와 같다.

[표 24]

// This is automatically generated by GRI parser. // if you like to update this // update GRI source and generate this again. #include "motor_el.h" #include "su_parameter.h" #include "su_ubuffer.h" #include <string> #include <vector> // CEventDispatcher Implements namespace _motor { class _CeventStatusChanged : public GRIS::CEventDispatcher { public: explicit _CeventStatusChanged(GRIS::CEventListener *l) : GRIS::CEventDispatcher(l) { } ~_CeventStatusChanged() { } int callback(const GRIS::CComponent *_comp, const void *_in, int _inSize, sutime_t _eventTime); };

이상과 같이, 본 명세서와 도면에는 본 발명의 바람직한 실시예에 대하여 개시하였으며, 비록 특정 용어들이 사용되었으나, 이는 단지 본 발명의 기술 내용을 쉽게 설명하고 발명의 이해를 돕기 위한 일반적인 의미에서 사용된 것이지, 본 발명의 범위를 한정하고자 하는 것은 아니다. 여기에 개시된 실시예 외에도 본 발명의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.

도 1은 본 발명의 실시예에 따른 로봇 통신 미들웨어의 상세 구조를 나타내는 도면.

도 2a 및 도 2b는 본 발명의 실시예에 따른 GRIS(General Robot Infra Structure)를 구성하는 각각의 구성 요소들간의 연결 관계 및 상기 GRIS를 이용하는 경우 로봇 서비스 어플리케이션이 로봇 하드웨어에 서비스를 호출하고, 이에 따른 데이터를 교환하는 과정을 개략적으로 나타내는 도면.

도 3a는 VMQ(135)의 데이터 교환 기능(Data Driven Processing)을 설명하는 도면.

도 3b는 VMQ(135)의 서비스 콜 프로세싱(Service Call Processing)을 설명하는 도면

도 3c는 VMQ(135)의 객체 세션 프로세싱(Object Session Processing)을 설명하는 도면.

도 4는 본 발명의 실시예에 따른 GRIS에 구현된 RFC(120)와 GDA(155)의 구조를 나타내는 도면.

도 5는 본 발명의 실시예에 따른 로봇 서비스 어플리케이션이 GDA단과 서로 다른 시스템인 경우, VMQ를 이용하여 원격에서 상기 로봇 서비스 어플리케이션과 GDA단을 상호 연동시키는 방법을 나타내는 도면.

도 6은 VMQ 에이전트를 이용하여 개발 시스템과 타켓 시스템을 원격에서 연동하는 구체적인 실시예를 나타내는 도면.

도 7은 본 발명의 실시예에 따른 실제 로봇 서비스 어플리케이션이 실행되면서 RFC(120)를 호출하고 이에 따라 GDA(155)를 구현한 드라이버가 실행되는 경우, RFC 단에서 상기 호출이 실행되는 과정을 나타내는 순서도.

도 8은 본 발명의 실시예에 따른 실제 로봇 서비스 어플리케이션이 실행되면서 RFC(120)를 호출하고 이에 따라 GDA(155)를 구현한 드라이버가 실행되는 경우, GDA 단에서 실제 함수가 실행되는 과정을 나타내는 순서도.

도 9는 로봇에 특수 장치 또는 새로운 기능이 부가되는 경우 RFC 단 및 GDA 단에 새로운 인터페이스를 추가하는데 사용되는 GRI 스터브 및 GRI 스켈레톤을 나타내는 도면.

Claims

로봇 장치를 제어하기 위한 인터페이스를 구비하는 어플리케이션 인터페이스;

상기 로봇 장치에 따라 대응하는 별도의 큐를 구비하는 가상 메시지 큐와, 상기 어플리케이션 인터페이스에서 특정 서비스 함수 호출 시 상기 호출된 서비스 함수를 분석하고 함수 호출 메시지를 생성하여 상기 가상 메시지 큐의 대응하는 큐에 저장하는 서비스 프록시와, 상기 가상 메시지 큐에 저장된 함수 호출 메시지를 분석하고 상기 호출된 서비스 함수에 대응하는 로봇 함수를 전송하는 서비스 디스패쳐를 구비하는 데이터 통신 모듈;

상기 어플리케이션 인터페이스에서 호출된 서비스 함수에 관한 정보를 수신하여 대응하는 로봇 함수를 실행하는 디바이스 인터페이스;

상기 로봇이 구비하는 장치에 관한 구성 정보를 포함하는 팩터 데이터 베이스를 구비하는 디바이스 설정 정보 모듈을 포함하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제1항에 있어서,

상기 서비스 프록시는 상기 어플리케이션 인터페이스에 로봇 장치 클래스가 등록되면 서비스 프록시 객체를 생성하고, 상기 로봇 장치 클래스를 식별하는데 필 요한 파트 ID 와 상기 파트 ID에 대응하는 서비스 프록시 객체에 관한 정보를 서비스 프록시 객체 테이블에 저장하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제2항에 있어서,

상기 서비스 프록시는 상기 서비스 프록시 객체 테이블에서 파트 ID를 검색하고 이에 대응되는 서비스 프록시 객체를 확인하여, 확인된 서비스 프록시 객체가 상기 팩터 데이터 베이스에서 상기 파트 ID에 대응되는 가상 메시지 큐를 확인하고, 확인된 가상 메시지 큐에 함수 호출 메시지를 생성하여 저장하도록 하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제3항에 있어서,

상기 함수 호출 메시지는 파트 ID, 서비스 함수 이름, 입력 버퍼 주소, 입력 버퍼 크기, 출력 버퍼 주소, 리턴 형태, 타임 아웃 시간, 메시지 타입, 쓰기 모드에 관한 정보를 포함하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제4항에 있어서,

상기 서비스 디스패쳐는 상기 가상 메시지 큐에 저장된 상기 함수 호출 메시지를 수신하고, 파트 ID 및 서비스 이름을 확인하여 상기 어플리케이션 인터페이스에서 호출된 서비스 함수에 대응되는 로봇 함수를 상기 디바이스 인터페이스에서 검색하여 실행하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
로봇을 구성하는 장치를 클래스 라이브러리로 구성하는 로봇 팩토리 클래스를 구비하는 어플리케이션 인터페이스;

상기 로봇 장치에 따라 대응하는 별도의 큐를 구비하는 가상 메시지 큐와, 상기 어플리케이션 인터페이스에서 특정 서비스 함수 호출 시 상기 호출된 서비스 함수를 분석하고 함수 호출 메시지를 생성하여 상기 가상 메시지 큐의 대응하는 큐에 저장하는 서비스 프록시와, 상기 가상 메시지 큐에 저장된 함수 호출 메시지를 분석하고 상기 호출된 서비스 함수에 대응하는 로봇 함수를 전송하는 서비스 디스패쳐를 구비하는 데이터 통신 모듈;

상기 로봇 팩토리 클래스에서 호출된 서비스 함수에 대응하는 로봇 함수를 실행하는 GRIS 드라이버 어댑터를 구비하는 디바이스 인터페이스; 및

상기 로봇이 구비하는 장치에 관한 구성 정보를 포함하는 팩터 데이터 베이스를 구비하는 디바이스 설정 정보 모듈을 포함하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제6항에 있어서, 상기 가상 메시지 큐는,

로깅 설정 및 글로벌 설정을 위한 로컬 프로파일과, 서버 설정 및 상기 가상 메시지 큐 설정을 위한 서버 정보를 포함하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제7항에 있어서, 상기 팩터 데이터 베이스는,

상기 로봇의 하드웨어 정보를 포함하는 프로덕트 설정과, 프로그램에서 사용되는 설정 정보를 포함하는 파트 설정과, 상기 로봇을 구성하는 장치들 상호간의 구성을 기술하는 컨피그 설정을 포함하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제8항에 있어서, 상기 파트 설정은,

상기 로봇 팩토리 클래스와 상기 GRIS 드라이버 어댑터의 연결 방법을 설정 가능한 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제9항에 있어서, 상기 연결 방법은,

상기 로봇 팩토리 클래스와 상기 GRIS 드라이버 어댑터를 상기 가상 메시지 큐를 이용하여 연결하거나 또는 직접 연결하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제10항에 있어서, 상기 파트 설정은,

상기 로봇의 장치마다 서로 다른 가상 메시지 큐를 설정하거나 또는 복수의 로봇 장치에 동일한 가상 메시지 큐를 설정 가능한 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제11항에 있어서,

상기 서비스 프록시는 상기 로봇 팩토리 클래스에 로봇 장치 클래스가 등록되면, 서비스 프록시 객체를 생성하여 상기 로봇 장치 클래스를 식별하는데 필요한 파트 ID 와, 상기 파트 ID에 대응하는 서비스 프록시 객체에 관한 정보를 서비스 프록시 객체 테이블에 저장하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제12항에 있어서,

상기 서비스 프록시는 상기 서비스 프록시 객체 테이블에서 파트 ID를 검색 하고 이에 대응되는 서비스 프록시 객체를 확인하여, 상기 확인된 서비스 프록시 객체가 상기 팩터 데이터 베이스에서 상기 파트 ID에 대응되는 가상 메시지 큐를 확인하고, 상기 확인된 가상 메시지 큐에 함수 호출 메시지를 생성하여 저장하도록 하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제13항에 있어서,

상기 함수 호출 메시지는 파트 ID, 서비스 함수 이름, 입력 버퍼 주소, 입력 버퍼 크기, 출력 버퍼 주소, 리턴 형태, 타임 아웃 시간, 메시지 타입, 쓰기 모드에 관한 정보를 포함하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제14항에 있어서,

상기 서비스 디스패쳐는 상기 가상 메시지 큐에 저장된 상기 함수 호출 메시지를 수신하고, 파트 ID 및 서비스 이름을 확인하여 상기 로봇 팩토리 클래스에서 호출된 서비스 함수에 대응되는 서비스 함수를 상기 GRIS 드라이버 어댑터에서 검색하여 실행하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제7항에 있어서, 상기 가상 메시지 큐는,

상기 서버 설정에서 원격에 있는 상기 GRIS 드라이버 어댑터가 위치하는 시스템의 IP 어드레스를 지정하여, 서로 다른 네트워크에 위치한 상기 로봇 팩토리 클래스와 상기 GRIS 드라이버 어댑터를 연결하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제16항에 있어서, 상기 가상 메시지 큐는,

로봇 장치간 우선 순위를 설정하여 상기 로봇 팩토리 클래스와 상기 GRIS 드라이버 어댑터를 연결하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제6항에 있어서,

상기 어플리케이션 인터페이스는, 상기 로봇에 장치 또는 기능이 부가되면, 상기 로봇 팩토리 클래스에 대응하여 추가되는 GRI 스터브를 더 포함하고,

상기 디바이스 인터페이스는, 상기 로봇에 장치 또는 기능이 부가되면, 상기 GRIS 드라이버 어댑터에 대응하여 추가되는 GRI 스켈레톤을 더 포함하는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
제18항에 있어서, 상기 GRI 스터브 또는 상기 GRI 스켈레톤은,

추가되는 인터페이스에 대한 서비스 함수의 정의가 기술된 GRI 다큐멘트가 GRI 파서에 입력되면, 상기 로봇 팩토리 클래스 또는 GRIS 드라이버 어댑터에 대응하는 소스 코드가 자동으로 생성되는 것을 특징으로 하는 로봇 통신 미들웨어 플랫폼.
로봇의 장치에 대한 로봇 팩토리 클래스 객체를 생성하는 단계;

상기 생성된 로봇 팩토리 클래스 객체를 서비스 프록시에 등록하는 단계;

함수 호출 방식과 지정된 가상 메시지 큐를 팩터 데이터 베이스에서 조회하여 함수 호출 메시지를 생성하고, 대응하는 가상 메시지 큐에 저장하는 단계를 포함하는 것을 특징으로 하는 로봇 통신 미들웨어의 통신 방법.
제20항에 있어서, 상기 함수 호출 메시지는,

파트 ID, 서비스 함수 이름, 입력 버퍼 주소, 입력 버퍼 크기, 출력 버퍼 주소, 리턴 형태, 타임 아웃 시간, 메시지 타입, 쓰기 모드에 관한 정보를 포함하는 것을 특징으로 하는 로봇 통신 미들웨어의 통신 방법.
GRIS 드라이버 어댑터 클래스 객체를 생성하는 단계;

상기 생성된 GRIS 드라이버 어댑터 객체에 대한 서비스 디스패쳐를 생성하는 단계;

가상 메시지 큐에 저장된 함수 호출 메시지를 분석하여, 상기 로봇 팩토리 클래스에서 호출된 서비스 함수에 대응하는 로봇 함수를 실행하는 단계를 포함하는 것을 특징으로 하는 로봇 통신 미들웨어의 통신 방법.
제22항에 있어서, 상기 함수 호출 메시지는,

파트 ID, 서비스 함수 이름, 입력 버퍼 주소, 입력 버퍼 크기, 출력 버퍼 주소, 리턴 형태, 타임 아웃 시간, 메시지 타입, 쓰기 모드에 관한 정보를 포함하는 것을 특징으로 하는 로봇 통신 미들웨어의 통신 방법.