KR20140052978A

KR20140052978A - 무인 운송체용 제어 컴퓨터

Info

Publication number: KR20140052978A
Application number: KR1020137025622A
Authority: KR
Inventors: 브래드포드 스캇 옐란드; 글렌 에릭 로건; 폴 리제보로프
Original assignee: 배 시스템즈 오스트레일리아 리미티드
Priority date: 2011-02-28
Filing date: 2012-02-14
Publication date: 2014-05-07
Also published as: US20130338856A1; EP2681635A1; AU2012223032A1; AU2012223032B2; US9199725B2; EP2681635B8; CA2831216C; CA2831216A1; EP2681635B1; WO2012117280A1; EP2681635A4; DK2681635T3; ES2913173T3

Abstract

무인 운송체용 제어 컴퓨터로서, 센서 데이터를 상기 운송체의 센서들로부터 수신하기 위한 센서 인터페이스로서, 상기 센서 데이터는 상기 운송체의 이동과 연관된 데이터 값을 포함하는 상기 센서 인터페이스; 액츄에이터 데이터를 상기 운송체의 제어 액츄에이터로 전송하기 위한 액츄에이터 제어 인터페이스로서, 상기 액츄에이터는 상기 운송체의 이동을 제어하는 것과 연관된 상기 운송체의 부품들을 제어하는 상기 액츄에이터 제어 인터페이스; 및 상기 이동의 하나 이상의 페이즈에 대응하는 상태들을 가지는 상태 머신을 실행하기 위한 그리고 상기 상태들 중 현재 상태 및 상기 상태들 중 다른 상태 사이의 천이를 상기 천이와 연관된 적어도 하나의 조건에 기초하여 결정하기 위한 시스템 관리 컴포넌트로서, 상기 적어도 하나의 조건은 상기 센서 데이터, 상기 액츄에이터 데이터 및 상기 컴퓨터의 상태에 기초하여 결정되는, 시스템 관리 컴포넌트를 포함하는, 무인 운송체용 제어 컴퓨터.

Description

무인 운송체용 제어 컴퓨터{CONTROL COMPUTER FOR AN UNMANNED VEHICLE}

본 발명은 운송체가 독자적으로 동작하도록 허용하기 위하여 사용될 수도 있는 무인 운송체용 제어 컴퓨터에 관련한다.

무인 운송체, 예컨대 무인 항공 운송체(unmanned aerial vehicles; UAVs)는 지상 운송체 제어기를 사용하는 조작자에 의하여 원격으로 제어된다. 조작자는 지상 제어기, 및 운송체의 센서들로부터의 다양한 정보를 사용하여 이동 및 동작의 상이한 스테이지들을 통하여 운송체를 유도한다. 운송체는 이것이 몇몇 동작, 예컨대 착륙을 독자적으로 수행하도록 이네이블하는 제어 처리 회로부를 포함할 수도 있다. 하지만 조작자가 운송체가 현재 이동의 어느 스테이지에 있는지를 결정하는 것 그리고 필요할 경우 운송체의 제어를 가져오는 것이 필요하다. 예를 들어, 조작자는 운송체가 독자적으로 착륙하도록 허용하는 적합한 위치에 운송체가 있다고 조작자가 판단할 때까지 비행 도중에 운송체를 제어할 필요가 있을 수도 있다.

계속적인 수동 개입에 대한 필요성을 제거하는 것 및 운송체가 독자적으로 동작하도록 허용하는 것은 다수 개의 상당한 장점들을 가져올 것이다. 독자적 운송체는 만일 원격 운송체 제어기와의 통신이 방해받거나 디스에이블된다고 하더라도 효과적으로 작동할 수 있을 것이다. 조작자 결정과 연관된 인간의 오류들이 역시 제거될 수 있는데, 만일 운송체가 매우 다양한 이동 상황들을 구별하고 스스로 네비게이션할 수 있었다면 특히 그러하다. 일차적 및 상당한 어려움은, 운송체가 언제 상이한 이동 스테이지들 또는 페이즈들 간에 제어가 변화하는지를 결정하도록 이네이블하는 것 또는 특히 이들 간에 전환하며 운송체 상의 사람과 같이 반응할 수 있는 것이다.

이에 상응하여 이러한 어려움을 해결하거나 적어도 유용한 대안을 제공하는 것이 바람직하다.

본 명세서에서 설명되는 실시예들은 무인 운송체용 제어 컴퓨터로서,

센서 데이터를 상기 운송체의 센서들로부터 수신하기 위한 센서 인터페이스로서, 상기 센서 데이터는 상기 운송체의 이동과 연관된 데이터 값을 포함하는, 센서 인터페이스;

액츄에이터 데이터를 상기 운송체의 제어 액츄에이터로 전송하기 위한 액츄에이터 제어 인터페이스로서, 상기 액츄에이터는 상기 운송체의 이동을 제어하는 것과 연관된 상기 운송체의 부품들을 제어하는, 액츄에이터 제어 인터페이스; 및

상기 이동의 하나 이상의 페이즈에 대응하는 상태들을 가지는 상태 머신을 실행하기 위한 그리고 상기 상태들 중 현재 상태 및 상기 상태들 중 다른 상태 사이의 천이를 상기 천이와 연관된 적어도 하나의 조건에 기초하여 결정하기 위한 시스템 관리 컴포넌트로서, 상기 적어도 하나의 조건은 상기 센서 데이터, 상기 액츄에이터 데이터 및 상기 컴퓨터의 상태에 기초하여 결정되는, 시스템 관리 컴포넌트를 포함하는, 무인 운송체용 제어 컴퓨터를 제공한다.

본 발명의 실시예들이 이제부터 첨부 도면들을 참조하여 오직 예로서 기술된다.
도 1 은 무인 운송체용 제어 컴퓨터의 일 실시예의 아키텍처 다이어그램이다;
도 2 는 제어 컴퓨터의 컴포넌트들의 블록도이다;
도 3 은 제어 컴퓨터의 컴포넌트들 간의 관련성의 도면이다;
도 4 는 컴퓨터에 의하여 제어되는 이동의 페이즈들의 도면이다;
도 5(a, b 및 c)는 컴퓨터의 상태 머신의 도면이다; 그리고
도 6 은 컴퓨터에 의하여 관리되는 동작 영역의 배치도이다.

도 1 및 도 2 에 도시된 바와 같은 무인 항공 운송체(UAV)의 비행 제어 컴퓨터(flight control computer; FCC)(100)는 운송체에 탑재된 센서(250)로부터 입력 센서 데이터를 수락하고 처리한다. FCC(100)는 또한 액츄에이터 제어 유닛(ACU)(250)에 대한 커맨드 데이터를 생성 및 발행하여, 인증된 비행 또는 임무 계획에 따라 운송체의 이동을 제어하기 위하여 운송체에 탑재된 다양한 액츄에이터들을 제어한다. ACU(250)는 또한 액츄에이터 및 액츄에이터가 제어하는 운송체의 부품들과 관련한 응답 또는 상태 데이터를, 컴퓨터(100)가 센서 데이터로서 처리하도록 다시 컴퓨터로 제공한다. 컴퓨터(100)는 비행 계획의 페이즈들 동안 운송체를 제어하기 위한 네비게이션, 경로점 관리 및 유도 컴포넌트들(206, 208 및 210)을 포함한다. 도 1 에 도시된 바와 같은 컴퓨터(100)는 전력 PC 및 입력/출력 인터페이스들(예컨대 RS232, 이더넷 및 PCI)이 있는 단일 보드 CPU 카드(120), 및 플래시 메모리(160), GPS 수신기(180) 및 UART 포트들이 있는 I/O 카드(140)를 포함한다. 또한, 컴퓨터(100)는 관성 측정 유닛(inertial measurements unit; IMU)(190)을 하우징하며 그리고 GPS 수신기(예를 들어 노바텔(Novatel) OEMV1)(180)는 글로벌 포지셔닝 시스템을 위하여 운송체 상의 안테나에 직접적으로 접속한다.

FCC(100)는 운송체 상의 후속하는 센서들(250) 및 액츄에이터를 제어하고, 조정하며 모니터링한다:

(i) 기압 트랜스듀서들을 포함하는 에어 데이터 센서(air data sensor; ADS),

(ii) 예를 들어 지상 지향되는 레이저 또는 소나에 의하여 제공되는 정밀 높이 센서(accurate height sensor; AHS),

(iii) 바퀴 상 중량 센서(weight on wheels sensor; WoW),

(iv) 지상 운송체 제어기(ground vehicle controller; GVC)와의 통신을 핸들링하는 트랜스폰더,

(v) 전력 시스템(electrical power system; EPS),

(vi) 일차적 비행 제어들, 예컨대 표면들 용 제어들 (예를 들어 에일러론(ailerons), 방향타(rudder), 승강타(elevators), 에어 브레이크), 브레이크 및 쓰로틀,

(vii) 추진 시스템으로서,

(a) 엔진 터보 제어 유닛(turbo control unit; TCU),

(b) 엔진 관리 시스템(engine management system; EMS),

(c) 엔진 킬(kill) 스위치,

(d) 기화기(carburettor) 히터,

(e) 엔진 팬,

(f) 오일 팬

(viii) 연료 시스템,

(ix) 비행기 온도 센서, 기류 밸브 및 휀을 포함하는 환경 제어 시스템(environmental control system; ECS),

(x) 피토(Pitot) 프루브 히팅,

(xi) 외부 조명, 및

(xii) 아이싱(icing) 검출기를 포함하는 것.

(v) 내지 (xi) 까지의 액츄에이터는 FCC(100)에 의하여 적어도 하나의 액츄에이터 제어 유닛(ACU) 또는 액츄에이터로 접속된 프로세서(252)로 전송된 액츄에이터 데이터에 의하여 제어된다.

FCC(100)는 임베딩된 실 시간 운영 체제(RTOS), 예컨대 그린 힐즈 소프트웨어(Green Hills Software) 아이앤씨에 의한 인테그리티(Integrity)-178B를 저장하고 실행한다. RTOS(304)는 CPU(120)에 의한 메모리 액세스, 리소스 이용가능성, I/O 액세스, 및 적어도 하나의 가상 어드레스 공간을 각각의 CSC로 할당함으로써 컴퓨터의 임베딩된 소프트웨어 컴포넌트들(CSCs)의 파티셔닝을 핸들링한다.

FCC(100)는 도 3 에 도시된 바와 같은, 컴퓨터 소프트웨어 컴포넌트들(CSCs) 및 그 위에서 컴포넌트들이 실행되는 운영 체제(304)를 포함하는 컴퓨터 시스템 구성 아이템(computer system configuration item; CSCI)(302)을 포함한다. CSC들은 플래시 메모리(160) 상에 저장되며 그리고 임베딩된 C++ 또는 C 컴퓨터 프로그램 코드를 포함할 수도 있다. CSC들은 다음 컴포넌트들을 포함한다:

(a) 헬쓰 모니터(202);

(b) 시스템 관리(204)(비행에 중요하거나 비행에 중요하지 않음);

(c) 네비게이션(206);

(d) 경로점 관리(208);

(e) 유도(210);

(f) 안정성 증강(212);

(g) 데이터 로딩/계측(Instrumentation)(214); 및

(h) 시스템 인터페이스(216)(비행에 중요하거나 비행에 중요하지 않음).

헬쓰 모니터 CSC(202)는 CSCI(302)를 포함하는 컴포넌트들의 각각에 접속됨으로써 컴포넌트들이 처리를 성공적으로 완료하는 경우 메시지를 헬쓰 모니터(202)로 전송할 수 있도록 한다.

시스템 인터페이스 CSC(216)는 저 수준 하드웨어 인터페이스 및 초록 데이터를 다른 CSC들에 의하여 사용가능한 포맷으로 제공한다.

네비게이션 CSC(206)은 IMU 데이터 및 GPS 데이터의 조합을 사용하며 그리고 비행기의 현재 위치(위도/경도/높이), 속도, 가속도 및 자세(attitude)를 연속적으로 계산한다. 또한 네비게이션 CSC는 IMU 바이어스 에러를 추적하며 그리고 IMU 및 GPS 에러들을 검출하고 고립시킨다. 네비게이션 CSC에 의하여 생성된 데이터는 WGS-(84)(구형 지구) 좌표를 나타낸다.

경로점 관리(Waypoint Management; WPM) CSC(208)는 주로 FCC 내에서, 3D 공간을 통과하는 운송체의 의도된 경로를 결정하는 유도 CSC(210)로 전송할 4 개의 경로점들의 세트를 생성하는 것을 담당한다. WPM CSC(208)는 또한,

(a) 이벤트 또는 상태 데이터를 시스템 관리 CSC(204)로 공급하여 운송체와 연관된 특정 상황들의 발생을 표시한다.

(b) 수신된 비행 또는 임무 계획들의 유효성을 점검한다.

(c) 운송체의 공중(airborne) 임무 시스템(Mission System; MS)(254)과의 상호작용을 관리한다. MS는 경로점들 및 현재 액티브 임무 계획에 기초하여 WPM(208)으로 루트 요청을 전송한다.

유도 CSC(210)는 4 개의 경로점들에 의하여 규정된 정의된 3 차원의 경로를 따라가기 위하여 (롤, 피치 및 요 레이트들을 나타내는) 운송체 자세 요구 데이터를 생성한다. 자세 레이트 요구는 안정성 증강 CSC(212)로 제공된다. 이러한 요구를 생성하는데 사용되는 4 개의 경로점들은 경로점 관리 CSC(208)로부터 수신된다. 유도 CSC(210)는 이동의 모든 페이즈에서 운송체를 독자적으로 유도한다.

안정성 증강(Stability Augmentation; SA) CSC(212)는 운송체 각도 레이트 요구를 제어 표면 요구로 변환하며 그리고 GVC에 의하여 수신될 수도 있는 임의의 매뉴얼 레이트 요구가 필요할 경우 지상 동작들 도중에 운송체를 제어하도록 허용한다. 또한, SA CSC(212)는 에어 데이터 센서 판독값을 수집하고 컴포넌트들의 나머지를 위하여 에어 속력 및 압력 고도로 변환한다.

기반구조 CSC는 다수 개의 CSC들을 통하여 사용되는 공통 소프트웨어 컴포넌트이다. 이것은 기능들, 예컨대 메시지 생성 및 디코딩, IO 계층 인터페이싱, 시간 관리 기능, 및 시리얼 통신 및 UDP와 같은 프로토콜을 핸들링한다.

시스템 관리 CSC(204)는 내부 및 외부 통신을 포함하는 FCC의 다수 개의 기능들을 관리하는 것을 담당한다.

비행 계획에 따른 UAV 동작은 도 4 에 도시된 바와 같은 비행의 7 개의 상이한 페이즈들을 통하여 이동하거나 동작하는 것으로 간주될 수 있다. 7 개의 비행 페이즈들이 표 1 에서 아래에 설명된다.

독자적 운송체들에 대한 상당한 어려움은 운송체가 언제 이러한 페이즈들 중 하나에 있는지를 결정할 수 있어야 한다는 것, 및 또한 페이즈들 간의 천이이다. 이것을 달성하기 위하여, FCC CSCI(302)는 운송체의 이동의 페이즈들의 각각에 대한 하나 또는 다수 개의 상태들을 확립하는 상태 머신을 포함한다. 상태들 각각은 운송체의 특정한 포함된 동작에 대응함으로써, 운송체의 손상 또는 충돌을 방지하기 위하여 상태들 간의 천이가 상태 머신에 의하여 조심스럽게 관리될 필요가 있도록 한다. 상태 머신은 CSCI의 동작을 이것이 운송체에게 수행하도록 지시하는 동작과 함께 제어한다. 상태 및 그들의 대응하는 페이즈가 이하 표 2 에서 설명된다.

시스템 관리 컴포넌트(204)는, 각각의 상태에 대한 조건들 및 이용가능한 천이에 기초하여, 그리고 CSC들, 예컨대 현재 상태에 의존하는 유도, 네비게이션 및 안정성 증강 및 경로점 관리에 의하여 제공된 데이터에 기초하여, 현존 상태를 결정하고 상태들 간의 변화에 영향을 줌으로써, 상태 머신을 정의하고, 확립하며, 실행한다. CSC에 의하여 제공되며 상태에 영향을 주는 데이터는 순서대로 센서 데이터에 의존하며 그리고 FCC(100)에 의하여 수신된다. 상태 머신의 상태 다이어그램이 도 5a, 도 5b 및 도 5c에 도시된다. 상태는 박스에 의하여 표현되고, 라인은 천이를 나타내며, 그리고 아래에서 논의되는 천이 조건들은 천이 라인들 상에 또는 인접하게 표시된다. 아래에서 표시되고 논의되는 바와 같이, 천이 조건들은 특정 데이터 값을 가지는 CSC들의 파라미터들(예를 들어 플래그들, 커맨드들, 요구들 등)에 의하여 정의된다.

Commence_State(502)는 시스템 관리 컴포넌트(204)가 초기화하는 경우에 진입되는 제 1 상태이다. 이러한 상태에서는, 컴포넌트는 비행 제어 컴퓨터(100)의 전체 헬쓰를 결정하기 위하여 시스템 상태 점검을 담당한다. 운송체의 연속 빌트인 테스트 회로(CBIT)가 IMU 센서들, GPS, 및 에어 데이터 센서들 및 다른 하드웨어 및 소프트웨어가 양호하다는 것을 표시하기만 하면, 시스템 관리는 Commence_Status 플래그를 패스 값으로 설정한다. Commence_State에서, 컴퓨터(100)는 또한 운송체 시스템들을 구성함으로써:

(a) 모든 바퀴 브레이크들이 완전히 체결되도록 설정하고

(b) 제어 표면들을 제로 각도 레이트 제어로 설정하며

(c) 엔진 쓰로틀 요구를 아이들로 설정하고

(d) 오토-쓰로틀을 디스에이블한다.

Commence_Status 플래그가 패스하도록 설정되기만 하면, 상태 머신은 Nav_Align_State(504)로 천이하며 그리고 FCC(100)의 네비게이션 CSC(206)는 GPS 및 IMU 센서들의 헬쓰 및 성능에 대한 추가적 분석을 수행한다. 이러한 상태에 있는 동안 FCC는 비행기가 정지된 것으로 가정하며 그러므로 이러한 센서들로부터 수신된 데이터는 수락된 센서 노이즈 제한을 넘어서 변동할 것이 기대되지 않는다. 이러한 노이즈 제한을 넘는 IMU(190)로부터의 각도, 각도 레이트 및 가속도 데이터 또는 GPS(180)로부터의 위치 및 속도 데이터에서의 임의의 변동은 오류로서 플래깅된다. FCC는 추가적으로 IMU 및 GPS 센서 헬쓰 플래그들을 점검하며 그리고 센서 레이트를 분석하여 센서들이 유효한 데이터를 요구된 센서 레이트에서 출력하고 있다는 것을 확인한다.

Nav_Align_State 내에서, GPS 데이터는 추가적으로 네비게이션 CSC(206)에 의하여 분석되어 운송체에 의하여 사용되는 적어도 두 개의 상이한 안테나들로부터의 데이터가 정확한 분리 및 운송체 헤딩 추정(heading estimation)을 위한 적합성을 표시하는 것을 보장한다. FCC는 또한 GPS로부터의 위치 데이터 및 IMU 틸트 센서로부터의 각도 데이터의 평균을 모션이 없다는 가정을 사용하여 생성한다. 이러한 평균은 평균에 대한 센서 노이즈의 효과를 감소시키기 위하여 60 초의 기간 동안 수행된다. 이러한 평균 위치 및 롤 및 피치 각도는 듀얼 GPS 안테나 위치 차분으로부터 유도된 헤딩 추정(heading estimate)과 함께 사용되어 위치 및 자세의 초기 추정을 제공한다. 네비게이션 CSC(206)는 (IMU 틸트 데이터로부터의) 피치 및 롤에 대한 데이터 값, (GPS 안테나들의 위치 차분으로부터의) 요, (GPS 데이터로부터의) 위도, 경도 및 높이 및 IMU(190)의 자이로스코프 및 가속도계에 대한 바이어스 값을 포함하는 위치 및 속도 데이터 값이 정확하게 결정된 바 있는 경우 상태를 성공적으로 완료한다.

E-Test_State(506)는 진단을 테스트하기 위하여 사용된다. FCC는 임의의 테스트 명령된 메시지(Test Commanded message)가 생성되고 수신된다면, Commence_State 또는 Nav_Align_State 중 하나로부터 이 상태로 천이한다. 이것은 원격 지상 운송체 제어기(ground vehicle controller; GVC)로부터 생성되고 전송될 수도 있다.

만일 Nav_Align_State가 네비게이션 CSC(206)(Nav_Align_Status 플래그가 패스로 설정되는 것에 의하여 표시됨)에 의하여 성공적으로 완료된 바 있으며 그리고 Prepare_To_Start_Engine 커맨드 메시지가 수신된 바 있다면 FCC는 Start_Engine_State(508)로 진입한다. Prepare_To_Start_Command 메시지는 Nav_Align_State가 성공적으로 완료되었기만 하면 GVC로부터 생성되고 수신되거나 시스템 관리 컴포넌트(204)로부터 생성될 수도 있다.

Start_Engine_State(508)에서는, FCC는 엔진 시동 커맨드를 시스템 인터페이스(216)에 대하여 생성하고 전송하는데, 그러면 이제 이것은 액츄에이터 데이터를 ACU(252)로 전송하여 엔진을 시동한다. FCC는 엔진 RPM을 10 개의 프레임 기간동안 분석함으로써 엔진 상태를 모니터링한다. FCC는 100 Hz에서 실행하여 CSC들이 매 초당 100 개의 실행 블록들을 실행하도록 설정될 수 있는데, 여기에서 각각의 블록은 10ms 지속기간의 프레임인 것으로 간주될 수 있다. 엔진의 RPM이 이러한 10 개의 프레임 기간 동안 미리결정된 임계를 초과했기만 하면, 이것은 시동된 것으로 여겨지며 그리고 Engine_Status 플래그가 시동됨으로 설정된다. 비행 또는 임무 계획도 역시 FCC가 TAXI_State(510)로 천하도록 허용되기 이전에 성공적으로 로딩되고, 패스되며, 그리고 수락되었을 것이 필요하다. GVC가 자신이 운송체를 제어하지 않을 것이라는 것을 표시하고, 이를 통하여 Manual_Control 플래그를 거짓으로 설정할 것도 역시 요구 사항일 수도 있다. Prepare_To_Shutdown_Engine 커맨드도 역시 GVC에 의하여 전송되어 FCC를 Engine_Shutdown_State(530)로 천이시킬 수 있다.

Taxi_State(510)에서는 FCC가 운송체를 이것의 현재 위치로부터 이것이 takeoff_State(512)로 천이할 수 있는 활주로 상의 시작 위치로 이동시키기 위하여, 운송체의 지상 이동을 제어한다.

Taxi_State 동안에는, 조건들을 변경하여 운송체가 과속하도록 야기하는 것이 가능하다(이것은 운송체가 사고에 의하여 공중에 뜨게 되도록 하는 결과를 초래할 수 있다). 이러한 고장 모드를 완화하기 위하여, FCC는 에어 및 지상 속력을 모니터링하며 그리고 지상 또는 에어 속력 임계가 초과되는 경우 쓰로틀을 차단하여 아이들 상태로 만들고 에어브레이크들을 활용할 것이다. 만일 이러한 액션이 효율적이지 않고 속력이 계속하여 증가한다면, FCC는 바퀴 브레이킹을 요구할 것이다.

Takeoff State(512)로 천이하기 위해서는, FCC는 운송체가 다음에 해당한다고 결정하여야 한다:

(a) 활주로 중앙선(임무 계획에서 홀딩 포인트 및 이륙 포인트 간의 선분을 통하여 기동됨)으로부터 측면으로 5 미터 이내;

(b) 활주로 방향에서 홀딩 포인트를 10 미터 이상 지나치지 않음;

(c) 홀딩 포인트 높이로부터 10 미터 이내;

(d) 활주로 벡터 헤딩으로부터 5 도 내의 헤딩을 가짐;

(e) 2m/s보다 낮은 속력으로 이동중; 및

(f) CBIT 상태가 양호함.

Takeoff_Command가 GVC로부터 수신될 것이 역시 요구 사항일 수도 있다.

GVC로부터의 Prepare_To_Shutdown_Engine_Command 메시지의 수신 시에, FCC는 Taxi State(512)로부터 Engine Shutdown State(530)로 천이할 것이다.

Takeoff_State(512)에서는, FCC는 액츄에이터 데이터를 포함하는 액츄에이터 요구를 생성하고 출력함으로써:

(a) 운송체를 가속하고;

(b) 이륙 궤적 또는 임무 계획의 경로에 의하여 정의되는 수평 궤적을 획득하며; 그리고

(c) EAS가 이륙을 위한 최소 임계와 동일할 경우 이륙 회전(takeoff rotation)을 수행한다.

다른 요구는 다음을 포함할 수도 있다:

(c) 바퀴(들)를 상승시키기 위하여 유효 에어 속력(effective air speed; EAS) 임계에 도달될 때까지 운송체를 지면에서 유지시키는 것; 및

(d) EAS 임계보다 더 큰 EAS에 대하여 정의된 이륙 피치 자세 프로파일을 따라감으로써 결과적으로 바퀴(들)의 상승을 야기하는 것.

이륙이 개시될 때, FCC(100)는 엔진에 대하여 100% 쓰로틀(또는 임무 계획에 의하여 허용되는 최대값)을 명령하며 그리고 에어 및 바퀴 브레이크를 릴리스한다.

FCC는 또한 특정 비행기에 특유한 커맨드들을 생성할 수도 있다. 예를 들어, FCC는 비행기 꼬리가 70% 스톨 속력(stall speed)을 지날 때 한번 들리도록 명령할 수도 있으며 그리고 그러면 속력이 115% 스톨 속력을 지나기만 하면 회전을 명령할 것이다. 이러한 기동은, 운송체를 바퀴(들)가 지상에 놓여진 채로 유지하고 운송체가 충분한 양력이 이용가능할 경우 지면으로부터 스스로 상승하도록 (이것은 스톨 조건에서의 또는 이에 매우 근접한 비행을 초래할 수 있다) 하는 것 대신에, 지상 활주 동안에 비행기 드래그(drag)를 감소시키며 이륙을 위한 깔끔한 회전을 제공하려고 의도된다.

후속하는 3 개의 조건 중 두 개가 만족되는 경우, FCC는 Takeoff_Complete 파라미터를 참으로 설정하며 Climbout_State(514)로 천이한다.

(i) EAS가 임계, 예를 들어 30 m/s보다 더 크다;

(ii) 바퀴 상 부하가 양 바퀴 모두에 대하여 마지막 11 개의 프레임들, 즉 110 ms 동안에 자주 제로이다;

(iii) 수직 속력이 1 m/s보다 더 크다.

이러한 조건들은 잘못된 WOW 또는 압력 센서들을 가지고 이륙을 검출하는 문제점을 완화하기 위하여 설계된다.

만일 이륙 중지 커맨드가 GVC로부터 수신된다면 FCC는 Rollout State(528)로 천이한다. 만일 GVC와의 통신이 이륙 결정 속력 (예를 들어 추정된 스톨 속력의 80%) 이전에 끊긴다면, 이러한 상태로 천이하도록 역시 결정될 수도 있다.

Climbout_State(514)에서, FCC는 최대 쓰로틀(즉 쓰로틀의 115%)을 요구하는 액츄에이터 데이터를 생성하며 그리고 임무 계획의 상승(climbout) 부분에 의하여 정의되는 수평 궤적 또는 경로를 추적하거나 따라간다. FCC는 또한, 예를 들어 7 도의 상승 피치 각도를 유지하기 위한 커맨드를 발행한다. 이것은 운송체가, 지면에 근접하여 인접할 때 저 속력 조건 및 잠재적 스톨 조건 또는 큰 각도 레이트를 야기할 수 있는 특정한 상승 경로를 제공하는 것보다, 더욱 견실한 상승을 실행하도록 보장한다. 후속하는 조건들 중 하나가 참이라는 것을 표시하는 센서 데이터를 FCC가 수신하는 경우, 이것은 Scenario_State(516)로 천이한다:

(a) 운송체 고도가 규정된 높이 임계에 도달했을 것;

(b) 운송체 EAS가 상승에 대하여 달성되어야 하는 EAS보다 더 클 것; 및

(c) 운송체의 수평 위치가 임무 계획의 상승 부분에서 규정된 상승 경로점에 도달했을 것.

이러한 조건들은 비행기에 대한 상이한 상승 성능을 설명하며 과속 또는 홀딩된 쓰로틀 발생을 방지한다.

Scenario_State(516)에서는, FCC는 비행기를 임무 계획에서 정의된 시나리오 경로점들을 따라 이동시키며, 그리고 경로점 관리 CSC(208)에 의하여 규정된 에어 속력을 역시 유지하는 동안 경로점들에 의하여 규정된 수평 및 수직 경로를 추적한다. FCC는 운송체가 임무 계획의 시나리오 부분에 의하여 정의된 궤적을 따르도록 야기하는 액츄에이터 데이터를 생성한다. FCC는 GOTO_Waypoint_Command가 경로점 관리 CSC(208)에 의하여 생성되는 경우 임무 계획 시나리오 궤적을 수정한다. 루트를 정의하는 일련의 유효한 경로점들이 공중 임무 시스템(Airborne Mission System; AMS)(254)에 의하여 FCC로 제공되는 경우, 두 개의 임무 계획 경로점들 간의 경로는 루트 포인트들에 의하여 정의되어 직선형 라인 대신에 양 방향 포인트들 간의 대안적인 경로를 효과적으로 제공한다. 루트는, 경로점 관리 CSC(208)가 그 루트가 운송체 성능 및 경로점 기하학적 구조 점검을 통과하며 그리고 최대 2 개 이하의 배드 루트들이 AMS로부터 잇달아 수신된 바 있다고 결정하기만 하면 AMS(254)로부터 FCC(100)에 의하여 수락된다.

FCC는 Loiter 커맨드가 생성되는 경우 Scenario_State로부터 Loiter_State(510)로 천이하는데, 이것은 GVC에 의하여 전송될 수도 있다. FCC는 운송체가 임무 계획의 마지막 시나리오 경로점을 통과하거나 Inbound_Command가 수신되는 경우, INBOUND_State(520)로 천이한다. 또한, FCC는 만일 운송체가 GVC와의 통신의 손실을 검출한다면 Inbound_State(520)로의 천이가 발생하도록 구성될 수 있다.

만일 Heading_Hold 생성되고 커맨드가 FCC(100)에 의하여 수신된다면, Scenario_State(516), Loiter_State(518), Inbound_State(520), Circuit_State(522), Approach_State(524) 및 Landing_State(526) 중 하나로부터 Heading_Hold State(540)로의 진입이 수행된다. Heading_Hold 커맨드는 에어 트래픽 제어에 의하여 발행된 방향에 응답하여 GVC의 조작자에 의해 생성될 수도 있다. Heading_Hold 커맨드는 운송체가 따라가야 하는 특정 방향성 헤딩을 나타내는 데이터를 포함하며, 그리고 이에 상응하여 FCC(100)는 액츄에이터 데이터를 생성하여 운송체가 그 방향성 헤딩, 예를 들어 진북에 대해 90°를 따라가도록 한다. Heading Hold State(540)에서, 비행기는 FCC가 다른 상태로 천이할 때까지 그 헤딩을 고정된 고도에서 계속하여 유지할 것이다. FCC는 만일 Cancel_Heading_Hold 커맨드가 생성되고 수신되거나 또는 수평 비행 익스텐트(horizontal flight extent)에 도달한다면 Loiter_State(518)로 천이한다. FCC(100)는 또한, 만일 GVC와의 통신이 끊긴다면 Inbound_State(520)로 천이할 것이다.

Loiter_State(518)에서, FCC(100)는 운송체가 임무 계획의 로이터 부분에 의하여 정의되는 궤적을 따라가도록 액츄에이터 데이터를 생성하며, 이것은 효과적으로 운송체가 로이터 패턴 비행 계획의 랩(laps)으로 진입하도록 야기한다. LOITER_State에서, FCC는 새 임무 계획에 기초하여 수락 및 동작할 수 있다.

FCC가 Loiter_State(518)에 있으며 (GVC에 의하여 전송될 수도 있는) Resume_Scenario_Command를 수신하고, 그리고 이전의 상태가 Scenario_State(516)였다면, FCC는 로이터 패턴의 현재 랩의 완료시에 자신의 상태를 Scenario_State로 천이할 것이다. 이러한 경우에는, Scenario_State로 변경하기만 하면 운송체는 Loiter_State로 진입할 때 그것이 놓여졌던 곳으로부터 시나리오 경로점들을 복구할 것이다.

FCC가 Loiter_State(518)에 있으며 (GVC에 의하여 전송될 수도 있는) Enter_Scenario_Command를 수신하는 경우, 만일 공급된 시나리오 엔트리 경로점으로 비행하기 위한 생성된 경로가 (임무 계획의 비행 익스텐트에 의하여 정의되는 바와 같은) 허용된 비행 영역을 위반하지 않는다면, FCC는 자신의 상태를 즉시 Scenario_State로 천이할 것이다.

FCC가 Loiter_State(518)에 있으며 (GVC에 의하여 전송될 수도 있는) Resume_Inbound_Command를 수신하고, 그리고 이전의 상태가 Inbound_State였다면, FCC는 로이터 패턴의 현재 랩의 완료시에 자신의 상태를 Inbound_State(520)로 천이할 것이다. 이러한 경우는, Inbound_State(520)로 변경하기만 하면 운송체는 로이터 패턴으로 진입할 때 그것이 놓여졌던 곳으로부터 인바운드 진입 경로를 복구할 것이다.

FCC가 Loiter_State(518)에 있으며 Enter_Inbound_Command를 GVC로부터 수신하는 경우, FCC는 자신의 상태를 즉시 Inbound_State로 천이하여, 아래에서 논의되는 바와 같은 인바운드 엔트리를 수행할 것이다.

만일 FCC가 Loiter_State(518)에 있으며 새 임무 계획이 수락되고 활성화된다면, 복구 시나리오 및 복구 인바운드 천이가 디스에이블된다. 새 임무 계획이 활성화될 수도 있는 오직 하나의 공중 상태는 Loiter_State이다. 복구 인바운드 천이는 또한 만일 FCC가 인바운드로부터 Loiter_State에 있으며 착륙 활주로가 변경되었다면 디스에이블된다.

위에서 논의된 바와 같이, 임무 계획의 시나리오 부분이 완료되거나 또는 기지로 되돌아가라는 커맨드가 발행되고 수신되는 경우에 Inbound_State(520)에 진입한다. Inbound_State(520)는 만일 에러 또는 위험이 발생하고 운송체가 안전하게 복구되고 기지로 귀항할 필요가 있는 경우 다른 상태들이 천이하는 타겟인 안전성 상태이다. 예를 들어, 만일 GVC와의 통신이 끊기면, Scenario_State(516), Loiter_State(518), Heading_State(540)는 직접적으로 Inbound_State(520)로 천이할 수 있다. Inbound_State(520)에서, 컴퓨터(100)는 임무 계획의 인바운드 부분에 의하여 정의되는 궤적을 따라갈 액츄에이터 데이터를 생성한다. 이러한 상태에서, FCC는 자신의 기지로의 능동 귀환 경로점들(active return to base waypoints)을 수락하고 변경하거나 또는 인바운드 궤적을 업데이트할 수 있다. 이것은 Inbound_State가 비행장으로의 정적으로 정의된 인바운드 경로로의 동적으로 생성된 엔트리로 이루어지도록 허용한다.

FCC는 착륙 비행장으로 되돌아가는, 비행 익스텐트를 위반하지 않는 (엔트리 포인트로부터 인바운드 경로점들을 따라가는) 최단 비행 경로를 제공하는 인바운드 엔트리 포인트를 선택한다(임무 계획 인바운드 포인트는 엔트리인 것으로 또는 엔트리가 아닌 것으로 지정된다). 정적 임무 계획 점검이 FCC(100)에 의하여 수행되어 비행 익스텐트들 내의 모든 위치들로부터 적어도 하나의 인바운드 엔트리 포인트에 도달하는 것이 가능하다는 것을 보장하는데, 여기로부터 착륙 비행장으로 복귀할 안전한 경로가 보장된다. 도 6 에 도시된 바와 같이, 만일 운송체가 현재 포인트(602)에 있다면, FCC(100)는, 활주로(608)에 가장 가까우며 그리고 운송체가 비 비행 영역(610)을 정의하는 비행 익스텐트들을 위반하지 않으면서 이를 향해 비행하는 인바운드 궤적(606)의 인바운드 경로점(604)을 선택한다. 만일 운송체가 위치(612)에 있으며 그리고 비 비행 익스텐트들이 인바운드 엔트리를 금지한다면 FCC(100)는 활주로(608) 이전에 최종 인바운드 경로점과 더욱 가까운 인바운드 경로점(614)에서 인바운드 궤적(606)과 만날 것이다.

만일 FCC가 Inbound_State(520)에 있으며 운송체가 비행 익스텐트들을 위반한다면 (이것에 대한 가능한 이유는 열화된 운송체 상승/하강 성능을 포함함), 경로점 관리 CSC(208)는 Loiter_State(518)로의 (획득된 것이 아닌) 요구된 고도를 가지는 천이를 강제할 것이다. 이것은 운송체가 요구되는 바와 같은 비행 익스텐트를 넘어서 상승하도록(또는 그 밑으로 하강하도록) 강제한다. 요구된 고도에 도달하면, FCC는 Resume_Inbound_Command를 생성할 것이다. 만일 통신이 끊긴 상황이라면, Loiter_State 밖으로의 끊긴 통신(lost communications transition) 천이가 디스에이블될 것이며, 운송체가 그 고도에 도달하기 이전에 인바운드로 되돌아 천이하는 것을 방지할 것이다. 이러한 끊긴 통신 디스에이블은 Inbound_State로부터 Loiter_State에 진입되었던 경우에만 적용된다.

유도 CSC(210)로부터의 데이터에 기초한 경로점 관리 CSC(208)에 의하여 결정된 바와 같은 마지막 인바운드 경로점의 완료시에, FCC(100)는 Inbound_State(520)로부터 Circuit_State(522)로 천이한다.

Circuit_State(522)에서, FCC는 운송체를 비행장 주위에서 기동시켜서 이것을 활주로로의 접근을 위하여 정렬한다. 이러한 상태에서 FCC는 임무 계획의 선회 부분(circuit portion)에 의하여 정의된 궤적을 따라가기 위한 액츄에이터 데이터를 생성한다. 만일 Enter_Scenario_Command가 (예를 들어 GVC로부터) Circuit_State 도중에 수신되며 그리고 공급된 엔트리 경로점으로의 엔트리 경로가 비행 익스텐트들을 위반하지 않는다면 FCC는 Scenario_State(516)로 천이할 것이다. 만일 Enter_Inbound_Command가 (예를 들어 GVC로부터) Circuit_State 도중에 수신된다면 FCC는 Inbound_State(520)로 천이할 것이다.

FCC는 운송체가 선회 출구 경로점(Circuit Exit Waypoin)으로 지정된 선회 부분 궤적의 선회 경로점에 도달하는 경우 Circuit_State(522)로부터 Approach_State(524)로 천이한다. 이러한 경로점은 활주로와 정렬되어 접근 위치로의 비-기동 천이(non-manoeuvring transition)를 제공한다.

Circuit_State로부터 Approach_State로의 천이는 (예를 들어 GVC로부터의) Inhibit_Approach_Command의 수신시에 디스에이블된다. 이러한 경우에는, FCC는 운송체를 선회 경로점들을 따라서 계속하여 디렉팅할 것이다. FCC가 임무 계획의 마지막 선회 경로점에 도달하는 경우, 이것은 선회 반복 경로점(Circuit Repeat waypoint)으로 지정된 경로점으로 이동함으로써 선회 궤적으로 루프 백할 것이다. 그러면, Inhibit_Approach_Command가 제거되어 Approach_State로의 천이를 허용한다.

만일 Approach_State(524) 또는 Landing_State(526)로부터 Circuit_State에 진입하면, FCC는 최종 인바운드 경로점 근방에서 시작할 정상 선회 경로점들 대신에 임무 계획으로부터의 (통상적으로 활주로의 먼 끝으로부터 시작할) 중지 선회 경로점들을 사용할 것이다.

Approach_State(524)에서 FCC는 에어 브레이크의 0.3 을 인가하기 위한, 그리고 임무 계획의 접근 부분에 의하여 정의된 궤적을 따라가기 위한 액츄에이터 데이터를 포함하는 요구(또는 커맨드)를 생성한다. Approach_State가 FCC에 의하여 사용되어 운송체를 접근 경로 밑으로 유도하며 착륙을 위한 (요구된 위치 및 속력 파라미터 값을 포함하는)조건들을 설정한다.

FCC는 다음의 경우에 Approach_State로부터 Circuit_State로 천이한다:

(a) Abort_Landing_Command가 (예를 들어 GVC로부터) 수신되는 경우; 또는

(b) FCC가 운송체가 요구된 접근 경로로부터 수평으로 또는 수직으로 11m 보다 더 편향되었다는 것을 검출하는 경우.

FCC는 운송체가 접근 경로의 착륙 임계 경로점을 지나가기만 하면 Approach_State(524)로부터 Landing_State(526)로 천이한다.

Landing_State(526)에서, FCC는 Flare_Commence 플래그가 거짓이라면 다음:

(a) 임무 계획의 착륙 부분에 의하여 정의된 궤적을 따라갈 것;

(b) 운송체의 경사각(bank angle)을 운송체의 지면 상의 높이 (height above ground level; HAGL)의 함수로서 제한할 것;

(c) 유효 레벨에서 에어브레이크를, 예를 들어 0.3 에어브레이크를 적용할 것의 요구를 생성한다.

Landing_State(526)는 3-점 착륙을 달성하기 위하여 필요한 최종 기동을 수행하기 위하여 FCC에 의하여 사용된다. 이것은 착륙 경로의 최종 부분까지 운송체를 유도하는 것 및 수락가능한 하강 레이트 및 최소의 바운스를 가지는 3-점 착륙을 달성하기 위한 운송체의 플레어 및 정지(flare and hold-off)를 포함한다.

FCC는 만일:

(a) Abort_Landing_Command가 (예를 들어 GVC로부터) 수신된다면; 또는

(b) FCC가 운송체가 요구된 접근 경로로부터 수평으로 또는 수직으로 11m 보다 더 편향되었다는 것을 검출하며, 운송체가 플레어 및 정지 기동을 시작하지 않았다면 Landing_State(526)로부터 Circuit_State(522)로 천이한다.

FCC는 FCC가: (i) 운송체가 WOW 센서(250)로부터의 데이터에 기초하여 바퀴에 부하를 2초 동안 유지했다고; 그리고(ii) 자신의 에어속력을 스톨 속력 아래로 감소시켰다고 결정한다면 Landing_State(526)로부터 Rollout_State(528)로 천이한다.

Rollout_State(528)에서, FCC는 운송체를 쉬게 하며 임무 계획의 롤아웃 궤적 경로를 따라가도록 하는 액츄에이터 데이터를 포함하는 요구들을 생성한다. Rollout_State는 (임무 계획의 착륙/이륙 경로점들에 의하여 정의된 바와 같은) 활주로 중앙선을 따라 운송체를 스티어링하면서 운송체를 착륙/이륙 속력으로부터 정지까지 감속하기 위하여 FCC에 의하여 사용된다.

FCC는 만일 운송체 속력이 2.0 m/s 아래로 감소되었고, FCC가 매뉴얼 제어 커맨드들을 수신하고 있지 않으며 그리고 Taxi_Command가 생성된 바 있다면(이것은 GVC로부터 온 것일 수도 있다) Rollout_State(528)로부터 Taxi_State(510)로 천이한다.

FCC는 만일 운송체 속력이 2.0 m/s 아래로 감소되었으며, Engine_Shutdown_Command가 (예를 들어 GVC로부터) 생성된다면, Rollout_State(528)로부터 Engine_Shutdown_State(530)로 천이한다.

Engine_Shutdown_State(530)에서, FCC는:

(a) 모든 바퀴 브레이크들이 완전히 체결되도록 설정하고;

(b) 롤, 피치, 요 사이드슬립(sideslip) 및 엔진 에어 속력에 대하여 제로 레이트를 요구하며;

(c) 오토 쓰로틀(auto throttle)을 디스에이블하고;

(d) 제로 에어브레이크를 요구하며;

(e) 엔진 쓰로틀 요구를 아이들로 설정하기 위한 액츄에이터 데이터를 생성한다;

Engine_Shutdown_State(530)는 운송체를 엔진이 셧 다운할 수도 있는 공지된 조건에 두기 위하여 FCC에 의하여 사용되는데, 이것은 아이들 쓰로틀 및 풀 브레이크를 요구한다.

FCC는 Shutdown_Command 의 (예를 들어 GVC로부터의) 수신 또는 생성 시에 Engine_Shutdown_State(530)로부터 Shutdown_State(532)로 천이한다. Shutdown_State(532)에서, FCC는 스스로를 파워다운될 수 있는 조건으로 둔다. FCC가 시스템을 셧다운으로서 마킹하기 이전의 최종 액션은 운송체의 바퀴 브레이크들을 릴리스하여 지상 핸들러들이 이것을 격납고로 이동시킬 수 있도록 하는 것이다.

많은 변경들이 본 발명의 범위로부터 벗어나지 않고서 당업자에게 명백하게 이해될 것이다. 예를 들어, CSC들이 임베딩된 소프트웨어 컴포넌트들인 것으로 설명되지만, 이들은 또한 하드웨어 회로들, 예컨대 ASIC 및 FPGA에 의하여 구현될 수 있다. 본 발명은 또한 지상 운송체 및 UAV에도 적용될 수 있다.

Claims

무인 운송체용 제어 컴퓨터에 있어서,
센서 데이터를 상기 운송체의 센서들로부터 수신하기 위한 센서 인터페이스로서, 상기 센서 데이터는 상기 운송체의 이동과 연관된 데이터 값을 포함하는, 센서 인터페이스;
액츄에이터 데이터를 상기 운송체의 제어 액츄에이터로 전송하기 위한 액츄에이터 제어 인터페이스로서, 상기 액츄에이터는 상기 운송체의 이동을 제어하는 것과 연관된 상기 운송체의 부품들을 제어하는, 액츄에이터 제어 인터페이스; 및
상기 이동의 하나 이상의 페이즈에 대응하는 상태들을 가지는 상태 머신을 실행하기 위한 그리고 상기 상태들 중 현재 상태 및 상기 상태들 중 다른 상태 사이의 천이를 상기 천이와 연관된 적어도 하나의 조건에 기초하여 결정하기 위한 시스템 관리 컴포넌트로서, 상기 적어도 하나의 조건은 상기 센서 데이터, 상기 액츄에이터 데이터 및 상기 컴퓨터의 상태에 기초하여 결정되는, 시스템 관리 컴포넌트를 포함하는, 무인 운송체용 제어 컴퓨터.
제 1 항에 있어서,
상기 천이와 연관된 적어도 하나의 조건은 상기 현재 상태의 이동의 페이즈의 완료를 나타내는, 무인 운송체용 제어 컴퓨터.
제 1 항 또는 제 2 항에 있어서,
상기 적어도 하나의 조건은 상기 현재 상태와 연관된 상기 운송체의 이동 제한의 위반을 나타내는, 무인 운송체용 제어 컴퓨터.
제 1 항에 있어서,
상기 운송체의 이동의 페이즈는 복수 개의 상기 상태들에 대응하는, 무인 운송체용 제어 컴퓨터.
제 1 항 내지 제 4 항 중 어느 한 항에 있어서,
상기 상태들은 개시 상태를 포함하고,
상기 액츄에이터 데이터는 상기 운송체가 정지할 것을 요구하며, 그리고
상기 시스템 관리 컴포넌트는 상기 컴퓨터의 성공적 초기화 및 동작을 결정하는, 무인 운송체용 제어 컴퓨터.
제 1 항 내지 제 5 항 중 어느 한 항에 있어서,
상기 상태들은 네비게이션 정렬 상태(alignment state)를 포함하고,
네비게이션과 연관된 상기 센서들은 테스트되며, 그리고
위치 및 속도 데이터를 포함하는 초기 네비게이션 센서 데이터가 획득되는, 무인 운송체용 제어 컴퓨터.
제 1 항 내지 제 6 항 중 어느 한 항에 있어서,
상기 상태들은 시동 엔진 상태를 포함하고,
이동 계획이 수락되고 인증되어, 상기 운송체의 엔진은 성공적으로 시동되는, 무인 운송체용 제어 컴퓨터.
제 1 항 내지 제 7 항 중 어느 한 항에 있어서,
상기 상태들은 위치 상태를 포함하고,
상기 액츄에이터 데이터는, 상기 센서 데이터가 발진 상태로의 천이를 위한 상기 적어도 하나의 조건인 것에 기초하여 상기 운송체를 발진 위치로 이동시키도록 생성되는, 무인 운송체용 제어 컴퓨터.
제 1 항 내지 제 8 항 중 어느 한 항에 있어서,
상기 상태들은 시나리오 상태를 포함하고,
상기 컴퓨터는 이동 계획의 시나리오 경로점들을 통과하여 상기 운송체를 이동시키기 위한 액츄에이터 데이터를 생성하는, 무인 운송체용 제어 컴퓨터.
제 9 항에 있어서,
상기 컴퓨터는 상기 경로점들을 완료하기 위한 액츄에이터 데이터를 센서 데이터에 기초하여 생성하는 유도(guidance), 네비게이션, 및 경로점 관리 컴포넌트들을 포함하는, 무인 운송체용 제어 컴퓨터.
제 1 항 내지 제 10 항 중 어느 한 항에 있어서,
상기 상태들은 인바운드 상태(inbound state)를 포함하고, 그리고
상기 인바운드 상태로의 천이를 위한 상기 적어도 하나의 조건은 상기 운송체와 연관된 에러 조건을 포함하는, 무인 운송체용 제어 컴퓨터.
제 11 항에 있어서,
상기 에러 조건은 원격 제어기와의 통신 두절을 포함하는, 무인 운송체용 제어 컴퓨터.
제 11 항 또는 제 12 항에 있어서,
상기 인바운드 상태에서, 상기 컴퓨터는 상기 운송체가 이동 계획의 인바운드 궤적을 따라서 기저 위치로 복귀하도록 하는 액츄에이터 데이터를 생성하는, 무인 운송체용 제어 컴퓨터.
제 1 항 내지 제 13 항 중 어느 한 항에 있어서,
상기 상태들은, 상기 컴퓨터가 상기 운송체가 홀딩 경로(holding path)를 따라가도록 액츄에이터 데이터를 생성하는 적어도 하나의 상태를 포함하는, 무인 운송체용 제어 컴퓨터.
제 1 항 내지 제 14 항 중 어느 한 항에 있어서,
상기 상태들은 상기 운송체의 착륙(landing) 이동 페이즈에 대응하는 선회, 접근, 및 착륙 상태들을 포함하는, 무인 운송체용 제어 컴퓨터.
제 1 항 내지 제 15 항 중 어느 한 항에 있어서,
상기 상태들은 상기 운송체의 이륙 이동 페이즈에 대응하는 이륙 및 상승(climb out) 상태를 포함하는, 무인 운송체용 제어 컴퓨터.
제 1 항 내지 제 16 항 중 어느 한 항에 있어서,
상기 상태들은 상기 운송체의 크루즈 이동 페이즈에 대응하는 시나리오 및 로이터 상태들을 포함하는, 무인 운송체용 제어 컴퓨터.
제 1 항 내지 제 17 항 중 어느 한 항에 있어서,
상기 상태들은 상기 운송체의 셧다운 페이즈에 대응하는 엔진 셧다운 및 제어 컴퓨터 셧다운 상태들을 포함하는, 무인 운송체용 제어 컴퓨터.
무인 운송체용 제어 컴퓨터에 의하여 수행되는 방법에 있어서,
센서 데이터를 상기 운송체의 센서들로부터 수신하는 단계로서, 상기 센서 데이터는 상기 운송체의 이동과 연관된 데이터 값을 포함하는, 수신하는 단계;
액츄에이터 데이터를 상기 운송체의 제어 액츄에이터로 전송하는 단계로서, 상기 액츄에이터는 상기 운송체의 이동을 제어하는 것과 연관된 상기 운송체의 부품들을 제어하는, 전송하는 단계, 및
상기 상태들 중 현재 상태 및 상기 상태들 중 다른 상태 사이의 천이를 상기 천이와 연관된 적어도 하나의 조건에 기초하여 결정하기 위하여 상기 이동의 하나 이상의 페이즈에 대응하는 상태들을 가지는 상태 머신을 실행하는 단계로서, 상기 적어도 하나의 조건은 상기 센서 데이터, 상기 액츄에이터 데이터, 및 상기 컴퓨터의 상태에 결정되는, 실행하는 단계를 포함하는, 무인 운송체용 제어 컴퓨터에 의하여 수행되는 방법.