KR20120087990A - 로보틱스 시스템 - Google Patents

Abstract

로봇 제어 방법은 적어도 하나의 프로세서 상에서 다수의 애플리케이션(130)을 실행하는 단계를 포함하고, 각각의 애플리케이션(130)은 로봇 제어기(140) 및 액션 선택 엔진(200)을 구비한다. 각각의 애플리케이션(130)은 로봇의 적어도 일부의 적어도 하나의 행동(300) 및 적어도 하나의 액션 모델(400)과 통신한다. 이 방법은 각각의 액션 선택 엔진(200) 상에서 주기적인 액션 선택 사이클들(210)을 실행하는 단계를 포함한다. 각각의 액션 선택 사이클(210)은 각각의 액션 모델(400)의 각각의 액션 공간(410)에 대한 명령(440)을 선택하는 단계, 각각의 액션 모델(400)에 대한 축적된 명령들(440)에 기초하여 단일 종합 명령(442)을 생성하는 단계, 및 종합 명령(442)을 로봇 상에서의 실행을 위해 로봇 제어기(140)로 전송하는 단계를 포함한다.

Description

로보틱스 시스템{ROBOTICS SYSTEMS}

<관련 출원들의 상호 참조>

본 특허 출원은 2008년 4월 2일자로 출원된 미국 가출원 제61/041,707호에 대해 35 U.S.C. §119(e) 하에 우선권을 주장한다. 이 선출원의 명세서는 본 출원의 명세서의 일부로서 간주되며, 본 출원의 명세서 내에 참고 문헌으로 포함된다.

본 발명은 로보틱스 시스템들에 관한 것이다.

행동 기반 로보틱스 시스템들은 그의 장점들(실시간 응답성, 확장성 및 강건성)을 보존하면서 한계들(상태의 결여 및 과거 또는 미래 조사 능력의 결여)을 보완하기 위하여 로봇 제어에 대한 대응적 접근 방식을 탈피한다. 지난 10년 동안, 행동 기반 시스템들은 자율적인 시스템 제어를 위한 두 가지의 선호되는 일반적인 방법 중 하나로서(다른 하나는 하이브리드 시스템들) 그리고 물리적인 멀티 로봇 시스템 조정을 위한 가장 인기 있는 방법으로서 입증되었다. 효과적인 행동 선택 또는 중재는 주어진 시간에 어떠한 행동 또는 행동들의 서브세트가 로봇을 제어할지를 결정하므로, 행동 기반 제어의 중요한 과제이다. 현재의 시스템들은 행동들을 직렬로 실행하지만, 로봇의 중복 자원들을 필요로 하는 다수의 행동을 동시에 실행하는 작업이 주어질 경우에는 많은 문제에 직면한다.

효과적인 액션 선택 및 제어 중재는 로봇 시스템들에 대한 고품질 행동 기반 제어를 제공하는 데에 중요한 요소들이다. 설계되는 시스템은 많은 상이한 애플리케이션들에 걸쳐 액션의 일관성을 제공하면서, 로봇 시스템에서의 많은 경쟁 목표들, 장애물들 및 물리적 제한들 사이의 조정을 제공해야 한다. 이러한 메커니즘들은 주어진 시간에 어떠한 행동(또는 행동들의 서브세트)이 로봇을 제어할지를 결정하기 위해 협력한다. 행동 제어를 위한 현재의 시스템들은 일관성 및 조정을 동시에 제공하지 못하며, 최신의 로봇 시스템들 내의 다수의 액추에이터(종종, 10 이상의 DOF)로 확장되지 못한다.

개시되는 로보틱스 시스템은 저부담 인-프로세스(low-overhead in-process) 컴포넌트 API 시스템으로서 설계된다. 로보틱스 시스템은, 로봇 내의 모든 다른 프레임워크의 기초이고, 다른 내부 인터페이스들이 어떻게 정의되는지는 물론, 재사용 가능한 유닛들로부터 어떻게 소프트웨어 모듈들을 구축할지를 정의하는 기초 프레임워크를 포함할 수 있다. 기초 프레임워크는 단일 프로세스 내의 동적으로 로딩되고 구성되는 이진 객체들의 원칙에 의거하는 중간 입도의 소프트웨어 구성에 필요한 기반구조를 제공한다. 이러한 특징은 상당한 내부 복잡성을 갖는 확장 가능한(플러그-인 또는 애드-온) 소프트웨어 컴포넌트들의 구축을 지원하도록 포함된다. 기초 프레임워크의 특징들은 복잡성 관리, 시스템 크기의 확장 및 인터페이스들에 대한 실행시의 동적 소프트웨어 구성에 대한 필요들을 해결하는 것을 의도한다.

본 명세서에 설명되는 로보틱스 시스템은 두 가지 레벨의 애플리케이션 구조를 제공하며, 행동 기반 로봇들의 소프트웨어 설계에 있어서의 역할들 및 책임들을 명확히 구별하는 데 사용된다. 로보틱스 시스템은 다수의 애플리케이션이 우선 순위 방식으로 로봇 액추에이터들의 제어를 통시에 공유하는 것을 허가하는 제어 중재 계층을 포함한다. 제어 중재 계층은 애플리케이션들의 세트에 걸쳐 로봇 액추에이터(자원) 액세스의 일관성을 제공한다. 로보틱스 시스템의 제어 중재 계층은 다수의 애플리케이션이 실행시에 동적으로 시작되고 중지되는 것을 허가하며, 상이한 애플리케이션들 사이의 사용자 지정 우선 순위에 기초하여 상이한 애플리케이션들 사이의 로봇 자원들(액추에이터들)의 원칙에 근거하는 공유를 지원한다.

로보틱스 시스템은 애플리케이션 내의 행동들의 계층적 집합이 매우 많은 수의 자유도(많은 수의 액추에이터)에 대한 조정된 출력 명령을 협력 생성하는 것을 가능하게 하는 액션 선택 계층을 더 포함한다. 액션 선택 계층은 로봇 시스템 액추에이터들의 동적 한계들을 고려하는 공지된 실행 가능한 로봇 명령들로부터의 가능한 결과들을 평가함으로써 다수의 행동이 협력하는 것을 허가한다. 행동들은 결과들이라고 하는 미래의 액추에이션 상태들의 궤적들을 평가하고, 결과들의 평가들을 제공한다. 액션 모델들을 이용하여, 실행 가능한 명령들의 세트를 제공하고, 액추에이터들의 특정 세트에 대한 검색 휴리스틱(heuristic)을 제공하며, 명령의 결과들을 미리 시뮬레이션한다. 액션 선택 시스템 내의 검색 공간의 복잡성을 줄이기 위하여, 로봇 상의 자원들(액추에이터들)의 전체 세트는 가장 이용 가능하고, 실행 가능한 명령을 찾기 위해 독립적으로 검색되는 하위 공간들의 배열된 집합으로 분할된다. 행동들 자체는 로봇의 전체 인식 범위의 분리 가능한 부분들을 구현하는 것을 의도하고, 종종 사용자 레벨 문제 설명에 기초하여 분류되며, 하나의 행동(또는 행동들의 하나의 그룹)은 로봇의 전체 임무에 대한 사용자 레벨 설명 내의 각각의 작업에 할당된다.

액션 선택 계층은 행동들의 계층적 집합을 조정하기 위해 로봇 시스템의 외부 컴포넌트들에 의해 사용되는 통합 이벤트 디스패칭 루프도 제공한다. 액션 선택 계층의 이벤트 디스패칭 및 핸들링 요소들은 행동들 및 액션 모델 요소들을 인에이블/디스에이블하기 위해, 행동 내의 모드들 또는 상태들을 전환하기 위해, 또는 임의의 다른 애플리케이션 정의 목적을 위해 사용될 수 있다. 이러한 접근법의 중요한 의의는 행동들의 구축을 간략화하기 위하여 그러한 이벤트 핸들링 및 디스패칭이 기본 행동 애플리케이션 프로그래밍 인터페이스(API)와 통합된다는 것이다.

일 양태에서, 로봇 제어 방법은 프로세서 상에서 다수의 애플리케이션을 실행하는 단계를 포함하며, 각각의 애플리케이션은 로봇 제어기 및 액션 선택 엔진을 구비한다. 각각의 애플리케이션은 로봇의 적어도 일부의 적어도 하나의 행동 및 적어도 하나의 액션 모델과 통신한다. 이 방법은 각각의 액션 선택 엔진 상에서 주기적인 액션 선택 사이클들을 실행하는 단계를 포함한다. 각각의 액션 선택 사이클은 각각의 액션 모델의 각각의 액션 공간에 대한 명령을 선택하는 단계, 각각의 액션 공간에 대한 축적된 명령들에 기초하여 단일 종합 명령을 생성하는 단계, 및 로봇 상에서의 실행을 위해 종합 명령을 로봇 제어기로 전송하는 단계를 포함한다. 액션 선택 엔진의 하나의 장점은 로봇의 모든 액션 공간에 대한 명령들로 구성되는 로봇에 대한 종합 명령을 생성하는 그의 능력이다.

이러한 본 발명의 양태의 구현들은 다음 특징들 중 하나 이상을 포함할 수 있다. 일부 예들에서, 액션 선택 사이클은 3개의 단계, 즉 지정, 액션 선택 검색 및 완료 단계를 포함한다. 지정 단계에서, 각각의 액션 모델 및 각각의 행동은 시스템 상태 및 액션 선택 사이클의 개시를 통보받는다. 액션 선택 검색 단계에서, 액션 선택 엔진은 액션 모델들을 이용하여, 액션 공간들(이용 가능한 액션들의 공간들)의 각각에서 실행 가능한 명령들 및 시뮬레이션된 결과들을 생성한다. 액션 선택 엔진은 사이클에 이용 가능한 시간에 최상의 가능한 결과를 검색하면서 평가 기능들에 대한 다수의 호출을 행할 수 있다. 액션 모델들은 실행 가능한 명령들 및 행동들에 의해 평가되는 대응하는 결과적인 미래의 결과들을 생성한다. 액션 선택 엔진은 각각의 액션 공간에 대해 행동들에 의해 제공되는 결과 평가들을 축적하고, 각각의 액션 공간에 대한 최상의 결과 및 대응하는 명령을 선택한다. 이어서, 액션 선택 엔진은 각각의 개별 액션 공간에서의 선택된 명령을 결합함으로써 모든 로봇 자원들에 대한 종합 명령을 생성한다. 완료 단계에서, 액션 선택 엔진은 실행을 위해 종합 명령을 접속된 로봇 제어기로 전송하고, (가능한 경우에, 행동 정책들이 적응하는 것을 허가하는) 사이클 상의 피드백으로서 종합적인 결과를 모든 활성 행동들 및 행동 정책들로 전송한다.

일부 구현들에서, 액션 선택 사이클은 로봇 제어기로부터 시스템 상태를 취득하는 단계, 각각의 액션 모델 및 각각의 행동에 시스템 상태를 통지하는 단계, 및 각각의 액션 모델 및 각각의 행동에 액션 선택 사이클의 개시를 통지하는 단계를 포함한다. 일부 예들에서, 각각의 액션 공간에 대한 명령을 선택하는 단계는 대응하는 액션 모델을 호출하여, 액션 공간에 대한 실행 가능 명령을 생성하는 단계, 대응하는 액션 모델을 호출하여, 실행 가능 명령들에 대한 결과들을 생성하는 단계, 각각의 행동을 호출하여, 각각의 결과를 평가하고 각각의 결과에 대한 결과 평가를 제공하는 단계, 각각의 행동의 결과 평가들을 축적하는 단계, 액션 공간에 대한 승리 결과를 선택하는 단계, 및 승리 결과에 대응하는 명령을 선택하는 단계를 포함한다. 이 방법은 어느 애플리케이션이 주어진 시간에 그 애플리케이션에 의해 요구되는 로봇의 자원들에 대한 독점적인 제어를 갖는지를 결정하는 애플리케이션 우선 순위 정책을 구현하는 단계를 포함할 수 있다. 애플리케이션 우선 순위 정책은 각각의 로봇 제어기와 통신하는 로봇 관리기에 의해 구현될 수 있다.

다른 양태에서, 로봇 제어기에 대한 명령을 생성하는 방법은 적어도 하나의 액션 공간을 갖는 적어도 하나의 액션 모델을 호출하여, 각각의 액션 공간에 대한 실행 가능 명령들을 생성하는 단계, 각각의 액션 모델을 호출하여, 각각의 명령에 대한 결과를 생성하는 단계, 및 각각의 결과를 평가를 위해 적어도 하나의 행동으로 전송하는 단계를 포함한다. 각각의 행동은 각각의 결과에 대한 결과 평가를 제공한다. 이 방법은 적어도 하나의 결과 평가에 기초하여 각각의 액션 공간에 대한 승리 결과를 선택하는 단계, 각각의 액션 공간에 대한 승리 결과에 대응하는 명령을 선택하는 단계, 각각의 액션 공간에 대한 축적된 명령들에 기초하여 단일 종합 명령을 생성하는 단계, 및 종합 명령을 로봇 제어기로 전송하는 단계를 포함한다. 액션 선택 엔진과 통신하는 다수의 행동은 로봇 시스템 액추에이터들의 동적 한계들을 고려하는 실행 가능 로봇 명령들에 대한 액션 모델들에 의해 시뮬레이션된 결과들을 평가함으로써 협력할 수 있다. 일부 구현들에서, 이 방법은 로봇 제어기로부터 시스템 상태를 취득하는 단계, 및 각각의 액션 모델 및 각각의 행동에 시스템 상태를 통지하는 단계를 포함한다.

본 발명의 위의 두 양태의 구현들은 다음 특징들 중 하나 이상을 포함할 수 있다. 일부 구현들에서, 액션 모델을 호출하여 액션 공간에 대한 실행 가능 명령들을 생성하는 단계는, 로봇 시스템의 이전에 선택된 명령에 기초하고, 동적 액추에이터 한계들(가속도, 속도, 토크 등)에 의해 현재 상태로부터 가능한 확산으로 제한되는 명령들의 무작위 세트를 생성하는 단계를 포함한다. 액션 모델 휴리스틱이 이전에 선택된 명령의 주변에 명령들을 생성하는 예들에서, 액션 선택 엔진은 무작위로 생성된 실행 가능 명령들의 세트를 이용하여, 언덕 오르기(hill-climbing) 무작위 검색을 실행할 수 있다. 이러한 검색은 액션 공간의 명령 이력을 이용하는 검색 기술을 포함하고, 그리고/또는 현재의 명령에 기초하는 무작위 검색일 수 있다.

바람직하게는, 각각의 액션 모델이 소정의 순서로 순차적으로 호출되며, 각각의 액션 모델 내의 각각의 액션 공간이 소정의 순서로 순차적으로 호출된다. 임의의 이전 액션 공간들의 승리 결과들은 각각의 액션 공간에 대한 승리 결과를 선택할 때 고려된다. 결과 평가들은 각각의 행동과 관련된 가중치들에 따라 가중될 수 있다. 일부 예들에서, 이 방법은 종합 명령에 대한 종합 결과를 생성하는 단계, 및 종합 결과를 피드백으로 각각의 행동으로 전송하는 단계를 포함한다.

또 다른 양태에서, 로보틱스 시스템은 다수의 로봇 자원, 각각의 로봇 자원에 대한 제어 중재기, 및 제어 중재기들과 통신하는 다수의 애플리케이션을 포함한다. 각각의 제어 중재기는 그와 관련된 로봇 자원들을 제어한다. 각각의 애플리케이션은 제어 중재기들과 통신하는 로봇 제어기, 로봇 제어기와 통신하는 액션 선택 엔진, 액션 선택 엔진과 통신하는 적어도 하나의 행동, 및 액션 선택 엔진과 통신하는 적어도 하나의 액션 모델을 포함한다. 액션 선택 엔진은 액션 선택 사이클을 주기적으로 실행하여, 로봇 자원들 상에서의 실행을 위해 로봇 제어기로 전송되는 종합 명령을 생성한다. 각각의 액션 모델은 로봇 자원들 중 적어도 하나를 모델링하며, 적어도 하나의 액션 공간을 갖는다. 로봇 관리기가 애플리케이션들 및 제어 중재기들과 통신한다. 로봇 관리기는 주어진 시간에 어느 애플리케이션이 로봇 자원들 중 하나 이상에 대한 독점 제어를 갖는지를 결정하기 위한 애플리케이션 우선 순위 정책을 구현한다. 액션 선택 사이클은 각각의 액션 모델의 각각의 액션 공간에 대한 명령을 선택하는 단계, 각각의 액션 공간에 대한 축적된 명령들에 기초하여 단일 종합 명령을 생성하는 단계, 및 종합 명령을 로봇 제어기로 전송하는 단계를 포함한다.

이러한 본 발명의 양태의 구현들은 다음 특징들 중 하나 이상을 포함할 수 있다. 일부 구현들에서, 각각의 액션 모델은 로보틱스 시스템으로부터 독립적으로 제거될 수 있으며, 액션 모델 애플리케이션 프로그래밍 인터페이스를 통해 액션 선택 엔진과 통신한다. 액션 모델 애플리케이션 프로그래밍 인터페이스는 액션 모델의 자원 및 결과 상태 공간 구조를 제공하도록 구성되는 액션 공간 취득 기능을 포함한다. 일부 예들에서, 액션 모델 애플리케이션 프로그래밍 인터페이스는 액션 선택 사이클을 개시하도록 구성되는 사이클 개시 기능, 주어진 액션 공간에 대한 명령들을 생성하도록 구성되는 명령 생성 기능, 주어진 명령들에 대한 결과들을 시뮬레이션하도록 구성되는 명령 시뮬레이션 기능, 및 특정 액션 공간에 대해 선택된 명령을 액션 모델에 통지하도록 구성되는 명령 통지 기능을 포함한다.

일부 구현들에서, 각각의 행동은 로보틱스 시스템으로부터 독립적으로 제거 가능하며, 행동 애플리케이션 프로그래밍 인터페이스를 통해 액션 선택 엔진과 통신한다. 행동 애플리케이션 프로그래밍 인터페이스는 이용을 위해 행동을 초기화하도록 구성되는 초기화 기능, 액션 선택 사이클을 개시하도록 구성되는 사이클 개시 기능, 결과들의 집합을 평가하도록 구성된 평가 기능, 및 액션 선택 사이클이 완료되었음을 각각의 행동에 통지하도록 구성되는 사이클 종료 기능을 포함한다.

일부 구현들에서, 액션 선택 사이클은 로봇 제어기로부터 시스템 상태를 취득하는 단계, 각각의 액션 모델 및 각각의 행동에 시스템 상태를 통지하는 단계, 및 각각의 액션 모델 및 각각의 행동에 액션 선택 사이클의 개시를 통지하는 단계를 포함한다.

일부 예들에서, 각각의 액션 공간에 대한 명령을 선택하는 단계는 대응하는 액션 모델을 호출하여, 액션 공간에 대한 실행 가능 명령을 생성하는 단계, 대응하는 액션 모델을 호출하여, 실행 가능 명령들에 대한 결과들을 생성하는 단계, 각각의 행동을 호출하여, 각각의 결과를 평가하고 각각의 결과에 대한 결과 평가를 제공하는 단계, 각각의 행동의 결과 평가들을 축적하는 단계, 액션 공간에 대한 승리 결과를 선택하는 단계, 및 승리 결과에 대응하는 명령을 선택하는 단계를 포함한다. 바람직하게는, 로보틱스 시스템은 각각의 로봇 제어기, 각각의 제어 중재기 및 로봇 관리기 사이에 비동기 메시징을 제공하도록 구성되는 출판-구독 시스템을 포함한다.

다른 양태에서, 로보틱스 시스템은 다수의 로봇 자원, 각각의 로봇 자원에 대한 제어 중재기, 및 제어 중재기들과 통신하는 다수의 애플리케이션을 포함한다. 각각의 제어 중재기는 그와 관련된 로봇 자원을 제어한다. 각각의 음용은 제어 중재기들과 통신하는 로봇 제어기 및 로봇 제어기와 통신하는 액션 선택 엔진을 포함한다. 로봇 관리기가 애플리케이션들 및 제어 중재기들과 통신하여, 어느 애플리케이션이 주어진 시간에 그 애플리케이션에 의해 요구되는 로봇 자원들에 대한 독점 제어를 갖는지를 결정하기 위한 애플리케이션 우선 순위 정책을 구현한다. 액션 선택 엔진은 로봇 자원들 중 하나 이상을 모델링하는 각각의 액션 모델의 각각의 액션 공간 상에서 휴리스틱 검색을 실행하여, 실행 가능한 명령들을 식별한다. 각각의 액션 모델은 각각의 명령에 대한 결과를 제공한다. 액션 선택 엔진은 액션 선택 엔진과 통신하는 각각의 행동에 의해 제공되는 결과 평가들에 기초하여 각각의 액션 공간에 대한 명령들 중 하나를 선택한다. 액션 선택 엔진은 각각의 액션 공간에 대해 선택된 명령들에 기초하여 제어 중재기들을 통해 로봇 자원들에 대해 로봇 제어기에 의해 실행될 종합 명령을 생성한다.

이러한 본 발명의 양태의 구현들은 다음 특징들 중 하나 이상을 포함할 수 있다. 일부 구현들에서, 액션 선택 엔진은 각각의 액션 공간에 대한 결과 평가들을 축적하고, 각각의 액션 공간에 대한 승리 결과를 선택한다. 액션 선택 엔진은 각각의 액션 공간에 대한 승리 결과에 대응하는 명령을 선택한다. 액션 모델은 휴리스틱 검색을 제공할 수 있다. 바람직하게는, 액션 선택 엔진은 각각의 액션 모델을 소정의 순서로, 그리고 각각 액션 모델 내의 각각의 액션 공간을 소정의 순서로 순차적으로 처리한다. 액션 선택 엔진은 결과 평가들에 기초하여 대응하는 승리 결과를 선택함으로써 각각의 액션 공간에 대한 명령을 선택한다. 결과 평가들은 각각의 행동과 관련된 가중치들에 따라 가중된다. 액션 선택 엔진은 각각의 액션 공간에 대한 승리 결과를 선택할 때 임의의 이전 액션 공간들의 승리 결과들을 이용할 수 있다. 액션 선택 엔진은 종합 명령에 대한 종합 결과를 생성하고, 종합 결과를 피드백으로서 각각의 행동으로 전송한다.

다른 양태에서, 로보틱스 제어를 위한 액션 선택 시스템은 하나 이상의 액션 모델, 하나 이상의 행동 및 하나 이상의 액션 선택 엔진을 포함한다. 각각의 액션 모델은 물리적 자원에 대한 명령들에 대한 시뮬레이션된 상태 전파를 정의하는 적어도 하나의 액션 공간 모델, 물리적 자원에 대한 소정의 제한된 수의 실행 가능 명령들을 생성하는 명령 생성 루틴, 및 대응하는 액션 공간 모델의 시뮬레이션된 상태 전파를 이용하여 시뮬레이션된 결과들을 생성하는 명령 시뮬레이션 루틴을 포함한다. 각각의 시뮬레이션된 결과는 하나의 실행 가능 명령에 대응한다. 각각의 행동은 센서 데이터를 수집하기 위한 루틴, 및 센서 데이터, 현재 자원 상태 데이터, 및 행동과 관련된 소정의 목표들을 고려하는 평가 루틴을 이용하여 시뮬레이션된 결과들에 스코어들을 할당하는 루틴을 포함한다. 각각의 액션 선택 엔진은 각각의 액션 모델 객체의 각각의 액션 공간 모델로부터 시뮬레이션된 결과들을 순차적으로 취득하고, 스코어들을 할당하기 위해 각각의 행동 객체에 시뮬레이션된 결과들을 제공하고, 행동 객체들 사이의 소정의 가중에 따라 스코어들을 가중하고, 가중된 스코어들을 비교하여 각각의 액션 공간 모델에 대한 하나의 승리 결과를 결정하고, 이어서 각각의 액션 공간 모텔에 대한 하나의 승리 결과에 대응하는 하나의 실행 가능 명령을 하나의 실행 가능 명령, 하나의 승리 결과 및 하나의 액션 공간 모텔에 대응하는 물리 자원으로 전송하기 위한 루틴을 포함한다.

이러한 본 발명의 양태의 구현들은 다음 특징들 중 하나 이상을 포함할 수 있다. 일부 구현들에서, 명령 생성 루틴은 액션 공간 모델의 전체에 걸쳐 명령들을 생성하고, 명령 시뮬레이션 루틴은 액션 공간 모델의 전체에 걸쳐 분포된 명령들로부터 시뮬레이션된 결과들을 생성한다. 바람직하게는, 명령 생성 루틴은 액션 공간 모델의 전체에 걸쳐 무작위 명령들을 생성한다. 다른 구현들에서, 명령 생성 루틴은 액션 공간 모델 내의 현재의 명령 근처에 명령들을 생성하며, 명령 시뮬레이션 루틴은 액션 공간 모델 내의 현재 명령 근처에 분포된 명령들로부터 시뮬레이션된 결과들을 생성한다. 바람직하게는, 명령 생성 루틴은 액션 공간 모델 내의 현재 명령의 근처에 무작위 명령들을 생성한다. 일부 구현들에서, 명령 생성 루틴은 액션 공간 모델 내의 하나 이상의 이전 명령 근처에 명령들을 생성하고, 명령 시뮬레이션 루틴은 액션 공간 모델 내의 하나 이상의 이전 명령 근처에 분포된 명령들로부터 시뮬레이션된 결과들을 생성한다. 바람직하게는, 명령 생성 루틴은 액션 공간 모델 내의 하나 이상의 이전 명령 근처에 무작위 명령들을 생성한다.

다른 양태에서, 로보틱스 제어를 위한 액션 선택 엔진은 (i) 액션 선택 엔진과 관련된 액션 모델 객체의 액션 공간 모델로부터 시뮬레이션된 결과들을 순차적으로 취득하고, (ii) 시뮬레이션된 결과들을 액션 선택 엔진과 관련된 행동 객체들에 제공하기 위한 루틴을 포함한다. 관련된 액션 모델 객체들은 물리 자원에 대한 명령들에 대한 시뮬레이션된 상태 전파를 정의하는 적어도 하나의 액션 공간 모델, 물리 자원에 대한 소정의 제한된 수의 실행 가능 명령들을 생성하는 명령 생성 루틴, 및 대응하는 액션 공간 모델의 시뮬레이션된 상태 전파를 이용하여, 하나의 실행 가능 명령에 각기 대응하는 시뮬레이션된 결과들을 생성하는 명령 시뮬레이션 루틴에 의해 특성화된다. 관련된 행동 객체들은 센서 데이터를 수집하기 위한 루틴, 및 센서 데이터, 현재 자원 상태 데이터, 및 행동과 관련된 소정의 목표들을 고려하는 평가 루틴을 이용하여 시뮬레이션된 결과들에 스코어들을 할당하는 루틴에 의해 특성화된다. 전술한 루틴은 또한 (iii) 행동 객체들 사이의 소정의 가중에 따라 스코어들을 가중하는 단계, (iv) 가중된 스코어들을 비교하여, 각각의 액션 공간 모텔에 대한 하나의 승리 결과를 결정하는 단계, 및 이어서 (v) 각각의 액션 공간 모델에 대한 하나의 승리 결과에 대응하는 하나의 실행 가능 명령을 하나의 실행 가능 명령, 하나의 승리 결과 및 하나의 액션 공간 모델에 대응하는 물리 자원으로 전송하는 단계를 포함한다.

다른 양태에서, 로보틱스 제어를 위한 행동은 (i) 센서 데이터를 수집하기 위한 루틴, 및 (ii) 접속된 객체로부터 한 세트의 시뮬레이션된 결과들을 수신하고, 센서 데이터, 현재 자원 상태 데이터, 이전의 사이클들로부터 이전에 결정된 일련의 승리 결과들, 및 행동과 관련된 소정의 목표들을 고려하는 평가 루틴을 이용하여 시뮬레이션된 결과들에 스코어들을 할당하는 루틴을 포함한다. 세트 내의 각각의 시뮬레이션 결과는 물리 자원에 대한 하나의 실행 가능 명령에 대응하는 시뮬레이션된 상태 전파로서 제공된다.

다른 양태에서, 로보틱스 제어를 위한 액션 모델은 (i) 물리 자원에 대한 명령들에 대한 시뮬레이션된 상태 전파를 정의하는 적어도 하나의 액션 공간 모델, (ii) 물리 자원에 대한 소정의 제한된 수의 실행 가능 명령들을 생성하는 명령 생성 루틴, (iii) 대응하는 액션 공간 모델의 시뮬레이션된 상태 전파들 이용하여 시뮬레이션 결과들을 생성하는 명령 시뮬레이션 루틴, 및 (iv) 접속 객체로부터의 메시지들에 응답하여, 각각의 액션 모델 객체의 각각의 액션 공간 모델에 대한 적어도 한 세트의 시뮬레이션 결과들을 제공하는 루틴을 포함한다. 각각의 시뮬레이션 결과는 하나의 실행 가능 명령에 대응한다. 일부 예들에서, 액션 모델 애플리케이션 프로그래밍 인터페이스는 이벤트들을 핸들링하도록 구성되는 이벤트 핸들러 기능을 포함한다.

본 발명의 하나 이상의 구현의 상세들은 첨부 도면들 및 아래의 설명에서 제공된다. 다른 특징들, 목적들 및 이익들은 설명 및 도면들로부터 그리고 청구항들로부터 명백할 것이다.

도 1은 로보틱스 시스템의 개략도이다.
도 2는 제어 중재 시스템의 개략도이다.
도 3은 행동 시스템의 개략도이다.
도 4는 액션 모델을 호출하여 액션 모델의 각각의 액션 공간에 대한 실행 가능 명령들 및 대응하는 결과들을 생성하는 액션 선택 엔진의 개략도이다.
도 5는 아암(arm)의 액션 모델을 호출하여 액션 모델의 각각의 액션 공간에 대한 실행 가능 명령들 및 대응하는 결과들을 생성하는 액션 선택 엔진의 개략도이다.
도 6a는 액션 모델의 2축 액션 공간의 개략도이다.
도 6b는 액션 선택 사이클의 개략도이다.
도 6c는 3개의 대응 명령에 대해 생성된 3개의 결과의 3개의 시뮬레이션된 궤적의 개략도이다.
도 7은 액션 선택 사이클의 흐름도이다.
도 8은 액션 선택 사이클 동안에 모든 액션 공간에 걸치는 최적화 패스 루프의 흐름도이다.
도 9는 액션 선택 사이클의 흐름도이다.
도 10은 액션 선택 엔진이 제1 액션 모델을 호출하여 액션 모델의 각각의 액션 공간에 대한 실행 가능 명령들 및 대응 결과들을 생성하는 액션 선택 사이클의 단계 동안의 로보틱스 시스템의 개략도이다.
도 11은 액션 선택 엔진이 평가를 위해 결과들을 행동들로 전송할 때의 도 10의 로보틱스 시스템의 개략도이다.
도 12는 액션 선택 엔진이 제2 액션 모델을 호출하여 액션 모델의 제1 액션 공간에 대한 실행 가능 명령들 및 대응 결과들을 생성할 때의 도 10의 로보틱스 시스템의 개략도이다.
도 13은 액션 선택 엔진이 평가를 위해 결과들을 행동들로 전송할 때의 도 12의 로보틱스 시스템의 개략도이다.
도 14는 액션 선택 엔진이 제2 액션 모델을 호출하여 액션 모델의 제2 액션 공간에 대한 실행 가능 명령들 및 대응 결과들을 생성할 때의 도 12의 로보틱스 시스템의 개략도이다.
도 15는 액션 선택 엔진이 종합 명령 패키지를 로봇 제어기로, 그리고 종합 결과 패키지를 피드백으로서 행동들로 전송할 때의 도 10의 로보틱스 시스템의 개략도이다.
도 16은 각각의 액션 공간에 대한 승리 결과를 선택하기 위하여 디폴트 결과 세트를 이용하는 액션 선택 엔진의 개략도이다.
도 17은 행동 선택 정책의 개략도이다.
도 18은 행동 결합 정책의 개략도이다.
도 19는 행동 전환 정책의 개략도이다.
도 20은 행동 순서화 정책의 개략도이다.
도 21은 로보틱스 시스템 상에서 실행되는 다수의 애플리케이션의 개략도이다.
도 22는 병렬/멀티코어 확장 로보틱스 시스템의 개략도이다.
도 23은 로보틱스 프레임워크의 개략도이다.
다양한 도면들에서 동일한 참조 부호들은 동일한 요소들을 지시한다.

본 발명은 개별적으로 작성되고 독립적으로 배치된 프로그램들 또는 애플리케이션들이 로봇 상에서 동시에 실행되고, 로봇을 동시에 제어하는 것을 가능하게 하는 로보틱스 시스템을 제공한다. 독립적으로 배치된 애플리케이션들은 실행시에 동적으로 결합되며, 로봇의 자원들을 공유할 수 있는 것이 필요하다. 실행시에 애플리케이션들 사이에서 로봇 자원들을 동적으로 공유하기 위해 저레벨 정책이 구현된다. 정책은 어느 애플리케이션이 그 애플리케이션에 의해 요구되는 로봇 자원들에 대한 제어를 갖는지(예컨대, 애플리케이션들 사이의 우선 순위 계층 구조)를 결정한다. 애플리케이션들은 동적으로 개시되고 중지되며, 서로 완전히 무관하게 실행될 수 있다. 로보틱스 시스템은 또한, 서로 돕기 위해 서로 결합될 수 있는 복잡한 행동들을 제공한다.

도 1을 참조하면, 로보틱스 시스템(100)은 서로 통신하는 제어 중재 시스템(102) 및 행동 시스템(104)을 포함한다. 제어 중재 시스템(102)은 애플리케이션들(130)이 로보틱스 시스템(100)에 동적으로 추가되고 제거되는 것을 허가하며, 애플리케이션들(130)이 임의의 다른 애플리케이션들(130)에 대해 알 필요없이 로봇을 각기 제어하는 것을 가능하게 하는 것을 돕는다. 즉, 제어 중재 시스템(102)은 애플리케이션들(130)과 로보틱스 시스템(100)의 자원들(122) 사이에 간단한 우선 순위 제어 메커니즘을 제공한다. 제어 중재 시스템은 하나 이상의 로봇 제어기(140), 로봇 관리기(150) 및 하나 이상의 제어 중재기(120)를 포함한다. 이러한 컴포넌트들은 공통 프로세스 또는 컴퓨터 내에 있을 필요가 없으며, 임의의 특정 순서로 개시될 필요가 없다. 이러한 능력은 독립적인 컴퓨팅 능력을 갖는 상이한 모듈들(예를 들어, 페이로드들)이 로보틱스 시스템(100)에 플러그 인되는 것을 허가하는 것은 물론, 동일한 액추에이터 공간을 이용하면서, 전체 로보틱스 시스템(100)에 여러 능력들을 제공하는 소형 로봇 두뇌를 플러그 인할 수 있는 능력을 제공한다.

로봇 제어기(140) 컴포넌트는 애플리케이션들(130)에 대해 제어 중재 시스템(102)에 대한 인터페이스를 제공한다. 모든 애플리케이션(130)에 대해 이 컴포넌트의 인스턴스가 존재한다. 로봇 제어기(140)는 인증, 분산된 자원 제어 중재기들, 명령 버퍼링 등의 복잡성들을 추상화하고 캡슐화하여 제거한다.

로봇 관리기(150)는 어느 애플리케이션(130)이 임의의 특정 시간에 로봇 자원들(122) 중 임의 자원에 대한 독점적 제어를 갖는지를 제어함으로써 애플리케이션들(130)의 우선 순위를 조정한다. 이것은 정보의 중앙 조정자이므로, 로봇당 로봇 관리기(150)의 하나의 인스턴스만이 존재한다. 로봇 관리기(150)는 로봇 제어기들(140)의 선형 우선 순위를 갖는 우선 순위 정책(260)을 구현하며, 하드웨어 제어를 제공하는 자원 제어 중재기들(120)을 계속 추적한다.

제어 중재기(120)는 모든 애플리케이션(130)으로부터 명령들을 수신하고, 애플리케이션들의 우선 순위들에 기초하여 단일 명령을 생성하며, 그와 관련된 자원들(122)에 대해 단일 명령을 발행한다. 제어 중재기(120)는 또한 그와 관련된 자원들(122)로부터 상태 피드백을 수신하고, 상태 피드백을 애플리케이션들(130)로 백업 전송한다. 로봇 자원들(122)은 하나 이상의 하드웨어 제어기들을 갖는 기능 모듈들(예컨대, 액추에이터들, 구동 시스템들 및 이들의 그룹들)의 네트워크일 수 있다. 각각의 자원(122)은 그 자원(122)에 대해 명령들을 발행하는 제어 중재기(120)를 구비한다. 로봇 자원들(122)은 플러그될 수 있으며, 실행시에 로보틱스 시스템(100) 및 그의 네트워크(110)에 동적으로 추가되거나 제거될 수 있다. 제어 중재기(120)의 명령들은 특정 액션들을 수행하도록 그의 자원(122)에 고유하다.

도 1을 계속 참조하면, 로봇(도시되지 않음)을 위한 로보틱스 시스템(100)은 실시간 발행/구독 시스템을 통해 제어 중재 시스템(102)에 대한 인트라-프로세스 통신을 제공하는 네트워크(110)를 포함한다. 발행/구독(또는 pub/sub)은 메시지들의 송신기들(발행자들)이 그들의 메시지들을 특정 수신기들(구독자들)로 전송하도록 프로그래밍되지 않는 비동기 메시징 패러다임이다. 오히려, 발행된 메시지들은 (존재할 경우) 어떤 구독자들이 존재할 수 있는지에 대한 지식 없이 클래스들로 특성화된다. 구독자들은 하나 이상의 클래스에 관심을 표시하고, (존재할 경우) 어떤 발행자들이 존재하는지에 대한 지식 없이 관심 있는 메시지들만을 수신한다. 이러한 발행자들과 구독자들의 분리는 더 큰 확장성 및 더 동적인 네트워크 토폴로지를 제공할 수 있다. 발행은 분산형 데이터베이스 내의 특정 데이터 아이템을 갱신하기 위한 메커니즘을 제공하며, 따라서 발행 클라이언트가 구독자들에 대한 어떠한 지식도 갖지 않고도, 값이 모든 관련 당사자들("구독자들")에게 전파될 것이다. 구독은 데이터 아이템의 정확한 소스("발행자")에 대한 지식 없이도 분산형 데이터베이스로부터 특정 데이터 아이템에 액세스하기 위한 메커니즘을 제공한다. 예를 들어, 행동들(300)은 로컬 네트워크(110) 상에서 발행/구독 시스템에 발행된 센서 정보를 수집할 수 있다. 다른 예에서, 로봇 제어기들(140)은 로컬 네트워크(110) 상에서 발행/구독 시스템의 공유 메모리에 대해 명령들(440)을 발행할 수 있으며, 이 공유 메모리는 임의의 특정 순서로 명령들(440)을 인출하기 위해 제어 중재기들(120)에 의해 액세스된다. 바람직하게는, 제어 중재기들(120)은 발행된 우선 순위 정책(160)에 따라 명령들(440)을 인출한다.

발행/구독 모델에서, 통상적으로 구독자들은 발행된 전체 메시지들의 서브세트만을 수신한다. 수신 및 처리를 위한 메시지들을 선택하는 프로세스를 필터링이라 한다. 두 가지 일반적 형태의 필터링, 즉 주제 기반 필터링 및 내용 기반 필터링이 존재한다. 주제 기반 시스템에서, 메시지들은 "주제들" 또는 지정된 논리 채널들에 대해 발행된다. 주제 기반 시스템 내의 구독자들은 그들이 구독하는 주제들에 대해 발행된 모든 메시지를 수신하며, 주제에 대한 모든 구독자들은 동일 메시지들을 수신할 것이다. 발행자는 구독자들이 구독할 수 있는 메시지들의 클래스들의 정의를 담당한다. 내용 기반 시스템에서, 메시지들의 속성들 또는 내용이 구독자에 의해 정의된 제한들과 매칭되는 경우에 그러한 메시지들은 그 구독자에게만 전달된다. 구독자는 메시지들의 분류를 담당한다. 어떠한 타입의 필터링도, 심지어 그 둘의 조합도 사용될 수 있다.

로보틱스 시스템(100)은 "실시간 분산 발행/구독", 예컨대 객체 모델링 그룹(OMG)의 실시간 시스템 표준에 대한 데이터 분산 서비스 5(DDS), 또는 실시간 혁신들로부터 상업적으로 이용 가능한 NDDS 구현, 또는 오픈 소스 OCERA ORTE, 또는 분산 자동화를 위한 인터페이스(IDA)의 실시간 발행 구독(RTPS), 또는 독점 또는 목적 구축 솔루션들을 포함하는 임의 형태의 전통적인 "실시간 발행/구독" 또는 그의 균등물을 이용할 수 있다. 로보틱스 시스템(100)의 바람직한 구현들에서, 발행들 및 구독들은 지정된 인스턴스들이며, 시스템 내의 임의의 다른 컴포넌트와 똑같이 생성, 관리, 이용 및 접속될 수 있다. 통신 엔드포인트의 추가는 발행 또는 구독을 인스턴스화하고 파라미터들을 제공하는 일이다. 이어서, 클라이언트 노드는 강형(strongly typed) 데이터를 다수의 스레드, 프로세스 또는 컴퓨터 시스템 사이에 비동기 전송하기 위해 간단한 기록/판독 API들을 사용할 수 있다. 발행/구독 미들웨어 구현은 타입 시스템에 의해 데이터 전송 구현의 일부로서 제공되는 타입 송출 인터페이스들을 이용한다. 발행/구독 시스템의 기본 개념은 분산형 공유 메모리 공간이며, 로컬 네트워크(110) 상의 이 분산형 공유 메모리 내의 슬롯들은 지연된 바인딩을 지원하며, 강형이다. 각각의 기계 사이의 상태의 네트워크 반영도 존재하며, 따라서 발행/구독 메타포(metaphor)는 컴퓨터들의 네트워크에 걸쳐 유지된다.

발행/구독은 공유 메모리를 동일 기계 상의 발행자들과 구독자들 사이의 데이터 전송을 위한 메커니즘으로서 사용한다. UDP 멀티캐스트는 기계들 사이의 네트워킹 갱신들을 위해 사용된다. 발행자들은 항상, 구현에 의해 핸들링되는 크로스 네트워크 전파를 이용하여 공유 메모리에 기록한다. 구독자들은 발행된 값이 국지적으로 이용 가능한 데이터에 대한 갱신 레이턴시의 명백한 변화가 아니라 상이한 기계로부터 나오고 있을 수 있다는 사실을 알지 못한다. 발행들 및 구독들은 지정된 인스턴스들이다. 사용 가능한 발행들 및 구독들은 2개의 객체, 즉 이들을 이용하는 프로그램 내의 객체 및 공유 메모리 내의 관련 엔드포인트를 포함한다. 엔드포인트들은 이름에 의해 참조되며, "공개" 또는 "비공개"일 수 있다. 발행 또는 구독이 공개 엔드포인트를 갖는 경우, 엔드포인트의 이름은 발행 또는 구독의 경로명이다. 비공개 엔드포인트의 이름은 엔드포인트가 생성될 때 자동으로 지어지며, 고유한 것이 보증된다. 이러한 지정된 엔드포인트 모델로 인해, 발행/구독은, 각각의 주제가 고유한 값 타입을 갖지만, 주제 기반 시스템이다. 동일 기계 상에서의 프로세스들 사이의 많은 상이한 상태의 빠른 공유를 가능하게 하기 위하여 이러한 인터-프로세스 통신 메커니즘의 레이턴시 및 록킹 행동들에 대한 강한 요구들이 존재한다. 특히, 발행에 기록함으로써 값을 발행하려는 시도는 기록되는 발행이 구독되는지의 여부에 관계없이 상이한 발행에 대한 동시 기록에 의해서도, 임의의 구독의 동시 갱신에 의해서도 차단되지 않아야 한다.

서버 프로그램(발행/구독 레지스트리 서버)이 공유 메모리의 생성 및 초기화를 담당한다. 이것은 엔드포인트들 및 이들 사이의 접속들을 등록 및 제거하고, 등록된 엔드포인트들 및 접속들의 세트에 대한 정보를 취득하기 위한 네트워크 서비스들을 제공한다. 이러한 네트워크 서비스들은 하나의 기계 상에서의 발행들과 다른 기계들 상에서의 구독들 사이에 접속들을 설정하고, 네트워크를 통해 원격 구독들로 전송될 국지적 발행 데이터를 준비하는 것을 포함한다.

구독은 값 갱신을 명시적으로 요청하여, 공유 메모리 내의 접속된 발행 엔드포인트로부터 현재 값을 취득해야 한다. 이것은 구독을 소유하는 클라이언트로 하여금, 새로운 데이터의 비동기 도달을 처리하도록 요구하는 것이 아니라, 값 갱신들이 발생하는 시기를 명확히 제어하는 것을 허가한다. 발행/구독은 또한 구독이 이용 가능한 새로운 값을 갖도록 기다리는 것을 지원한다. 이것은 접속된 발행으로부터 새로운 데이터를 취득하려고 시도하는 것을 포함하며, 가장 최근에 발행된 데이터가 이전의 구독 갱신에 대한 것과 (타임스탬프에 의해) 동일한 경우, 갱신 시도는 발행자가 새로운 값을 기록할 때까지 기다릴 것이다. 이것은 과다한 시스템 자원들을 점유하거나, 새로운 값들이 이용 가능하게 되는 것과 그들이 통지되는 것 사이에 큰 레이턴시들을 갖지 않고, 애플리케이션이 새로운 값들을 "폴링(polling)"하는 것을 허가한다. 구독들은 또한 구독 그룹의 일부로서 생성될 수 있다. 구독 그룹은 여러 구독들을 동시에 갱신하기 위한 편리한 메커니즘을 제공한다. 이것은 주기적인 스레드들에서의 일반적인 사용 예이며, 예를 들어 각각의 주기적인 액션은 여러 구독을 갱신한 후에 이들 모두를 처리하는 것으로 구성된다. 구독 그룹들은 또한 임의의 구독이 새로운 값을 갖도록 기다려, 다수의 데이터 소스 상에서의 선택과 같은 행동을 제공하는 것을 지원한다.

각각의 발행 또는 구독은 관련된 값 타입을 갖는다. 이러한 값 타입은 발행 또는 구독이 생성될 때 지정되며, 객체에 기록되거나 객체에 의해 수신될 수 있는 데이터의 타입을 지정한다. 이러한 타입은 또한 관련 엔드포인트에 대한 값 타입을 지정하며, 구독은 동일 값 타입을 갖는 발행에만 접속될 수 있다. 발행 가능하기 위하여, 그러한 값 타입은 타입 시스템에 의해 지정되는 바와 같이 "송출 가능"해야 한다. 특히, 이것은 타입이 부스트 직렬화 아카이브에 기록되는 것을 지원할 것을 요구한다. 발행/구독은 부스트 직렬화 라이브러리로부터의 이진 아카이브들을 이용하여, 발행자에 의해 공유 메모리에 기록되는 데이터를 인코딩하고, 구독자들을 위해 그 데이터를 디코딩한다. 이러한 공유 메모리를 통한 전송은 해당 타입이 "고속으로 송출 가능할" 때 더 최적화된다.

도 2는 제어 중재 시스템(102) 상에서의 제어 중재 프로세스의 일례를 제공한다. 로봇 관리기(150)는 제어 정책(160)을 구현하는, 로컬 네트워크(110)의 (예를 들어, 발행/구독 시스템에 대한) 공유 메모리 내에 저장된 로봇 관리기 구성(152)을 구비한다. 로봇 관리기 구성(152)은 로보틱스 시스템(100) 내에서 이용 가능한 모든 로봇 제어기들(140)의 (예를 들어, 이름에 의한) 사용자 정의 로봇 제어기 리스트(154) 및 모든 제어 중재기들(120)의 (예를 들어, 이름에 의한) 사용자 정의 제어 중재기 리스트(156)를 저장한다. 로봇 제어기 리스트(154) 및 제어 중재기 리스트(156)는 로봇 제어기들(140) 및 중재기들(120)의 선형 우선 순위를 제공하기 위해 사용자에 의해 또는 시스템 프로세스에 의해 자동으로 배열될 수 있다. 로봇 제어기 리스트(154) 내에 아이템화된 모든 로봇 제어기(140)는 로컬 네트워크(110)의 공유 메모리 내에 대응하는 로봇 제어기 메모리 블록(142)을 갖는다. 유사하게, 제어 중재기 리스트(156) 내에 아이템화된 모든 제어 중재기(120)는 로컬 네트워크(110)의 공유 메모리 내에 대응하는 제어 중재기 메모리 블록(124)을 갖는다. 로봇 제어기들(140) 각각은 로봇 관리기 구성(152)과 통신하여, 제어 중재기 리스트(156)를 취득함으로써 로보틱스 시스템(100)에서 명령들을 수신하는 데 이용할 수 있는 모든 제어 중재기들(120)을 파악한다. 각각의 로봇 제어기(140)는 그의 대응하는 로봇 제어기 메모리 블록(142)에 명령(440) 및 상태(144)를 발행한다. 명령(440) 및 상태(144)의 발행은 발행/구독 시스템을 통해 공유 메모리의 상태 변화를 유발한다. 각각의 제어 중재기(120)는 공유 메모리 변화에 응답하여 깨어난다.

각각의 제어 중재기(120)는 로봇 관리기 구성(152)과 통신하여, 로봇 제어기 리스트(154)를 취득함으로써 로보틱스 시스템(100) 내의 모든 로봇 제어기들(140)을 파악하며, 모든 로봇 제어기 메모리 블록들(142)로부터 명령들(440) 및 상태들(144)을 인출한다. 각각의 제어 중재기(120)는 각각의 로봇 제어기 메모리 블록(142)으로부터 명령(440) 및 상태(144)를 로봇 제어기 리스트(154)에 의해 정의된 순서로 순차적으로 인출하며, 로봇 제어기 상태(144)에 따라, 명령(440)을 그 제어 중재기(120)의 커미트되지 않은 접속된 자원들(120)(예를 들어, 하드웨어) 중 하나 이상에 대해 명령(440)을 발행한다. 각각의 로봇 제어기(140)는 타협 또는 비타협의 상태(144)를 갖는다. 타협 상태(144)의 경우, 로봇 제어기(140)는 부분 명령(440)의 발행을 기꺼이 허가한다. 이와 달리, 비타협 상태(144)의 경우, 로봇 제어기(140)는 전체 명령(440)의 발행만을 허가한다.

예를 들어, 도 2를 참조하면, 제1 제어 중재기(120A)는 터릿, 쇼울더, 엘보-1 및 엘보-2를 갖는 아암 자원(122)을 제어한다. 로봇 제어기들(140)은 로봇 관리기 구성(152)으로부터 제어 중재기 리스트(156)를 취득함으로써 제1 제어 중재기(120A) 내지 제n 제어 중재기(120N)에 대해 통지받는다. 각각의 활성 로봇 제어기(140)는 제어 중재 시스템(102)에 의한 실행을 위해 행동 시스템(104)으로부터 명령(440)을 수신하고, 그의 명령(440)을 그의 각각의 로봇 제어기 메모리 블록(142)에 발행한다. 제어 중재기들(120)은 하나 이상의 명령(440)이 발행되었음을 인식하고, 실행을 위해 명령들(440)을 순차적으로 인출한다. (제어 중재기 리스트(156)에 의해 그렇게 지정되는 바와 같은) 제1 제어 중재기(120A)는 각각의 로봇 제어기 메모리 블록(142)으로부터 (로봇 제어기 리스트(154)에 의해 그렇게 지정되는 바와 같은) 제1 로봇 제어기(140A)의 명령(440) 및 상태(144)를 인출하며, 이는 이 예에서 쇼울더 자원(122A-2)에 대한 명령(440)을 포함한다. 제1 로봇 제어기(140A)의 상태(144)는 관련이 없는데, 그 이유는 자원들(122)의 어느 것도 아직 커미트되지 않았기 때문이다. 제1 제어 중재기(120A)는 제1 로봇 제어기(140A)의 명령(440)에 대해 쇼울더 자원(122A-2)을 커미트한다.

이어서, 제1 제어 중재기(120A)는 각각의 로봇 제어기 메모리 블록(142)으로부터 제2 로봇 제어기(140B)의 명령(440) 및 상태(144)를 인출하며, 이는 이 예에서 쇼울더 자원(122A-2) 및 터릿 자원(122A-1)에 대한 명령(440) 및 타협 상태를 포함한다. 쇼울더 자원(122A-2)은 제1 로봇 제어기(140A)에 대해 커미트되었으므로, 제1 제어 중재기(120A)는 제2 로봇 제어기(140B)의 전체 명령(440)을 발행할 수 없을 것이다. 그러나, 제2 로봇 제어기(140B)는 타협의 상태를 가지므로, 제1 제어 중재기(120A)는 현재 커미트되지 않은 터릿 자원(122A-1)을 제2 로봇 제어기(140B)의 명령(440)에 대해 커미트함으로써 명령(440)을 부분적으로 발행할 수 있을 것이다. 제1 제어 중재기(120A)는 로봇 제어기 리스트(154) 내의 각각의 연속적인 로봇 제어기(140)의 명령(440) 및 상태(144)를 순차적으로 계속 인출하고, 각각의 로봇 제어기(140)의 상태(144)에 따라 자원들(122)을 커미트한다.

제n 로봇 제어기(140N)의 예에서, 제1 제어 중재기(120A)는 각각의 로봇 제어기 메모리 블록(142)으로부터 명령(440) 및 상태(144)를 인출하며, 이는 이 예에서 쇼울더 자원(122A-2), 엘보-1 자원(122A-3) 및 엘보-2 자원(122A-4) 에 대한 명령(440), 및 비타협의 상태를 포함한다. 쇼울더 자원(122A-2)은 제1 로봇 제어기(140A)에 대해 커미트되었으므로, 제1 제어 중재기(120A)는 제n 로봇 제어기(140N)의 전체 명령(440)을 발행할 수 없을 것이다. 또한, 제n 로봇 제어기(140N)는 비타협의 상태를 가지므로, 제1 제어 중재기(120A)는 커미트되지 않은 엘보-1 및 엘보-2 자원들(122A-3, 122A-4)에 대해 부분적으로 명령(440)을 발행할 수 없을 것이다. 결과적으로, 제1 제어 중재기(120A)는 제n 로봇 제어기(140N)로부터의 명령(440)에 대해 어떠한 자원(122)도 커미트하지 못한다. 제n 로봇 제어기(140N)로부터의 명령(440)은 모든 필요한 자원들(122)이 커미트되지 않고 이용 가능할 때 다른 사이클 동안 단위화(unit)될 것이다.

제1 제어 중재기(120A)는 그의 모든 접속된 자원들(122)이 커미트될 때까지 각각의 로봇 제어기(140)를 통해 계속 진행한다. 모든 접속된 자원들(122)이 커미트된 경우, 제어 중재기(120)는 일관된 명령을 그의 자원들(122)에 전송하고, 그의 대응 제어 중재기 메모리 블록(124)을 자원들(122)의 상태 피드백(126)으로 갱신한다. 각각의 로봇 제어기(140)는 대응하는 제어 중재기 메모리 블록(124)으로부터 각각의 제어 중재기(120)의 상태 피드백(126)을 (예컨대, 비동기적으로) 인출할 수 있다.

도 1 및 3을 참조하면, 행동 시스템(104)은 적어도 하나의 애플리케이션(130)을 포함한다. 각각의 애플리케이션(130)은 액션 선택 엔진(200) 및 로봇 제어기(140), 액션 선택 엔진(200)에 접속된 하나 이상의 행동(300), 및 액션 선택 엔진(200)에 접속된 하나 이상의 액션 모듈(400)을 구비한다. 행동 시스템(104)은 예측 모델링을 제공하며, 행동들(300)이 가능한 결과들을 평가함으로써 로봇의 액션들을 협력하여 결정하는 것을 허가하는데, 이는 아래에 설명될 것이다. 행동(300)은 내부 상태 기계에 기초할 수 있는 평가 기능, 다수의 소스들에서 결과들(450)로의 센서 피드백의 결합, 또는 후속 계층 내의 다른 행동들(300)의 평가 기능들의 조합을 제공하는 플러그-인 컴포넌트이다. 이것은 행동들(300)이 계층적으로 중첩되고, 상이한 상황들에서 센서 피드백을 결과들(450)에 상이하게 맵핑하는 계층적 및 완전 상태의 평가 기능을 형성하는 것을 허가한다. 행동들(300)은 애플리케이션(130)에 플러그-인되므로, 이들은 애플리케이션(130) 또는 로보틱스 시스템(100)의 어떠한 다른 부분도 변경할 필요 없이 제거 및 추가될 수 있다.

액션 선택 엔진(200)은 로봇 제어기 애플리케이션 프로그래밍 인터페이스(API)(142)를 통해 로봇 제어기(140)와, 행동 API(302)를 통해 행동(300)과, 그리고 액션 모델 API(402)를 통해 액션 모델(400)과 통신한다. 각각의 컴포넌트(140, 300, 400)의 추상화 및 캡슐화는 컴플라이언트 컴포넌트들(140, 300, 400)이 액션 선택 엔진(200)과 통신하는 방법을 제공하는 그들 각각의 API(142, 302, 402)를 통해 달성된다.

행동 API(302)에 대한 예시적인 인터페이스가 아래의 표 1에 제공된다. API와 통신할 수 있는 행동은 아래와 같은 함수들 및 데이터 구조들의 일부 또는 전부를 이용하여 통신한다.

공개 멤버 기능들(행동)	설명
void init (const ActionSpaceVector &actionSpaces)	이 행동에 대한 자원 셋업을 초기화한다. 초기화한다: "init" 함수는 이용 가능한 액션 공간들의 리스트를 나타내는, 바람직하게는 "ActionSpaceVector" 타입 또는 포맷인 "actionSpaces"를 독립변수/변수로서 갖는다. 리스트의 각각의 요소는 다음을 포함하는 ActionSpace 타입이다. - 이 액션 공간 내의 상태들 및 자원들의 타입. (축, 개별 정수 자원 또는 개별 부동 자원들) - 이 공간에 대해 생성된 사이클당 전체 액션들 - 모델 공간 자체의 이름 - 공간 내의 명령 가능 자원들의 이름들
beginCycle(const ChronometerTime tNow, const float tHorizon, const CombinedState &xInit)	이 인터페이스 함수는 명령 및 관련 변수들을 행동(300)으로 전송하는 채널 또는 기준 포인터이다. 액션 선택 사이클(210)을 시작한다. 사이클을 시작한다: "beginCycle" 함수는 3개의 독립변수/변수를 갖는다: 1. tNow는 사이클의 시작에 대한 타임스탬프이다(ChronometerTime은 기준 클럭 타입이다). 2. tHorizon은 액션 선택 사이클에 대한 시간 간격, 예컨대 1초를 패스하기 위한 변수이다. 3. xInit는 시스템 자원들의 현재 상태를 나타내는 CombinedState 타입 변수이다. 이것은 다음을 포함한다: - MultiAxisState 타입인 시스템의 축 자원들의 현재 상태. 각각의 축 자원은 연속적인 위치를 갖는 로봇의 제어되는 이동 부품을 나타내는 AxisState 타입이다. 이것은 다음을 포함한다. - 자원의 현재 속도 - 자원의 현재 가속도 - 자원의 현재 절대 위치 - 자원의 현재 증가 위치 - 축 상의 힘 또는 토크 - 위의 필드들(속도, 가속도, 위치, 증가 위치, 토크)의 각각에 대해, 그 필드에 대한 불확실성 정보를 나타내기 위한 각각의 필드 - 최소/최대 속도, 가속도, 위치 및 토크에 관한 자원 한계들 - 상태의 유효성에 대한 정보를 유지하기 위한 상태 비트들. (예컨대, POSITION_INVALID 비트가 설정되는 경우, 이것은 그 축에 대한 위치 데이터가 유효하지 않음을 의미한다. - 시스템 개별 정수 자원들의 현재 상태. 각각의 개별 정수 자원의 상태는 다음을 포함하는 InitState로서 제공된다. - 상태의 값. 이 데이터는 그 안에 품질에 대한 정보 및 정보의 유효성을 유지한다. - 이것의 상태의 최소 및 최대 값
void evaluate (const std::string &space, const float tHorizon, const CombinedState &xInit, const Outcome &defaultOutcome, const OutcomeVector &outcomeOptions, UtilityValueVector &evaluations)	결과들(450)의 집합을 평가한다. "evaluate" 함수는 다음을 포함하는 여러 독립변수/변수를 패키지하거나 지시한다. - 위에 설명된 바와 같은 tHorizon - 위에 설명된 바와 같은 xInit - "space"는 이 라운드에서 평가하도록 요청받은 액션 공간을 지정하는 스트링이다. - defaultOutcome은 이 액션 공간 및 다른 액션 공간(410) 내의 상태들의 전개를 나타내는 현재의 디폴트 결과 세트(451)를 나타내는 변수이다. 내부 구조는 자원 이름들의 각각의 디폴트 결과에 대한 맵핑을 나타낸다. 이러한 표현은 액추에이터들에 대한 액션 모델 예측 상태들의 개별 시간 표현인 CombinedState의 시간 단계 시퀀스를 나타내는 Outcome 타입이다. Outcome 타입은 예측된 정보를 하나의 일관된 구조 내에 유지하기 위해 시간 시퀀스 구조 및 CombinedState 인스턴스들의 집합을 조정하는 데이터 구조(OutcomeSampleVector)를 포함한다. - outcomeOptions는 평가를 위해 행동에 제공되는 가능한 결과들의 리스트를 나타내는 변수이다. 이것은 다수의 (위와 같은) Outcome 타입을 포함한다. - 평가들은 스코어들을 수용하는 UtilityValueVector 타입 또는 포맷의 스코어들의 어레이이며, 따라서 각각의 결과 옵션에는 결과가 행동의 최종 목표를 얼마나 양호하게 충족시키는지를 결정하는 스코어가 주어진다. 각각의 결과에 대한 이용은 [-1.0, 1.0] 사이의 값으로서 스코어를 유지하는 UtilityValue 타입에 의해 표현된다. &evaluations 어레이는 행동에 의해 반환된다.
void endCycle (const ChronometerTime tEnd, const Outcome &finalOutcome, const float overallScore)	이 액션 선택 사이클(210)이 완료되었음을 통지한다. 사이클을 종료한다: "endCycle" 함수 패키지들 - tEnd, 사이클의 종료에 대한 타임스탬프 - finalOutcome, 모든 승리 결과들의 어레이 - 선택된 결과에 대한 실제의 최종 결합된/가중된 스코어를 갖는 overallScore

행동들(300)은 로봇의 전체 인식 범위의 분리 가능한 부분(예컨대, 중간 지점으로 가기 또는 충돌 회피)을 구현하도록 의도된다. 모든 행동들(300)의 상태 기계들의 조정을 지원하기 위하여, 행동 시스템(104)은 외부 컴포넌트가 모든 행동들(300) 및 액션 모델들(400)로 동시에 신뢰성 있게 전송될 개별 메시지를 포스팅하는 것을 허가하는 이벤트 프로세서(280)(이벤트 핸들링 인터페이스 메소드들을 구비함)(도 3 참조)를 제공한다. 이벤트를 이벤트 우선 순위 큐 내에 밀어넣음으로써, 액션 선택 엔진(200)을 통해 또는 직접, 행동들(300)로 메시지가 포스팅되며, 행동들은 이벤트들을 수신하고 포스팅할 수 있다. 이벤트들은 행동들(300)을 턴온 및 턴오프하고, 이들의 모드들을 설정하는 것 등에 이용될 수 있다. 큐는 행동들을 개별적으로 처리하지 않고 행동들(300)에 대한 정책의 관리를 허가한다.

액션 모델 API(402)는 다양한 액션 모델들(400)이 자원들의 이름들, 상태들 및 각각의 액션 선택 사이클(201)에서 생성된 액션들의 수를 포함하는 구성 셋업을 액션 선택 엔진(200)으로 전송하는 것을 허가한다. 액션 모델들(400)은 이벤트 핸들러들이기도 하며, 따라서 이들은 필요에 따라 행동 시스템(104) 내의 임의의 이벤트 스트림 정보와 조화될 수 있다. 액션 모델 API(402)에 대한 예시적인 인터페이스들이 아래의 표들 2-3에 제공된다.

공개 멤버 함수들(액션 모델)	설명
ActionSpaceVector getActionSpaces () const	이 함수는 액션 공간들(410) 중 하나 이상을 액션 모델(400)에 반환함으로써 액션 모델의 자원 및 상태 공간 구조를 클라이언트들에게 제공하는 데 사용된다.

일반적으로, getActionSpaces 함수는 상이한 종류의 액션 모델들을 유도한다. 가능한 액션 모델들의 다양성으로 인해, 액션 모델의 특정한 공지된 다양성들을 위해 인터페이스들의 보조 세트가 사용되며, 다른 타입들도 사용될 수 있다. 명령/결과 모델링 및 검색 안내 휴리스틱을 제공하기 위해 액션 선택 엔진(200)에 의해 축 액션 모델 인터페이스(402)가 사용된다.

공개 멤버 함수들(액션 모델 축)	설명
void beginCycle (const std::string &space, const ChronometerTime tNow, const float tHorizon, const MultiAxisState &xInit_in, MultiAxisState &xInit_out)	액션선택 사이클(210)을 개시한다. 사이클을 개시한다: "beginCycle" 함수는 주어진 액션 공간에 대한 액션 선택 사이클의 개시를 알리는 API를 제공한다. 이것은 다음을 포함하는 여러 독립변수/변수를 갖는다: - &Space는 이 사이클 갱신에 대한 액션 공간의 이름이다. 이것은 getActionSpaces() 호출에서 이 액션 모델에 반환된 공간들 중 하나이어야 한다. - tNow는 이 중재 사이클의 시작 시간이다. - tHorizon은 이 중재 사이클에 대한 시간 간격이다. 액션 모델들은 평가를 위해 이 시간 범위에 걸쳐 결과들을 생성할 것이다. - xInit_in은 각각의 자원에 대한 한계들을 포함하는, 이 사이클의 개시시의 이 액션 공간 내의 액추에이터들의 현재 상태를 포함할 것이다. - xInit_out는 이 사이클의 개시시의 액추에이터들의 상태를 포함할 것이다. 이것은 xInit_in 내의 상태 정보는 물론, 액션 모델 내로부터의 증대된 상태들을 유지한다. 예를 들어, 이동/회전 액션 모델이 이동 및 회전 축의 현재 상태는 물론, 계산된 주행 거리 정보(X, Y, θ)를 제공할 수 있다. xInit_in 및 xInit_out 양자는 MultiAxisState에 의해 표현될 것이다(위 참조).
void generateCommands (const std::string &space, const float tHorizon, const MultiAxisState &xInit, const MultiAxisCommand &current, MultiAxisCommandVector &commandOptions, const std::string &genMode) [또는, 예컨대, DiscreteFloatActionModel 또는 DiscreteIntActionModel 액션 모델들에 대해, 각각 MultiAxisState 대신에 MultFloatState 또는 MultiInitState, MultiAxisCommand 대신에 MultiFloatCommand 또는 MultiInitCommand, MultiAxisCommandVector 대신에 MultiFloatCommandVector 또는 MultiInitCommandVector]	주어진 개시 상태 및 액션 공간(410)에 대한 명령들(440)을 생성한다. 명령들을 생성한다: "generateCommands" 함수는 다음을 포함하는 여러 독립변수/변수를 갖는다: - space는 이러한 생성 동작에 대한 액션 공간의 이름이다. - tHorizon은 이러한 액션들을 생성하는 시간 범위이다. - xInit는 액션 생성을 개시하기 위한 현재 상태이다. 이것은 시작 사이클에서 xInit_out에 의해 제공되는 결과적인 구조이다. - current는 그 액션 공간 내의 자원들에 대한 하드웨어에 적용된 현재 명령을 나타낸다. 이것은 자원 이름들의 AxisCommand 타입들에 대한 맵핑을 포함하는 MultiAxisCommand에 의해 표현된다. 축 명령은 다음을 포함한다: - 그 자원에 대해 전송된 명령의 타입(예를 들어, VELOCITY 명령 또는 POSITION 명령 등) - 명령 값 - commandOptions는 현재 상태 및 시간 범위가 주어질 때 가능한, 적절히 제한된 명령들로 채울 명령들의 벡터이다. 각각의 명령 옵션은 MultiAxisCommand이다(현재 독립변수에 대한 위의 설명 참고). 설명된 바와 같이, 어레이 정의들(타입 또는 포맷)이 교환될 데이터의 적절한 양들을 수용하는 것 외에는, 이들은 단계적인 개별 부동 또는 단계적인 개별 정수 기반 액션 모델들에 대해 본질적으로 동일하다.
void simulateCommand (const std::string &space, const MultiAxisState &xInit, const MultiAxisCommand &command, MultiAxisSampleVector &xSteps) [또는, 예컨대, DiscreteFloatActionModel 또는 DiscreteIntActionModel 액션 모델들에 대해, 위의 같이 각각 또는 MultiAxisSampleVector 대신에 MultiFloatSampleVector 또는 MultiIntSampleVector	상태 및 액션 공간(410)이 주어질 때 명령들(440)의 결과들(450)을 시뮬레이션한다. 명령들을 시뮬레이션한다: "simulateCommands" 함수는 다음을 포함하는 여러 독립변수/변수를 갖는다. - 공간 &xInit는 전술한 바와 같다. - command는 (전술한 바와 같은) 포맷의 MultiAxisCommand 타입의 시뮬레이션될 명령이다. - xSteps는 이 주어진 샘플 시간 델타들에 걸쳐 초기 상태로부터 주어진 명령을 시뮬레이션한 결과를 포함하는 벡터이다. - 이 벡터 내의 각각의 요소는 다음을 유지하는 MultiAxisSample 타입에 포함된 시간 슬라이스 시뮬레이션을 나타낸다. - 시간 단계 - 그 시간 슬라이스에 대한 결과적인 시뮬레이션된 상태. 상태는 MultiAxisState로서 표현된다. 설명된 바와 같이, 어레이 정의들(타입 또는 포맷)이 교환될 데이터의 적절한 양들을 수용하는 것 외에는, 이들은 단계적인 개별 부동 또는 단계적인 개별 정수 기반 액션 모델들에 대해 본질적으로 동일하다.
void notifyCommand (const std::string &space, const float tHorizon, const MultiAxisCommand &final, float overallUtility)	액션 공간들(410)에 대해 선택된 최종 명령(440)의 ActionModel을 통지한다. 명령을 통지한다: "notifyCommand" 함수는 다음을 포함하는 여러 독립변수/변수를 갖는다: - 전술한 바와 같은 space - 전술한 바와 같은 tHorizon - final은 그 액션 공간에 대한 평가 사이클로부터의 승리 명령들을 포함하는 어레이이다. 이것은 (전술한) MultiAxisCommand 타입이다. - overallUtility는 이 명령의 시뮬레이션으로부터 생성된 결과에 주어지는 최종 스코어를 제공한다. 단계적인 개별 부동 또는 단계적인 개별 정수 기반 액션 모델들에 대해 본질적으로 동일하다.

일반적으로, 상이한 액션 모델 타입들 하에서 교환되는 유사한 어레이들을 표현하기 위한 하나의 대안은 Multi[DOF]State, Multi[DOF]Command, Multi[DOF]CommandVector, Multi[DOF]SampleVector이며, "DOF"는 자유도이다.

도 3을 참조하면, 액션 선택 엔진(200)은 하나의 스레드 내의 이벤트들 모두를 조작하며, 따라서 행동(300)이 이벤트를 수신할 때 그 이벤트를 액션 선택 엔진(200)으로 전송하는 경우, 행동은 루프가 될 것이다. 이러한 루프를 파괴하기 위하여, 이벤트 핸들러 API(282)를 구비하는 이벤트 프로세서(280)가 존재한다(도 3 참조). 이벤트 프로세서 컴포넌트(280)에 대한 예시적인 인터페이스가 아래의 표 4에 제공된다.

공개 함수들 및 특성들(이벤트 프로세서)	설명
EventProcessor (aware::EventProcessor)	이벤트들을 수신하고, 처리 스레드에 의한 처리를 위해 이들을 큐잉한다.
Thread (aware::Thread)	처리 스레드에 대한 액세스 및 그의 제어를 제공한다.
MaxQueueLength (int = 128)	미처리 이벤트들의 최대 수. 이러한 많은 미처리 이벤트가 이미 존재할 때 새로운 이벤트를 통지하거나 포스팅하려는 시도가 예외를 발생시킬 것이다.
EventHandlers (aware::MultiConnection Var < aware::EventHandler>)	접속된 이벤트 핸들러들의 세트.

이벤트들이 실제로 어떻게 핸들링되는지는 이벤트 핸들러 API(282)를 구현하는 객체에 의존한다. 통상적으로, 수신 이벤트는 타입이 검사되고, "event" 클래스 상의 "narrow()" 연산을 이용하여 여러 이해되는 이벤트 클래스들 중 하나로 변환되며, 이어서 적절한 액션들이 취해진다. 이벤트 핸들러 API(282)에 대한 예시적인 인터페이스가 아래의 표 5에 제공된다.

공개 멤버 함수들(이벤트 핸들러)

설명

void notify (const EventHandle &event, ChronometerTime tNow, const EventProcessorHandle &source = 0) 핸들러에 이벤트를 통지하기 위해 호출된다.

이 함수는 핸들러에 이벤트를 통지하기 위해 호출된다. 이벤트 핸들러는 이벤트를 검사하고 그에 응답하는 것을 가능하게 하는 상수 이벤트 기준을 제공받는다. 또한, (공지된 경우) 소스 이벤트 핸들러에 대한 핸들을 제공받는다. 이러한 핸들이 0이 아닌 경우, 핸들러는 소스 이벤트 핸들을 이용하여 그를 호출한 이벤트 핸들러에 이벤트들을 "역 포스팅"할 수 있다. 파라미터들: [in] event는 이벤트를 참조하는 이벤트 핸들러이다. [in] tNow는 이벤트가 전달되는 시간이다. 이것은 이벤트의 타임스탬프와 항상 동일하지는 않다. 이것은 클라이언트들이 현재 시간에 대해 이벤트의 나이를 결정하고, 지연된 이벤트들을 처리하는 것 등을 가능하게 한다. [in] source는 (존재할 경우) 소스 이벤트 프로세서에 대한 핸들이다. 이 핸들은 0일 수 있다. 이것은 이벤트 핸들러 함수들 내로부터의 추가/미래 이벤트들의 직접적인 역 포스팅을 가능하게 한다. 반환들: 주석. 에러들에 관한 예외들을 발생시킨다.

이벤트 프로세서(280)는 그가 이벤트들을 수신할 때 이벤트들을 구축하는 이벤트들의 큐, 및 이벤트들 모두를 주기적으로 송출하는 스레드를 구비한다. 이것은 행동(300)이 기존의 이벤트를 핸들링하는 동안에 새로운 이벤트를 포스팅하는 것을 가능하게 한다. 각각의 행동 API(302)는 이벤트 핸들러 API(282)로부터 상속받는다(그리고 기능들을 상속한다). 이벤트 프로세서 컴포넌트(280)는 이벤트 객체들의 역다중화된 전송을 이벤트 핸들러 객체들의 집합에 제공한다. 이벤트 프로세서 컴포넌트(280)가 수신하는 각각의 이벤트는 그의 "이벤트 핸들러" 접속에 접속된 이벤트 핸들러 객체들 각각으로의 전송을 위해 큐잉(queuing)된다. 통지, 즉 notify() 함수를 통해 수신된 이벤트들은 즉석 전송을 위해 우선 순위 순서로 큐잉된다. 소정의 더 이른 이벤트가 여전히 처리되고 있는 동안에 새로운 통지가 도달하는 경우, 또는 다수의 포스팅된 이벤트들이 동시에 활성화되는 경우, 다수의 큐잉된 이벤트가 존재할 수 있다. 포스팅, 즉 post() 함수를 통해 수신된 이벤트들은 호출에 의해 지정되는 전달 시간에서의 전송을 위해 큐잉된다. 그 시간에 도달한 경우, 이벤트는 즉석 전송을 위해 임의의 다른 미처리 이벤트들과 함께 우선 순위 순서로 큐잉된다. 이벤트들의 실제 전송은 개별 스레드 컴포넌트(290)에 의해 소유되는 이벤트 처리 스레드에 의해 수행된다. 이 스레드는 전송될 준비가 된 큐잉된 이벤트들이 존재할 때마다 실행되며, 접속된 이벤트 핸들러들의 세트에 걸쳐 반복되어, 이들 각각에 이벤트를 통지한다. 이러한 통지 호출들에서, 이벤트 프로세서는 수신 핸들러들에 의한 콜백들에서 사용하기 위해 이벤트의 소스로서 패스된다.

일부 구현들에서, 액션 선택 엔진은 그 자신의 스레드를 포함하지 않는다. 대신에, 액션 선택 엔진은 그를 실행할 스레드를 포함하는 개별 스레드 컴포넌트(290)를 이용한다. 이것은 다른 컴포넌트들이 동일 레이트로 훅업(hook up)되고 실행되는 것을 허가한다. 스레드 컴포넌트(290)는 액션 인터페이스들을 트리거하기 위한 주기적인 스레드를 구비한다. 통상적으로, 행동 시스템(104)은 10Hz 이상으로 실행되어야 하며, 시스템에 의해 조사되는 시간 범위는 많은 사이클(종종, 초)을 미래로 연장해야 한다.

액션 선택 엔진(200)은 로보틱스 시스템(100)의 조정 요소이며, 모든 행동들(300)의 입력들이 주어질 때 최상의 액션을 검색하는 고속의 최적화된 액션 선택 사이클(210)(예측/정정 사이클)을 실행한다. 액션 선택 엔진(200)은 3개의 단계, 즉 지정, 액션 선택 검색 및 완료 단계를 갖는다. 지정 단계에서, 각각의 행동(300)은 액션 선택 사이클(210)이 시작되었음을 통지받으며, 사이클 시작 시간, 현재 상태, 및 로봇 액추에이터 공간의 한계들을 제공받는다. 내부 정책 또는 외부 입력에 기초하여, 각각의 행동(300)은 그가 이 액션 선택 사이클(210)에 참여하기를 원하는지를 여부를 결정한다. 이 단계 동안, 활성인 행동들(300)의 리스트가 생성되며, 그의 입력은 로봇 상에서 실행될 명령들(440)의 선택에 영향을 미칠 것이다.

액션 선택 검색 단계에서, 액션 선택 엔진(200)은 액션 공간(410)으로도 지칭되는 이용 가능한 액션들의 공간으로부터 가능한 결과들(450)을 생성한다. 액션 선택 엔진(200)은 액션 모델들(400)을 이용하여, 미래의 시간 범위에 대해 예측되는 (위치, 속도 및 가속도와 같은 물리적인 액추에이터 한계들 내에서) 실행 가능한 명령들(440) 및 대응 결과들(450)의 풀을 제공한다. 액션 모델들(400)은 행동 시스템(104)에 접속되는 독립 컴포넌트들이며, 로봇의 일부를 나타낸다. 액션 모델들(400) 각각은 시스템의 그 부분의 상태 전파를 모델링하며, 액션 선택 검색 단계 동안에 이용 가능한 액션들에 대한 동적인 적응성 검색 윈도들(420)(도 6 참조)을 제공한다. 액션 선택 검색 단계 동안, 각각의 활성 행동 정책(310)은 (액션 모델들(400)에 의해 시뮬레이션된) 결과 옵션들(450)의 동일 세트를 제공받는다. 행동들(300)은 로봇에서 그들의 지정된 분리 가능한 기능에 기초하여 평가 기능을 구현하는 컴포넌트들이다. 이러한 평가는 범위 [-1,1] 내의 스코어의 형태로 보고된다. 값 -1은 행동(300)이 제안된 결과(450)가 그가 나타내는 기능에 대한 최악의 가능한 결과라고 생각한다는 것을 의미한다. 값 1은 행동(300)이 제안된 결과(450)가 그가 나타내는 기능에 대한 최상의 가능한 결과(450)라고 생각한다는 것을 의미하며, 값 0은 행동(300)이 이러한 결과(450)에 대한 어느 방식에도 관심이 없다는 것을 의미한다. 다른 값들은 그러한 극단들 사이의 단계들이다.

완료 단계에서, 협력적인 최상 스코어의 결과(450)에 대응하는 명령들(440)이 종합 명령(442)으로서 함께 결합되어, 그들의 대응하는 자원 제어 중재기들(120)을 통해 로봇 자원들(122) 상에서의 실행을 위해 로봇 제어기(140)에 제공된다. 최상의 결과(450)는 활성 행동들(300)에 피드백으로서 제공되어, 미래의 평가 사이클들에서 사용된다.

도 3-5를 참조하면, 액션 모델들(400)은 로봇의 전부 또는 일부의 운동학적, 동적 제한들을 설명하고, 국지적인 시간 범위 상에서 명령 결과들(450)의 예측들을 지원하는 플러그-인 컴포넌트들이다. 액션 모델들(400)은 로봇이 전환될 수 있는 가능한 상태들을 생성하며, 예측되는 미래의 결과들(450)을 생성한다. 액션 모델들(400)은 액션 선택 엔진(200)에 의해 사용되거나 호출되어, 도 4에 도시된 바와 같이 로봇 자원들(122)에 대한 (메커니즘을 모델링함으로써) 실행 가능한 명령들(440) 및 (동적 모델링을 통해) 대응하는 예상 결과들(450)을 제공하며, 이들은 최상의 액션을 찾기 위해 행동들(300)에 의해 평가된다. 액션 모델(400)은 로봇의 전부 또는 일부의 가능한 액션 공간(410)의 생성을 담당한다. 검색 공간의 복잡성을 줄이기 위해, 로봇 상의 자원들(122)은 독립적으로 평가되는 더 작은 액션 공간들(410)로 분할된다.

도 5에 도시된 예에서, 터릿(510), 쇼울더(520), 엘보-1(530) 및 엘보-2(540)를 구비하는 로봇 아암(500)의 액션 모델(400)은 대응하는 터릿 액션 공간(412A), 쇼울더 액션 공간(412B), 엘보-1 액션 공간(412C) 및 엘보-2 액션 공간(412D)을 포함한다. 액션 선택 엔진(200)은 로봇 아암(500)의 액션 모델(400)을 호출하여, 각각의 액션 공간(412A, 412B, 412C, 412D)에 대한 실행 가능 명령들(440A, 440B, 440C, 440D)의 세트들 및 결과들(450A, 450B, 450C, 450D)의 예상 세트들의 대응 세트들을 제공한다.

명령 생성을 위해, 액션 모델(400)은 액션 공간(410)에 의해 제어되는 시스템 자원들(122)의 현재 상태를 고려한다. 현재 자원 상태들, 자원들(122)의 동적 한계들 및 명령들(440)을 생성할 시간 범위가 주어지는 경우, 액션 모델(400)은 실행 가능한 명령들(440)의 범위인 "동적 윈도"(420)를 생성한다. 이어서, 휴리스틱 선택 메커니즘들을 이용하여 그러한 가능한 범위 사이에서 그리고 동적 윈도(420) 내에서 명령들(440)이 선택된다. 이러한 메커니즘들은 가능한 명령들(440)의 균일한 분포로부터 명령들(440)을 선택하는 메커니즘, 및 행동 시스템(104)이 선택하기를 원하는 명령을 향해 언덕을 오르도록 선택된 최종 명령들(443) 주위의 적응적 범위로부터 명령들(440)을 선택하는 메커니즘을 포함할 수 있지만, 이에 한정되지 않으며, 그러한 범위는 선택된 이전 명령들(440)의 편차에 기초하여 적응된다. 명령 생성의 목표는 지정된 시간 범위 내에서 시스템 하드웨어(122)에 의해 달성 가능한 명령들(440)을 생성하는 것이며, 이러한 명령들은 잠재적인 상태 궤적들이 행동 시스템(104) 내의 행동들(300)에 의해 높게 평가될 가능성을 크게 한다. 명령 생성은 시스템의 목표들이 변하는 경우에 무작위 명령들(440)을 제공하면서, 시스템이 하고 있었던 것에 기초하여 시스템이 무엇을 해야 하는지를 추측하려고 시도한다.

도 6a는 X-Y 액추에이터 로봇 자원(122)(예를 들어, 구동 시스템)의 축 1 및 축 2에 대한 2축 액션 공간(410)의 일례를 나타낸다. 최종 공지 명령(443) 및 액션 모델(400) 주위에 적응성 윈도(422)가 설정된다. 적응성 윈도(422)의 크기는 명령 이력, 이전 명령들(400)의 소정 수, 및/또는 최종 명령(443) 주위에 중심을 둔 최대 또는 최소 크기를 포함할 수 있는 적응성 윈도 파라미터에 의해 설정될 수 있다. 특히 X-Y 액추에이터 로봇 자원(122)의 역학 및 운동학을 모델링하는 대응하는 액션 모델(400)은 X-Y 액추에이터 로봇 자원(122)의 현재 명령 상태(430), X-Y 액추에이터(122)의 동적 한계들 및 시간 범위에 기초하여 한 세트의 가능한 명령들(440), 이 예에서는 20개의 명령(440)을 생성한다. 현재 상태 정보는 특히 위치, 속도 및 토크를 포함한다. 액션 모델(400)은 적응성 윈도(422) 내에 소정 수의 명령들(440), 이 예에서는 10개의 명령(440)을, 그리고 적응성 윈도(422)의 밖에, 그러나 동적 윈도(420) 내에 다른 세트의 조사 명령들(440), 이 예에서는 10개 이상의 명령(440)을 생성한다. 액션 선택 엔진(200)은 행동들(300)에 의한 평가를 위해 동적 윈도(420) 내에서 그리고 적응성 윈도(422) 내에서 소정 수의 명령들(440)을 무작위로 선택한다.

도 6b를 참조하면, 액션 선택 엔진(200)은 액션 공간(410)에 대한 액션 모델(400)을, 가능한 명령들(440)을 생성하고, 검색 휴리스틱(예컨대, 언덕 오르기)을 제공하고, 가능한 명령들(440)을 시뮬레이션하여 결과들(450)을 얻기 위한 수단으로서 이용하여, 그 액션 공간(410)의 무작위 검색을 실행한다. 도시된 예에서, 가능한 액션 공간(410)은 현재 명령 상태(430)를 둘러싼다. 액션 선택 엔진(200)은 액션 모델(400)을 이용하여, 모든 가능한 명령들(440)의 예상 결과들(450)을 미래의 수초까지 예측한다. 행동들(300)이 이러한 명령들(440)(예컨대, 미래의 시스템 궤적들)을 그들의 예상 결과들(450)에 기초하여 평가할 때, 이들은 미래의 수초 동안 예상 상태 전개에 액세스한다. 액션 선택 엔진(200)은 결과 평가들(450)에 기초하여 바람직한 결과(450)를 계산하고, 애플리케이션(130)의 로봇 제어기(140)와 인터페이스하여, 네트워크(110)를 통해 발행/구독 시스템에 명령들(440)을 발행하여 제어 중재기들(120)이 명령들(440)을 이용 가능하게 하고, 상태 피드백(126)을 수신함으로써 대응 명령(400)을 제어 중재 시스템(102)으로 전송한다. 액션 선택 엔진(200)은 또한 선택된 명령(440)을 피드백으로서 액션 모델(400)에 통지한다.

로보틱스 시스템들을 구성하는 센서들 및 액추에이터들은 결정적이 아니다. 이들은 내부 추정 에러 또는 제어되지 않는 환경들에 의해 발생하는 에러들인지에 관계없이 다양한 소스로부터의 에러에 취약하다. 행동 시스템(104)은 시스템(100) 내의 모든 상태들에 대한 표준 편차를 이용하여 이러한 에러를 모델링하기 위한 필드(129)를 제공한다. 이것은 로봇 자원들(122)이 그들의 불확실성을 상태 피드백을 통해 액션 모델들(400)에 보고하는 것을 가능하게 하며, 행동들(300)이 결정을 행할 때 불확실성을 고려하는 것을 가능하게 한다. 예를 들어, 회전시에 자연히 미끄러지는 구동 시스템(122)을 고려한다. 구동 시스템(122)에 대한 액션 모델(400)이 명령들(440)의 세트에 대한 결과 궤적들을 생성할 때, 이 모델은 더 많은 회전을 갖는 궤적들 내의 상태들에 대해 증가된 불확실성을 제공함으로써 회전 불확실성을 고려할 수 있다. 도 6c는 3개의 상이한 명령(440A, 440B, 440C)의 결과인 3개의 상이한 결과(450A, 450B, 450C)에 대한 구동 시스템 X-Y 자원(122)의 이동의 시뮬레이션된 궤적들(127A, 127B, 127C)을 제공한다. 각각의 궤적(127A, 127B, 127C)은 3개의 시간 단계(t1, t2, t3)를 가지며, 이들 각각은 구동 시스템 X-Y 자원(122)이 각각의 결과(450A, 450B, 450C)에 대해 대응하는 시간 단계(t1, t2, t3)에서 위치할 가능한 공간(129A, 129B, 129C)을 (예를 들어, 표준 편차에 기초하여) 정의하는 불확실성 영역(128A, 128B, 128C)을 갖는다.

행동(300)이 궤적들(127A, 127B, 127C)을 평가할 때, 이 행동은 불확실성을 고려할 수 있다. 충돌 방지 행동의 특정 예의 경우, 목표 지점(또는 상태)에 대한 최단 경로(19)는 더 많은 회전을 포함할 수 있으며, 그 결과로서 더 많은 불확실성을 가질 수 있다. 예측되는 상태는 물체와 충돌하지 않을 수 있지만, 불확실성이 고려되는 경우, 궤적은 충돌할 가능성을 갖는다. 이어서, 행동(300)은 장애물(17)과 충돌할 가능성이 없는 목표(19)에 대한 더 긴 경로를 취하기로 결정할 수 있다. 불확실성을 모델링하는 방식은 고정될 수 있거나, 로봇이 그의 명령들이 세상에서의 그의 실제 상태와 어떻게 관련되는지에 관한 피드백을 얻을 때, 환경에 적응할 수 있으며, 따라서 시멘트 상에서 이동한 후에 모래로 전이하는 로봇은 그의 모델을 궤적 관계에 대한 명령에 있어서 낮은 레벨의 불확실성으로부터 더 높은 레벨의 불확실성으로 적응시킬 수 있다. 제3 결과(450C)와 관련하여, 구동 시스템 X-Y 자원(122)은 시간 단계 t3에서 장애물(17)과 충돌할 가능성을 갖는다. 충돌 방지 행동(300)이 결과들(450A, 450B, 450C)을 평가할 때, 행동(300)은 제3 결과(450C)가 장애물(17)과의 충돌을 유발할 가능성을 가지므로 그에게 가장 낮은 스코어를 부여하고, 제2 결과(450B)가 장애물 주위에서 목표 지점(또는 상태)(19)을 향해 구동 시스템 X-Y 자원(122)을 유도하므로 그에게 가장 높은 스코어를 부여하며, 제1 결과(450A)에는 제2 결과(450B)와 제3 결과(450C) 사이의 스코어를 부여할 것이다.

이러한 예측 프로세스는 매 초마다 최적화되고 여러 번(예를 들어, ~30Hz) 반복되며, 현재 명령 세트에 대한 예측기-교정기 시스템과 같이 동작한다. 행동들(300)이 현재 명령(430)의 궤적의 시간 전개를 이용할 수 있게 하는 것은 행동들(300)이 정적 및 동적 위험들 모두를 그들의 결과 평가들 내에 통합하는 것을 가능하게 한다. 이러한 대응 및 예측 액션 선택의 결합은 액션 선택 프로세스에서 안전성 및 반응성을 제공한다.

액션 선택 엔진(200)은 현재 시스템 상태 피드백에 결합되는 주기적인 사이클이고, 임의의 실시간 결과들에 의존하는 것이 아니라, 예측된 결과들(450)만을 이용하여 명령들(440)을 선택한다는 점에서, 액션 공간(410) 내에서 명령(440)의 캐스케이딩 폐루프 선택을 수행할 수 있다. 액션 선택 엔진(200)은 로봇의 현재 상태(예컨대, 현재 위치, 속도, 가속도 및/또는 기타 각각의 자원(122)의 원격 측정)를 이용하며, 액션 선택 사이클(210)을 계속 갱신하고 실행한다. 액션 공간(410)의 가능한 하위 영역 또는 동적 윈도(420)가 액션 모델(400)에 의해 한계들 및 현재 상태 값들에 기초하여 계산된다. 이 동적 윈도(420)는 생성되는 명령들(440)을 제한하는 데 사용되며, 따라서 액션 선택 엔진(200)은 최상의 이용 가능한 명령(440)을 선택할 수 있다. 이러한 명령(440)은 전역적으로 최적은 아닐 수 있지만, 시스템의 동적(기계적, 기타 등등) 한계들을 고려한 "국지적으로 양호한" 솔루션이다. 액션 모델(400)은 적응적이며, 따라서 검색될 액션 공간(410)은 명령 이력에 기초하여 가능한 크기로부터 훨씬 더 작은 크기로 축소된다. 결과적으로, 액션 선택 엔진(200)은 한계 근처의 명령(440)을 반복적으로 선택하지 않을 것이다. 예를 들어, 명령 이력이 매번 소정의 지점으로 이동하는 것을 포함하는 경우, 검색 윈도(420)는 과거에 가장 많이 검색된 영역 주위에서 해상도를 증가시키는 크기가 된다. 결과적으로, 액션 선택 엔진(200)은 순방향 모델링(예컨대, 비반전)에 기초하며, 국지적 경로 계획을 수행한다. 액션 공간(410)의 문제 크기는 "전역적 최상의 이용 가능한" 명령(440)에 대해 한꺼번에 해결하는 것이 아니라 (각각의 사이클 동안) 각각의 액션 공간(410) 내의 최상의 이용 가능한 명령(440)에 대해 하나씩 해결함으로써 감소된다. 예를 들어, 10^4개의 CPU 사이클을 이용하여 10*10*10*10개의 옵션을 검색하는 대신에, 액션 선택 엔진(200)은 40개의 CPU 사이클을 이용하여 10+10+10+10개의 옵션을 검색한다. 이것은 로봇이 소형/구식(저용량) 내장 프로세서들 상에서 비교적 높은 성능을 갖게 한다.

일반적으로, 최상의 결과(450)를 갖는 최상의 명령(440)에 대해서만 전체 액션 모델(400)을 검색할 충분한 시간은 존재하지 않는다. 액션 선택 엔진(200)은 접속된 행동들(300)의 선호들을 충족시키는 가능한 명령들(440)에 대한 가능한 액션 공간(410)에 걸쳐 휴리스틱 시간 제한 검색을 수행한다. 바람직하게는, 각각의 액션 공간(410)에 대한 이전에 선택된 명령 값에 기초하여, 언덕 오르기로 알려진 검색 기술이 이용된다. 시간이 지나면서 많은 다른 휴리스틱이 추가될 수 있는데, 이는 액션 모델들(400)이 액션 모델 API(402)를 따르는 임의의 컴포넌트로 대체될 수 있기 때문이다. 이것은 또한 시스템(104) 내의 거동들(300)을 재작성하지 않고 새로운 검색 휴리스틱들이 추가되는 것을 가능하게 한다. 액션 선택 엔진(200)은 다수의 자유도를 가지며, 암시적 평가들을 수행한다. 휴리스틱 검색들은 플러그-인 액션 모델들(400)에 의해 제공되며, 이는 행동들(300)의 재작성 없이 새로운 휴리스틱 검색들이 로보틱스 시스템(100)에 추가되는 것을 가능하게 한다.

도 7을 참조하면, 액션 선택 엔진(200)은 액션 선택 프로세스에서의 활동의 관리기 또는 허브로서 동작한다. 액션 선택 엔진(200)은 다음 단계들, 즉 1) 로봇 제어기(140)로부터 시스템 상태를 취득하는 단계, 2) 모든 접속된 액션 모델들(400) 및 행동들(300)에게 (예컨대, 그들 각각의 API들(402, 302)을 호출함으로써) 사이클이 시작될 것임을 통지하고, 그들에게 현재 시스템 상태를 제공하는 단계, 3) 각각의 액션 모델(400)의 각각의 액션 공간(410)에 대한 최적화 패스를 그들이 구성되는 순서로 개별적으로 실행하는 단계, 및 4) 모든 액션 모델(400)에 대한 명령들(440)을 전체 로봇 시스템(100)에 대한 단일 "종합 명령"(442)으로 축적하는 단계를 포함하는 주기적 액션 선택 사이클(210)을 실행한다. 액션 선택 엔진(200)은 1) 접속된 액션 모델(400)을 호출하여, 가능한 명령들(440)을 생성하고, 2) 접속된 액션 모델(400)을 호출하여, 그러한 가능한 명령들(440)로부터 결과들(450)을 생성(시뮬레이션)하고, 3) 접속된 행동들(300)을 호출하여, 결과들(450)을 제공하고, 각각의 결과(450)의 순위 또는 평가(460)를 제공하고, 그들의 선호들에 기초하여 그러한 결과들이 얼마나 좋은지 또는 나쁜지를 [-1,1]로부터의 스케일 상에 표현함으로써 각각의 액션 공간(410)에 대한 최적화 패스를 실행하며, 여기서 -1은 매우 바람직하지 않음을 의미하고, 1은 매우 바람직함을 의미하며, 0은 무관함을 의미한다. 평가 함수가 로봇의 일관성있는 액션을 얻기 위한 결과(450)를 선택한다. 많은 다양한 정책을 이용하여 다른 행동들(300)(계층 구조)의 결과 평가들(460)을 결합하는 행동들(300)이 존재할 수 있지만, 코어 액션 선택 엔진(200)에 의해 사용되는 기본 정책은 가중 합산 중 하나이다. 액션 선택 엔진(200)은 평가들(460)의 가중 합에 의해 행동들(300)의 결과 평가들(460)을 누산하고, 최상의 (최고 순위의) 결과(450)를 승자로서 선택한다. 액션 선택 엔진(200)은 이러한 특정 액션 모델(400)에 대한 승리 결과(450)의 대응 명령(440)을 저장하고, 선택된 명령(440)을 피드백으로 액션 모델(400)에 통지한다. 액션 모델들(400)은 현재 명령(430)으로부터의 국지적 및 "탐구" 변화들 사이의 혼합 분포를 이용하여, 가능하고 무작위인 명령들(440)을 생성하도록 구성된다.

행동(300)의 평가 기능(들)은 자원들(122) 외부의 컴포넌트로부터의 센서 데이터에 기초할 수 있다. 일반적으로, 자원(122)의 축에 고유한 데이터는 액션 선택 사이클(210)의 개시시에 다른 시스템 상태 정보와 더불어 액션 모델들(400) 및 행동들(300)로 패스된다. 예를 들어, 인코더 정보(예를 들어, 위치)가 시스템 상태 정보에 포함된다. 그러나, 외부 컴포넌트들(예를 들어, 이동 로봇 상의 레이저 범위 파인더 또는 글로벌 포지셔닝 시스템)로부터의 센서 데이터는 로컬 네트워크(110)의 발행/구독 시스템을 통해 액션 모델들(400) 및 행동들(300)에 의해 액세스된다. 도 6c를 다시 참조하면, 이제 로봇에 부착된 레이저 범위 파인더 및 액션 선택 엔진(200)에 접속된 충돌 방지 행동(300)의 예를 포함한다. 로봇 주위의 스캔(예를 들어, 180도)으로부터의 정보를 제공하는 한 세트의 데이터(원시 데이터 또는 다른 시스템 컴포넌트에 의해 처리된 데이터)가 로보틱스 시스템(100) 내의 다른 컴포넌트들에 의한 액세스를 위해 레이저 범위 파인더에 의해 (로컬 네트워크(110)의 발행/구독 시스템에 대해) 발행된다. 액션 선택 사이클(210) 동안, 충돌 방지 행동(300)은 (로컬 네트워크(110)의 발행/구독 시스템에) 가입하여, 레이저 범위 파인더 데이터를 이용하여, 로봇 주위의 환경 내의 장애물들을 식별하거나 검출한다. 이어서, 충돌 방지 행동(300)은 로봇과 목표 위치(또는 상태)(19) 사이의 장애물(17)에 대한 그의 인식에 비추어 3개의 제공된 결과(450A, 450B, 450C)를 평가한다. 행동(300)은 제3 결과(450C)가 장애물(17)과의 충돌을 유발할 가능성을 가지므로 그에게 가장 낮은 스코어를 부여하고, 제2 결과(450B)가 장애물 주위에서 목표 지점(또는 상태)(19)을 향해 X-Y 액추에이터 자원(122)을 유도하므로 그에게 가장 높은 스코어를 부여하며, 제1 결과(450A)에는 제2 결과(450B)와 제3 결과(450C) 사이의 스코어를 부여할 것이다.

바닥 청소 로봇에 대한 다른 예에서, 행동 시스템(104)은 로봇의 청소 경로를 좌우하는 데 사용될 수 있다. 일례에서, 청소 로봇은 지지면을 통해 로봇을 구동 방향으로 앞으로 구동하는 구동 메커니즘을 보유하는 로봇 본체를 포함한다. 로봇은 구동 방향으로 이동하는 동안에 로봇이 만나는 물체들에 반응하는 전방 장애물 센서를 포함한다. 이동 방향을 가로지르는 로봇의 주요 측부 상의 물체들의 근접을 검출하기 위해 측면 센서가 배치된다. 로봇의 주요 측부는 로봇이 물체(또는 장애물)에 인접하는 영역을 청소할 때 그 물체(또는 장애물)의 근처에 유지되거나 그와 접촉하는 측부이다. 로봇 본체는 주요 측부를 정의하도록 비대칭 형상을 가질 수 있다. 측면 브러시와 같은 표면 영역 처리 메커니즘이 로봇의 주요 측부 상에서 효과적이다. 측면 브러시는 로봇의 주요 측부로부터 연장하며, 로봇에 의한 수집을 위해 로봇 주변 너머의 부스러기들을 청소하도록 동작한다. 전방 센서가 로봇 이동 방향에서 물체를 검출할 때, 이 센서는 로컬 네트워크(110)의 발행/구독 시스템에 대해 센서 데이터를 발행한다. 액션 선택 사이클(210) 동안, 벽 추적 행동(300)은 로컬 네트워크(110)에 가입하여, 제공된 결과들(450)의 평가 동안에 고려할 이용 가능한 전방 센서 데이터를 취득한다. 벽 추적 행동(300)의 목표는 벽들의 근처까지 청소하는 것이다. 행동(300)이 전방 센서가 로봇의 이동 방향에서 물체를 검출한 것을 알게 될 때, 행동은 검출된 물체를 로봇의 주요 측부에 배치하도록 로봇을 회전시키고, 표면 영역 처리 메커니즘이 주요 측부 상의 물체에 인접하는 지지 표면의 일부를 처리하는 동안, 검출 물체를 로봇의 주요 측부에 유지하도록 로봇을 구동하는 구동 명령들(440)에 대응하는 결과들(450)에 높은 스코어를 부여할 것이다.

도 8에 도시된 예에서, 액션 선택 사이클(210)은 액션 모델들(400)을 호출하여, 디폴트 결과 세트(451)를 각각 생성하는 단계를 포함한다(도 11 참조). 행동들(300)이 각각의 결과(450)를 평가하고 순위화할 때, 그들의 평가는 해당 액션 공간(410) 및/또는 행동(300)에 대해 적합한 경우에 디폴트 결과 세트(451)를 참조하거나 그에 의존할 수 있다. 또한, 선택된 승리 결과(450)는 해당 액션 공간(410)에 대한 디폴트 결과 세트(451)를 갱신하거나 대체하는 데 사용될 수 있다.

도 7을 다시 참조하면, 각각의 액션 모델(400)이 처리된 후에, 액션 선택 엔진(200)은 각각의 액션 모델(400)에 대한 축적된 선택 명령들(440)을 이용하여, 전체 로봇 시스템(100)에 대한 단일 "종합 명령"(442)을 생성한다. 종합 명령(442)은 로봇 자원들(122) 상에서의 실행을 위해 자원 제어 중재기들(120)로 전송하기 위해 로봇 제어기(140)로 전송된다. "종합 명령"(442)은 액션 모델들(400)의 선택된 명령들(440)의 대응 결과들(450)을 축적함으로써 생성된 시뮬레이션된 "종합 결과"(452)를 갖는다. 이러한 "종합 결과"(452)는 액션 선택 사이클(210)의 종료를 지시하는 피드백으로서 모든 접속된 행동들(300)로 패스된다.

도 9는 예시적인 액션 선택 사이클(210)을 나타낸다. 액션 선택 엔진(200)은 관련된 로봇 제어기(140)에 상태 요청을 제출함으로써 개시한다. 로봇 제어기(140)는 그의 시스템 상태 및 한계들을 반환한다. 이어서, 액션 선택 엔진(200)은 액션 선택 사이클(210)이 시작될 것임을 모든 접속된 액션 모델들(400) 및 행동들(300)에 통지한다. 액션 선택 엔진(200)은 각각의 액션 모델(400)로부터 디폴트 결과(451)를 요청하며, 이는 결과들(450)의 평가를 위해 행동들(300)에 의해 사용되거나 참조될 수 있다. 액션 선택 엔진(200)은 각각의 액션 모델(400)의 각각의 액션 공간(410)을 통해 루프를 진행한다. 액션 모델들(400)은 액션 선택 엔진(200)에 의한 순차적 처리를 위해 (예컨대, 로봇 상의 영향에 의해) 소정의 순서를 갖는다. 마찬가지로, 액션 모델(400) 내의 각각의 액션 공간(410)은 액션 선택 엔진(200)에 의한 순차적 처리를 위해 (예컨대, 자원(들)(122) 상에 영향에 의해) 소정의 순서를 갖는다.

도 9-10을 참조하면, 액션 선택 엔진(200)은 제1 액션 모델(400A)을 호출하여, 각각의 액션 공간(410)에 대한 가능한 명령들(440) 및 대응하는 결과들(450)을 생성한다. 도 10에 도시된 예에서, 제1 액션 모델(400A)은 미끄럼 조종 자원(122)에 대한 이동 및 회전을 모델링하는 이차원 액션 공간(410)을 갖는다. 액션 선택 엔진(200)은 제1 액션 모델(400A)을 호출하여, 이동 및 회전 액션 공간(410)에 대한 가능한 명령들을 생성한다. 액션 선택 엔진(200)은 제1 액션 모델(400A)을 호출하여, 각각의 가능한 명령(440)에 대해 발생할 미끄럼 조종 자원(122)의 결과들(450) 또는 예측되는 미래 상태들을 생성하거나 시뮬레이션한다.

도 9 및 11을 참조하면, 액션 선택 엔진(200)은 평가를 위해 결과들(450)을 각각의 활성 행동(300)으로 전송한다. 각각의 행동(300)은 행동(300)이 활성인지 및 그의 가중치를 지시하는 상태 및 가중치 특성(304)을 갖는다. 각각의 액션 선택 사이클(210) 상에서, 행동들(300)은 시뮬레이션된 결과들(450)의 평가 프로세스에 참여할지의 여부를 결정할 수 있다. 각각의 액션 선택 사이클(210)의 개시시에, 액션 선택 엔진(200)은 각각의 행동(300)에게 해당 사이클에 참여하기를 원하는지를 묻는다. 특정 행동이 참여하지 않기로 결정한 경우, 그의 상태는 "오프"로 설정된다. 해당 액션 선택 사이클(210)의 나머지 기간 동안, 액션 선택 엔진(200)은 참여하기로 결정한, 따라서 그 사이클 동안 "활성 행동들"인 행동들(300)과만 상호작용한다. 이것은 매우 쉽고 유연한 임무 정책 관리를 제공한다. 행동 가중치(304)는 행동(300)의 특정 인스턴스의 스코어들 또는 결과 평가들의 영향을 증가시키는 데 사용된다. 행동 가중치(304)는 관련 행동의 고정된 특성이 아니라, 오히려 행동(300)의 인스턴스와 관련된 가중치이다. 행동(300)은 특정 최종 목표에 기초하여 평가 휴리스틱을 구현하며, 그것이 얼마나 중요한지를 알 필요가 없다. 행동 가중치(304)는 애플리케이션(130)의 전체 설계의 상황과 관련된다. 동일한 행동(300)이 상이한 타입의 애플리케이션들(130)에 대해 상이한 레벨의 중요도 또는 가중치(304)를 가질 수 있다.

도 11에 도시된 예에는, 3개의 활성 행동(300)이 존재한다. 제1 행동은 통신 두절/브레이크 가동("통신 두절") 행동(300A)으로서, 로봇과 운영자 제어기 유닛의 통신이 두절될 때 로봇이 그의 액션들의 일부 또는 전부를 제동하거나 중지하게 하는 행동이다. 제2, 제3 및 제4 행동(300B, 300C, 300D)은 이 액션 선택 사이클(210) 동안 비활성인 것으로 도시된다. 제5 행동(300E)은 로봇의 원격 제어를 위한 원격 조작 행동이다. 제6 행동(300F)은 충돌 방지 행동이다. 도시된 예에서, 통신 두절 행동(300A)은 다른 행동들(300) 중에서 최고의 가중치(304)(예컨대, 100)를 갖는데, 이는 이 행동이 통신 두절시에 로봇이 헤매는 것을 방지하기 때문이다. 충돌 방지 행동(300F)은 통신 두절 행동(300A)의 절반인 다음으로 높은 행동 가중치(304)를 가지며, 이어서 원격 조작 행동(300E)은 통신 두절 행동(300A)의 단지 1/10의 행동 가중치(304)를 갖는다. 활성 행동들(300A, 300E, 300F)은 결과들(450)을 평가하고, 그들의 가중된 스코어들 또는 결과 평가들(460)을 액션 선택 엔진(200)에 반환한다. 액션 선택 엔진(200)은 최고로 가중된 결과 평가(460)를 갖는 결과(450)를 해당 액션 공간(410, 410A)에 대한 승리 결과(450)로서 선택한다. 액션 선택 엔진(200)은 각각의 액션 모델(400)의 각각의 액션 공간(410)에 대한 승리 명령들(440)에 기초하여 종합 명령(442)을 생성하기 위해 승리 결과(450)에 대응하는 명령(440)을 저장한다. 액션 선택 엔진(200)은 승리 결과(450)로 디폴트 결과 세트(451)를 갱신한다.

도 9 및 12를 참조하면, 이어서 액션 선택 엔진(200)은 제2 액션 모델(400B)을 호출하여, 각각의 액션 공간(410)에 대한 가능한 명령들(440) 및 대응하는 결과들(450)을 생성한다. 도 12에 도시된 예에서, 제2 액션 모델(400B)은 아암 자원(122)의 터릿, 엘보 및 손목을 모델링하는 3개의 일차원 액션 공간(410)을 갖는다. 액션 선택 엔진(200)은 제2 액션 모델(400B)을 호출하여, 제1 순위의 액션 공간(410)인 터릿 액션 공간(410)에 대한 가능한 명령들을 먼저 생성한다. 액션 선택 엔진(200)은 제2 액션 모델(400B)을 호출하여, 각각의 가능한 명령(440)에 대해 발생할 아암 자원(122)의 결과들(450) 또는 예측되는 미래의 상태들을 생성하거나 시뮬레이션한다.

도 9 및 13을 참조하면, 액션 선택 엔진(200)은 제2 액션 모델(400B)의 제1 액션 공간(410)의 결과들(450)을 평가를 위해 각각의 활성 행동(300)으로 전송한다. 도 13에 도시된 예에는, 결과들(450)을 수신하도록 활성인 하나의 행동 정책(310)만이 존재한다. 행동 정책들(310)은 행동들(300)의 선택 및 이용에 대한 논리를 제공하는 데 사용되며, 아래에 더 상세히 설명된다. 액션 선택 엔진(200)은 최고로 가중된 결과 평가(460)를 갖는 결과(450)를 해당 액션 공간(410, 410A)에 대한 승리 결과(450)로서 선택한다. 액션 선택 엔진(200)은 각각의 액션 모델(400)의 각각의 액션 공간(410)에 대한 승리 명령들(440)에 기초하여 종합 명령(442)을 생성하기 위해 승리 결과(450)에 대응하는 명령(440)을 저장한다. 액션 선택 엔진(200)은 승리 결과(450)로 디폴트 결과 세트(451)를 갱신한다.

도 9 및 14를 참조하면, 이어서 액션 선택 엔진(200)은 제2 액션 모델(400B)을 호출하여, 다음 액션 공간(410)에 대한 가능한 명령들(440) 및 대응하는 결과들(450)을 생성한다. 도 14에 도시된 예에서, 액션 선택 엔진(200)은 제2 액션 모델(400B)의 엘보 액션 공간(410)이 가능한 명령들(440)을 생성하는 것은 물론, 각각의 가능한 명령(440)에 대해 발생할 아암 자원(122)의 결과들(450)(또는 예측되는 미래의 상태들)을 시뮬레이션하게 한다. 액션 선택 사이클은 순서에 따라 다음 액션 모델(400)인 카메라 마스트 액션 모델(400C)의 액션 공간(들)(410)에 걸치는 최적화 패스를 루프하기 전에 제2 액션 모델(400B)의 최적화 패스를 완료하기 위해 이 액션 공간(410) 및 이어서 팔목 액션 공간(410)을 통해 루프한다.

도 9 및 15를 참조하면, 각각의 액션 모델(400)이 처리된 후, 액션 선택 엔진(200)은 각각의 액션 모델(400)의 각각의 액션 공간(410)에 대한 축적된 승리 명령들(440)을 이용하여, 전체 로보틱스 시스템(100)에 대한 단일 "종합 명령"(442)을 생성한다. 종합 명령(442)은 로봇 자원들(122) 상에서의 실행을 위해 자원 제어 중재기들(120)로의 전송을 위해 로봇 제어기(140)로 전송된다. "종합 명령"(442)은 액션 모델들(400)의 선택된 명령들(440)의 대응 결과들(450)을 축적함으로써 생성된 시뮬레이션된 "종합 결과"(452)를 갖는다. "종합 결과"(452)는 액션 선택 사이클(210)의 종료를 지시하는 피드백으로서 모든 접속된 행동들(300)로 패스된다.

도 16을 참조하면, 액션 선택 엔진(200)은 액션 모델(400) 내에 다중 기준 배열(예컨대, 액션 모델(400)에 의해 설정되는 사전 편집 배열)을 갖는 다수의 액션 공간(410) 상에서 결과들의 캐스케이딩 선택을 실행할 수 있다. 액션 선택 엔진(200)이 액션 선택 사이클(210) 상에서 각각의 액션 공간(410)(또는 액션 모델(400))에 대한 명령(440) 및 대응 결과(450)를 선택할 때, 이러한 선택의 결과들은 결과들(450)과 관련하여 순방향으로 전파되며, 따라서 후속 액션 공간들(410)(또는 액션 모델(400)) 내의 행동들(300)을 통해 패스되는 후속 액션 선택 사이클(210)은 디폴트 결과 세트(451)에 액세스함으로써 이전 액션 공간에서 선택된 명령의 결과들을 볼 수 있다. 이것은 액션 공간들(410)(또는 액션 모델(400))의 완전한 포괄적인 검색을 수행하지 않음으로써 발생하는 부정적인 결과들을 줄인다. 설명된 바와 같이, 액션 선택 엔진(200)은 소정의 순서에 따라 각각의 액션 공간(410)을 통해 개별적으로 진행하며, 각각의 액션 공간(410)에 대한 결과(450)를 선택한다. 액션 공간들(410)은 통상적으로 로봇 액션들에 대한 그들의 영향 레벨에 따라 배열된다. 결과들(450)의 선택은 각각의 액션 공간(410)에 대한 결과(450)가 임의의 선행 액션 공간들(410)의 결과들(450)에 기초하여 결정되는 점진적 커미트에 따른다. 각각의 액션 선택 사이클(210)에서, 디폴트 결과 세트(451)는 각각의 모델링된 자원(122)에 대한 승리 결과(450)로 갱신된다. 도 5를 다시 참조하면, 이 도면은 터릿(510), 쇼울더(520), 엘보-1(530) 및 엘보-2(540)를 구비하는 로봇 아암(500)을 도시한다. 아암(500)에 대한 액션 모델(400)은 대응하는 터릿 액션 공간(412A), 쇼울더 액션 공간(412B), 엘보-1 액션 공간(412C) 및 엘보-2 액션 공간(412D)을 구비한다. 액션 선택 엔진(200)은 로봇 아암(500)의 액션 모델(400)을 호출하여, 각각의 액션 공간(412A, 412B, 412C, 412D)에 대한 가능한 명령들(440A, 440B, 440C, 440D)의 세트들 및 예상되는 결과들(450A, 450B, 450C, 450D)의 대응 세트들을 제공한다. 액션 선택 엔진(200)이 각각의 액션 공간(412A, 412B, 412C, 412D)을 통해 진행할 때, 이 엔진은 디폴트 결과 세트(451)에 저장된 임의의 이전 액션 공간들(412A, 412B, 412C, 412D)의 승리 결과들(450A, 450B, 450C, 450D)을 참조하면서 그들의 승리 결과들(450A, 450B, 450C, 450D)을 결정한다. 예를 들어, 액션 선택 엔진(200)이 엘보-2 액션 공간(412D)을 통해 진행할 때, 이 엔진은 제4의 엘보-2 액션 공간(412D)에 대한 승리 결과(450D)를 결정할 때 3개의 이전 액션 공간(412A, 412B, 412C)의 승리 결과들(450A, 450B, 450C)을 고려할 것이다.

도 17-20을 참조하면, 행동들(300)은 로봇의 액추에이터 시스템들로부터 도출되는 제한들을 포함하는 특정 제한들을 고려하면서 특정 목표들을 달성하기 위해 애플리케이션들(130)에서의 행동들(300)의 선택 및 사용에 대한 논리를 구성하고, 구조화하고, 제공하는 데 사용된다. 행동(300)의 평가 기능은 다수의 하위 행동들(300)로부터의 결과 평가 값들(460)을 결합하는 임의의 정책일 수 있으므로, 행동들(300)의 계층적 집합은 많은 새로운 조정 정책이 추가될 수 있게 하는 데 사용될 수 있다. 하위 행동들(300)의 평가를 결합하는 행동들(300)에 대한 통상적인 행동 정책들(310)은 행동 선택 정책(310A), 행동 결합 정책(310B), 행동 전환 정책(310C) 및 행동 순서화 정책(310D)을 포함한다.

도 17을 참조하면, 행동 선택 정책(310A)은 최고의 행동 가중치(304)를 갖는 활성인 접속된 행동(300) 또는 행동 정책(310)을 선택한다. 도시된 예에서, 행동 선택 정책(310A)은 1의 행동 가중치(304)를 갖는 활성 제2 행동(300B)을 배제하고 10의 행동 가중치(304)를 갖는 활성 제1 행동(300A)을 선택한다.

도 18을 참조하면, 행동 결합 정책(310B)은 활성인 접속된 행동들(300) 또는 행동 정책들(310)의 결과 평가들(450)을 결합한다. 도시된 예에서, 행동 결합 정책(310B)은 어느 접속된 행동들이 활성인지를 알기 위해 검사한다. 이 예에서, 제1 및 제2 행동들(300A, 300B)은 활성인 반면, 제3 행동(300C)은 이 특정 액션 선택 사이클(210)에 대해 비활성이다. 행동 결합 정책(310B)은 그들 각각의 행동 가중치들(304)에 따라 가중된 제1 및 제2 행동들(300A, 300B)의 결과 평가들(450)을 결합하는 반면, 비활성인 제3 행동(300C)은 무시한다.

도 19를 참조하면, 행동 전환 정책(310C)은 액션 선택 사이클(210)마다 (예컨대, 이벤트 프로세서(280)를 통해) 설정될 수 있는 전환 특성(310C1)에 기초하여 행동들(300)의 둘 이상의 그룹 사이에서 전환한다. 행동 전환 정책(310C)은 행동들(300)의 특정 그룹이 행동들(300)의 다른 접속된 그룹들 사이에서 독점적으로 이용 가능하게 되는 것을 허가한다. 도시된 예에서, 행동 전환 정책(310C)은 관련 전환 특성(310C1)에 기초하여 제1 행동 그룹(300X)과 제2 행동 그룹(300Y) 사이에서 전환한다. 이 예에서, 행동 전환 정책(310C)은 (비활성인 제3 행동(300C)은 제외하고) 활성인 제1 및 제2 행동들(300A, 300B)의 행동 결합 정책(310B)을 포함하는 제2 행동 그룹(300Y)을 이용하도록 전환하였다.

도 20을 참조하면, 행동 순서화 정책(310D)은 행동들(300)의 세트를 통해 순차적으로 진행한다. 행동 순서화 정책(310D)은 세트의 제1 행동(300)이 더 이상 활성이 아닐 때까지 제1 행동을 계속 이용하며, 제1 행동이 활성이 아닌 때에는 행동 순서화 정책(310D)은 다음 활성인 행동(300)을 그가 더 이상 활성이 아닐 때까지 이용하며, 기타 등등이다. 도시된 예에서, 행동 순서화 정책(310D)은 제1 행동(300A)을 그가 더 이상 활성이 아닐 때까지 이용하였으며, 이어서 제2 행동(300B)으로 진행하여, 제2 행동(300B)을 그가 더 이상 활성이 아닐 때까지 이용하였고, 이어서 제3 행동(300C)으로 진행하였다. 행동 순서화 정책(310D)은 제3 행동(300C)을 그가 더 이상 활성이 아닐 때까지 이용할 것이며, 제3 행동이 활성이 아닐 때, 활성인 제4 행동(300D)으로 진행할 것이다.

도 13에 도시된 예를 다시 참조하면, 행동 선택 정책(310A)은 제4 행동(300D)보다 높은 행동 가중치(304)를 갖는 행동 결합 정책(310B)을 선택한다. 행동 결합 정책(310B)은 제2 및 제3 행동들(300B, 300C)의 가중된 결과 평가들(460)을 결합한다. 결합된 가중 결과 평가들(460)은 행동 결합 정책(310B)의 행동 가중치(304)에 따라 더 가중된다. 최종적으로, 결과적인 결과 평가들(460)은 행동 선택 정책(310A)의 행동 가중치(304)에 따라 더 가중된다. 액션 선택 엔진(200)은 행동 선택 정책(310A)으로부터 반환된 가중 결과들의 세트로부터 최고로 가중된 결과 평가(460)를 갖는 결과(450)를 승리 결과(450)로서 선택한다.

로보틱스 시스템(100)은 개별 애플리케이션들(130)이 행동들(300)을 구현하기 위해 로봇 자원들(122)의 제어를 공유하는 것을 용이하게 하고 가능하게 한다. 전술한 바와 같이, 로봇 관리기(150)는 어느 애플리케이션(130)이 주어진 시간에 그 애플리케이션(130)에 의해 요구되는 로봇 자원들(122)에 대해 다른 동시 실행 애플리케이션들(130)에 비해 독점적인 제어를 갖는지를 결정함으로써 애플리케이션 우선 순위 정책(160)을 구현한다. 애플리케이션들(130)은 로봇 관리기(150)에 의해 제공되고 각각의 제어 중재기(120)로 전송되는 애플리케이션 우선 순위 정책(160)에 따라 다른 동시 실행 애플리케이션들(130)에 비해 자원들(122)을 독점적으로 요구한다.

도 21은 로보틱스 시스템(100)에 의한 행동들(300)의 실행의 일례를 나타낸다. 행동 A를 실행하는 제1 애플리케이션(130A)은 제1 자원(122A)(예컨대, 플립퍼), 제2 자원(122B)(예컨대, 이동) 및 제3 로봇 자원(122C)(예컨대, 회전)의 이용을 지배하며, 행동 B를 실행하는 제2 애플리케이션(130B)은 제2 자원(122B)(예컨대, 이동), 제3 로봇 자원(122C)(예컨대, 회전) 및 제4 로봇 자원(122D)(예컨대, 터릿)의 이용을 지배한다. 이 예에서, 애플리케이션 우선 순위 정책은 제1 애플리케이션(130A)이 제2 애플리케이션(130B) 위의 우선 순위를 갖는 것으로 규정한다. 애플리케이션 우선 순위 정책(160)에 기초하여, 로봇 관리기(150)는 행동 B를 실행하는 제2 애플리케이션(130B)을 배제하고 제1 애플리케이션(130A)이 행동 A의 실행시에 제1, 제2 및 제3 로봇 자원들(122A, 122B, 122C)을 이용하는 것을 허가한다. 그러나, 로봇 관리기(150)는 제2 애플리케이션(130B)이 제1 애플리케이션(130A)에 의해 요청되지 않은 제4 자원(122D)을 이용하는 것을 허가한다. 제1 애플리케이션(130A)이 행동 A의 실행을 종료한 때, 제2 애플리케이션(130B)은 행동 B를 실행하기 위해 자유로워진 제2 및 제3 로봇 자원(122B, 122C)의 제어를 수신한다. 이 예에서 더 설명되는 바와 같이, 제3 애플리케이션(130C)은 제2 및 제3 자원들(122B, 122C)의 이용을 지배하며, 제1 애플리케이션(130A) 위의 우선 순위를 갖는다. 결과적으로, 제1 애플리케이션(130A)이 행동 A를 실행하고 있는 동안에 제3 애플리케이션(130C)이 행동 C를 실행할 때, 제3 애플리케이션(130C)은 이 예에서 제2 및 제3 자원들(122B, 122C)인 필요한 로봇 자원들(122)의 제어를 요구하여 행동 C를 실행한다. 제3 애플리케이션(130C)이 행동 C의 실행을 종료한 경우, 제1 애플리케이션(130A)은 행동 A의 실행을 위해 자유로워진 제2 및 제3 자원들(122B, 122C)의 제어를 수신한다.

도 22를 참조하면, 병렬/멀티코어 확장 로보틱스 시스템(100)에서, 다수의 동일한 행동 시스템(104, 104A, 104B)이 멀티코어 컴퓨터 시스템(600) 상에 존재한다. 액션 선택 엔진(200)은 무작위화에 기초하여 액션 공간(410) 내의 명령(400)을 결정하므로, 각각의 병렬 네트워크(110) 상에서 실행되는 각각의 액션 선택 엔진(200)은 아마도 상이한 명령(440)을 생성할 것이다. 각각의 명령(440)은 명령(440)의 적합성에 대한 잔여 행동 평가의 정량화인 관련 명령 모랄(morale)(445)을 갖는다. 모랄 명령 선택기(610)는 병렬 네트워크들(110) 상에서 실행되는 각각의 액션 선택 엔진들(200)에 의해 동시에 생성된 명령들(440)의 그룹으로부터 최고의 관련 명령 모랄(445)을 갖는 명령(440)을 선택한다. 개별 로보틱스 시스템들(100)은 고유하게 직렬화되지만, 무작위 검색 기술들은 모랄 명령 선택기(610)와 연계하여 선형 고속화를 제공하여, 병렬 시스템이 메모리 공간 및/또는 대역폭에 의해서만 제한되게 한다.

도 23을 참조하면, 로보틱스 시스템(100)을 제어하기 위한 로보틱스 프레임워크(700)는 동적 구조(720)와 통신하는 정적 구조(710)를 포함한다. 정적 구조(710)는 로봇의 기능 및 성능 특성들을 제공하는 하나 이상의 수직 애플리케이션 프로그래밍 인터페이스(API)(712)를 포함한다. 로보틱스 프레임워크(700)의 API들(712)은 다른 수직 API들(712)과 더불어 컴포넌트 프레임워크(740)를 형성하는 수평 인터페이스들(742)과 통신한다. 동적 구조(720)는 메타데이터 모듈(722)(예컨대, XML) 및 스크립팅 모듈(724)(예컨대, Python)을 포함한다. 일부 구현들에서, 로보틱스 프레임워크(700)는 공통 인터페이스 API(712A), 행동 시스템 API(712B) 및 국지적 인식 공간 API(712C)를 포함한다.

기초 프레임워크(700)에 의해 충족되는 기본 요구들은 실행시에 플러그 가능한 소프트웨어 컴포넌트들을 동적으로 생성하고, 실행시에 새로운 플러그 가능한 소프트웨어 컴포넌트들을 동적으로 로딩하고, 생성의 일부로서의 인스턴스화 후에 소프트웨어 컴포넌트를 동적으로 구성하고, 소프트웨어 컴포넌트들을 전체 구성의 일부로서 동적으로 접속할 수 있는 것을 포함할 수 있다. 완전한 인터페이스 캡슐화가 존재하며, 따라서 어떠한 구현 인스턴스 고유 정보도 클라이언트들이 볼 수 없다(확장 시스템에 대한 격리). 프레임워크는 기존의 클라이언트 코드 인터페이스들을 파괴하지 않고도 확장될 수 있는 확장 가능한 모듈식 API들에 대한 지원을 제공할 수 있다. 프레임워크는 기존의 클라이언트 코드 인터페이스들을 파괴하지 않고도 시스템 내의 새로운 인터페이스들의 순조로운 전개에 대한 지원은 물론, (전개, 모듈성, 재사용성의 지원하에) 동일한 일관된 소프트웨어 컴포넌트에 대한 다수의 상이한 인터페이스들의 지원을 제공할 수 있다. 프레임워크는 (반사라고 하는) 복잡한 모듈들의 상세한 상호작용 테스팅 및 진단을 지원하기 위해 실행중인 구성된 컴포넌트들의 구조, 인터페이스들 및 상호접속들에 대한 메타데이터를 유지할 수 있다. 프레임워크는 이용 가능한 다중 스레드 환경들 및 이용 가능한 실시간 환경들을 제공할 수 있으며, 이러한 환경들에서 동적 재구성은 시간 임계 경로 상에 있지 않다(즉, 시동시에 또는 특정 시스템 모드들에서 행해진다). 프레임워크는 관심들을 작은 인터페이스들의 집합으로 분리한다. 여기에서 사용되는 중요한 설계 패턴은, 오리지널 COM 모델에 의해 대중화되었지만, 이제는 많은 상용 및 오픈 소스 소프트웨어 시스템들에서 일반적으로 사용되는 일반적인 "추상 인터페이스" 또는 "프로토콜 계층 구조 [Lakos96]" 패턴들의 확장이다. CORBA 컴포넌트 모델(CCM) 접근법과 같은 훨씬 더 무거운 컴포넌트 모델들에서 제공되지만, C++ 언어 고유 고성능 인식 방식으로 구현되는 코어 기능들에 대한 추가적인 지원 및 저장 인터페이스들이 존재한다.

컴포넌트는 시스템의 교체 가능 부품이다. 컴포넌트들의 예들은 로봇 제어기(140), 액션 선택 엔진(200), 제어 중재기들(120), 로봇 관리기(150), 행동들(300) 및 액션 모델들(400)을 포함한다. 컴포넌트는 시스템의 전체 동작에 영향을 미치지 않고 등가 컴포넌트에 의해 쉽게 교환 및 교체될 수 있다. 로보틱스 시스템(100)의 아키텍처는 소스 코드의 어떠한 재작성 또는 재 컴파일링도 없이 쉽게 교체될 수 있는 소프트웨어 컴포넌트들에 기초한다. 교체 가능하기 위하여, 소프트웨어 컴포넌트는 한 세트의 필요하고, 제공되는 인터페이스들에 따라야 한다. 새로운 스테레오 수신기가 상이한 타입의 입력들 및 출력들을 제공해야 하며, 그에 따라 더 오래된 또는 더 새로운 오디오-비주얼 컴포넌트들에 대해 훅업될 수 있는 것과 동일한 방식으로, 소프트웨어 컴포넌트의 인터페이스들은 시스템 내의 다른 컴포넌트들의 인터페이스들과 100% 호환되어야 한다. 구체적으로, 소프트웨어 컴포넌트에 의해 구현되는 임의의 인터페이스들(즉, "제공되는" 인터페이스들)은 변경되지 않아야 하며, 따라서 이러한 인터페이스를 이용하는 다른 컴포넌트들은 컴플라이언스를 유지하기 위해 변경될 필요가 없음 것이다. 또한, 컴포넌트가 다른 컴포넌트들과 상호작용하기 위해 사용하는 임의의 인터페이스들(즉, "필요한" 인터페이스들)도 변경되지 않아야 한다. 컴포넌트들은 또한 그것을 설명하는 데 사용되는 특성들을 가질 수 있다. 예를 들어, "삼각형"이라고 하는 컴포넌트는 아마도 그의 3개의 꼭지점의 좌표를 지정하기 위한 특성(또는 특성들의 세트)을 가질 것이다.

로보틱스 시스템(100)에서, 컴포넌트는 예를 들어 기초 프레임워크와 호환되는 특성들, 인터페이스들 및 접속들을 갖는 C++ 클래스로서 구현된다. 컴포넌트들의 인스턴스들은 실행시에 동적으로 로딩되고 언로딩될 수 있다. 컴포넌트의 각각의 인스턴스는 디버깅 도구들에 의한 인터페이스 네비게이션을 지원하기 위해 공통 인터페이스 클래스로부터 도출되는 한 세트의 지정된 인터페이스들을 지원할 수 있다.

특성은 컴포넌트를 기술하는 데 유용한 컴포넌트의 특정 속성이다. 예컨대, "로켓"이라고 하는 컴포넌트는 로켓의 스테이지들의 수를 나타내는 "NumStages"라고 하는 특성을 가질 수 있다. 로보틱스 시스템 내의 특성은 컴포넌트 정의 내의 PropertyVar<T> 템플릿을 이용하여 지정된다. 예를 들어, 로켓 내의 스테이지들의 수는 정수이어야 하므로, "NumStages" 특성은 로켓 컴포넌트 정의 내에 그와 같이, 즉 PropertyVar<unsigned int>NumStages로서 선언될 것이다.

인터페이스는 다른 컴포넌트들에 대해 서비스들을 제공하는 지정된 세트의 동작들이다. 예컨대, 약속들의 추적을 유지하는 소프트웨어 컴포넌트는 (캘린더와 같은) 다른 컴포넌트가 약속들의 리스트를 취득하고, 이들을 캘린더 상에 표시하는 것을 허가하는 인터페이스를 제공할 수 있다. 캘린더 컴포넌트는 약속들의 리스트에 액세스하기 위하여, 약속 추적 컴포넌트에 의해 제공되는 인터페이스에 대해 "접속"을 설정해야 하며, 그 인터페이스 내에 제공되는 동작들 중 하나는 요청된 약속 데이터를 취득하고 그것을 반환하기 위한 메소드이어야 한다. 따라서, 인터페이스는 컴포넌트들이 서로 통신하기 위한 수단으로서 간주될 수 있다. 로보틱스 시스템에서, 인터페이스는 기능 및 데이터를 제공하는 지정된 API이며, 예를 들어 C++ 클래스로서 구현된다. 인터페이스 클래스들은 완전한 캡슐화를 제공하여 구현 상세들을 클라이언트들에게 노출하지 않는 추가 특성을 갖는다. 로보틱스 시스템(100) 내의 인터페이스들의 예들은 로봇 제어기 API(142), 행동 API(302) 및 액션 모델 API(402)를 포함한다.

접속들은 컴포넌트들을 함께 결합하는 와이어링이다. 인터페이스들은 컴포넌트들이 서로 대화하는 것을 허가하지만, 인터페이스들은 하나의 컴포넌트가 그가 대화하기를 원하는 다른 컴포넌트(들)를 지정할 방법이 없는 경우에는 무의미하다. 이를 행하기 위해, 컴포넌트는 필요한 인터페이스에 대하여 접속을 설정해야 한다. 친숙한 유사물을 이용하기 위하여, 전화 통신 시스템을 고려한다. 두 당사자가 전화 상에서 서로 대화하기 위하여, 여러 것들이 이루어져야 한다. 먼저, 각자는 대화를 갖기 위한 인터페이스를 제공해야 한다. 이것은 듣고 말하기 위한 스피커 및 마이크로폰을 포함하는 전화 자체일 것이다. 양 당사자가 전화를 갖는 한, 이들은 서로 대화할 수 있다. 그러나, 모든 이들은 대화하고 싶은 사람의 전화 번호를 알지 못하는 경우에는 단지 전화를 소유하는 것으로는 충분하지 않다는 것을 안다. 이것이 접속이 필요한 경우이다. 전화를 집어들고 누군가의 번호를 다이얼링할 때, 그들과의 접속이 설정된다. 접속이 설정되면, 접속이 유지되는 동안, 서로 통화할 수 있다. 로보틱스 시스템(100)은 두 가지 타입의 접속, 즉 단일 접속 및 다중 접속을 제공할 수 있다. (ConnectionVar<T>에 의해 지정되는) 단일 접속들은 컴포넌트가 다른 컴포넌트의 단일 인스턴스의 인터페이스에 액세스하는 것이 필요할 때 적합하다. (템플릿 MultiConnectionVar<T>에 의해 지정되는) 다중 인터페이스 접속들은 컴포넌트가 다른 컴포넌트의 다수의 인스턴스의 인터페이스에 액세스하는 것이 필요할 때 적합하다.

기본 컴포넌트 구조 외에도, 모듈 및 디렉토리 클래스들의 형태의 실행 시간 지원이 존재할 수 있다. 프레임워크는 시스템의 주요 기능을 나타내는 지정된 컴포넌트 인스턴스들의 트리를 관리하도록 설정된다. 이러한 컴포넌트 인스턴스들의 트리는 지정된 인터페이스들의 확장 가능 세트를 각각 지원한다. 트리 내의 각각의 인스턴스는 지정된 인스턴스이며, 모듈 자체 내에 경로명을 갖는다. 객체 인스턴스 이름들은 이러한 지정된 인스턴스들의 동적 인스턴스 계층 구조에 의해 설정된다. 동적 인스턴스 트리 내의 각각의 컴포넌트 인스턴스는 다른 인스턴스들에 의해 전송되는 인터페이스들에 대한 접속들을 지원할 수 있다. 이러한 와이어링은 실행시에 발생하며, 시스템 내의 컴포넌트들로부터 더 높은 레벨의 기능을 구성하는 데 사용된다. 프레임워크 기반 컴포넌트들의 사용은 이러한 코어 모듈 내의 명시적인 인터페이스 접속 메커니즘 및 해당 컴포넌트들에 대한 전송된 인터페이스 헤더 파일들을 통해 이루어진다. 인터페이스를 공유하는 컴포넌트들 사이에는 구현 코드의 어떠한 공유도 요구되지 많지만, 이러한 공유는 다른 이유들로 인해 적절히 행해질 수 있다.

기초 프레임워크는 인터페이스들을 정의하며, 재사용 가능한, 동적으로 로딩 가능한, 동적으로 구성 가능하고 동적으로 접속 가능한, 스크립트 가능한 수행 C++ 소프트웨어들을 구축하기 위한 구현들을 제공한다. 이러한 소프트웨어들은 로보틱스 시스템 내의 컴포넌트들로 지칭된다. 모듈(실행 가능) 레벨에서의 인터페이스 및 API 정의의 주요 수단은 기초 프레임워크로부터 도출되는 새로운 C++ 클래스 인터페이스들의 정의를 통하는 것이다. 코어 프레임워크는 유연한 인터페이스들에 대한 발판 및 클라이언트 코드에 대한 시간에 따른 구현의 전개를 제공한다. 모듈(프로세스 또는 실행 가능 범위) 내의 실행 시간 기반 구조는 프로세스에 대한 모듈 인스턴스의 인터페이스에 액세스함으로써 초기화된다. 이어서, 모듈 인터페이스는 모듈 내의 다른 인스턴스들을 유지하는 루트 디렉토리는 물론, 기본적인 자원 로딩 기능을 제공한다. 모듈 내에 서브디렉토리들이 존재할 수 있으며, 이들은 순환 중첩된다. 이러한 객체들은 디렉토리 인터페이스를 구현하며, 프로세스 범위 내의 컴포넌트 인스턴스들에 대한 계층적 이름 공간을 제공한다. 이러한 계층적 이름 공간은 모듈들이 패키지들 내에 동적으로 구성되고 국지적으로 체계화되는 것을 가능하게 한다. 이러한 명명은 소프트웨어 모듈 내에서 진행되고 있는 것에 대한 사람의 검사 및 이해를 지원하고, 객체 인스턴스들을 참조하는 국지적 이름 공간이 설정되는 것을 허가하기 위해 제공된다. 또한, 계층적 명명은 모듈 내의 컴포넌트들의 프로그램 방식의 네비게이션 및 구성을 돕기 위해 사용될 수 있다.

모듈 인터페이스는 또한 새로운 공장 객체들을 찾기 위한 수단을 제공할 수 있다. 각각의 공장 인스턴스는 일 타입의 지정 객체(또는 컴포넌트)를 생성할 수 있다. 모듈 인터페이스는 공장 인스턴스를 검색할 때, 새로운 동적 라이브러리들을 로딩하여, 모듈에 대해 필요한 기능을 가져올 수 있다. 공장 인터페이스 상의 createNew 함수는 새로운 지정 인터페이스를 반환한다. 모듈 인터페이스는 또한 라이브러리들로부터 새로운 타입들도 탐색하고 동적으로 로딩하여, 프로세스가 프로세스 컴포넌트들의 나머지가 전개된 후에 정의된 타입에 대한 타입 핸들링 코드를 "픽업"하는 것을 허가할 수 있다.

컴포넌트 인터페이스와 관련하여, 각각의 컴포넌트에 의해 지원되는 개별 서비스들 및 API들은 인스턴스 상의 Component::get 메소드를 통해 액세스된다. 이것은 인터페이스에 대한 지정된 핸들을 반환하며, 이어서 이 핸들은 특정 인터페이스 핸들 타입으로 안전하게 축소될 수 있다. 이러한 초기 인디렉션이 발생한 경우, 새로운 인터페이스를 통한 호출들은 가상 함수 호출의 부담을 갖고 동작한다. 인터페이스의 사용이 완료되면, 인터페이스는 핸들에 0을 할당하거나 핸들이 범위를 벗어나게 함으로써 해제된다. 자동 기준 카운팅 핸들들은 컴포넌트 인스턴스들 상의 기준 카운트를 유지하는 데 사용된다.

각각의 인터페이스 타입에 대해, 매칭 기준(핸들) 타입이 존재한다는 점에 유의한다. 이러한 기준 카운팅 핸들은 API에서 사용되며, 클라이언트들 및 구현들에 대해 똑같이 자동 기준 카운팅 지원을 제공한다. 기준 카운팅 핸들들은 STL 컨테이너들 내에 저장되고, 독립 변수들로서 패스되고, 스택 상에서 생성되고, 할당되고, 반환되는 것 등이 이루어질 수 있으며, 그들의 시맨틱은 적절한 기준 카운팅을 보장한다. 이러한 기준 핸들들은 또한 적절히 사용될 때 기준 카운팅에 대한 예외 안전성을 제공한다. 이러한 메커니즘은 바이패스될 수 있지만, 코드의 기준 카운팅 신뢰성을 크게 향상시킬 가능성이 크다.

다수의 구현이 설명되었다. 그러나, 본 발명의 사상 및 범위를 벗어나지 않고 다양한 변경들이 이루어질 수 있음을 이해할 것이다. 따라서, 다른 구현들도 아래의 청구항들의 범위 내에 속한다.

Claims (1)

1. 명세서 또는 도면에 기재된 방법 및 장치.

Images