KR100980793B1

KR100980793B1 - 로봇을 위한 하드웨어 추상화 계층에서의 센서 및액추에이터 추상화 및 집단화

Info

Publication number: KR100980793B1
Application number: KR1020047008104A
Authority: KR
Inventors: 머레이토마스제이.4세; 팜바오쿠오크엔.; 퍼자니안파올로
Original assignee: 에볼루션 로보틱스, 인크.
Priority date: 2001-11-28
Filing date: 2002-11-27
Publication date: 2010-09-10
Anticipated expiration: 2022-11-27
Also published as: AU2002357040A1; US7076336B2; US8996168B2; US20120041592A1; US6889118B2; WO2003045639A2; KR20040066849A; US20080071423A1; US7302312B2; JP2005515903A; US7925381B2; WO2003045639A3; US20030171846A1; US20050021186A1; US20070050088A1; AU2002357040A8

Abstract

본 발명은 로봇에 하드웨어 추상화 계층(HAL)(202)을 제공하는 방법 및 장치에 관한 것이다. HAL(202)은, 소프트웨어 계층으로서 존재하거나, 혹은 로봇 제어 소프트웨어(157, 158, 160, 162)와 하부 로봇 하드웨어(152, 154) 및/또는 그 하드웨어를 위한 운영 시스템(156) 사이에 존재하는 펌웨어 계층으로서 존재할 수 있다. HAL(202)은 하부 하드웨어의 집합체에 비교적 균일한 추상을 제공함으로써, 그 하부 로봇 하드웨어는 지각 및 제어 소프트웨어(157, 158, 160, 162) 즉, 로봇 제어 소프트웨어(157, 158, 160, 162)에 대하여 투명하게 된다. 이것은 로봇 제어 소프트웨어(157, 158, 160, 162)가 로봇-독립적 방식으로 기록될 수 있게 해주는 장점이 있다. 로봇 제어 소프트웨어의 개발자는 그후 사소한 하위-레벨의 태스크로부터 해방되게 된다. 이식성은 다른 장점이다. 예를 들면, HAL(202)은 한 로봇을 위해 개발된 로봇 제어 소프트웨어(157, 158, 160, 162)가 다른 로봇에 이식될 수 있게 해준다. 한 예로, HAL(202)은 동일한 항법 알고리즘이 바퀴달린 로봇(104)으로부터 이식되어 인간에 가까운 다리달린 로봇(106)에서 이용될 수 있게 해준다.

로봇, 하드웨어 추상화 계층(HAL), 소프트웨어, 리소스, 인터페이스

Description

로봇을 위한 하드웨어 추상화 계층에서의 센서 및 액추에이터 추상화 및 집단화{SENSOR AND ACTUATOR ABSTRACTION AND AGGREGATION IN A HARDWARE ABSTRACTION LAYER FOR A ROBOT}

본 발명은 일반적으로 로봇에 관한 것이다. 특히, 본 발명은 제어 또는 비헤비어(behavior) 소프트웨어의 이식성(portability)을 높이는 하드웨어 추상화 계층에 관한 것이다.

로봇은 많은 목적에 이용될 수 있다. 예를 들면, 로봇은 반복적인 작업을 위한 산업적 애플리케이션 또는 위험한 환경에서 이용될 수 있고, 오락(entertainment)을 위해 장난감으로서 이용될 수 있는 등 많은 목적에 이용될 수 있다. 로봇용 하드웨어 및 로봇용 제어 소프트웨어는 점점 더 복잡해지고 있다. 로봇은 구조체에 부착되는 다양한 센서 및 액추에이터(actuator)를 포함할 수 있다.

기존의 로봇 및 로봇 소프트웨어에 대한 하나의 단점은, 제어 소프트웨어에 대한 투명성(transparency)이 부족하다는 점이다. 기존의 로봇에서는, 소프트웨어 가 각각의 새로운 로봇 구성에 대하여 어렵게 적응된다. 예를 들면, 전형적인 로봇 소프트웨어 아키텍처에서, 로봇 소프트웨어는 하위-레벨 장치 드라이버를 통해 로봇 하드웨어와 상호작용한다. 이러한 하위-레벨 장치 드라이버는, 전형적으로 하드웨어 장치의 물리적 특성에 의하여 전송 및 수신되는 커맨드 및 피드백 정보를 지원한다. 예를 들면, 드라이브 시스템 모터에 대한 하위-레벨 장치 드라이버는 로봇 소프트웨어로부터 커맨드를 수신하여, 특정 속도로 모터를 회전시킬 수 있다. 그러나, 드라이브 시스템은 전체적으로 모터 뿐만 아니라, 기어와 바퀴도 포함할 수 있다. 따라서, 기어 비율(gear ratio) 및/또는 바퀴 직경에 대하여 변경이 이루어지는 경우, 소프트웨어 개발자는 로봇이 필요에 따라 행동하도록 특정의 분당 회전수를 변경하기 위해서 로봇 소프트웨어를 수정해야 한다.

이러한 사소한 프로그래밍 변경은 시간 소모적이고, 로봇의 소프트웨어 및 하드웨어 개발 양쪽 모두에 있어서 비효율적이다. 본 발명의 실시예들은 로봇 하드웨어로부터 로봇 소프트웨어를 분리시켜서 종래 기술의 단점을 극복할 수 있다는 장점이 있다.

본 발명의 실시예들은 로봇에 하드웨어 추상화 계층(Hardware Abstraction Layer: HAL)을 제공하는 방법 및 장치에 관한 것이다. HAL은, 소프트웨어 계층으로서 존재하거나 혹은 로봇 제어 소프트웨어와 하부 로봇 하드웨어 및/또는 그 하드웨어를 위한 운영 시스템 사이에 존재하는 펌웨어 계층으로서 존재할 수 있다. HAL 은 하부 하드웨어의 집합체(aggregate)에 비교적 균일한 추상(abstract)을 제공함으로써, 그 하부 로봇 하드웨어는 지각(perception) 및 제어 소프트웨어 즉, 로봇 제어 소프트웨어에 대하여 비교적 투명하게 된다. 이것은 로봇 제어 소프트웨어가 로봇-독립적 방식으로 기록될 수 있게 해주는 장점이 있다.

로봇 제어 소프트웨어의 개발자는 그후 사소한 하위-레벨의 태스크로부터 해방되게 된다. 또한, 로봇 제어 소프트웨어의 이식성은 다른 장점들을 제공한다. 예를 들면, HAL은 한 로봇을 위해 개발된 로봇 제어 소프트웨어가 다른 로봇에 이식될 수 있게 해준다. 한 예로, HAL은 동일한 항법 알고리즘이 바퀴달린 로봇으로부터 이식되어 인간에 가까운 다리달린 로봇에서 이용될 수 있게 해준다.

본 발명의 일 실시예는 로봇 소프트웨어 아키텍처내에 하드웨어 추상화 계층(HAL)을 포함한다. 이 HAL은, 상위-레벨 소프트웨어에 대한 소프트웨어 인터페이스 - 상기 소프트웨어 인터페이스는 주위환경과의 로봇 상호작용에 관한 실세계(real-world) 측정값을 이용하여 상기 상위-레벨 소프트웨어와 통신하도록 구성됨 - ; 상기 상위-레벨 소프트웨어에, 이용가능한 리소스의 표시를 제공하는 리소스 구성; 다수의 리소스 드라이버 - 상기 리소스 드라이버 중 적어도 일부는 상기 리소스 구성내의 상기 이용가능한 리소스에 대응하고, 상기 리소스 드라이버 중 적어도 2개는 기능이 중복되고, 상기 적어도 2개의 리소스 드라이버 중 단지 1개만이 이용가능한 대응 리소스를 가지며, 이용가능한 리소스에 대한 리소스 드라이버는 로봇에 대한 실세계 측정값과 장치에 대한 장치-레벨 측정값 사이에서 변환하도록 구성됨 - ; 및 하위-레벨 장치 드라이버에 대한 인터페이스 - 상기 하위-레벨 장치 드라이버는 장치 레벨에서 대응하는 하드웨어와 통신하고, 하위-레벨 장치 드라이버에 대한 상기 인터페이스는 리소스 드라이버를 통해 상기 상위-레벨 소프트웨어와 통신함 - 를 포함할 수 있다.

본 발명의 일 실시예는 로봇에서 로봇 제어 소프트웨어에 하드웨어 추상화를 제공하는 방법에 관한 것이다. 이 방법은, 상기 로봇에 다수의 리소스 드라이버 - 상기 다수의 리소스 드라이버는 상기 로봇에 어떠한 대응하는 하드웨어도 존재하지 않는 리소스 드라이버를 포함함 - 를 제공하는 단계; 상기 로봇에 대한 하드웨어 구성을 검출하는 단계; 상기 검출된 하드웨어 구성에 근거하여, 상기 로봇에서 이용가능한 리소스를 자동으로 검출하는 단계; 소정의 타입의 리소스를 이용하기 위해 상기 로봇 제어 소프트웨어로부터 요구를 수신하는 단계; 상기 로봇 제어 소프트웨어에 의해 요구된 상기 타입의 리소스에 대응하는 리소스를, 상기 이용가능한 리소스로부터 자동으로 선택하는 단계; 상기 로봇 제어 소프트웨어와 제1 정보 - 상기 제1 정보는 상기 선택된 리소스의 이용과 관련된 것이고, 로봇과 관련된 측정값의 단위로 제공됨 - 를 교환하는 단계; 상기 리소스에 대응하는 하위-레벨 장치 드라이버와 제2 정보 - 상기 제2 정보는 상기 로봇 제어 소프트웨어에 의해 요구된 이용과 관련된 것이고, 제2 정보는 대응하는 장치와 관련된 측정값의 단위로 제공되고, 제2 정보는 상기 제1 정보와 다름 - 를 교환하는 단계; 및 상기 로봇의 상기 검출된 구성에 근거하여, 상기 제1 정보와 상기 제2 정보 사이에서 변환하는 단계를 포함할 수 있다.

일 실시예는 하드웨어 추상화를 제공하는 방법을 수행하기 위한 컴퓨터 실행 가능 명령을 갖는 컴퓨터 판독가능 매체를 포함한다. 이 컴퓨터 판독가능 매체는 하드 디스크, 플로피 디스크 및 다른 자기 디스크, RAM, ROM, 플래시 메모리, 메모리 카드 및 다른 고체 기억장치, 광 디스크, CD-ROM, DVD-ROM(이것에만 한정되는 것은 아님) 등을 포함하는 매우 다양한 매체에 대응할 수 있다.

이제, 하기에 요약된 도면들을 참조하여 본 발명의 이들 및 기타 다른 특징들을 설명하기로 한다. 이 도면들 및 관련 설명은 본 발명의 바람직한 실시예들을 예시하기 위해 제공되는 것이며, 본 발명의 범위를 한정하고자 하는 것은 아니다.

도1a는 본 발명의 실시예들에 이용될 수 있는 다양한 로봇들의 비-전면적(non-exhaustive) 표본을 도시한 도면.

도1b는 종래의 로봇 소프트웨어 아키텍처를 도시한 도면.

도2는 하드웨어 추상화 계층(HAL)을 갖는 소프트웨어 아키텍처를 도시한 도면.

도3은 하드웨어 장치의 추상화 및 리소스 드라이버와 리소스 간의 관계를 도시한 도면.

도4는 HAL의 상세도.

도5는 논리 장치 버스를 통해서 하드웨어 장치를 프로세싱 유닛에 연결한 것을 도시한 도면.

도6은 리소스 구성의 상세도.

도7은 리소스 드라이버 객체(object)가 IResourceDriver와 하나 이상의 IResource 인터페이스로부터 어떻게 유도(derive)되는지를 도시한 도면.

도8은 리소스를 상위-레벨 소프트웨어에 이용가능하게 되도록 하는 프로세스를 도시한 도면.

도9 내지 도17은 본 발명의 양태들을 개략적으로 예시하는 흐름도들.

도18은 도17에 도시된 흐름도를 위한 변수 참조(variable reference)를 나타낸 도면.

본 발명은 어떠한 바람직한 실시예들에 의해 설명될 것이지만, 본원에서 설명되는 이득 및 특징 모두를 제공하지는 않는 실시예들을 포함하여, 이 기술분야의 당업자에게 명백한 다른 실시예들 역시 본 발명의 범위내에 있다. 따라서, 본 발명의 범위는 단지 첨부된 청구항을 참조하여서만 정의된다.

도1a는 서로다른 타입의 로봇들의 예를 도시한다. 로봇들은 매우 다양하게 이용될 수 있으며, 매우 다양한 구성에 대응할 수 있다. 예를 들면, 제1 로봇(102)은 병원에서 의료 용품용 자동화 운송 장치에 대응할 수 있다. 제2 로봇(104)은 연구 및 취미용 로봇에 대응할 수 있다. 제3 로봇(106)은 인간에 가까운 로봇에 대응할 수 있다. 제4 로봇(108)은 오락을 목적으로 한 장난감에 대응할 수 있다. 이 기술분야의 당업자이면, 많은 다른 로봇 구성이 가능하다는 것을 알 수 있을 것이다.

다양한 구성의 로봇들은 하드웨어에 있어 실질적인 차이가 있을 수 있다는 것을 알 수 있을 것이다. 예를 들면, 제1 로봇(102)과 제2 로봇(104)은 바퀴로 이동하는 반면, 제3 로봇(106)과 제4 로봇(108)은 다리를 이용하여 이동한다. 본 발명의 실시예들은 유리하게 하부 하드웨어가 근본적으로 다르더라도, 한 로봇을 위해 개발된 소프트웨어가 다른 로봇에 편리하게 이식될 수 있게 해준다. 또한, 본 발명의 실시예들은, 로봇에 대하여 바퀴 직경의 변경과 같은 비교적 중요하지 않은 변경이 이루어질 경우, 동일한 소프트웨어를 사용하여 로봇을 제어할 수 있다.

본 발명의 실시예들은, 유리하게 로봇 소프트웨어가 하드웨어-독립적 방식으로 개발될 수 있게 해주는 하드웨어 추상화 계층(HAL)을 제공한다. 이 HAL은 유리하게 로봇 소프트웨어와 하드웨어 드라이버 사이의 소프트웨어 아키텍처내의 한 계층에 존재한다. HAL은 한 로봇을 위해 개발된 로봇 소프트웨어가 다른 로봇에 효율적으로 이식될 수 있게 해준다. HAL은 또한 로봇 소프트웨어를 변경할 필요없이 기존 로봇의 재구성이 수행될 수 있게 해준다. 예를 들면, 센서 또는 액추에이터가 변경될 수 있다. HAL의 이용은, 로봇 소프트웨어 및 하드웨어의 신속한 개발 및 진보를 촉진한다.

도1b는 종래의 로봇을 위한 소프트웨어 아키텍처를 도시한다. 로봇 소프트웨어(150)는 센서(152)로부터의 입력을 처리하여 액추에이터(154)에 제어 출력을 제공한다. 도1b의 예시된 소프트웨어 아키텍처에서, 로봇 소프트웨어(150)는 상위-레벨 플래너(planner)(157) 또는 애플리케이션(158)을 포함한다. 상위-레벨 플래너(157)는 심볼 형태로 특정되는 목적을 이용한다. 상위-레벨 플래너(157)는 그들의 목적을 최상으로 달성하는 법을 결정하기 위해 직관 논리(intrinsic logic) 를 갖는다. 예를 들면, 상위-레벨 플래너는 임무 계획 작성, 수색 구조 및 서비스-지향형 태스크와 같은 다양한 로봇 애플리케이션에서 이용된다. 애플리케이션(158)은 로봇의 제어를 위한 소프트웨어 프로그램 또는 알고리즘에 대응할 수 있다. 상위-레벨 플래너(157) 또는 애플리케이션(158)은, 다양한 로봇 동작을 캡슐화(encapsulation)하는 비헤비어 또는 태스크(task)로서 예시된 보다 작은 소프트웨어 성분들을 조정(coordinate)함으로써 그의 목적을 달성한다. 비헤비어의 일례로서, "로봇앞의 임의의 장애물을 피하시오"가 있다. 태스크의 일례로서, "내부 맵상의 특정 위치로 가시오"가 있다. "회의실로 가시오"라는 목적이 주어진 상위-레벨 플래너(157)는 "피하시오"의 비헤비어와 "위치로 가시오"의 태스크의 이용을 조정하여 내부 맵에서 회의실의 위치를 알아내어 장애물과 충돌함이 없이 회의실로 이동할 수 있다. 이들 비헤비어 및 태스크 성분은 중간의 비헤비어 계층(160) 및/또는 태스크 계층(162)을 형성할 수 있다. 비헤비어 계층(160) 및/또는 태스크 계층(162)은, 그 다음에 하위-레벨 장치 드라이버(156)를 통해서 로봇 하드웨어 즉, 센서(152) 및/또는 액추에이터(154)와 상호작용한다.

하위-레벨 장치 드라이버(156)는 대응하는 하드웨어 장치에 대하여 특정이다. 하위-레벨 장치 드라이버(156)는 전형적으로 주어진 커맨드를 지원하며, 대응하는 장치의 물리적 특성에 의하여 피드백 정보를 제공한다. 예를 들면, 모터 드라이버는, 모터를 어떤 분당 회전수(RPM)로 특정될 수 있는 소정 속도로 회전시키기 위한 커맨드를 지원하도록 구성될 수 있다. 로봇을 위한 드라이브 시스템에서 모터가 이용될 경우, 비헤비어 계층(160) 및/또는 태스크 계층(162)은 모터의 회전에 의하여, 대응하는 하위-레벨 장치 드라이버에 커맨드를 제공한다. 이것은 비교적 비효율적이고 불편하다.

로봇의 움직임(motion)은 모터보다는, 로봇에 적용가능한 치수 단위에 의하여 보다 효율적으로 기술될 수 있다. 예를 들면, 본 발명의 실시예들에 의해 이용되는 보다 편리한 표기법은 센티미터(cm)와 같은 직접 거리 단위(direct distance unit) 또는 초당 센티미터(cm/sec)와 같은 속도 단위를 이용하여 로봇의 변위(displacement)를 기술한다. 이러한 직접 표기법은 모터의 회전 속도와 같은 간접 표기법보다 훨씬더 사용이 편리할 수 있다.

대조적으로, 종래의 로봇 소프트웨어(150)가 하위-레벨 장치 드라이버(156)와 인터페이스하도록 구성될 때, 비헤비어 계층(160) 및/또는 태스크 계층(162)은 이러한 간접 단위의 값을 특정 로봇의 드라이브 시스템의 특성으로 변환한다. 예를 들면, 종래의 로봇 소프트웨어를 사용하는 소프트웨어 개발자는, 특정 변위를 달성하기 위해 비헤비어 계층(160) 및/또는 태스크 계층(162)을 특정 로봇의 특정 기어 비율 및 바퀴 크기에 맞추어야 하는 단점이 있다. 이러한 개별화(customization)는, 로봇에 대하여 바퀴 크기의 변경과 같은 변경이 이루어질 경우 다시 맞추어져야 하는 단점이 있다. 또한, 특정 로봇을 위해 맞추어진 비헤비어 계층(160) 및/또는 태스크 계층(162)은 전형적으로 다른 구성의 로봇에 이식할 수 없다.

도2는 하드웨어 추상화 계층(HAL)(202)을 갖는 본 발명의 실시예에 따른 소프트웨어 아키텍처(200)를 도시한다. 이 HAL(202)은 상위-레벨 로봇 비헤비어 소프트웨어에 중간 계층 인터페이스를 제공함으로써, 상위-레벨 로봇 비헤비어 소프트 웨어가 하부 하드웨어의 특정 세부사항에 의해서라기 보다는 실세계 치수에 근거하여 개발될 수 있게 한다는 장점이 있다. 이것은 소프트웨어 개발자가 로봇 애플리케이션을 프로그래밍할 때, 하부 로봇 하드웨어 장치의 정밀한 세부사항을 보상하는 혼란(distraction)이 없이 실세계 개념을 가지고 작업할 수 있게 해주는 장점이 있다. 또한, 일 실시예에서, HAL(202)은 HAL(202)의 상부에 기록되는 로봇 비헤비어 소프트웨어가 서로 다른 로봇 하드웨어 플랫폼에 대한 변경이 없이도 동작할 수 있게 해준다.

소프트웨어 아키텍처(200)는 또한 다양한 플랫폼에 로드(load)될 수 있다. 예를 들면, 예시된 소프트웨어 아키텍처(200)는 리눅스, 유닉스, 마이크로소프트, 윈도우즈, 애플사의 MacOS 등과 같은 매우 다양한 운영 시스템에서 구현될 수 있다. 매우 다양한 컴퓨터 하드웨어가 또한 로봇용 소프트웨어 아키텍처(200)를 호스트(host)할 수 있다. 예를 들면, 컴퓨터 하드웨어는 개인용 컴퓨터, 랩탑 컴퓨터, 개인 휴대 정보 단말기(PDA), 싱글 보드 컴퓨터(single-board computer) 등에 대응할 수 있다. 컴퓨터 하드웨어는 로봇과 근거리에 있을 수 있거나 혹은 멀리 떨어져서 위치할 수도 있다.

도2에 의해 예시된 바와 같이, HAL(202)은 하위-레벨 장치 드라이버(156) 계층과 비헤비어 로봇 소프트웨어 사이의 소프트웨어 계층에 존재한다. HAL(202)의 일 실시예의 보다 상세한 설명은 나중에 도3, 도4, 도6, 도7 및 도8을 참조하여 하기로 한다. 일 실시예에서, 하위-레벨 장치 드라이버 계층은 하부 운영 시스템(OS) 예를 들면, 윈도우즈 XP 계층에 존재한다. 로봇에 비교적 균일한 제어 인터페이스 를 제공하는 것에 추가하여, HAL(202)은 로봇의 센서와의 상호작용을 위한 비교적 균일한 인터페이스를 제공한다. 그러나, 자동 로봇에 대해서, 자동 결정 및 동작을 위해 센서 데이터를 이용하기 위하여, 로봇에서의 센서의 위치, 센서 데이터의 표본 추출 비율 및 다른 센서 특성과 같은 다른 정보 역시 필요할 수 있다. HAL(202)의 실시예들은 로봇 시스템에서 센서의 이러한 특성을 캡슐화하기 위한 일련의 기술을 더 포함할 수 있으며, 유리하게 하부 로봇 하드웨어의 특정 특성과 독립적인 방식으로 데이터를 액세스하기 위한 비교적 균일한 인터페이스를 제공할 수 있다는 장점이 있다.

HAL(202)의 일 실시예는 다음의 이득들 중 적어도 하나를 제공한다.

(Ⅰ) 하드웨어 장치를 추상화하기 위해 유연성있는 프레임워크를 제공하고;

(Ⅱ) 플랫폼 중립성(neutrality)을 제공하고; 그리고

(Ⅲ) 로봇 하드웨어의 실시간 제어를 위해 시스템-레벨 효율성을 제공한다.

하드웨어 장치를 추상화하기 위해 유연성있는 프레임워크를 제공하는 이득(Ⅰ)은 도4를 참조하여 나중에 더 상세하게 설명된다. (Ⅱ) 플랫폼 중립성 및 (Ⅲ) 시스템-레벨 효율성을 달성하기 위해서, HAL(202)의 일 실시예는 C++ 프로그래밍 언어로 구현될 수 있다. C++ 프로그래밍 언어는 시스템-레벨 효율성을 갖는 다양한 플랫폼에 대하여 비교적 광범위하게 표준화된 지원을 제공한다. 또한, C++ 프로그래밍 언어의 객체-지향형 방법론 지원 역시 비교적 잘 조직된 소프트웨어 설계를 촉진한다. 이 기술분야의 당업자이면, 매우 다양한 프로그래밍 언어가 이용될 수 있다는 것을 알 수 있을 것이다. 다른 실시예에서는, 자바(Java) 또는 리스프(Lisp)가 이용된다.

도3은 HAL(202)에서의 하드웨어 장치의 추상화를 도시하고, 리소스 드라이버(302)와 리소스(304) 간의 관계를 도시한다. HAL(202)은 리소스(304) 및 하위-레벨 장치 드라이버(156)를 통해 하위-레벨 하드웨어 장치(306)에 통신 경로를 제공한다. 리소스(304)는 하드웨어 장치(306)에 대한 제어를 제공하기 위해 불연속의 로봇 동작들 및/또는 지각 피드백을 캡슐화하거나 나타내는 논리 구성에 대응할 수 있다. 하위-레벨 장치 드라이버(156)는 소정의 리소스(304)와 관련된 하드웨어 장치(306)를 제어하는 비교적 하위-레벨 소프트웨어에 대응할 수 있다. HAL(202)은 적절한 리소스(304)에 대응하는 리소스 드라이버(302)를 통해 하드웨어 장치(306)에 액세스한다.

리소스(304)에 의해 추상화되는 하드웨어 장치(306)는 커맨드를 수신하거나 센서 데이터를 제공하는 능동 소자(모터 등)와, 리소스(304)와 통신하지는 않지만 물리적인 세계(physical world)와 로봇의 상호작용에 영향을 미치는 수동 소자(기어, 바퀴 등) 양쪽 모두를 포함할 수 있다. 하드웨어 추상화는 비교적 단순한 것으로부터 비교적 복잡한 것에 이르기까지 다양할 수 있다. 비교적 단순한 하드웨어 추상화의 예로는, 단일 모터 조립체가 있다. 예를 들면, 모터의 드라이브 시스템의 추상화는 모터 회전의 결과로 생긴 움직임을 계산하기 위해 바퀴 직경과 기어 비율의 저장 및 이용을 포함할 수 있다. 중간 정도의 복잡성의 예에서, IR 센서와 같은 하드웨어 장치(306)는 하드웨어 장치(306)로부터 판독하여, 예를 들어, 볼트(volts) 단위일 수 있는 그 판독값을, 센티미터(cm)와 같은 적절한 치수 단위 로 변환함으로써 추상화된다. 차동(differential) 드라이브 시스템과 같은 소자의 집합체는 비교적 복잡한 하드웨어 장치(306)의 한 예이다. 차동 드라이브 시스템의 추상화의 한 예는, 2개의 모터의 속도 및 가속도의 적절한 조정을 이용하여 원하는 선속도 및 각속도를 달성한다.

리소스(304)는 물리적 장치, 물리적 접속점, 속도 인식 소프트웨어와 같은 소프트웨어 리소스 및 로봇 제어 소프트웨어가 외부 환경과 상호작용하는 다른 수단을 나타낼 수 있다. 리소스(304)는 센서 및 액추에이터, 네트워크 인터페이스, 마이크로폰 및 음성 인식 시스템, 심지어 배터리 전하 잔여량을 나타낼 수 있다. 도3에 도시된 바와 같이, 리소스(304)는 물리적 장치, 물리적 장치들의 조합, 소프트웨어 동작 또는 하드웨어 동작을 나타내거나 모델링하고, 리소스 드라이버(302)는 리소스(304)의 소프트웨어 구현에 대응할 수 있다. 3차원 얼굴을 렌더링하기 위한 소프트웨어 또는 음성 인식을 위한 소프트웨어와 같은 외부 소프트웨어 애플리케이션을 나타내는 리소스(304)에 대해서, 리소스 드라이버(302)는 외부 소프트웨어 리소스에 대한 표준 애플리케이션 프로그램 인터페이스(API)를 제공하는 중간 추상화 계층에 대응할 수 있다.

다른 예로, 드라이브 시스템을 위한 리소스(304)는 대응하는 로봇의 동작이 초당 센티미터(cm/sec)와 같은 물리적 거리 단위를 갖는 속도 및 가속도의 표현으로 특정될 수 있게 한다. 이것은, 로봇이 이동하기 위해 2개의 모터를 갖는 차동 드라이브 시스템을 이용하는지 혹은 기계적 다리를 이용하는지에 관하여 고려하지 않고 로봇 비헤비어 소프트웨어가 개발될 수 있게 한다는 장점이 있다.

하드웨어 장치(306)를 위한 리소스(304)는 하드웨어 장치의 일부, 전체 하드웨어 장치 또는 하드웨어 장치들의 조합의 추상화일 수 있다. 예를 들면, 모터 드라이브 시스템에서, 리소스(304)는 바퀴, 기어 및 모터를 추상화할 수 있다. 또한, 단일 하드웨어 장치(306) 또는 그의 위치는 하나 이상의 리소스(304)에 의해 추상화될 수 있다. 예를 들면, 모터 드라이브 시스템에 대한 추상화에 이용되는 동일한 바퀴 및 기어는 기구학적구조(odometry)의 위치 피드백에 대한 추상화에 포함될 수 있다.

도4는 HAL의 상세도이다. HAL(202)은 리소스 컨테이너(402)를 포함하며, 결과적으로 하나 이상의 리소스 드라이버(302, 404, 406)를 포함한다. 리소스 컨테이너(402)내의 리소스 드라이버의 수는 매우 다양하게 변할 수 있음을 인지해야 한다. 리소스 구성(408)은 리소스 드라이버(302, 404, 406)를 생성하는데 이용되는 정보를 포함할 수 있다. 리소스 구성(408)은 영구 데이터 저장 장치(410)에 저장될 수 있다. 리소스 구성(408)의 일 실시예는 도6을 참조하여 나중에 더 상세하게 설명된다.

HAL(202)의 이득(Ⅰ) 즉, 하드웨어 장치를 추상화하기 위해 유연성있는 프레임워크를 제공하는 이득은 도2를 참조하여 이전에 간결하게 설명되었다. 일 실시예에서, HAL(202)의 이득(Ⅰ)은 유리하게 다음의 장점들 중 적어도 일부를 구현함으로써 실시될 수 있다.

I(a) XML과 같은 비교적 일반적이고 이식가능한 장치 기술 포맷을 이용하여 HAL(202)에 이용가능한 리소스를 기술하는 리소스 구성(408)을 제공하고;

I(b) 리소스(304)에 의해 추상화된 장치(306)의 생명 주기를 관리하고;

I(c) 실세계 개념 및 단위에 근거하여 다양한 로봇 동작을 위해 확장성 소프트웨어 인터페이스 세트를 제공하고;

I(d) 상위-레벨 소프트웨어에 리소스(304)와의 액세스를 제공하고; 그리고

I(e) 장치(306)에 액세스하기 위한 보안 메커니즘을 제공한다.

도5는 논리 장치 버스를 통해서 하드웨어 장치를 프로세싱 유닛에 연결하는 것을 도시한다. 특정 로봇 플랫폼에서 이용가능한 리소스(304)는, HAL(202)이 리소스(304)를 적절하게 추상화하여 그 추상화된 리소스(304)가 상위-레벨 소프트웨어에 의한 사용을 위해 이용가능하게 될 수 있도록, HAL(202)에 기술되어야 한다. 일 실시예에서, 리소스(304)는 HAL(202)에 리소스 구성(408)이라 칭해지는 트리형 계층 데이터 구조로 기술된다. 리소스 구성(408)의 조직화(organization)는 로봇 하드웨어 장치의 프로세싱 하드웨어(502)에의 실세계 연결을 모방할 수 있다.

다양한 하드웨어 장치는 논리 장치 버스를 통해서 로봇의 프로세싱 소자(502)에 연결될 수 있다. 논리 장치 버스는 하드웨어 데이터 버스를 포함할 수 있으며, 이 하드웨어 데이터 버스는 예를 들면, 직렬 포트, 병렬 포트, PCI 버스, USB, 파이어와이어(Firewire) 등과 같은 매우 다양한 하드웨어 데이터 버스에 해당할 수 있다. 논리 장치 버스는 하드웨어 데이터 버스를 거쳐서 로봇 장치와 통신하는데 이용되는 특별한 프로토콜 또는 드라이버를 포함하는 논리 구조에 더 대응할 수 있다.

예를 들면, 로봇 장치 A(306)와 하드웨어 장치 B(504)는 제1 USB 포트에 연 결하며 휴먼 인터페이스(human interface) 드라이버를 이용하고, 하드웨어 장치 C(506)는 역시 USB 포트에 접속하지만 가상 COM 포트 드라이버를 이용한다. 하드웨어 장치 A(306)와 하드웨어 장치 B(504)는 USB 하드웨어 포트와 휴먼 인터페이스 드라이버의 집합체인 제1 논리 데이터 버스(510)에 연결한다. 대조적으로, 하드웨어 장치 C(506)는 USB 하드웨어 포트와 가상 COM 포트 드라이버의 집합체인 제2 논리 데이터 버스(512)에 연결한다. 도5는 제2 논리 데이터 버스(512)에 또한 연결된 하드웨어 장치 D(508)를 더 도시한다. 논리 데이터 버스의 수는 매우 다양하게 변할 수 있음을 인지해야 한다.

하나 이상의 하드웨어 장치(306, 504, 506, 508)는 단일 논리 장치 버스에 부착될 수 있지만, 단일 장치는 하나 이상의 논리 장치 버스에 부착되어서는 안된다는 것을 인지해야 한다. 복수의 하드웨어 장치(306, 504, 506, 508)는 장치 그룹으로 집단화될 수 있다.

도6은 리소스 구성(408)의 일 실시예의 상세도이다. 리소스 구성(408)은 하나 이상의 장치 그룹 구성 및 하나 이상의 장치 버스 구성을 포함할 수 있다. 장치 그룹 구성은 하드웨어 장치에 대한 하나 이상의 참조를 포함할 수 있다. 예를 들면, 도6의 제1 장치 그룹 구성(602)은 제1 장치 참조(604) 및 제2 장치 참조(606)를 갖는 것으로 도시되어 있다.

제1 장치 그룹 구성(602)은, 제1 장치 그룹 구성(602)에 대응하는 하드웨어 장치들이 서로 어떻게 상호작용하는지를 관리하는, 이전에 도3을 참조하여 설명된 리소스 드라이버(302)와 같은, 대응하는 리소스 드라이버의 구현을 이용한다. 모터 드라이브 시스템을 위한 리소스 드라이버는 장치 그룹 구성을 구현하는 리소스 드라이버의 한 예로써, 이 모터 드라이브 시스템을 위한 리소스 드라이버는 하나 이상의 모터, 기어 및 바퀴를 집단화할 수 있다. 일 실시예에서, 장치가 로봇에 어떻게 그리고 어디에 장착되는지에 대한 물리적 특성은 장치 기술 자체의 부분이고, 즉, 구조 및 장치는 HAL(202)의 리소스 구성에 기술되며, 특정 장치가 어떻게 그리고 어디에 장착되는지에 대한 물리적 특성은 장치 그룹 구성의 장치들과 집단화되지 않는다. XML 포맷의 IRSensor에 대한 장치 구성의 한 예가 하기에 제공된다.

상기에 보인 예에서, id 속성은 IR 장치를 고유 식별한다. 타입(type) 속성은 장치가 USB IR 센서임을 나타낸다. 어드레스 값(address value)은 이 장치가 발견될 수 있는 논리 장치 버스상의 어드레스를 나타낸다. 링크 값(link value)은 이 장치가 어떻게 로봇에 부착되는지를 나타낸다. x, y 및 z 변수는 로봇에 대한 장치의 위치에 대응한다. 롤(roll), 피치(pitch) 및 요(yaw) 변수는 로봇에 대한 장치의 오리엔테이션(orientation)에 대응한다.

도5를 참조하여 설명된 바와 같은 이용가능한 논리 장치 버스는 또한 리소스 구성(408)에도 기술되어야 한다. 논리 장치 버스에 대한 기술(description)은 도6에 도시된 바와 같은 장치 버스 구성에 대응한다. 예를 들면, 제1 장치 버스 구성(608)은 제1 논리 데이터 버스(510)에 대응할 수 있고, 제2 장치 버스 구성(610)은 제2 논리 데이터 버스(512)에 대응할 수 있다.

장치 버스 구성은 소프트웨어에서 논리 장치 버스를 활성화하여 이용하는데에 사용되는 임의의 정보를 포함해야 한다. 예를 들면, 논리 장치 버스가 직렬 프로토콜의 추상화인 경우, 대응하는 장치 버스 구성은 변조 속도(baud rate), 패리티(parity) 등과 같은 임의의 관련 직렬 통신 파라미터를 포함해야 한다.

하드웨어 장치는 해당 장치 구성에 의해 특정 및 정의될 수 있다. 예를 들면, 도5에 도시된 바와 같은 하드웨어 장치 A(306), 하드웨어 장치 B(504), 하드웨어 장치 C(506) 및 하드웨어 장치 D(508)는 제1 장치 구성(612), 제2 장치 구성(614), 제3 장치 구성(616) 및 제4 장치 구성(618) 각각에 의해 특정 및 정의될 수 있다. 장치 구성(612, 614, 616, 618)은 길이, 폭, 질량 등과 같은 장치의 물리적 특성에 속하는 정보를 포함할 수 있고, 장치의 위치를 포함할 수 있고, 그리고 필요에 따라, 로봇에 대한 오리엔테이션을 포함할 수 있다.

제1 하드웨어 장치(306)가 카메라에 대응하는 예에서, 로봇에 대한 카메라의 위치 및 오리엔테이션은 유용할 수 있고, 대응하는 장치 구성(612)에 포함되어야 한다. 그러나, 이러한 위치 및 오리엔테이션 정보는 텍스트를 음성으로 변환하는 장치(text-to-speech device)와 같은 다른 로봇 장치와 관련이 없을 수도 있다.

대응하는 로봇 장치가 연결되어 있는 논리 장치 버스의 논리 장치 버스 구성하에서 하나 이상의 장치 구성이 그룹화된다. 제1 장치 버스 구성(608)과 같은 장치 구성은, 장치 파라미터를 포함하여, 소프트웨어에 하나 이상의 대응하는 하드웨어 장치(306, 504)를 활성화하여 이용하기 위해 이용되는 정보를 포함하는 것이 바람직하다. 예를 들면, 하드웨어 장치 B(504)가 적외선(IR) 센서에 해당하는 경우, 제1 논리 데이터 버스(510)상의 적외선 센서의 어드레스, 센서에 대한 교정 데이터 및 센서의 최소 및 최대 범위 등과 같은 정보가 특정되어야 한다. 다른 예로, 리소스가 단지 하드웨어 장치 C(506)에 대해서만 추상화하는 것과 같이, 하나의 로봇 장치에 대해서만 추상화하는 경우, 대응하는 장치 구성(616)은 장치 데이터를 장치 단위로부터 실세계 단위와 같은 보다 편리한 단위로 변환하는데 이용되는 변환 계수(factor)를 포함하여, 리소스(304)가 하드웨어 장치 C(506)를 적절하게 추상화하는데 이용되는 데이터를 충분히 특정해야 한다.

제1 장치 버스 구성(608)과 같은 각각의 장치 버스 구성, 제1 장치 구성(612)과 같은 각각의 장치 구성 및 제1 장치 그룹 구성(602)과 같은 각각의 장치 그룹 구성은 고유 식별자(id) 스트링에 의해 식별될 수 있다. HAL(202)의 일 실시예는 이 고유 id를 이용하여 서로 다른 리소스들 간을 효율적으로 구별한다.

도7은 리소스 드라이버 객체가 IResourceDriver 및 1개 이상의 IResource 인터페이스로부터 어떻게 유도되는지를 도시한다. 선택된 리소스(304)에 대한 리소스 인터페이스(702)를 획득하기 위해서, HAL(202)의 일 실시예는 선택된 리소스(304)의 id를 이용함으로써 리소스 컨테이너(402)로부터 "obtain_interface" 메소드(method)와 같은 메소드를 호출한다.

이제 도6을 참조하면, 로봇에 2개의 IR 센서가 장착되어 있는 한 예에서, 제1 IR 센서에 대한 제1 장치 구성(612)은 "IR1"의 id를 가질 수 있고, 제2 IR 센서에 대한 제2 장치 구성(614)은 "IR2"의 id를 가질 수 있다. 이들 센서 둘다 거리 센서(range sensor)이고, 로봇 소프트웨어가 이들 센서를 이용하기 위해서, HAL(202)은 리소스 컨테이너(402)로부터 IRangeSensor를 검색하여, 적절한 id 즉, 제1 센서에 대해 "IR1" 및 제2 센서에 대해 "IR2"가 리소스 컨테이너(402)의 "obtain_interface" 메소드의 제2 파라미터(resource_id)로서 전달된다.

리소스(304)가 복수의 장치를 추상화할 경우, 리소스(304)는 도6을 참조하여 이전에 설명된 바와 같이 장치 그룹 구성으로서 기술될 수 있다. 제1 장치 그룹 구성(602)과 같은 장치 그룹 구성은 그 장치 그룹 구성에 하드웨어 장치의 장치 참조에 대한 참조를 포함할 수 있다. 예를 들면, 제1 장치 그룹 구성은 제1 장치 참조(604) 및 제2 장치 참조(606)를 포함한다.

일 실시예에서, 제1 장치 참조(604)와 같은 장치 참조는 단지 제1 장치 참조(604)가 가리키는 제2 장치 구성(614)과 같은 장치 구성을 고유 식별하기에 충분한 데이터만을 포함한다. 고유 식별자는 관련 데이터베이스내의 식별자 또는 리소스 구성(408)의 확장성 생성 언어(XML) 구현시의 식별자에 대응할 수 있으며, 제1 장치 참조(604)는 이 제1 장치 참조(604)가 가리키는 제2 장치 구성(614)의 id를 포함하는 XML 태그에 대응할 수 있다. 제1 장치 그룹 구성(602)의 제1 장치 참조(604) 및 제2 장치 참조(606)와 같은 장치 그룹 구성의 장치 참조는 다양한 장치 버스 구성의 하나 이상의 장치 구성을 가리킬 수 있다.

일 실시예에서, 하드웨어 장치 B(504) 및 하드웨어 장치 D(508)와 같은 복수의 하드웨어 장치는 서로 다른 논리 장치 버스(510, 512)에 부착되어 있어도, 리소스에 의해 추상화될 수 있다. 별개의 논리 장치 버스와 통신하는 하드웨어 장치를 포함할 수 있는 하드웨어 장치의 그룹을 추상화하는 능력은, 가능하며 HAL(202)에 의해 지원될 수 있는 장치 그룹 구성의 수를 확장한다는 장점이 있다. 일 실시예에서, 장치 그룹내의 장치들의 집단화는 그 그룹에 대한 별개의 리소스 드라이버(302)에 대응한다.

리소스 구성(408)은 또한 로봇에 대한 구조 정보를 저장할 수 있다. 일 실시예에서, 구조 정보는 하나 이상의 형상(shape) 구성(632)을 포함하는 차원(dimension) 구성(630)에 유지된다. 각각의 형상 구성(632)은 로봇의 고정(rigid) 구조 요소에 관한 정보를 포함할 수 있다. 한 예에서, 이 정보는 다음 중 적어도 하나와 같은 정보를 유지하도록 구성될 수 있다.

- 상향을 가리키는 정극성(positive)의 z-축 및 전방을 가리키는 정극성의 x-축을 갖는 우측 좌표 시스템(right hand coordinate system)을 이용하는 x, y, z 좌표에 의하여 로봇의 접지 중심(ground center)에 상대적인 고정 구조 요소의 위치

- x, y 및 z 축에 따른 치수에 의한 구조 요소의 크기

- 롤, 피치 및 요에 의한 구조 요소의 오리엔테이션

- 고정 구조 요소와 관련된 링크의 id

형상 구성(632)에 추가하여, 리소스 구성(408)은 링크에 접속된 조인트(joint)를 기술하는 링크 구성(634)을 포함한다. 각각의 링크 구성(634)은 하나의 고정 구조 요소를 나타낼 수 있으며, 고유 id를 갖는다. 일 실시예에서, 링크 구성(634)은 Denavit-Hartenberg 파라미터를 이용하여 고정 구조 요소를 다른 고정 구조 요소에 접속하는 조인트에 관한 정보를 포함한다.

리소스 구성(408)의 저장 포맷은 매우 다양하게 변할 수 있다. 일 실시예는 유리하게 XML 파일을 이용하여 구현되지만, 이 기술분야의 당업자이면, 리소스 구성(408)의 포맷은, 적절한 장치 정보가 검색가능한 포맷으로 저장되면, 사실상 무엇이든지 될 수 있다는 것을 알 수 있을 것이다. 리소스 구성(408)은 또한 필요한 경우 HAL(202)에 의한 검색을 위해, 플래시 메모리 또는 하드 드라이브와 같은 접근가능 영구 데이터 저장 장치(410)에 저장되어야 한다.

리소스 구성(408)은 리소스 구성 구문분석기(parser)에 의해 검색될 수 있다. 일 실시예에서, 리소스 구성 구문분석기는 HAL(202)에 의해 내부적으로 이용가능한 포맷으로 리소스 구성(408)에 저장된 장치 구성을 구문분석하는 책임을 지는 소프트웨어 모듈에 대응할 수 있다. 구문분석된 리소스 구성 정보는 HAL(202)에 의해 저장 및 이용되는 리소스 컨테이너(402)에 제공된다. 일 실시예에서, 표준 XML 구문분석 기술은 리소스 구성 구문분석기에 의해, 리소스 구성(408)의 XML 기반의 구현을 구문분석하는데 이용될 수 있다. 리소스 구성(408)은, 비교적 일반적이고 이식가능한 장치 기술 포맷을 이용하여 HAL(202)에 이용가능한 리소스를 기술하는 리소스 구성(408)을 제공하는 장점 I(a)를 제공할 수 있다.

리소스 컨테이너(402)는 리소스 구성 구문분석기를 통해서 적용가능 로봇 플랫폼상의 이용가능한 리소스(408)에 관한 정보를 획득한다. 일 실시예에서, 각각의 리소스(304)에 대해서, 제1 장치 구성(612)과 같은 장치 구성에 의해서 혹은 제1 장치 그룹 구성(602)과 같은 장치 그룹 구성에 의해서 기술되는 바와 같이, 하나 이상의 장치를 추상화할 수 있는 리소스 드라이버(302)가 존재한다.

리소스 컨테이너(402)는 리소스 구성(408)내의 각각의 장치 구성 또는 장치 그룹 구성에 대하여 대응하는 리소스 드라이버(302)를 생성할 수 있다. 일 실시예에서, 생성된 리소스 드라이버(302)에 대한 참조가 드라이버 테이블에 저장된다. 리소스 컨테이너(402)는 또한 각각의 리소스 드라이버(302)에 대한 종속물 목록(dependency list)을 계산할 수 있다. 종속물 목록은, 애플리케이션에 따라, 활성화 순서로 리소스 드라이버(302)보다 우선해야 하는 다른 리소스 드라이버(302)의 목록을 포함할 수 있다. 활성화 순서는 하드웨어 장치 A(306) 또는 하드웨어 장치 B(504)와 같은 하나 이상의 하드웨어 장치를 추상화하는 복합 리소스 드라이버가 존재할 경우에 중요할 수 있다.

일 실시예에서, 각각의 개별 하드웨어 장치(306, 504, 506, 508)에 대한 리소스 드라이버(302)는 복합 리소스 드라이버(302)가 활성화되기 전에 활성화되어야 한다. 리소스 컨테이너(402)는 하나 이상의 리소스 드라이버의 종속물 목록을 이용하여, 리소스 드라이버(302)가 활성화되어야 하는 순서를 결정한다. 일단 만족할만한 활성화 순서가 결정되었다면, 리소스 컨테이너(402)는 애플리케이션가능 리소스 드라이버를 활성화 순서로 활성화할 수 있다. 리소스의 활성화 및 비활성화를 지원 하기 위해서, HAL(202)은 IResourceDriver 인터페이스(706)를 포함할 수 있다.

도7에 도시된 바와 같이, IResourceDriver 인터페이스(706)는 "activate" 및 "deactivate" 가상 메소드를 포함한다. 리소스 드라이버(302)의 구현은 IResourceDriver 인터페이스(706)로부터 유도하여, "activate" 및 "deactivate" 가상 메소드를 구현해야 한다. "activate" 메소드는 리소스 드라이버(302)를 소프트웨어에서 이용하기 위한 준비를 하는데 이용되는 태스크를 수행해야 한다. "deactivate" 메소드는 리소스 드라이버(302)에 의해 이용된 데이터를 없애고, 리소스 드라이버(302)에 의해 추상화된 대응하는 하드웨어 장치를 적절하게 셧다운한다.

리소스의 활성화 시퀀스가 결정되었을 때, 리소스 컨테이너(402)는 활성화 시퀀스에 따라 각각의 리소스 드라이버(302)의 "activate" 메소드를 호출한다. 일 실시예에서, 비활성화 시퀀스는 활성화 시퀀스의 반대이다. 예를 들면, 소프트웨어가 종료할 때, 리소스 컨테이너(402)는 활성화 순서와 반대의 순서로 "deactivate" 메소드를 호출함으로써 리소스 드라이버(302)를 비활성화한다. 리소스 드라이버(302)의 "activate" 및 "deactivate" 메소드와, 리소스 컨테이너(402)에 의한 이러한 메소드들의 이용에 의하여, 장점 I(b)을 달성한다.

HAL(202)의 장점 I(c)는 실세계 개념 및 단위에 근거하여 다양한 로봇 동작을 위한 확장성 소프트웨어 인터페이스 세트를 제공하는 것이다. 이 확장성 리소스 인터페이스 세트는 본원에서 리소스 인터페이스(702)로서 기술되며, HAL(202)의 리소스 드라이버(302)에 의해 구현될 수 있다. 리소스 드라이버(302)는 하나 이상의 리소스 인터페이스(702)를 구현함으로써 로봇 동작을 추상화 및 캡슐화한다. 리소스 인터페이스(702)는 기준(base) IResource(704) 인터페이스 정의로부터 유도할 수 있고, 로봇 동작 또는 장치의 타입을 캡슐화할 수 있다. 전형적으로, 도7에 도시된 바와 같이, 리소스 드라이버(302) 객체는 IResourceDriver 기준 클래스(706)와 그것이 구현하는 리소스 인터페이스(702)의 기준 클래스 둘다로부터 유도한다.

리소스 인터페이스(702)는 일련의 로봇 동작을 수행하는 함수 호출 (메소드) 목록에 대응할 수 있다. 상위-레벨 소프트웨어는 리소스 드라이버(302)와 상호작용하여, 결국 리소스 드라이버의 리소스 인터페이스(들)에 대한 참조를 수신하고 리소스 인터페이스의 메소드를 호출함으로써 하부 하드웨어 장치와 상호작용한다. 이들 메소드와 그의 파라미터 및 결과는 하부 하드웨어 또는 구현에 대한 가정이 없이, 실세계 표현으로 편리하게 정의될 수 있다. 예를 들면, 코드 블록9와 관련하여 나중에 더 상세하게 설명되는 IDriveSystem 리소스 인터페이스는 "move_and_turn"과 같은 메소드를 포함할 수 있으며, 이 메소드는 속도를 위한 초당 센티미터(cm/sec) 및 가속도를 위한 cm/sec² 와 같은 표준 단위를 이용하여, 원하는 선속도 및 각속도와 대응하는 가속도의 특정화에 의해 로봇의 동작 제어가 가능하도록 구성될 수 있다. 다른 예로는, 거리 센서로부터의 판독값을 센티미터(cm)와 같은 편리한 거리 단위로 리턴하는 "get_distance_reading" 메소드를 제공하도록 구성될 수 있는 IRangeSensor 리소스가 있다. 리소스 인터페이스 및 대응하는 메소드의 표본 목록은 나중에 표본 코드 블록의 논의후 설명된다.

리소스 인터페이스(702)의 확장성을 지원하기 위해서, HAL(202)은, 리소스 인터페이스(702)를 구현하는 코드가 동적 로드가능 공유 라이브러리에 존재함을 특정할 수 있다. 윈도우즈에서의 동적 링크 라이브러리 및 다른 플랫폼에서의 공유 라이브러리 또는 공유 객체로서 알려져 있는 이러한 구조는 최신의 운영 시스템에 의해 지원되며, 이하 "공유 라이브러리"로서 칭해질 것이다. 리소스 드라이버 구현을 포함하는 공유 라이브러리의 명칭 및 위치는 리소스 구성(408)의 부분으로서 특정되어야 한다. 따라서, 동일한 리소스 드라이버(302)에 의해 추상화되는 태스크를 수행하는 다른 하드웨어에 대한 다른 구현은 다른 공유 라이브러리에서 구현될 수 있고, 정확한 라이브러리는 이용되고 있는 하드웨어를 위해 로드된다. 이것은 새로운 구현이 쉽게 프레임워크에 추가될 수 있게 한다. 또한, 새로운 리소스 드라이버는 심지어 제3자에 의해서도 정의될 수 있으며, 그들의 구현은 실행시간에 로봇 시스템으로 로드되는 새로운 공유 라이브러리에 저장될 수 있다.

리소스 드라이버(302)를 포함하는 공유 라이브러리를 식별한 후, HAL(202)은 리소스 드라이버(302)를 사례화(instantiate)할 수 있다. 그러나, 리소스 드라이버(302)가 사례화될 때 공유 라이브러리가 로드됨을 증명하는 것이 바람직할 수 있다. 일 실시예에서, 공유 라이브러리는 실행가능한 것으로 직접 링크되어 실행(run)하지만, 불편하고 비실용적일 수 있다. 바람직하게는, 리소스 드라이버 id 및 그의 공유 라이브러리는 동적 로드를 가능하게 하는 어떤 방식으로 통지되어야 한다. 일 실시예에서, HAL(202)은 C++ 매크로 DECLARE_RESOURCE를 제공하는데, 이 C++ 매크로 DECLARE_RESOURCE는 리소스 드라이버(302) 코드에 배치되어 그의 id 및 공유 라이브러리명을 통지한다. DECLARE_RESOURCE 매크로는 HAL(202)에 의해 리소스 드라이버를 생성하는데 이용되는 하나 이상의 메소드 및 데이터 항목의 선언을 포함할 수 있다. DECLARE_RESOURCE 매크로는 리소스 드라이버의 구현자(implementor)가 이들 표준 메소드 및 데이터 멤버(member)에 타이핑(type)하지 못하게 할 수 있다는 장점이 있다. 예를 들면, 이들 메소드는, HAL(202)이 리소스 드라이버의 인스턴스(instance)를 생성하기 위해 호출할 수 있는 "create_resource" 및 HAL(202)이 리소스 드라이버의 id를 검색하기 위해 호출할 수 있는 "get_driver_id"를 포함할 수 있다. DECLARE_RESOURCE 매크로에 선언된 데이터 멤버는 리소스 드라이버의 id를 포함한다.

일 실시예에서, HAL(202)은 운영 시스템에 설정된 환경 변수의 경로하에서 리소스 디렉토리를 검색한다. 리소스 드라이버(302)의 리소스 구성(408)은 리소스 드라이버(302)를 포함하는 공유 라이브러리의 명칭을 특정할 수 있다. 리소스 드라이버의 id가 등록되지 않았을 경우, HAL(202)은 공유 라이브러리를 로드하기 위한 운영 시스템 방법을 이용함으로써, 리소스 드라이버(302)를 포함하는 공유 라이브러리를 로드하고자 시도할 수 있다.

C++ 구현에서, 리소스 드라이버(302)는 IResourceDriver 인터페이스(706)와 그것이 구현하는 IResource-유도 리소스 인터페이스(702)로부터 유도한다. 그 다음, 리소스 드라이버(302)는 추상화되는 리소스(304)의 특정 세부사항에 대한 적절한 코드를 이용하여 이들 인터페이스의 가상 메소드를 구현한다.

다양한 리소스 드라이버(302) 및 리소스 인터페이스(702)가 소정의 시스템에 존재할 수 있다. 다음은 어느 리소스 인터페이스(702)가 실제로 이용가능한지를 식별하기 위한 하나의 방식을 설명한다.

IResourceDriver 인터페이스(706) 기준 클래스는 리소스 드라이버(302)에 의해 구현되어야 하는 가상 "obtain_interface" 메소드를 특정한다. 이 메소드는, 어느 리소스 인터페이스(702)가 구현하는지를 리소스 드라이버(302)가 식별하는 메소드이다.

이 메소드는 입력으로서 인터페이스 리소스 id를 받아들인다. 리소스 드라이버(302)가 특정된 id를 갖는 리소스 인터페이스(702)를 구현할 때, "obtain_interface" 메소드는 명명된 리소스 인터페이스(702)에 대한 유효 참조를 리턴하고, 그 다음에 그 리소스 인터페이스(702)의 메소드를 직접 호출하는데 이용될 수 있다.

장점 I(d)는, 리소스가 상위-레벨 소프트웨어에 이용가능하게 된다는 것이다. 일단 리소스 드라이버(302)가 활성화되었다면, 리소스 컨테이너(402)는 리소스가 상위-레벨 소프트웨어에 의해 이용하기 위해 이용가능하게 한다. 일 실시예에서, 리소스 컨테이너(402)는 그 자신의 "obtain_interface" 메소드를 통하여 리소스를 이용가능하게 한다. 이 메소드는 리소스 드라이버 id 및 리소스 인터페이스 id를 받아들인다. 리소스 컨테이너(402)는 특정 리소스 드라이버를 배치하고, 그 다음 그 드라이버의 "obtain_interface" 호출을 호출하여 특정 리소스 인터페이스(702)가 구현되는지를 결정한다. 특정 리소스 인터페이스(702)가 특정 리소스 드라이버(302)에 의해 구현되는 경우, 리소스 컨테이너(402)의 "obtain_interface" 메소드는 그 리소스 인터페이스에 대한 유효 참조를 리턴한다. 특정 리소스 인터페이스(702)가 특정 리소스 드라이버(302)에서 이용가능하지 않은 경우, "obtain_interface" 호출은 적절한 에러 코드를 리턴한다. 이것은, 상위-레벨 소프트웨어가 원하는 리소스 인터페이스(702)에 대해 리소스 컨테이너(402)를 조회할 수 있게 한다. 일단 상위-레벨 소프트웨어가 원하는 리소스 인터페이스(702)를 수신하면, 상위-레벨 소프트웨어는 그 인터페이스의 메소드를 호출하여 리소스(304)와 상호작용할 수 있다. 예를 들면, 일단 상위-레벨 소프트웨어가 거리 센서에 대한 원하는 IRangeSensor 리소스 인터페이스를 획득하면, 상위-레벨 소프트웨어는 IRangeSensor 인터페이스의 get_distance_reading 메소드를 호출하여, 그 센서로부터의 판독값을 편리한 실세계 거리 단위로 획득할 수 있다.

도8은 거리 센서의 예를 이용하여, 리소스가 상위-레벨 소프트웨어에 이용가능하게 되도록 하는 프로세스를 도시한다. 리소스가 이용가능하게 되도록 하는 프로세스는 장점 I(d)과 관련하여 이전에 간결하게 설명되었다. 도8에서, 비헤비어(상위-레벨 소프트웨어)는 거리 센서 "IR1"로부터 판독값을 요구한다. 상위-레벨 소프트웨어는 리소스 컨테이너(402)의 obtain_interface 메소드를 호출하여 센서 "IR1"의 IRangeSensor 인터페이스를 검색한다. 이러한 요구를 이행하기 위해서, 리소스 컨테이너(402)는 그의 리소스 드라이버 테이블을 통해서 검색하여 리소스 "IR1"에 대응하는 리소스 드라이버(302)를 배치한다. 일단 발견되었다면, 리소스 컨테이너(402)는 그의 IRangeSensor 리소스 인터페이스를 요구하는 리소스 드라이버(302)의 obtain_interface 메소드를 호출한다. "IR1"에 대응하는 리소스 드라이 버(302)는 IRangeSensor 리소스 인터페이스를 구현하여, 리소스 컨테이너(402)에 센서 "IR1"을 위한 IRangeSensor 리소스 인터페이스에 대한 참조를 리턴하고, 결과적으로 요구 비헤비어에 리턴한다. 이 비헤비어는 이제 거리 센서 "IR1"에 대한 IRangeSensor 리소스 인터페이스에 대하여 참조를 가지며, 이제 이 리소스 인터페이스의 get_distance_reading 메소드를 호출하여 편리한 실세계 거리 단위로 "IR1" 거리 센서의 판독값을 얻을 수 있다. 거리 센서 리소스 드라이버(302)가 거리 센서 인터페이스에 대한 참조를 리턴하여 적절한 거리 판독값을 제공할 수 있는 메소드에 대한 한 예가 "리소스 드라이버 상세설명"과 관련하여 나중에 설명된다.

일 실시예에서, 비헤비어 또는 태스크 계층에서 상위-레벨 소프트웨어는 단지 리소스 컨테이너(402) 및 리소스 인터페이스(702)와 인터페이스한다. 비록 상위-레벨 소프트웨어가 다른 로봇 하드웨어 플랫폼에 이식되더라도, HAL(202)은 새로운 로봇 하드웨어 플랫폼의 리소스 구성(408)에 근거하여 정확한 리소스 드라이버(302)를 로드함으로써 이러한 이식을 처리한다. 새로운 로봇 하드웨어 플랫폼에 더이상 이용가능하지 않은 리소스 인터페이스(702)의 상태는 리소스 컨테이너의 "obtain_interface"에 의해 리턴된 에러 결과 코드를 이용하여 상위-레벨 소프트웨어에 의해 확인될 수 있고, 그 리소스에 의존하는 동작은 적절하게 작동하지 않을 수 있다.

장점 I(e)는 HAL(202)이 제1 하드웨어 장치(306)와 같은 하드웨어 장치에 액세스하기 위한 보안 메커니즘을 제공해야 함을 나타낸다. 보안을 위해 HAL(202)에 의해 제공될 수 있는 하나의 메커니즘은, 매(every) 메소드 호출에 보안 파라미터를 포함시키는 것이다. 본원에서 티켓 id로 칭해지는 파라미터는 보안 티켓을 나타내며, 바람직하게는 리소스 인터페이스(702)의 공개(public) 메소드의 제1 파라미터이다.

이 메커니즘은 개별 메소드 레벨에 이르기까지 비교적 미세한 보안성 입도(granularity)를 지원한다. 예를 들면, 특정 보안성 배제(clearance)를 위하여, 리소스 인터페이스(702)의 어떤 메소드는 사용이 가능하고, 다른 메소드는 사용이 제한될 수 있다. 또한, 리소스 드라이버(302)의 "obtain_interface" 메소드는 예약 카운트 파라미터(reservation count parameter)를 갖는다. 이 파라미터는 리소스 드라이버(302)에 대한 동시 액세스가 몇번 허용되는지를 나타낸다. 예를 들면, 이 예약 카운트는 몇개의 클라이언트가 동시에 리소스 드라이버(302) 인터페이스에 대한 참조를 홀드(hold)할 수 있는지를 리소스 컨테이너(402)에 나타내는데 이용될 수 있다. 리소스 컨테이너(402)는 이 예약 카운트를 이용하여 참조를 추적하고 이 예약 카운트가 꽉 차 있으면 클라이언트에 대한 인터페이스를 거절한다. 임의의 수의 동시 액세스가 허용되는 경우, 참조 카운트는 0으로 설정될 수 있다.

예약 카운트가 유용하게 될 수 있는 하나의 경우는, 리소스 드라이버(302)가 리소스 드라이버(302)의 내부 상태를 변경하는 "기입기(writer)" 리소스 인터페이스(702)에 대해 한번에 단지 1회의 액세스만을 지원하지만, 단지 리소스 드라이버(302)의 내부 상태를 조회하는 "판독기(reader)" 리소스 인터페이스(702)에 대해 무제한 액세스를 지원하는 경우이다. 판독기 리소스 인터페이스는 0의 예약 카운트를 특정할 수 있으며, 이것에 의해 무제한 액세스가 허용될 수 있고, 기입기 리소스 인터페이스는 1의 예약 카운트를 특정할 수 있어 한번에 단지 1회의 기입 액세스만이 가능하게 된다. 리소스 드라이버(302)의 "obtain_interface" 메소드의 티켓 id 및 예약 카운트 파라미터는 장점 I(e)를 제공할 수 있다.

리소스 드라이버 상세설명

다음은 IR 센서에 대한 리소스 드라이버의 구현의 예를 포함하여, 리소스 드라이버(302)가 어떻게 생성될 수 있는지에 관하여 더 상세하게 설명한다.

리소스 드라이버는 적절한 인터페이스 클래스(들)에 추가하여, 추상화 클래스 IResourceDriver로부터 유도함으로써 구현될 수 있다. IResourceDriver는 HAL(202)의 다른 성분들이 드라이버와 상호작용하는 기본적인 메소드를 선언한다. 그러나, HAL(202)은 ResourceDriverImpl이라 불리는, IResourceDriver로부터 유도되는 헬퍼(helper) 클래스를 제공할 수 있으며, 이것은 "add_ref" 및 "remove_ref"와 같은 메소드의 이용가능한 디폴트 구현을 제공함으로써 드라이버 생성을 용이하게 한다. 그 다음, 드라이버는 초기화, 활성화를 위한 메소드, 그리고 그 드라이버가 구현하는 리소스 인터페이스(들)(702)의 메소드를 다시 정의내릴 수 있다.

초기화

리소스 드라이버의 구성자(constructor)에서의 초기화는 일반적으로 비교적 간단해야 하는데, 그 이유는 하드웨어 액세스 및 구문분석 구성 정보가 전형적으로 활성화 단계에서 일어나기 때문이다. 메소드는 객체의 멤버 변수를 초기화하여 그것을 활성화할 준비를 한다. 다음은 IRSensor 구성자의 비교적 간단한 구현에 대응 하는 표본 코드이다.

코드 블록1(도9)

예시된 실시예에서, 구성자는 단지 데이터 멤버를 디폴트 0값으로 초기화한다.

활성화

일 실시예에서, 3가지 메소드 즉, "activate", "deactivate" 및 "is_active"이 리소스 드라이버의 활성화를 조정한다. 그 명칭이 의미하는 바와 같이, 이 메소드들은 각각 활성화, 비활성화 및 활성화 상태의 표시를 담당한다. 활성화 및 비활성화는 반복적으로 일어날 수 있으며, 예를 들면, 고장안전 시스템이 장치를 리셋하고자 하여 작업을 중단시킨 드라이버를 비활성화 및 재활성화할 수 있고, 리소스 드라이버(302)는 이러한 어커런스(occurrence)를 정확하게 조정해야 한다. "activate" 및 "deactivate" 시퀀스후, 리소스 드라이버(302) 및 하드웨어는 활성화하기 전과 동일한 상태로 돌아가야 한다. 이러한 이유로, 하드웨어, 스레딩(threading), 및/또는 네트워크 또는 다른 통신 초기화는 구성자(constructor)에서 일어나서는 안되며, "activate"에서 일어나야 한다. 셧다운은 "deactivate"에서 일어나야 한다. 리소스 구성(408)의 판독은 "activate"에서 일어나야 하고, 리소스 구성(408)내의 파라미터를 이용하여 리소스 드라이버를 적절한 상태로 설정해야 한다. "is_active" 메소드는, 활성화가 성공적으로 완료된 경우, "참(true)" 표시를 리턴하고, 그렇지 않은 경우, "거짓(false)" 표시를 리턴할 수 있다. "is_active" 메소드는 드라이버의 상태에 관한 정확한 보고를 제공한다는 것에 주목해야 한다. 리소스 드라이버(302)를 관리하는 리소스 컨테이너(402)는 이 정보를 이용하여, 하드웨어가 정확하게 수행중인지 여부와 드라이버가 인터페이스 포인터에 대한 요구를 수락할 준비가 되어 있는지 여부를 결정할 수 있다.

또한, "activate" 메소드는 그의 실행 초기에 "is_active"를 검사하여, 리소스 드라이버(302)가 이미 활성이면, 즉시와 같이 비교적 빨리 성공(success) 표시를 리턴한다. "deactivate" 메소드는 리소스 드라이버(302)가 활성이 아닌지를 결정할 수 있다. "activate" 또는 "deactivate"의 호출을 반복하는 것은 잘못된 것이 아니며, 이 메소드의 의미 규칙(semantics)은 효과적으로 "아직 활성이 아닌 경우 활성화함(activate if not already)"이라는 것을 주목한다.

다음은 IRSensor 리소스 드라이버의 예에 대한 "activate" 메소드에 대응하는 표본 코드이다. 예시된 표본 코드는 명확성을 위하여 단순화되었으며, 당업자이면, 예시된 소스 코드가 로깅(logging) 및/또는 에러 조정 기능으로 구현될 수 있다는 것을 알 수 있을 것이다.

코드 블록2(도11)

"activate" 메소드의 하나의 목적은 IR 센서에 대한 유효 장치 핸들(handle)을 획득하기 위한 것이다. 그렇게 하기 위해서는, resource_config의 "get_parameter" 및 "get_bus_id" 메소드를 호출함으로써 리소스 구성(408)으로부터 IR 센서가 연결된 어드레스 및 버스를 획득해야 한다. 메소드가 버스 id를 획득 했으면, 그 메소드는 리소스 컨테이너(402)의 "obtain_interface" 메소드를 호출함으로써 버스 리소스 드라이버에 대한 참조를 획득한다. 버스의 리소스 인터페이스가 획득되면, 그 메소드는 그 인터페이스의 "get_device" 메소드를 호출하여 IR 센서의 장치 핸들에 대한 참조를 획득한다. 이 장치 핸들이 유효한 한, IR 센서는 액세스될 수 있으며, 리소스는 활성으로 고려될 수 있다.

IRSensor 리소스 드라이버의 "is_active" 메소드의 하나의 구현은 다음과 같다.

코드 블록2a(도10)

"deactivate" 메소드에 대응하는 소스 코드의 하나의 예는 다음과 같다.

코드 블록3(도12)

"deactivate" 메소드는 장치 및 버스 인터페이스를 해방시킴으로써 완료된다. "deactivate" 메소드는 또한 _device 및 _bus 인터페이스 포인터를 널(NULL)로 재설정하고, _address를 0으로 재설정하여, "activate" 메소드가 호출되기 이전의 상태로 돌린다. 이러한 표본 코드는 또한 HAL(202) 객체의 예시된 실시예의 내장 참조 계산(built in reference counting)을 설명한다. "release_interface" 호출은 객체가 임의의 다른 객체에 의해 참조되지 않을 때 효과적으로 버스 및 장치 객체를 검출한다.

인터페이스의 획득

리소스 드라이버(302)가 유용하게 되기 위해서는, 다른 소프트웨어 성분이 액세스할 수 있는 잘 알려진 리소스 인터페이스(702)를 공개해야 한다. 하기에 설명된 "obtain_interface" 메소드는 그 기능을 수행할 수 있는 하나의 메소드를 예시한다. 리소스 드라이버(302)는 리소스 컨테이너(402)의 내부에 보호됨으로써, 리소스 인터페이스(702)가 어떤 리소스 드라이버(302)에 의해 구현되게 하고자 할 때, 리소스 컨테이너(402)를 통해서 요구해야 한다. 컨테이너의 "obtain_interface" 메소드는 리소스 드라이버(302)가 활성이고, 그 다음, 요구된 리소스 인터페이스(702)를 이용하여 리소스 드라이버(302)의 "obtain_interface" 메소드를 호출한다는 것을 검증한다.

그 다음, 드라이버는 요구된 리소스 인터페이스(702)가 지원되는지를 결정하여 그 요구된 리소스 인터페이스(702)에 대한 포인터를 리턴해야 한다. 요구된 리소스 인터페이스(702)가 지원되지 않을 경우, 호출은 RESULT_NOT_IMPLEMENTED를 리턴해야 한다. 리소스 인터페이스(702)가 리턴되면, "obtain_interface"는 리소스 드라이버(302)의 "add_ref" 메소드를 호출해야 하는데, 그 이유는 클라이언트가 이제 리소스 드라이버(302)에 대한 참조를 가지며, 완료되면 리소스 컨테이너(402)를 통해서 그것을 해방시키는 담당을 하기 때문이다. 인터페이스 포인터에 추가하여, HAL(202)의 장점 I(e)과 관련하여 설명된 바와 같이, "obtain_interface" 메소드는 예약 카운트를 출력한다. 하기의 예에서, IRSensor 리소스 드라이버는, IRSensor 리소스 드라이버가 구현하는 유일한 것인 IRangeSensor 리소스 인터페이스에 대하 여 무제한 액세스를 허용하여, 예약 카운트가 0으로 설정된다.

코드 블록4(도13)

예시된 실시예에서, IRSensor 인터페이스는 단지 IRangeSensor 인터페이스만을 지원하므로, IRSensor 인터페이스는 단지 interface_name 파라미터가 불변의 IRangeSensor::INTERFACE_ID와 일치하는지 여부만을 결정할 필요가 있다. 리소스 드라이버(302)는 또한 하나 이상의 리소스 인터페이스(702)를 지원할 수 있으며, 이 경우, "obtain_interface" 메소드는 지원된 리소스 인터페이스(702)의 id와 interface_name 파라미터를 검사하여 일치한다고 밝혀지면 적절한 인터페이스 참조를 리턴할 수 있다는 것을 알 수 있을 것이다.

리소스 인터페이스(702)는 캡슐화된 리소스(304)의 동작과 관련된 메소드를 정의한다. 이 예에서의 IRangeSensor 리소스 인터페이스는 다음의 메소드를 구현한다.

코드 블록5

이들 메소드는 거리 센서에 대한 전형적인 동작을 예시한다. "get_distance_reading" 메소드는 센서의 미가공 판독값으로부터 처리된 실세계 단위의 판독값을 리턴한다. "get_raw_reading" 메소드는 센서로부터의 미가공 판독값을 리턴한다.

표본 IRSensor 리소스 드라이버에 대한 get_distance_reading 메소드의 표본 구현에 대응하는 소스 코드의 하나의 예가 하기에 제공된다.

코드 블록6(도14)

예시된 "get_distance_reading" 메소드는 리소스 드라이버(302)가 처리전에 활성임을 검증한다. 그 다음, "get_distance_reading" 메소드는 하드웨어 드라이버 메소드 "ercm_device_read_analog"을 이용해서, 이 특정 타입의 장치에 액세스하여 IR 센서로부터 미가공 값을 판독함으로써, "activate" 메소드에 의해 이전에 획득되었던 센서의 _device 참조 및 _address 값과 함께 넘겨준다. 판독값에 대한 타임스탬프 값이 획득된 다음, 미가공 판독값을 거리 판독값으로 변환하는 "raw_to_distance" 메소드를 수행한다. 그 다음, 변환된 거리 값은 유출 거리 파라미터에 저장되고, RESULT_SUCCESS 값이 리턴된다.

"get_raw_reading" 메소드의 IRSensor의 구현의 일 실시예가 하기에 제공된다.

코드 블록7(도15)

이 구현은 미가공 판독값을 거리 판독값으로 변환하는 대신, 그 판독값이, 이용된 특정 IR 센서의 미가공 형태에 대응하는 전압 단위로 변환된다는 것을 제외하고는 거의 get_distance_reading과 동일하다는 것에 주목한다.

(주의: 본원에는 코드 블록8이 존재하지 않는다.)

다음은 상위-레벨 소프트웨어가 리소스 드라이버(302)를 이용하여 로봇 비헤비어를 생성하는 방법을 더 상세하게 설명한다. 로봇 비헤비어의 하나의 예는 로봇을 원하는 속도로 어떤 거리까지 이동시키는 것이다. 이것을 달성하기 위해서, 비헤비어는 로봇이 원하는 속도로 전방으로 이동하고 있는지를 결정할 수 있어야 하고, 이동 거리를 주기적으로 결정할 수 있어야 하고, 그리고 로봇이 원하는 거리를 이동했을 때 로봇을 중지시킬 수 있어야 한다.

일 실시예에서, 이 비헤비어는 HAL(202)에 의해 제공된 2개의 서로 다른 리소스 인터페이스(702) 즉, 드라이브 시스템 리소스 인터페이스와 기구학적구조 리소스 인터페이스를 이용한다. 드라이브 시스템 리소스 인터페이스는 비헤비어가 선속도를 특정할 수 있게 해주는 "move_and_turn" 메소드를 제공한다. 이 메소드의 일 실시예는 또한 각속도의 설정을 허용하지만, 전방으로 이동하는 경우, 각속도는 0으로 설정될 수 있다.

일 실시예에서, 기구학적구조 리소스 인터페이스는 "get_position" 메소드를 가지며, 이 메소드는 로봇의 오리엔테이션(θ)과 함께, 데카르트(Cartesian) 좌표(x,y)에서 로봇의 위치를 포함하는 위치 구조에서 로봇의 현재 위치를 리턴한다.

도8을 참조하여 이전에 설명된 바와 같이, 비헤비어는 리소스 컨테이너(402)의 "obtain_interface" 메소드를 호출함으로써 HAL(202)로부터 이들 2가지 리소스 인터페이스(702)에 대한 참조를 요구함으로써 개시한다. 리소스 컨테이너(402)는 드라이브 시스템 및 기구학적구조 리소스 인터페이스에 대한 참조를 리턴한다. 그 다음, 비헤비어는 기구학적구조 리소스 인터페이스의 "get_position" 메소드를 호출하여, 로봇의 현재 위치를 검색하고, 비헤비어는 이 위치를 동작 개시점으로서 저장할 수 있다. 그 다음, 비헤비어는 드라이브 시스템 비헤비어의 "move_and_turn" 메소드를 호출하여 원하는 속도로 로봇의 이동을 개시한다. 그러고 나서, 비헤비어는 기구학적구조 리소스의 "get_position" 메소드를 호출함으로써 로봇의 현재 위치를 주기적으로 검사하는 루프를 시작할 수 있으며, 표준 제곱 근 거리 공식을 이용하여 현재의 위치와 개시 위치 간의 거리를 계산하여 원하는 거리에 이르렀는지를 알 수 있다. 이것이 달성되면, 비헤비어는 그 루프를 중단하고, 0 선속도 및 0 각속도를 갖는 드라이브 시스템 리소스 인터페이스의 "move_and_turn" 메소드를 호출하여 중단(stop)을 시작한다. 이 비헤비어의 C++ 구현의 한 예가 하기의 코드 블록9에 설명된다.

코드 블록9(도16)

코드 블록9는 간단한 로봇 동작 예를 들면, 어떤 거리인 경우 전방으로 이동하는 동작을 달성하기 위해 HAL(202)과 상호작용하는 상위-레벨 비헤비어를 예시한다. 예시된 동작은 2개의 서로 다른 리소스 인터페이스(702)를 이용한다. 비헤비어는 먼저 리소스 컨테이너(402)에 대한 "obtain_interface" 호출을 이용하여 이들 리소스 인터페이스를 획득한다. 이들 인터페이스에 대한 참조가 획득되면, 비헤비어는 이들 인터페이스의 메소드 즉, IOdometry의 "get_position" 메소드 및 IDriveSystem의 "move_and_turn" 메소드를 이용하여 그의 목적을 달성한다. 유리하게는 HAL(202)로 인해, 예시된 코드는 하부 로봇 하드웨어의 특성에 무관하게 실행할 수 있다. 리소스 구성(402)은 활성 하드웨어를 기술하고, HAL(202)은 리소스 구성(408)내의 정보를 이용하여 이 2가지 메소드의 정확한 구현을 결정해서 비헤비어에 리턴함으로써, 비헤비어가 이 메소드들을 호출할 때, HAL(202)에 의해 추상화된 활성 로봇 하드웨어는 의도한 바와 같이 수행하게 될 것이다.

코드 블록10은 2개의 모터를 갖는 차동 드라이브 시스템의 "move_and_turn" 메소드의 하나의 구현을 예시한다.

코드 블록10(도17)

코드 블록10은, 차동 드라이브 시스템에 대한 "move_and_turn" 메소드가 선속도 및 각속도, 그리고 그들 각각의 가속도와 같은 편리한 실세계 파라미터를 취하여, 좌측 및 우측 모터에 대해 개별적인 속도를 계산함으로써 원하는 결과를 얻을 수 있는 방법을 예시한다. 도18은 도17의 흐름도에서의 변수들을 참조하기 위한 차트를 포함한다. 이것은 리소스 인터페이스(702)의 기능성(functionality)을 나타낸다. HAL(202)에 의해 제공되는 이들 메소드의 구현에 관한 세부사항은 하부 하드웨어에 따라 변할 수 있다는 것을 알 수 있을 것이다. 예를 들면, 2개의 모터를 이용하여 2세트의 다리를 구동하는 드라이브 시스템을 위한 "move_and_turn" 메소드의 구현은 차동 드라이브 시스템에 대한 상기의 코드와 실질적으로 다르다. 그러나, 드라이브 시스템이 활성인 리소스 구성(408)에 표시함으로써, HAL(202)은 유리하게 정확한 구현을 갖는 상위-레벨 소프트웨어를 제공하고, 상위-레벨 소프트웨어는 특정 로봇에 대한 특유의 독자성(peculiarity)으로부터 효과적으로 분리된다.

구현된 리소스 인터페이스

HAL(202)의 일 실시예에 의해 구현될 수 있는 리소스 인터페이스(702)의 비-전면적 목록이 하기에 제공된다. 추가적인 리소스 인터페이스(702)가 추가될 수 있다는 것을 알 수 있을 것이다. 읽기 쉽도록 하기 위해서 리소스 인터페이스를 일반적인 카테고리들로 조직한다.

오디오 카테고리

바람직하게는, HAL(202)은 종래의 비-로봇 플랫폼에서 지원되는 장치를 포함하여, 매우 다양한 장치에 대하여 추상화한다. 오디오 리소스 추상화는 상위-레벨 소프트웨어가 로봇에 부착된 사운드 장치(마이크로폰, 디지털 합성장치, 스피커 등)와 상호작용할 수 있게 해준다. 객체-지향형 설계를 이용하여, 오디오 리소스는 다음의 클래스 계층(class hierarchy)으로 구조화될 수 있다.

IResource

IAudioBase

IAudioPlay

IAudioRecord

IAudioLevel

IAudioBase는 모노 또는 스테레오, 표본 추출 비율, 블록 크기, 오디오 채널의 수 및 이용가능한 오디오 장치의 열거 및 선택과 같은 디지털 오디오 파라미터의 특정화를 허용한다.

IAudioPlay는 디지털 오디오를 재생하는데 이용될 수 있다.

IAudioRecord는 디지털 오디오를 녹음하는데 이용될 수 있다.

IAudioLevel은 로봇 주변의 환경에서 일반적인 환경 잡음을 검출하는데 이용될 수 있다. 이 IAudioLevel은, 사운드에 반응하기 위해 상위-레벨 소프트웨어 성 분에 의해 이용될 수 있는 감각 입력(sensory input)을 제공할 수 있다. 예를 들면, 보안 비헤비어는 "침입자 경보(Intruder Alert)"를 울림으로써 어떤 환경음 레벨에 반응하도록 구성될 수 있다.

영상 카테고리

영상 카테고리내의 리소스는 카메라와 같은 영상 센서를 추상화한다. 이 리소스는 이미지 크기, 컬러 심도 및 포맷(color depth and format), 비디오 코덱, 비디오 프레임율, 압축 품질과 같은 다양한 비디오 및 스틸 프레임 파라미터의 특정화를 허용한다. 일 실시예에서, 리소스 계층은 다음과 같다.

IResource

ICamera

ICameraGroup

ICamera 리소스는 단일 카메라로부터 스틸 프레임 및 비디오를 검색할 수 있다. 검색된 프레임은 다양한 컬러 포맷의 미가공 래스터(raster) 데이터로, 혹은 JPEG과 같은 압축 포맷으로 저장될 수 있다. ICameraGroup 리소스의 일 실시예는, 하나 이상의 카메라의 상대적인 위치, 오리엔테이션 및 간격을 고려해, 복수의 카메라와의 상호작용을 추상화하여, 스테레오 비전 또는 파노라마 생성과 같은 애플리케이션을 위해 복수의 이미지 및 비디오의 동기화된 캡쳐(capture)를 가능하게 한다.

센서 카테고리

센서 카테고리는 다양한 타입의 비-영상 감각 장치(non-visual sensory device)의 리소스 추상화를 포함한다. 이용가능한 센서의 종류는, 레이저 거리 측정기(laser range finder)와 같은 비교적 고도의 기술이고 고가인 센서에서부터, 수중음파탐지기(sonar) 또는 범프-스위치(bump-switch) 센서와 같은 비교적 단순하고 저가인 센서에 이르기까지 매우 다양하다. 센서 리소스는, 센서를 기능적인 카테고리로 그룹화하여 각 카테고리에 비교적 단순하고 균일한 인터페이스를 제공함으로써, 이러한 다양한 센서를 다루는 어려움을 극복하여 추상화를 행한다. 클래스 계층은 기능적 카테고리 분류를 따르며, 하기에 더 상세하게 설명된다.

IResource

IBumpSensor

IRangeSensor

IspatialSensor

IBumpSensor 리소스는, 센서와 어떤 이물체(foreign object) 간의 물리적 접촉을 검출하는 센서를 추상화할 수 있다. 이 카테고리내의 센서는 다양한 스위치 센서를 포함한다.

IRangeSensor 리소스는 센서의 한정된 거리내에서 이물체의 존재를 검출하는 센서를 추상화할 수 있다. IRangeSensor 리소스의 일 실시예는 단일 거리 판독값을 리턴한다. 리소스는 모호하거나 반응이 없는 지역, 최소 범위 및 최대 범위와 같은 어떤 거리 센서의 물리적 한계를 기술한다. 센서로부터 리턴된 판독값은 거리 단위로 변환되어, 리소스 구현에 의한 에러를 최소화하도록 필터링될 수 있다. 이 카테고리내의 센서는 대부분 IR 및 수중음파탐지기 센서를 포함한다.

IspatialSensor 리소스는 비교적 넓은 영역에서 이물체의 존재를 검출하는 센서를 추상화하며, 복수의 판독값을 동시에 리턴할 수 있다. 회전 레이저 거리 측정기(rotating laser range finder)는 이 카테고리내의 센서에 대한 하나의 예이다.

감정

IFace

IFace 리소스 인터페이스는 감정 파라미터에 근거하여 3D-렌더링 얼굴의 조작을 지원한다. 얼굴은 미소, 찌푸림 등과 같은 얼굴의 표정을 반영하도록 변경될 수 있다.

Locomotion

IMotorCommand

IMotorQuery

IDriveSystem

IOdometry

IMotorCommand 리소스 인터페이스는 모터의 회전 속도 및 가속도 설정과 같은 단일 모터의 제어를 캡슐화한다.

IMotorQuery 리소스 인터페이스는 모터 위치 또는 속도와 같은 단일 모터의 상태에 대하여 이루어질 수 있는 조회를 캡슐화한다.

IDriveSystem 리소스 인터페이스는 전체 로봇을 이동시키는 드라이브 시스템을 추상화할 수 있다. 이 리소스 인터페이스는, 다른 소프트웨어 성분이 선속도 및 각속도와 같은 편리한 실세계 파라미터에 근거하여 로봇의 움직임을 제어할 수 있게 해준다. 그 구현은 이들 간단한 커맨드를, 차동 드라이브 시스템의 2개의 모터 또는 복수의 로봇 다리의 복잡한 움직임과 같은 매우 다양한 하드웨어에 대응할 수 있는 하부 이동(locomotion) 하드웨어의 대응하는 제어 신호로 변환한다.

Display

IImageDisplay

IImageDisplay 리소스 인터페이스는 그래픽 사용자 인터페이스 윈도우에 이미지를 디스플레이하기 위한 능력을 캡슐화한다.

Input

IJoystick

ISwitchDevice

IJoystick 리소스 인터페이스는 조이스틱으로부터의 입력을 캡슐화한다.

ISwitchDevice 리소스 인터페이스는 외부 다중위치 하드웨어 스위치로부터의 입력을 캡슐화한다.

Manipulator

IGripper

IGripper 리소스 인터페이스는 그리퍼(gripper)의 상태 조회 및 그리퍼를 여닫기 위한 커맨드를 포함하여, 그리퍼의 동작을 캡슐화한다.

Speech

ISpeechRecognizer

ISpeechTTS

ISpeechRecognizer 리소스 인터페이스는 음성 인식 인터페이스를 추상화한다.

ISpeechTTS 리소스 인터페이스는 텍스트 입력으로부터 음성 합성 능력을 지원하기 위한 메소드를 포함할 수 있다.

Utility

IPollable

ITransactable

IPollable 리소스 인터페이스는 선택된 리소스의 폴링(polling) 동작을 캡슐화한다. 리소스 인터페이스(702)가 폴링되어야 할 때, 리소스 인터페이스(702)는 또한 폴링이 어떻게 행해져야 하고 어떤 간격으로 행해져야 하는지를 나타내도록 이 인터페이스를 구현한다.

ITransactable 리소스 인터페이스는 일부 리소스 드라이버를 지원할 수 있고, 단일 트랜잭션의 부분으로서 복수의 커맨드 및/또는 조회를 전송하도록 구성된다.

본 발명의 다양한 실시예가 상기에 설명되었다. 비록 본 발명은 이들 특정 실시예를 참조하여 설명되었지만, 이 설명은 본 발명을 예시하기 위한 것일 뿐이며, 본 발명을 이 설명으로만 한정하기 위한 것이 아니다. 이 기술분야의 당업자에게는 첨부된 청구의 범위에 정의된 바와 같이 본 발명의 정신 및 범위에서 벗어남이 없이 다양한 변형 및 애플리케이션이 이루어질 수 있다.

Claims

로봇 소프트웨어 아키텍처내의 하드웨어 추상화 계층(HAL)에 있어서,

상위-레벨 소프트웨어에 대한 소프트웨어 인터페이스 - 상기 소프트웨어 인터페이스는 주위환경과의 로봇 상호작용에 관한 실세계 측정값을 이용하여 상기 상위-레벨 소프트웨어와 통신하도록 구성됨 - ;

상기 상위-레벨 소프트웨어에, 이용가능한 리소스의 표시를 제공하는 리소스 구성;

다수의 리소스 드라이버 - 상기 리소스 드라이버 중 적어도 일부는 상기 리소스 구성내의 상기 이용가능한 리소스에 대응하고, 상기 리소스 드라이버 중 적어도 2개는 기능이 중복되고, 상기 적어도 2개의 리소스 드라이버 중 단지 1개만이 이용가능한 대응 리소스를 가지며, 이용가능한 리소스에 대한 리소스 드라이버는 로봇에 대한 실세계 측정값과 장치에 대한 장치-레벨 측정값 사이에서 변환하도록 구성됨 - ; 및

하위-레벨 장치 드라이버에 대한 인터페이스 - 상기 하위-레벨 장치 드라이버는 장치 레벨에서 대응하는 하드웨어와 통신하고, 하위-레벨 장치 드라이버에 대한 상기 인터페이스는 리소스 드라이버를 통해 상기 상위-레벨 소프트웨어와 통신함 -

를 포함하는 하드웨어 추상화 계층(HAL).
제1항에 있어서,

상기 리소스 구성은 장치가 로봇에 구조적으로 연결되어 있는 곳의 표시를 더 포함하는

하드웨어 추상화 계층(HAL).
제1항에 있어서,

상기 상위-레벨 소프트웨어는 플래너, 애플리케이션, 비헤비어 및 태스크로 구성된 그룹으로부터 선택된 적어도 하나를 포함하는

하드웨어 추상화 계층(HAL).
제1항에 있어서,

장치 드라이버는 모터 드라이버에 대응하고, 대응하는 리소스 드라이버는 바퀴 직경 및 기어 비율을 이용하여 모터 각속도를 고려해 속도를 계산함으로써, 상기 리소스 드라이버가 상기 모터 드라이버에 대한 모터 각속도와 상기 상위-레벨 소프트웨어에 대한 선속도 사이에서 변환하는

하드웨어 추상화 계층(HAL).
제1항에 있어서,

상기 리소스 드라이버는 상기 상위-레벨 소프트웨어와 상기 하위-레벨 장치 드라이버 사이의 애플리케이션 프로그램 인터페이스(API) 계층에 존재하는

하드웨어 추상화 계층(HAL).
로봇에서 로봇 제어 소프트웨어에 하드웨어 추상화를 제공하는 방법에 있어서,

상기 로봇에 다수의 리소스 드라이버 - 상기 다수의 리소스 드라이버는 상기 로봇에 어떠한 대응하는 하드웨어도 존재하지 않는 리소스 드라이버를 포함함 - 를 제공하는 단계;

상기 로봇에 대한 하드웨어 구성을 검출하는 단계;

상기 검출된 하드웨어 구성에 근거하여, 상기 로봇에서 이용가능한 리소스를 자동으로 검출하는 단계;

소정의 타입의 리소스를 이용하기 위해 상기 로봇 제어 소프트웨어로부터 요구를 수신하는 단계;

상기 로봇 제어 소프트웨어에 의해 요구된 상기 타입의 리소스에 대응하는 리소스를, 상기 이용가능한 리소스로부터 자동으로 선택하는 단계;

상기 로봇 제어 소프트웨어와 제1 정보 - 상기 제1 정보는 상기 선택된 리소 스의 이용과 관련된 것이고, 로봇과 관련된 측정값의 단위로 제공됨 - 를 교환하는 단계;

상기 리소스에 대응하는 하위-레벨 장치 드라이버와 제2 정보 - 상기 제2 정보는 상기 로봇 제어 소프트웨어에 의해 요구된 이용과 관련된 것이고, 상기 제2 정보는 대응하는 장치와 관련된 측정값의 단위로 제공되고, 상기 제2 정보는 상기 제1 정보와 다름 - 를 교환하는 단계; 및

상기 로봇의 상기 검출된 구성에 근거하여, 상기 제1 정보와 상기 제2 정보 사이에서 변환하는 단계

를 포함하는 방법.
제6항에 있어서,

상기 제1 정보는 선속도이고, 상기 제2 정보는 각속도인

방법.
제6항에 있어서,

상기 방법은 애플리케이션 프로그램 인터페이스(API)로 구현되는

방법.
제6항에 있어서,

상기 타입의 리소스는 거리 감지를 포함하고, 선택되는 상기 리소스는 범프 센서, 레이저 거리 측정기, 초음파 센서 및 적외선 센서로 구성된 그룹으로부터 선택된 장치에 대응하는

방법.
제6항에 있어서,

상기 로봇은 처음에 범프 센서를 포함하고, 상기 로봇에 대한 상기 하드웨어 구성은 상기 범프 센서를 특정하고,

상기 범프 센서를 적외선 센서로 변경하는 단계;

상기 로봇에 대한 상기 하드웨어 구성을 변경하는 단계; 및

상기 로봇 제어 소프트웨어가 변경없이 이용될 수 있도록 상기 로봇의 새로 검출된 구성에 근거하여 상기 제1 정보와 상기 제2 정보 사이에서 자동으로 변환하는 단계를 더 포함하는

방법.
제6항에 있어서,

메소드 호출에 보안 파라미터를 포함시키는 단계;

리소스에 대한 액세스가 요구될 때 보안 티켓을 검증하는 단계; 및

상기 보안 티겟에 근거하여 상기 리소스에 대한 액세스를 제어하는 단계를 더 포함하는

방법.
제6항에 있어서,

리소스에 대한 액세스에 근거하여 갱신되는 예약 카운트 파라미터를 유지하는 단계; 및

상기 카운트에 근거하여 상기 리소스에 대한 액세스를 제어하는 단계를 더 포함하는

방법.
로봇 제어 소프트웨어에 대한 로봇에서의 하드웨어 추상화 계층(HAL)에 있어서,

상기 로봇에 다수의 리소스 드라이버 - 상기 다수의 리소스 드라이버는 상기 로봇에 어떠한 대응하는 하드웨어도 존재하지 않는 리소스 드라이버를 포함함 - 를 제공하기 위한 수단;

상기 로봇을 위한 하드웨어 구성을 검출하기 위한 수단;

상기 검출된 하드웨어 구성에 근거하여 상기 로봇에서 이용가능한 리소스를 자동으로 검출하기 위한 수단;

소정의 타입의 리소스를 이용하기 위해 상기 로봇 제어 소프트웨어로부터 요구를 수신하기 위한 수단;

상기 로봇 제어 소프트웨어에 의해 요구된 상기 타입의 리소스에 대응하는 상기 이용가능한 리소스로부터 자동으로 리소스를 선택하기 위한 수단;

상기 로봇 제어 소프트웨어와 제1 정보 - 이 제1 정보는 상기 선택된 리소스의 이용과 관련되고, 로봇과 관련된 측정값의 단위로 제공됨 - 를 교환하기 위한 수단;

상기 리소스에 대응하는 하위-레벨 장치 드라이버와 제2 정보 - 이 제2 정보는 상기 로봇 제어 소프트웨어에 의해 요구된 상기 이용과 관련되고, 상기 제2 정보는 대응하는 장치에 관련된 측정값의 단위로 제공되고, 그리고 상기 제2 정보는 상기 제1 정보와 다름 - 를 교환하기 위한 수단; 및

상기 로봇의 상기 검출된 구성에 근거하여 상기 제1 정보와 상기 제2 정보 사이에서 변환하기 위한 수단

을 포함하는 하드웨어 추상화 계층(HAL).
로봇에 다수의 리소스 드라이버 - 상기 다수의 리소스 드라이버는 상기 로봇에 어떠한 대응하는 하드웨어도 존재하지 않는 리소스 드라이버를 포함함 - 를 제공하는 단계;

상기 로봇을 위한 하드웨어 구성을 검출하는 단계;

상기 검출된 하드웨어 구성에 근거하여 상기 로봇에서 이용가능한 리소스를 자동으로 검출하는 단계;

소정의 타입의 리소스를 이용하기 위해 상기 로봇 제어 소프트웨어로부터 요구를 수신하는 단계;

상기 로봇 제어 소프트웨어에 의해 요구된 상기 타입의 리소스에 대응하는 상기 이용가능한 리소스로부터 자동으로 리소스를 선택하는 단계;

상기 로봇 제어 소프트웨어와 제1 정보 - 이 제1 정보는 상기 선택된 리소스의 이용과 관련되고, 로봇과 관련된 측정값의 단위로 제공됨 - 를 교환하는 단계;

상기 리소스에 대응하는 하위-레벨 장치 드라이버와 제2 정보 - 이 제2 정보는 상기 로봇 제어 소프트웨어에 의해 요구된 상기 이용과 관련되고, 상기 제2 정보는 대응하는 장치에 관련된 측정값의 단위로 제공되고, 그리고 상기 제2 정보는 상기 제1 정보와 다름 - 를 교환하는 단계; 및

상기 로봇의 상기 검출된 구성에 근거하여 상기 제1 정보와 상기 제2 정보 사이에서 변환하는 단계

를 포함하는 방법을 수행하기 위한 컴퓨터 실행가능 명령을 갖는 컴퓨터 판독가능 매체.