KR20240019231A - 자율주행 차량 테스트를 위한 지원 도구 - Google Patents
자율주행 차량 테스트를 위한 지원 도구 Download PDFInfo
- Publication number
- KR20240019231A KR20240019231A KR1020247000255A KR20247000255A KR20240019231A KR 20240019231 A KR20240019231 A KR 20240019231A KR 1020247000255 A KR1020247000255 A KR 1020247000255A KR 20247000255 A KR20247000255 A KR 20247000255A KR 20240019231 A KR20240019231 A KR 20240019231A
- Authority
- KR
- South Korea
- Prior art keywords
- recognition
- time
- error
- data
- computer system
- Prior art date
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 152
- 230000008447 perception Effects 0.000 claims abstract description 64
- 238000000034 method Methods 0.000 claims abstract description 54
- 238000009877 rendering Methods 0.000 claims abstract description 26
- 238000004422 calculation algorithm Methods 0.000 claims abstract description 19
- 230000000007 visual effect Effects 0.000 claims abstract description 19
- 230000008569 process Effects 0.000 claims abstract description 18
- 230000001364 causal effect Effects 0.000 claims abstract description 9
- 238000011156 evaluation Methods 0.000 claims description 40
- 230000033001 locomotion Effects 0.000 claims description 31
- 230000003068 static effect Effects 0.000 claims description 21
- 238000001914 filtration Methods 0.000 claims description 15
- 238000012545 processing Methods 0.000 claims description 8
- 230000002123 temporal effect Effects 0.000 claims description 6
- 238000004590 computer program Methods 0.000 claims description 3
- 239000003795 chemical substances by application Substances 0.000 description 145
- 238000001514 detection method Methods 0.000 description 79
- 238000004088 simulation Methods 0.000 description 63
- 230000006399 behavior Effects 0.000 description 25
- 230000006870 function Effects 0.000 description 20
- 230000000875 corresponding effect Effects 0.000 description 16
- 238000012800 visualization Methods 0.000 description 14
- 238000004458 analytical method Methods 0.000 description 13
- 230000001133 acceleration Effects 0.000 description 12
- 230000008859 change Effects 0.000 description 9
- 238000010586 diagram Methods 0.000 description 9
- 238000013459 approach Methods 0.000 description 8
- 230000007613 environmental effect Effects 0.000 description 8
- 238000013519 translation Methods 0.000 description 8
- 239000000284 extract Substances 0.000 description 7
- 230000004044 response Effects 0.000 description 7
- 230000036461 convulsion Effects 0.000 description 6
- 230000009471 action Effects 0.000 description 5
- 230000001149 cognitive effect Effects 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 5
- 238000003384 imaging method Methods 0.000 description 5
- 230000004913 activation Effects 0.000 description 4
- 238000013461 design Methods 0.000 description 4
- 238000000605 extraction Methods 0.000 description 4
- 230000004927 fusion Effects 0.000 description 4
- 239000007787 solid Substances 0.000 description 4
- 230000009466 transformation Effects 0.000 description 4
- 241000282412 Homo Species 0.000 description 3
- 235000004522 Pentaglottis sempervirens Nutrition 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 238000007670 refining Methods 0.000 description 3
- 230000001131 transforming effect Effects 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 2
- 230000001276 controlling effect Effects 0.000 description 2
- 230000009849 deactivation Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000009499 grossing Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000000746 purification Methods 0.000 description 2
- 230000002829 reductive effect Effects 0.000 description 2
- 230000035945 sensitivity Effects 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 230000036962 time dependent Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 238000012351 Integrated analysis Methods 0.000 description 1
- 241001465754 Metazoa Species 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000004931 aggregating effect Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000033228 biological regulation Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 239000003086 colorant Substances 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000002408 directed self-assembly Methods 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 230000037406 food intake Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000009191 jumping Effects 0.000 description 1
- 239000003550 marker Substances 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000011895 specific detection Methods 0.000 description 1
- 238000003860 storage Methods 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000012549 training Methods 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/323—Visualisation of programs or trace data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3692—Test management for test results analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N3/00—Computing arrangements based on biological models
- G06N3/004—Artificial life, i.e. computing arrangements simulating life
- G06N3/006—Artificial life, i.e. computing arrangements simulating life based on simulated virtual individual or collective life forms, e.g. social simulations or particle swarm optimisation [PSO]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/01—Dynamic search techniques; Heuristics; Dynamic trees; Branch-and-bound
- G06N5/013—Automatic theorem proving
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Computing Systems (AREA)
- Computational Linguistics (AREA)
- Evolutionary Computation (AREA)
- Artificial Intelligence (AREA)
- Mathematical Physics (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Health & Medical Sciences (AREA)
- Life Sciences & Earth Sciences (AREA)
- Biomedical Technology (AREA)
- Biophysics (AREA)
- General Health & Medical Sciences (AREA)
- Molecular Biology (AREA)
- Traffic Control Systems (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Testing Of Devices, Machine Parts, Or Other Structures Thereof (AREA)
Abstract
센서 장착 차량에 대한 실시간 인식 시스템을 테스트하기 위한 컴퓨터 시스템으로서, 상기 컴퓨터 시스템은 센서 장착 차량에 의해 수행된 실제 운전 실행(real-world driving run)의 데이터를 수신하는 입력, 상기 데이터는 시계열적(time-series) 센서 데이터 및 상기 인식 시스템에 의해 그로부터 추출된 적어도 하나의 관련된 시계열적 런타임 인식 출력들을 포함하며; 그래픽 사용자 인터페이스(GUI)를 렌더링하기 위한 렌더링 데이터를 생성하는 렌더링 컴포넌트, 상기 그래픽 사용자 인터페이스는 실행의 각각의 시간 단계에서 발생한 인식 에러의 시각적 표시를 갖는 인식 에러 타임라인을 포함하며; 그라운드 트루 인식 출력들을 추출하기 위해 비실시간 및/또는 비인과적(non-causal) 인식 알고리즘을 적용함으로써, 센서 데이터 및 런타임 인식 출력들 중 적어도 하나를 프로세싱하도록 구성된 그라운드 트루 파이프라인; 및 상기 그라운드 트루 인식 출력들과 상기 런타임 인식 출력들을 비교하고, 그리고 인식 에러 타임라인을 생성하기 위해 발생한 인식 에러들을 식별하도록 구성된 인식 오라클(perception oracle)을 포함한다.
Description
본 개시는 실제 또는 시뮬레이션 시나리오에서 자율주행 차량 시스템 및 궤적 플래너의 성능을 평가하기 위한 도구 및 방법, 그리고 이를 구현하기 위한 컴퓨터 프로그램 및 시스템에 관한 것이다. 예시적인 애플리케이션은 자율주행 운전 시스템(ADS: Autonomous Driving System) 및 고급 운전자 지원 시스템(ADAS: Advanced Driver Assist System) 성능 테스트를 포함한다.
자율주행 차량 분야에서는 크고 빠른 발전이 있었다. 자율주행 차량(AV)는 센서와 제어 시스템을 장착하여, 사람이 차량의 동작을 제어하지 않고도 작동할 수 있는 차량을 말한다. 자율주행 차량에는 차량의 물리적 환경을 인식할 수 있는 센서가 장착되어 있으며, 이러한 센서는 카메라, 레이더, 라이더 등을 포함한다. 자율주행 차량에는 센서에서 수신한 데이터를 처리하고 센서에서 인식한 상황을 기반으로 안전하고 예측가능한 결정을 내릴 수 있도록 적절하게 프로그래밍된 컴퓨터가 장착되어 있다. 자율주행 차량은 완전 자율형(적어도 특정 상황에서는 사람의 감독이나 개입없이 작동하도록 설계됨)이거나 반자율형일 수 있다. 반자율형 시스템은 다양한 레벨의 인간 감독 및 개입을 필요로 하며, 이러한 시스템은 고급 운전자 보조 시스템(Advanced Driver Assist Systems) 및 레벨 3 자율주행 운전 시스템(level 3 Autonomous Driving Systems)을 포함한다. 특정 자율주행 차량 또는 자율주행 차량 유형에 탑재된 센서 및 제어 시스템의 동작을 테스트하는데는 다양한 측면들이 존재한다.
'레벨 5 차량은 최소한의 안전 수준을 항상 보장하므로 어떤 상황에서도 완전히 자율적으로 작동할 수 있는 차량이다. 이러한 차량은 수동 제어(스티어링 휠, 페달 등)가 전혀 필요하지 않다.
이와 대조적으로, 레벨 3 및 레벨 4 차량은 완전히 자율적으로 작동할 수 있지만, 소정의 정의된 상황에서만 작동할 수 있다(예컨대, 지오펜스 지역 내에서). 레벨 3 차량은 즉각적인 대응이 필요한 모든 상황(예: 비상 제동)을 자율적으로 처리할 수 있어야 한다. 그러나 상황의 변화로 인해 운전자가 제한된 시간 내에 차량을 제어해야 하는 "전환 요구(transition demand)"가 발생할 수 있다. 레벨 4 차량도 비슷한 제한을 갖는다. 하지만, 운전자가 필요한 시간 내에 응답하지 않는 경우, 레벨 4 차량은 "최소 위험 기동"(MRM: minimum risk maneuver), 즉 차량을 안전한 상태로 만들기 위한 몇 가지 적절한 조치(예컨대, 차량 속도를 줄이고 주차함)를 자율적으로 구현할 수도 있어야만 한다. 레벨 2 차량은 운전자가 언제든지 개입할 준비가 되어 있어야 하며, 자율 시스템이 언제든지 적절하게 반응하지 못할 경우, 개입하는 것은 운전자의 책임이다. 레벨 2 자동화에서는 개입이 필요한 시기를 결정하는 것이 운전자의 책임이다. 레벨 3 및 레벨 4의 경우 이러한 책임은 차량의 자율 시스템으로 이동하며 그리고 개입이 필요할 때 운전자에게 경고해야 하는 것은 차량이다.
자율성 수준이 향상되고 더 많은 책임이 인간에서 기계로 이동함에 따라, 안전은 점점 더 어려워지는 과제이다. 자율주행에서는 안전성 보장의 중요성이 인식되고 있다. 안전성 보장은 반드시 사고가 발생하지 않는다는 것을 의미하는 것이 아니라, 정의된 상황에서 최소한의 안전 수준이 충족된다는 것을 의미한다. 일반적으로 자율주행이 가능하려면 이러한 최소 안전 수준이 인간 운전자의 안전 수준을 훨씬 초과해야 한다고 가정된다.
본 명세서에 그 전체 내용이 참조로서 포함되는 살레브-쉬바르츠 등의 논문(Shalev-Shwartz et al. "On a Formal Model of Safe and Scalable Self-driving Cars"(2017), arXiv:1708.06374(RSS 논문))에 따르면, 인간의 운전은 시간당 10-6 정도의 심각한 사고를 유발하는 것으로 추정된다. 자율주행 운전 시스템이 이를 최소 3배 이상 감소시킬 것이라는 가정하에서, RSS 논문은 시간당 10-9 정도의 심각한 사고 정도의 최소 안전 레벨이 보장될 필요가 있다고 결론을 내렸다. 따라서, 순수한 데이터 기반 접근방식(pure data-driven approach)은 AV 시스템의 소프트웨어나 하드웨어가 변경될 때마다 방대한 분량의 주행 데이터가 수집될 것을 요구한다.
RSS 논문은 안전 보장에 대한 모델 기반 접근 방식을 제공한다. 규칙 기반 책임-감각 안전(RSS) 모델은 다음과 같은 몇몇 개의 "상식적인" 운전 규칙들을 공식화함으로써 구성된다:
"1. 뒤에서 누군가를 충돌하지 마십시오.
2. 무모하게 끼어들기(cut-in) 하지 마십시오.
3. 통행권(Right-of-way)은 주어지는 것이지 빼앗는 것이 아닙니다.
4. 시야가 제한되는 지역에서는 주의하세요.
5. 다른 사고를 일으키지 않고 사고를 피할 수 있다면 반드시 그렇게 해야 합니다.”
RSS 모델은 모든 에이전트들이 RSS 모델들의 규칙을 항상 준수한다면 사고가 발생하지 않는다는 점에서 안전성이 입증된 것으로 제시된다. 목표는 필요한 안전 수준을 입증하기 위해 수집될 필요가 있는 주행 데이터의 분량을 수십 수백배 만큼(several orders of magnitude) 감소시키는 것이다.
안전 모델(가령, RSS)은, 자율주행 시스템(스택: stack)의 제어 하에서 실제 시나리오 또는 시뮬레이션 시나리오에서 에고 에이전트에 의해 계획되거나 실현되는 궤적들의 품질을 평가하기 위한 기초로 사용될 수 있다. 다양한 시나리오들에 스택을 노출시키고 그리고 결과적인 에고 궤적이 안전 모델의 규칙을 준수하는지 평가하는 방식으로 스택이 테스트된다(규칙 기반 테스트). 규칙 기반 테스트 접근법은 편안함이나 정의된 목표를 향한 진행 등과 같은 다른 성능 측면에도 적용될 수 있다.
AV 시스템의 인식 에러들과 운전 성능을 모두를 전문가가 평가할 수 있게 하는 기술이 설명된다. 그라운드 트루 인식 출력과의 비교에 의하여 AV의 인식 시스템의 인식 출력을 평가하면, 전문가는 소정 AV 시스템의 전체 성능에 대한 인식 문제의 기여도를 평가할 수 있다. 본 명세서에 서술된 UI는 단일 시각화에서 인식 에러들과 운전 성능을 제시하여, 인식과 운전 성능 사이의 상관관계를 제공하고 그리고 전체 운전 성능에 기여할 수 있는 인식 에러의 원인을 전문가가 판별하는데 도움을 줄 수 있다.
본 발명의 제 1 양상은 센서 장착 차량에 배치하기 위한 실시간 인식 시스템(real-time perception system)을 테스트하기 위한 컴퓨터 시스템에 관한 것으로, 상기 컴퓨터 시스템은:
센서 장착 차량에 의해 수행된 적어도 하나의 실제 운전 실행(real-world driving run)의 데이터를 수신하는 적어도 하나의 입력, 상기 데이터는 (i) 센서 장착 차량에 의해 캡처된 시계열적 센서 데이터 및 (ii) 테스트 중인 상기 실시간 인식 시스템에 의해 그로부터 추출된 적어도 하나의 관련된 시계열적 런타임 인식 출력들을 포함하며;
그래픽 사용자 인터페이스(GUI)를 렌더링하기 위한 렌더링 데이터를 생성하는 렌더링 컴포넌트, 상기 그래픽 사용자 인터페이스는 인식 에러 타임라인을 포함하고, 상기 인식 에러 타임라인은 상기 적어도 하나의 실제 운전 실행의 다수의 시간 단계들 각각에 대해, 해당 시간 단계에서 발생한 인식 에러의 시각적 표시를 가지며;
상기 런타임 인식 출력들과 비교하도록 적어도 하나의 시계열적 그라운드 트루 인식 출력들(의사 그라운드 트루: pseudo-ground truth)을 추출하기 위해 적어도 하나의 비실시간 및/또는 비인과적(non-causal) 인식 알고리즘을 적용함으로써, (i) 상기 시계열적 센서 데이터 및 (ii) 상기 시계열적 런타임 인식 출력들 중 적어도 하나를 프로세싱하도록 구성된 그라운드 트루 파이프라인(ground truthing pipeline); 및
상기 시계열적 그라운드 트루 인식 출력들과 상기 상기 시계열적 런타임 인식 출력들을 비교하고, 그리고 이에 의해서 인식 에러 타임라인을 생성하기 위해 하나 이상의 시간 간격들에서 발생한 인식 에러들을 식별하도록 구성된 인식 오라클(perception oracle)을 포함한다.
일실시예에서, 상기 시계열적 런타임 인식 출력들과 상기 시계열적 그라운드 트루 인식 출력들 사이의 수치적 에러 값들을 계산하고, 그리고 상기 수치적 에러 값들을 적어도 하나의 인식 에러 임계값과 비교함으로써 인식 에러들이 식별될 수 있다.
예를 들어, 수치적 에러 값이 에러 임계값을 초과하는 경우에만, 수치적 에러 값이 인식 에러로서 식별될 수 있다. 에러 임계값은 고정되거나 가변적일 수 있다. 예를 들어, 서로 다른 인식 에러 임계값들이 서로 다른 액터들/에이전트들 또는 이들의 상이한 유형들에 적용될 수 있다(예컨대, 차량 vs 보행자에 대한 서로 다른 임계값 등).
에러 임계값(들)은 예를 들어, GUI를 통해 조정/구성되거나 또는 인식 오라클에 제공되는(예를 들어 도메인 특정 언어(DSL)로 코딩된) 규칙 정의 명령을 통해, 조정가능하거나 달리 구성될 수 있다. 인식 에러 사양의 형태로 DSL의 규칙 정의 지침을 코딩하기 위해 규칙 편집기가 제공될 수 있다. 후자의 접근법은 여기서 "인식 에러 프레임워크"라고 불리는 것을 제공한다.
에러 임계값은 예를 들어, 에러 임계값이 적용되는 객체의 변수(들)과 같은, 운전 실행의 하나 이상의 장면 변수들(실행 변수들)에 따라 달라질 수도 있다. 예를 들어, 주어진 객체(예: 에이전트 또는 정적 객체)에 대해, 인식 에러 임계값은 객체와 에고 에이전트 사이의 거리에 따라 해당 객체에 대해 증가될 수 있다(가까운 객체에 대한 인식 오류가 작을수록 더 중요하다는 점을 토대로). 고정된 임계값을 사용하여 동일한 효과를 얻을 수 있지만, 장면 변수에 따라 가중치가 부여된 수치 에러 값(예: 역 거리에 의해 가중치가 부여됨)으로 달성될 수도 있다. 본 명세서에서, "가변 임계값"에 대한 언급은 달리 명시되지 않는 한 후자의 구현을 포함한다.
(가중된) 수치적 인식 에러는 정규화될 수 있다. 즉, 일부 미리결정된 스케일로 변환되는바, 선택적으로 고정된 에러 임계값을 사용하여, 예를 들어 실패 임계값이 0으로 설정된 범위 [-1,1]로 변환된다. 정규화된 인식 에러는 인식 "견고성" 점수로 지칭될 수 있다.
가중치 기준/변수 임계값은 예를 들어 GUI 또는 DSL을 통해 구성될 수 있다.
(정규화된) 에러 값은 식별된 인식 에러(들)에 추가하여 GUI를 통해 액세스 가능하게 렌더링될 수 있다.
예를 들어, 하나 이상의 에러 임계값을 기반으로 인식 에러를 식별하기 위해 여러 인식 에러 값 또는 그 조합을 매핑하는데 더 복잡한 규칙이 적용될 수 있다.
"인식 에러"는 인식 에러의 이진 표시자이거나(에러/에러 없음) 또는 이진이 아닌 범주형 표시자(예컨대, 빨간색-녹색-파란색 '신호등' 스타일 범주)일 수 있다.
인식 에러는 인식 에러 카운트일 수도 있다(예컨대, 다수의 객체들 및/또는 센서들 및/또는 센서 양식들에 걸쳐 집계됨).
예를 들어, 인식 에러 규칙은 계층적으로 정의될 수 있다. 예를 들어, 다수의 센서들 및/또는 센서 양식들(예: LiDAR, 레이더, 카메라 등) 및/또는 다수의 객체들의 경우, 다수의 양식들/객체들에 대해 집계하여, 총체적 인식 에러가 추출될 수 있다. 이 경우, 다수의 인식 에러 타임라인들이 도출될 수도 있으며, 여기서 예를 들어, 미리결정된 규칙들을 "하위 레벨" 타임라인들(예: 특정 객체, 센서 및/또는 센서 양식에 대한)에 적용함으로써 "탑 레벨" 집계 타임라인이 채워진다. 탑 레벨 타임라인은 하위 레벨 타임라인을 보기 위해 확장될 수 있다. 또한, 운전 실행의 "줌 아웃된" 뷰를 제공하기 위하여, 인식 에러들이 시간 윈도우에 걸쳐 집계될 수도 있다.
인식 오라클은 실행(run)의 적어도 하나의 시간 간격을 필터링하도록 구성될 수 있으며, 여기서 해당 시간 간격은 인식 에러 타임라인에서 생략되며, 필터링은 다음에 적용되는 하나 이상의 필터링 기준에 기초하여 수행될 수 있다: 인식 에러(예컨대, 인식 에러가 발생하지 않은 시간 간격을 필터링함) 및/또는 실제 운전 실행과 관련된 하나 이상의 태그들/라벨들(가령, 취약한 도로 사용자와 같은 소정 유형의 장면 요소가 존재하는 간격만을 포함하기 위해). 예를 들어, 태그들은 동적 및/또는 정적 장면 요소 또는 조건(액터, 날씨, 조명 등)과 관련된 온톨로지 태그(들)를 포함할 수 있다. 이러한 필터링은 타임라인의 "슬라이싱(slicing)"이라 지칭될 수 있다.
타임라인은 다수의 운전 실행들을 집계할 수 있다. 슬라이싱은 이러한 맥락에서 유용한 도구인데, 왜냐하면 타임라인 상에 디스플레이되는 '흥미롭지 않은' 정보의 범위를 줄이는 방법이기 때문이다.
태그는 GUI를 통해 액세스할 수 있다.
운전 실행의 개략적인 표현이 GUI에 디스플레이될 수 있다. 정적 표현은 현재 시간 단계에서 운전 실행의 정적 스냅샷을 디스플레이할 수 있으며, 현재 시간 단계는 GUI에 대한 명령을 통해 선택가능하다. 현재 시간 단계가 변경됨에 따라 시각적 표시자가 변경되어 인식 에러 타임라인에서 현재 시간 단계를 마킹할 수 있다.
개략적인 표현과 함께, 적어도 하나의 실제 운전 주행에 대한 (원시) 데이터도 디스플레이될 수 있다. 예를 들어, 실제 운전 주행의 적어도 하나의 3D 포인트 클라우드(예컨대, 라이다(LiDAR), 레이더, 모노/스테레오 깊이 포인트 클라우드, 또는 이들의 임의의 조합/집합)와 중첩되는 개략적인 탑-다운 뷰가 디스플레이될 수 있다. 대안적으로 또는 추가적으로, 하나의 실제 운전 실행으로부터 캡처된 적어도 하나의 이미지가 현재 시간 단계에 대해 디스플레이될 수 있다(현재 시간 단계를 변경하면 이에 따라 GUI가 해당 이미지로 업데이트된다).
운전 실행의 개략적인 표현은 시계열적 런타임 인식 출력들을 사용하여 렌더링될 수 있다. 예를 들어, 시계열적 런타임 인식 출력들은 검출된 다수의 객체들 각각에 대한 시계열적 그라운드 트루 경계 상자들(위치, 포즈, 크기), 및 각 객체에 대해 식별된 객체 유형을 포함할 수 있으며, 이는 주행 실행의 공지된 도로 레이아웃(예: 지도에서 파생된) 상에 있는 해당 객체의 시각적 아이콘을 렌더링하는데 이용된다.
시계열적 런타임 인식 출력들은, 그라운드 트루 인식 출력들과의 시각적 비교를 위해 GUI를 통해 디스플레이될 수 있다. 예를 들어, 시계열적 런타임 인식 출력들은 후자에서 파생된 개략적인 표현에 오버레이될 수 있다. 예를 들어, 런타임 인식 출력들은 검출된 다수의 시계열적 실시간 경계 상자들을 포함할 수 있고, 현재 시간 단계와 연관된 런타임 경계 상자들의 서브세트는 현재 시간 단계의 스냅샷에 오버레이될 수 있다.
인식 그라운드 트루는 각 에이전트(에고 및/또는 다른 에이전트)에 대한 트레이스의 형태일 수 있으며, 여기서 트레이스는 공간 및 모션 상태들(예: 경계 상자 및 감지된 속도 벡터 또는 다른 모션 벡터)의 시간-시퀀스이다.
추출된 트레이스는 GUI에서 실행을 시각화하는데 사용될 수 있다.
시나리오가 진행됨에 따라 인식 에러 타임라인을 따라 이동하는 비디오 표시자와 함께, GUI에서 시나리오를 동적으로 "재생"하기 위한 옵션이 제공될 수 있다.
제 2 운전 성능 타임라인이 또한 GUI에 디스플레이될 수 있으며, 이는 동일한 그라운드 트루 인식 출력들(예를 들어, 트레이스들)에 적용된 운전 성능 평가의 결과들을 전달한다. 예를 들어, 테스트 오라클이 이러한 목적으로 제공될 수 있다.
실행 데이터(run data)는 예를 들어, 2개 이상의 라이다, 레이더 및 이미지 (예컨대, 스테레오 또는 모노 이미지로부터의 깊이 데이터)와 같은 여러 센서 양식을 포함할 수 있다.
일부 실시예에서, 하나의 센서 양식(또는 센서 양식들의 조합)은 다른 센서 양식(또는 센서 양식들의 조합)에 대한 그라운드 트루를 제공하는데 사용될 수 있다. 예를 들어, 보다 정확한 LiDAR를 사용하여 레이더 또는 이미지(모노 또는 스테레오) 데이터에서 파생된 검출 또는 기타 인식 출력의 기준으로 사용되는 의사 그라운드 트루를 도출할 수 있다.
예를 들어, 의사 그라운드 트루 또는 런타임 인식 출력의 정확성을 검증하거나 측정하기 위한 기준으로서, 상대적으로 적은 분량의 수동으로 라벨링된 그라운드 트루가 시스템 내에서 사용될 수 있다.
비록 앞선 일례에서는 의사 그라운드 트루로부터 도출된 인식 에러를 고려했지만, 본 발명의 다른 측면에서, 전술한 GUI는 다른 방식으로 도출된 인식 에러들을 렌더링하는데 사용될 수 있다(의사 그라운드 트루를 사용함이 없이 실제 세계 데이터로부터 그리고 시뮬레이터에서 생성된 시뮬레이션 운전 실행의 인식 에러를 포함하여). 시뮬레이션 실행의 경우 위의 설명은 시뮬레이터에서 직접 제공한 그라운드 트루(그라운드 트루 파이프라인 필요없음) 및 시뮬레이션 실행의 장면 변수에 동일하게 적용된다.
본 명세서의 제 2 양상은 자율주행 차량 성능을 평가하기 위한 컴퓨터 시스템을 제공하며, 상기 컴퓨터 시스템은:
적어도 하나의 자율주행 운전 실행의 성능 데이터를 수신하도록 구성된 적어도 하나의 입력, 상기 성능 데이터는 적어도 하나의 시계열적 인식 에러들 및 적어도 하나의 시계열적 운전 성능 결과들을 포함하고; 및
그래픽 사용자 인터페이스(GUI)를 렌더링하기 위한 렌더링 데이터를 생성하는 렌더링 컴포넌트를 포함하며,
상기 그래픽 사용자 인터페이스는 성능 데이터를 시각화하기 위한 것이며,
(i) 인식 에러 타임라인, 그리고
(ii) 운전 평가 타임라인을 포함하고,
타임라인은 시간에 따라 정렬되고, 그리고 적어도 하나의 운전 실행의 다수의 시간 단계들로 분할되며, 각각의 시간 단계에 대해: 상기 인식 타임라인은 해당 시간 단계에서 인식 에러가 발생했는지 여부를 나타내는 시각적 표시를 포함하고, 상기 운전 평가 타임라인은 해당 시간 단계에서 운전 성능에 대한 시각적 표시를 포함한다.
운전 평가 타임라인과 인식 타임라인은 서로 평행할 수 있다.
위의 도구는 운전 성능을 인식 에러에 시각적으로 링크하여, 열악하거나 허용할 수 없는 ADS/ADAS 성능의 경우를 판단함에 있어서 전문가에게 도움을 줄 수 있다. 예를 들어, 운전 수행 타임라인 중에서 중대한 운전 규칙 실패가 발생한 영역에 포커싱함으로써, 전문가는 인식 에러 타임라인을 동시에 확인하여 인식 에러가 규칙 실패에 기여했는지 여부를 확인할 수 있다.
실시예에서, 운전 성능은 하나 이상의 미리정의된 운전 규칙(들)과 관련하여 평가될 수 있다.
운전 성능 타임라인은 다수의 개별 운전 규칙들에 걸쳐 운전 성능을 집계할 수 있으며, 개별 운전 규칙에 대한 각각의 운전 성능 타임라인을 볼 수 있도록 확장될 수 있다.
(각각의) 주행 성능은 (아래에 설명된 바와 같이) 규칙의 계산 그래프 표현을 보기 위해 확장될 수 있다.
운전 실행(driving run)은 실제 트레이스에 운전 규칙이 적용된 실제 실행(real-world run)일 수 있다.
일부 경우, 그라운드 트루 파이프라인을 사용하여 (의사) 그라운드 트루 트레이스(들)/인식 출력들을 추출할 수 있으며, 이는 인식 에러를 결정하고 운전 규칙과 관련된 성능을 평가하는데 사용된다(전술한 제 1 양상에서와 같이).
대안적으로, 의사 그라운드 트루를 사용하지 않고 인식 에러를 식별할 수도 있다. 예를 들어, 이러한 에러는 "깜박이는(flickering)" 객체(이것은 런타임 객체 검출기가 실패하면 나타나거나 사라짐) 또는 "점프하는" 객체(운동학적으로 실행불가능한 방식으로 장면을 가로질러 점프하는 것으로 볼 수 있음)에서 식별될 수 있다. 예컨대, 런타임 검출기는 실행 중 일부 포인트에서 근처에 있는 2개의 객체를 "교환(swap)"할 수 있다.
성능 데이터는 관심있는 인식 영역을 나타내는 적어도 하나의 시계열적(time-series) 수치적 인식 점수들을 포함할 수 있고, 그래픽 사용자 인터페이스는 수치적 인식 점수의 대응 타임라인을 적어도 포함할 수 있으며, 각 시간 단계에 대해 수치적 인식 점수 타임라인은 해당 시간 단계와 관련된 수치적 인식 점수의 시각적인 표시를 포함한다.
시계열적 수치적 인식 점수들은, 각각의 시간 단계에서 인식 시스템의 난이도 척도를 나타내는 시계열적인 경도(hardness) 점수일 수 있다.
성능 데이터는 적어도 하나의 시계열적 사용자 정의 점수를 포함할 수 있고, 그래픽 사용자 인터페이스는 적어도 하나의 대응하는 커스텀 타임라인을 포함할 수 있으며, 각 시간 단계에 대해 커스텀 타임라인은 해당 시간 단계에서 평가된 사용자 정의 점수의 시각적 표시를 포함한다.
대안적으로, 실행(run)은 시뮬레이션된 실행일 수 있고, 인식 에러들이 시뮬레이션될 수 있다.
예를 들어, 하나 이상의 인식 에러(또는 인식 성능) 모델들이 이용되어, 인식 에러를 샘플링할 수 있으며, 보다 일반적으로는 그라운드 트루 시뮬레이터 상태를 더 현실적인 인식 에러들로 변환할 수 있는바, 상기 더 현실적인 인식 에러들은 시뮬레이션 동안 테스트 중인 스택의 상위 레벨 컴포넌트에 제공될 수 있다.
또 다른 일례로서, 합성 센서 데이터가 시뮬레이션에서 생성되고 그리고 실제 센서 데이터와 동일한 방식으로 스택의 인식 시스템에 의해 프로세싱될 수 있다. 이 경우, 시뮬레이션된 인식 에러들은 실제 인식 에러들과 동일한 방식으로 도출될 수 있다(비록 이 경우 그라운드 트루 파이프라인이 필요하지 않지만 시뮬레이터에 내재된 그라운드 트루와 비교하여 인식 에러를 식별할 수 있음).
필터/슬라이싱이 타임라인에 적용될 수도 있는바, 예를 들어, 특정 규칙/규칙들의 조합에 대해 실패한 시간 기간만을 보여줄 수 있다. 따라서, 인식 에러 타임라인은 운전 성능 타임라인에 적용된 규칙들에 기초하여 필터링/슬라이싱될 수 있으며 그 반대도 마찬가지이다.
그래픽 사용자 인터페이스는 타임라인과 정렬된 진행 바(progress bar)를 포함할 수 있으며, 진행 바는 규칙적인 시간 간격들을 나타내는 하나 이상의 마커를 가지며, 각각의 간격은 운전 실행의 하나 이상의 시간 단계를 포함한다. 마커들의 서브세트에는 숫자 시간 표시자가 라벨링될 수 있다.
그래픽 사용자 인터페이스는 타임라인을 따라 연장되고 운전 실행의 선택된 시간 단계를 나타내는 스크러버 바를 포함할 수 있다. 운전 실행의 새로운 시간 단계에 대한 사용자 선택에 응답하여 타임라인들 중 하나의 타임라인 상의 포인트를 클릭함으로써 스크러버 바는 타임라인을 따라 이동할 수 있으며, 따라서 스크러버 바는 선택된 포인트에서 타임라인을 가로질러 확장될 수 있다.
그래픽 사용자 인터페이스는 타임라인에 포함된 운전 실행의 시간 단계들의 개수를 증가 또는 감소시키는데 이용가능한 줌 입력을 포함할 수 있다. 타임라인들은 다음과 같이 구성될 수 있는바, 타임라인의 시간 단계들의 수를 늘리거나 줄이기 위해 줌 입력이 이용되는 경우, 각각의 시간 단계에 대한 시각적 표시자는 각각 축소되거나 확장되며, 따라서 타임라인은 일정한 길이를 유지한다.
진행 바는 다음과 같이 구성될 수 있는바, 타임라인의 시간 단계들의 개수를 임계값 아래로 감소시키기 위해 줌 입력이 이용되는 경우, 더 짧은 시간 간격들을 나타내도록 마커들이 조정된다. 타임라인의 시간 단계들의 개수를 임계값 위로 증가시키기 위해 줌 입력이 이용되는 경우, 마커들은 더 긴 시간 간격들을 나타내도록 조정될 수 있다.
운전 실행의 시간 간격들의 개수를 조정하기 위해 줌 입력이 이용되는 경우, 타임 라인 상의 기준점을 중심으로 하는 정의된 범위 내의 시간 간격들만 포함하도록 타임 라인이 조정될 수 있다. 기준점은 운전 실행의 시작일 수 있다. 대안적으로, 기준점은 운전 실행의 현재 선택된 시간 간격일 수 있다. 현재 선택된 지점은 스크러버 바에 의해 표시될 수 있다.
줌 입력은 슬라이더 바를 따라 표시자를 이동함으로써 타임라인의 시간 단계들의 개수를 조정하는데 사용될 수 있는 줌 슬라이더 바를 포함할 수 있다. 바를 따라 슬라이더를 클릭 및 드래그하거나, 또는 표시자가 이동될 슬라이더 상의 지점을 클릭함으로써, 표시자가 이동될 수 있다. 줌 입력은 스크린을 터치하는 두 손가락 사이의 거리 변화에 기초하여 타임라인의 시간 단계들의 개수를 조정하는 터치 스크린 상의 핀치 제스처를 포함할 수 있다. 대안적으로, 줌 입력은 사용자가 휠을 앞으로 또는 뒤로 굴리는 것에 응답하여 타임라인의 시간 단계들의 개수를 조정하는 마우스 휠을 포함할 수 있다.
타임라인은 스크롤될 수 있으며, 따라서 타임라인에 디스플레이된 다수의 시간 단계들은 사용자 스크롤 동작에 응답하여 시간에 따라 앞으로 또는 뒤로 이동하도록 조정된다.
운전 실행 사이사이의 부분이 선택될 수 있는바, 해당 부분의 시작 시간을 나타내는 진행 바 상의 제 1 지점을 클릭하고 그리고 진행 바를 따라 해당 부분의 종료 시간을 정의하는 제 2 지점으로 드래그함으로써, 상기 부분이 선택될 수 있다.
선택된 부분에 해당하는 운전 데이터가 추출되어 데이터베이스에 저장될 수 있다.
전술한 제 1 양상은 런타임 인식 출력들과 도출된 (의사) 그라운드 트루 인식 출력들의 세트를 서로 비교함으로써 실시간 인식 시스템을 테스트하는 것에 관한 것이다. 다른 양상에서, 실시예들의 임의의 전술한 특징들이 보다 일반적으로 적용되어, 그라운드 트루 인식 출력들의 대응 시퀀스와의 비교에 의해 인식 출력들의 임의의 시퀀스를 평가할 수 있다. 이러한 맥락에서, 그라운드 트루는, 해당 기준선과의 비교에 의하여 인식 출력들을 평가할 목적으로 정확하다고 간주되는 임의의 기준선이 될 수 있다.
본 발명의 제 3 양상은 컴퓨터 시스템에 관한 것이며, 상기 컴퓨터 시스템은 다음을 포함한다:
적어도 하나의 주행 실행에 관한 데이터를 수신하는 적어도 하나의 입력, 상기 데이터는 (i) 제 1 시계열적 인식 출력들 및 (ii) 제 2 시계열적 그라운드 트루 인식 출력들을 포함하고, 시계열적 그라운드 트루 인식 출력들 및 시계열적 런타임 인식 출력들은 적어도 하나의 시간 간격과 연관되며;
그래픽 사용자 인터페이스(GUI)를 렌더링하기 위한 렌더링 데이터를 생성하는 렌더링 컴포넌트, 상기 그래픽 사용자 인터페이스는 인식 에러 타임라인을 포함하고, 상기 인식 에러 타임라인은 적어도 하나의 운전 실행의 다수의 시간 단계들 각각에 대해, 해당 시간 단계에서 발생한 인식 에러의 시각적 표시를 가지며;
시계열적 인식 출력들과 시계열적 그라운드 트루 인식 출력들을 비교하고, 그리고 이에 의해서 인식 에러 타임라인을 생성하기 위해 하나 이상의 시간 간격들에서 발생한 인식 에러들을 식별하도록 구성된 인식 오라클(perception oracle).
'인식 출력'이라는 용어는 이러한 맥락에서 광범위하게 사용되며, 차량의 인식 스택의 출력 뿐만 아니라 인간의 주석에서 얻은 인식 데이터를 포함한다.
추가적으로, 컴퓨터 시스템은 그라운드 트루 파이프라인을 포함할 수 있다. 그라운드 트루 파이프라인은 적어도 하나의 비실시간 및/또는 비인과적 인식 알고리즘을 적용하여 적어도 하나의 운전 실행의 데이터를 프로세싱함으로써 제 1 시계열적 인식 출력들을 생성하도록 구성될 수 있으며, 상기 데이터는 운전 실행으로부터 시계열적 센서 데이터 및 인식 시스템에 의해서 이로부터 추출된 관련 시계열적 런타임 인식 출력들을 포함한다. 그라운드 트루 인식 출력들은 적어도 하나의 운전 실행에 대한 수동 주석에 의해 생성될 수 있다. 본 실시예에서 인식 시스템에 의해 생성된 인식 출력들은 '의사' 그라운드 트루 인식 출력들이며, 이는 동일한 운전 실행에 대해 수신된 수동으로 주석이 달린 그라운드 트루 인식 출력들과 비교되어, 의사 그라운드 트루 인식 출력들에서 인식 에러들을 식별할 수 있다. 이러한 비교는 평가될 인식 출력들의 다른 세트와의 비교를 위해 그라운드 트루로서 이용되는 그라운드 트루 파이프라인으로부터 획득된 의사 그라운드 트루 인식 출력들의 적합성을 평가하는 방법으로 사용될 수 있다. 이러한 비교는 인간 주석이 이용불가능한 더 큰 데이터 세트에 대해 인식 출력을 평가하는데 의사 GT가 사용될 수 있도록, 수동으로 주석이 달린 운전 데이터의 서브세트에만 기초할 수 있다.
대안적으로, 인식 시스템은 센서 장착 차량에 배치하기 위한 실시간 인식 시스템을 포함할 수 있고, 인식 출력은 주어진 운전 실행에 대한 시계열적 센서 데이터로부터 실시간 인식 시스템에 의해서 추출된 시계열적 런타임 인식 출력들을 포함할 수 있다. 그라운드 트루 인식 출력은 그라운드 트루 파이프라인에 의해 생성될 수 있는바, 적어도 하나의 비실시간 및/또는 비인과적 인식 알고리즘을 적용하여 적어도 하나의 시계열적 센서 데이터 또는 시계열적 런타임 인식 출력을 프로세싱함으로써 생성될 수 있다. 대안적으로, 그라운드 트루 인식 출력은 운전 실행에 대한 수동 주석에 의해 생성될 수 있다.
운전 실행은 실제 운전 실행일 수 있다.
대안적으로, 운전 실행은 시뮬레이터에 의해 생성된 센서 데이터를 이용한 시뮬레이션 운전 실행일 수 있으며, 런타임 인식 출력은 시뮬레이션된 센서 데이터에 실시간 인식 시스템을 적용함으로써 획득될 수 있다. 런타임 인식 출력과 비교하기 위해 그라운드 트루 인식 출력이 시뮬레이터로부터 직접 획득될 수도 있다.
본 발명의 추가 양상은 실시간 인식 시스템을 테스트하기 위한 컴퓨터 구현 방법을 제공하며, 상기 실시간 인식 시스템은 센서 장착 차량에 배치하기 위한 것이며, 상기 방법은,
센서 장착 차량에 의해 수행된 적어도 하나의 실제 운전 실행(real-world driving run)의 데이터를 입력에서 수신하는 단계, 상기 데이터는 (i) 센서 장착 차량에 의해 캡처된 시계열적 센서 데이터 및 (ii) 테스트 중인 상기 실시간 인식 시스템에 의해 그로부터 추출된 적어도 하나의 관련된 시계열적 런타임 인식 출력들을 포함하며;
렌더링 컴포넌트에 의해, 그래픽 사용자 인터페이스(GUI)를 렌더링하기 위한 렌더링 데이터를 생성하는 단계, 상기 그래픽 사용자 인터페이스는 인식 에러 타임라인을 포함하고, 상기 인식 에러 타임라인은 상기 적어도 하나의 실제 운전 실행의 다수의 시간 단계들 각각에 대해, 해당 시간 단계에서 발생한 인식 에러의 시각적 표시를 가지며;
상기 런타임 인식 출력들과 비교하도록 적어도 하나의 시계열적 그라운드 트루 인식 출력들을 추출하기 위해 적어도 하나의 비실시간 및/또는 비인과적(non-causal) 인식 알고리즘을 적용함으로써, (i) 상기 시계열적 센서 데이터 및 (ii) 상기 시계열적 런타임 인식 출력들 중 적어도 하나를 그라운드 트루 파이프라인(ground truthing pipeline)에서 프로세싱하는 단계; 및
인식 오라클(perception oracle)에서, 상기 시계열적 그라운드 트루 인식 출력들과 상기 상기 시계열적 런타임 인식 출력들을 비교하고, 그리고 이에 의해서 인식 에러 타임라인을 생성하기 위해 하나 이상의 시간 간격들에서 발생한 인식 에러들을 식별하는 단계를 포함한다.
추가 양상들은 여기에 설명된 임의의 방법을 구현하는 컴퓨터 시스템을 프로그래밍하기 위한 실행가능한 프로그램 명령들을 제공한다.
본 개시의 더 나은 이해를 위해, 그리고 본 개시의 실시예가 어떻게 실행될 수 있는지를 보여주기 위해, 단지 일례로서 다음 도면을 참조한다:
도 1은 인식 에러 사양에 대한 일련의 사용 사례를 보여준다.
도 2a는 자율 차량 스택의 개략적인 기능 블록 다이어그램을 보여준다.
도 2b는 자율주행 차량 테스트 패러다임의 개략적인 개요를 보여준다.
도 2c는 시나리오 추출 파이프라인의 개략적인 블록 다이어그램을 보여준다.
도 3은 수동으로 태그가 지정된 주행을 검토하기 위한 사용자 인터페이스를 보여준다.
도 4a는 그라운드 트루 파이프라인의 개요를 보여준다.
도 4b는 노이즈가 있는 경계 상자 세트와 개선된 경계 상자 세트를 보여준다.
도 5a는 그라운드 트루 파이프라인에 사용되는 일련의 검출 개선 기술을 보여준다.
도 5b는 그라운드 트루 파이프라인에 사용되는 일련의 오프라인 감지 기술을 보여준다.
도 6a는 테스트 파이프라인의 개략적인 블록 다이어그램을 보여준다.
도 6b는 테스트 파이프라인의 가능한 구현에 대한 자세한 내용을 보여준다.
도 7a는 테스트 오라클 내에서 평가된 규칙 트리의 예를 보여준다.
도 7b는 규칙 트리 노드의 출력 예를 보여준다.
도 8a는 테스트 오라클 내에서 평가되는 규칙 트리의 예를 보여준다.
도 8b는 시나리오 그라운드 트루 데이터 세트에 대해 평가된 규칙 트리의 제 2 예를 보여준다.
도 8c는 테스트 오라클 내에서 규칙이 선택적으로 적용될 수 있는 방법을 보여준다.
도 9a는 그래픽 사용자 인터페이스를 렌더링하기 위한 시각화 컴포넌트의 개략적인 블록도를 보여준다.
도 9b, 9c 및 9d는 그래픽 사용자 인터페이스 내에서 이용가능한 다양한 뷰를 보여준다.
도 10a는 컷인 시나리오의 제 1 인스턴스를 보여준다.
도 10b는 제 1 시나리오 인스턴스에 대한 오라클 출력의 예를 보여준다.
도 10c는 컷인 시나리오의 제 2 인스턴스를 보여준다.
도 10d는 제 2 시나리오 인스턴스에 대한 오라클 출력의 예를 보여준다.
도 11은 인식 에러를 평가하기 위한 아키텍처의 예를 보여준다.
도 12a는 분류 도구에 대한 예시적인 그래픽 사용자 인터페이스를 보여준다.
도 12b는 그래픽 사용자 인터페이스에 표시된 센서 데이터를 포함하는 운전 시나리오의 개략도를 보여준다.
도 12c는 확대/축소 기능과 타임라인 스크러버를 갖춘 사용자 인터페이스의 예를 보여준다.
도 12d는 사용자 인터페이스에서 시나리오의 하위 섹션을 선택하는 것을 보여준다.
도 13은 인식 규칙을 보여주는 그래픽 사용자 인터페이스의 집중된 보기를 보여준다.
도 14는 인식 에러 프레임워크 내의 예제 규칙 정의를 보여준다.
도 15는 정의된 에러 임계값을 사용한 인식 에러에 대한 수치 점수의 예시 그래프를 보여준다.
도 16은 단일 인식 에러 사양이 실제 및 시뮬레이션 주행 시나리오에 어떻게 적용될 수 있는지 보여준다.
도 17은 정의된 인식 에러 사양이 인식 테스트 및 스택 계획에 어떻게 사용될 수 있는지 보여준다.
도 18a 및 18b는 시나리오의 관련 에러를 식별하기 위해 적용되는 필터링 도구를 보여준다.
도 19a는 에러 임계값이 그래픽 사용자 인터페이스를 통해 어떻게 조정될 수 있는지 보여준다.
도 19b는 운전 시나리오의 '슬라이스' 선택 및 분석을 보여준다.
도 1은 인식 에러 사양에 대한 일련의 사용 사례를 보여준다.
도 2a는 자율 차량 스택의 개략적인 기능 블록 다이어그램을 보여준다.
도 2b는 자율주행 차량 테스트 패러다임의 개략적인 개요를 보여준다.
도 2c는 시나리오 추출 파이프라인의 개략적인 블록 다이어그램을 보여준다.
도 3은 수동으로 태그가 지정된 주행을 검토하기 위한 사용자 인터페이스를 보여준다.
도 4a는 그라운드 트루 파이프라인의 개요를 보여준다.
도 4b는 노이즈가 있는 경계 상자 세트와 개선된 경계 상자 세트를 보여준다.
도 5a는 그라운드 트루 파이프라인에 사용되는 일련의 검출 개선 기술을 보여준다.
도 5b는 그라운드 트루 파이프라인에 사용되는 일련의 오프라인 감지 기술을 보여준다.
도 6a는 테스트 파이프라인의 개략적인 블록 다이어그램을 보여준다.
도 6b는 테스트 파이프라인의 가능한 구현에 대한 자세한 내용을 보여준다.
도 7a는 테스트 오라클 내에서 평가된 규칙 트리의 예를 보여준다.
도 7b는 규칙 트리 노드의 출력 예를 보여준다.
도 8a는 테스트 오라클 내에서 평가되는 규칙 트리의 예를 보여준다.
도 8b는 시나리오 그라운드 트루 데이터 세트에 대해 평가된 규칙 트리의 제 2 예를 보여준다.
도 8c는 테스트 오라클 내에서 규칙이 선택적으로 적용될 수 있는 방법을 보여준다.
도 9a는 그래픽 사용자 인터페이스를 렌더링하기 위한 시각화 컴포넌트의 개략적인 블록도를 보여준다.
도 9b, 9c 및 9d는 그래픽 사용자 인터페이스 내에서 이용가능한 다양한 뷰를 보여준다.
도 10a는 컷인 시나리오의 제 1 인스턴스를 보여준다.
도 10b는 제 1 시나리오 인스턴스에 대한 오라클 출력의 예를 보여준다.
도 10c는 컷인 시나리오의 제 2 인스턴스를 보여준다.
도 10d는 제 2 시나리오 인스턴스에 대한 오라클 출력의 예를 보여준다.
도 11은 인식 에러를 평가하기 위한 아키텍처의 예를 보여준다.
도 12a는 분류 도구에 대한 예시적인 그래픽 사용자 인터페이스를 보여준다.
도 12b는 그래픽 사용자 인터페이스에 표시된 센서 데이터를 포함하는 운전 시나리오의 개략도를 보여준다.
도 12c는 확대/축소 기능과 타임라인 스크러버를 갖춘 사용자 인터페이스의 예를 보여준다.
도 12d는 사용자 인터페이스에서 시나리오의 하위 섹션을 선택하는 것을 보여준다.
도 13은 인식 규칙을 보여주는 그래픽 사용자 인터페이스의 집중된 보기를 보여준다.
도 14는 인식 에러 프레임워크 내의 예제 규칙 정의를 보여준다.
도 15는 정의된 에러 임계값을 사용한 인식 에러에 대한 수치 점수의 예시 그래프를 보여준다.
도 16은 단일 인식 에러 사양이 실제 및 시뮬레이션 주행 시나리오에 어떻게 적용될 수 있는지 보여준다.
도 17은 정의된 인식 에러 사양이 인식 테스트 및 스택 계획에 어떻게 사용될 수 있는지 보여준다.
도 18a 및 18b는 시나리오의 관련 에러를 식별하기 위해 적용되는 필터링 도구를 보여준다.
도 19a는 에러 임계값이 그래픽 사용자 인터페이스를 통해 어떻게 조정될 수 있는지 보여준다.
도 19b는 운전 시나리오의 '슬라이스' 선택 및 분석을 보여준다.
도 11은 "인식 오라클(perception oracle)"(1108)이 여러 소스들(실제 및/또는 시뮬레이션)로부터 인식 에러 데이터를 수신하고 그리고 해당 데이터를 사용하여 "인식 분류(perception triage)" 그래픽 사용자 인터페이스(GUI)(500)를 채우는 예시적인 아키텍처를 보여준다.
테스트 오라클(252)은 운전 성능을 평가하고, GUI(500)의 특정 구현예는 각각의 타임라인에 대한 인식 정보와 함께 운전 성능 평가를 허용한다.
특정 인식 에러는 실제 또는 시뮬레이션 실행의 그라운드 트루 트레이스(ground truth traces)에서 파생될 수 있으며, 이러한 동일한 그라운드 트루 트레이스는 테스트 오라클에 의해 이용되어 운전 성능을 평가한다.
테스트 오라클(252)과 인식 오라클(1108)은 GUI(500) 상에서 타임라인들을 채우기 위해 구성가능한 규칙 기반 로직을 각각 적용하는 한 서로를 미러링한다. 전자는 실행(run)(또는 실행들: runs) 동안 운전 성능을 평가하기 위해(의사: pseudo-) 그라운드 트루 트레이스에 계층적 규칙 트리를 적용하는 반면에, 후자는 유사한 논리를 적용하여 핵심 인식 에러(salient perception errors)를 식별한다. 렌더링 컴포넌트(1120)는 디스플레이(들) 상에 GUI를 렌더링하기 위한 렌더링 데이터를 생성한다. 본 명세서에 참조로서 포함되고 본 출원인에 의해 출원된 국제출원 PCT/EP2022/053406 및 PCT/EP2022/053413는 테스트 오라클의 코딩 규칙을 위한 도메인 특정 언어(DSL :Domain Specific Language)을 설명한다. 인식 오라클에서 핵심 인식 에러를 식별하기 위한 규칙을 인코딩하는 DSL의 확장이 아래에 설명되어 있다.
설명된 실시예는 실제 또는 시뮬레이션 시나리오에서 모바일 로봇 스택의 규칙 기반 테스트를 용이하게 하는 테스트 파이프라인을 제공하며, 이는 유연한 방식으로 인식 에러의 존재를 식별하고 전달하기 위한 추가 기능을 포함한다.
"전체(full)" 스택은 일반적으로 저레벨 센서 데이터(인식)의 프로세싱 및 해석부터 예측 및 계획과 같은 기본적인 고레벨 기능에 대한 공급은 물론, 계획-레벨 결정(예컨대, 제동, 조향, 가속 등 제어)을 구현하기 위해 적절한 제어 신호를 생성하는 제어 로직까지 모든 것을 포함한다. 자율주행 차량의 경우, 레벨 3 스택운 전환 요구를 구현하기 위한 일부 로직을 포함하며, 레벨 4 스택은 최소 위험 기동을 구현하기 위한 일부 로직을 추가로 포함한다. 스택은 시그널링, 헤드라이트, 앞유리 와이퍼 등과 같은 보조 제어 기능을 구현할 수도 있다.
또한, "스택"이라는 용어는 인식, 예측, 계획 또는 제어 스택과 같은 전체 스택의 개별 서브-시스템(서브-스택)을 지칭할 수도 있으며, 이는 개별적으로 또는 원하는 조합으로 테스트될 수 있다. 또한, 스택은 순전히 소프트웨어, 즉 하나 이상의 범용 컴퓨터 프로세서에서 실행될 수 있는 하나 이상의 컴퓨터 프로그램을 의미할 수도 있다.
아래에 설명된 테스트 프레임워크는 실제 데이터로부터 시나리오 실제 데이터를 생성하기 위한 파이프라인을 제공한다. 이러한 그라운드 트루는 생성된 그라운드 트루를 테스트 중인 인식 스택의 인식 출력과 비교하고, 뿐만 아니라 운전 규칙에 대하여 운전 행동을 평가함으로써 인식 테스트의 기초로 사용될 수 있다.
실제 또는 시뮬레이션 시나리오에서의 에이전트(액터) 거동은 정의된 성능 평가 규칙에 기초하여 테스트 오라클에 의해 평가된다. 이러한 규칙은 안전의 다양한 측면들을 평가할 수 있다. 예를 들어, 특정한 안전 표준, 규정 또는 안전 모델(예컨대, RSS)에 대해 스택의 성능을 평가하기 위해 안전 규칙 세트가 정의될 수 있으며, 또는 성능의 임의의 측면들을 테스트하기 위해 맞춤형(bespoke) 규칙 세트가 정의될 수도 있다. 테스트 파이프라인은 안전에 대한 적용에 국한되지 않으며, 편안함이나 또는 정의된 목표를 향하는 진행 상황과 같은 성능의 모든 측면을 테스트하는데 사용될 수 있다. 규칙 편집기(rule editor)를 사용하면 성능 평가 규칙을 정의하거나 수정하고 테스트 오라클에 전달할 수 있다.
마찬가지로, 차량 인식(vehicle perception)은 정의된 인식 규칙에 기초하여 '인식 오라클'에 의해 평가될 수 있다. 이는 인식 에러를 정의하기 위한 표준 포맷을 제공하는 인식 에러 사양(perception error specification) 내에서 정의될 수 있다.
도 1은 인식 에러 프레임워크에 대한 가능한 사용 사례들의 세트를 도시한다. 인식 에러 프레임워크에서 규칙을 정의하면, 실제 운전 시나리오의 관심 영역들이 사용자에게 하이라이트될 수 있는바(1602), 예를 들어, 사용자 인터페이스에 제시된 시나리오의 재생에서 이러한 영역들에 플래그를 지정함으로써 하이라이트될 수 있다. 이를 통해 사용자는 인식 스택에서 명백한 에러를 리뷰하고, 오리지널 센서 데이터의 폐색(occlusion)과 같은 에러의 가능한 원인을 식별할 수 있다. 이러한 방식으로 인식 에러를 평가하면, AV 스택(1604)의 인식 컴포넌트 및 계획 컴포넌트 사이에서 '계약'이 정의될 수 있으며, 여기서 인식 성능에 대한 요건들이 지정될 수 있고 그리고 스택이 인식 성능에 대한 이러한 요건들을 충족하는 경우 안전하게 계획을 세울 수 있다고 약속한다. 통합 프레임워크는 실제 운전 시나리오로부터 실제 인식 에러를 평가하는데 사용될 수 있으며, 뿐만 아니라 인식 에러 모델을 사용하여 직접 시뮬레이션되거나 또는 시뮬레이션된 센서 데이터에 인식 스택을 적용하여 계산된(예를 들어, 카메라 이미지에 대한 실사적(photorealistic) 시뮬레이션) 시뮬레이션된 에러(1606)를 평가하는데 사용될 수 있다.
파이프라인에 의해 결정된 그라운드 트루는 동일한 인식 에러 사양(1608) 내에서 자체적으로 평가될 수 있는바, 시나리오를 수동으로 리뷰하고 주석을 달아 결정된 '진정한(true)' 그라운드 트루와 상기 파이프라인에 의해 결정된 그라운드 트루를 정의된 규칙에 따라 비교함으로써 평가될 수 있다. 마지막으로, 인식 에러 테스트 프레임워크를 적용한 결과는 스택의 인식 및 예측 서브시스템들 둘다를 테스트하기 위한 테스트 전략을 유도하는데 사용될 수 있다(1610).
실제이든 시뮬레이션되었든, 시나리오에서는 실제 또는 모델링된 물리적 컨텍스트를 탐색하기 위해 에고 에이전트가 필요하다. 에고 에이전트는 테스트 중인 스택의 제어 하에 움직이는 실제 또는 시뮬레이션된 모바일 로봇이다. 물리적 컨텍스트는 테스트 중인 스택이 효과적으로 응답하는데 필요한 정적 및/또는 동적 요소를 포함한다. 예를 들어, 모바일 로봇은 스택(에고 차량)의 제어를 받는 완전 자율 또는 반자율 차량일 수 있다. 물리적 컨텍스트는 정적 도로 레이아웃과 시나리오가 진행됨에 따라 유지되거나 변경될 수 있는 소정의 환경 조건(예: 날씨, 시간, 조명 조건, 습도, 오염/미립자 수준 등)의 세트를 포함할 수 있다. 대화형 시나리오는 하나 이상의 다른 에이전트들(예컨대, 다른 차량들, 보행자들, 자전거 타는 사람, 동물 등의 "외부" 에이전트)을 추가로 포함한다.
다음의 일례에서는 자율주행 차량 테스트에 대한 적용을 고려한다. 그러나 본 발명의 원리들은 다른 형태의 모바일 로봇에도 동일하게 적용된다.
시나리오는 다양한 추상화(abstraction) 레벨들에서 표현되거나 정의될 수 있다. 보다 추상화된 시나리오는 더 큰 수준의 변형을 수용한다. 예를 들어, "컷인(cut-in: 이하, 컷인 또는 끼어들기라 함) 시나리오" 또는 "차선 변경 시나리오"는 수많은 변형들(예컨대, 다양한 에이전트 시작 위치들 및 속도들, 도로 레이아웃, 환경적 조건들 기타 등등)을 수용하는 관심 기동(maneuver) 혹은 거동(behaviour)에 의해 특징지워지는 고도로 추상화된 시나리오의 일례이다. "시나리오 실행(run)"은 선택적으로는 하나 이상의 다른 에이전트들의 존재와 함께, 물리적 컨텍스트를 탐색하는 에이전트(들)의 구체적인 발생을 의미한다. 예를 들어, 컷인 또는 차선 변경 시나리오에 대한 다수의 실행들은, 다양한 에이전트 파라미터들(예컨대, 시작 위치, 속도 등), 다양한 도로 레이아웃들, 다양한 환경적 조건들 및/또는 다양한 스택 구성 등을 사용하여 수행될 수 있다(실제로 및/또는 시뮬레이터에서). 본 명세서에서 "실행(run)"과 "인스턴스(instance)"라는 용어는 호환가능한 의미로 사용된다.
다음의 일례에서, 스택의 성능은, 하나 이상의 실행 과정들에서 소정의 성능 평가 규칙들의 세트에 대해 테스트 오라클 내에서 에고 에이전트의 거동을 평가함으로써 적어도 부분적으로 평가된다. 규칙들은 시나리오 실행의 "그라운드 트루"에 적용되며, 이는 일반적으로, 테스트 목적으로 신뢰할 수 있는 것으로 간주되는 시나리오 실행(에고 에이전트의 거동을 포함)의 적절한 표현을 의미한다. 그라운드 트루(ground truth)는 시뮬레이션에 내재되어 있다: 시뮬레이터는 시나리오 상태들의 시퀀스를 계산하며, 이는 정의에 따라 시뮬레이션된 시나리오 실행에 대한 완벽하고 신뢰되는 표현이다. 실제 시나리오 실행에서, 시나리오 실행의 "완벽한(perfect)" 표현은 같은 의미로 존재하지 않는다. 그럼에도 불구하고, 온보드 센서 데이터의 수동 주석, 이러한 데이터의 자동/반자동 주석(예: 오프라인/비실시간 프로세싱을 이용하여), 및/또는 외부 정보 소스(외부 센서, 지도 등)을 이용함에 기초하여, 적절하게 유익한 그라운드 트루가 다양한 방식으로 획득될 수 있다.
시나리오 그라운드 트루는 일반적으로 에고 에이전트 및 적용가능한 임의의 다른 (현저한) 에이전트의 "트레이스(trace)"를 포함한다. 트레이스는 시나리오가 진행되는 동안 에이전트의 위치와 모션에 대한 히스토리이다. 트레이스를 표현하는 방법에는 여러 가지가 있다. 트레이스 데이터는 일반적으로 환경 내 에이전트의 공간 및 모션 데이터를 포함한다. 이러한 용어는 실제 시나리오(실제 트레이스 포함) 및 시뮬레이션 시나리오(시뮬레이션 트레이스 포함)와 관련하여 사용된다. 트레이스는 일반적으로 시나리오에서 에이전트에 의해 실현된 실제 궤적을 기록한다. 용어와 관련하여 "트레이스(trace)"과 "궤적(trajectory)"은 동일하거나 유사한 유형의 정보(예컨대, 시간에 따른 일련의 공간 및 동작 상태)를 포함할 수 있다. 궤적이라는 용어는 일반적으로 계획(planning)의 맥락에서 선호되는 반면에(미래/예측 궤적을 나타낼 수 있음), 트레이스이라는 용어는 일반적으로 테스트/평가의 맥락에서 과거의 거동과 관련하여 선호된다.
시뮬레이션 컨텍스트에서는 "시나리오 설명(scenario description)"이 시뮬레이터에 입력으로 제공된다. 예를 들어, 시나리오 설명은 SDL(시나리오 설명 언어)을 사용하여 인코딩되거나 또는 시뮬레이터에서 사용할 수 있는 임의의 다른 형태로 인코딩될 수 있다. 시나리오 설명은 일반적으로 여러 시뮬레이션 실행들이 발생할 수 있는 시나리오를 보다 추상적으로 표현한 것이다. 구현예에 따라, 시나리오 설명에는 가능한 변형의 정도를 증가시키기 위해 변경될 수 있는 하나 이상의 구성가능한 파라미터가 있을 수 있다. 추상화 및 파라미터화의 정도는 설계적인 선택이다. 예를 들어, 시나리오 설명은 파라미터화된 환경 조건(예: 날씨, 조명 등)을 사용하여 고정 레이아웃을 인코딩할 수 있다. 하지만, 구성가능한 도로 파라미터(예: 도로 곡률, 차선 구성 등)를 사용하여 추가적인 추상화가 가능하다. 시뮬레이터에 대한 입력은 파라미터 값들의 선택된 세트(적용가능한 경우)와 함께 시나리오 설명을 포함한다. 파라미터 값들의 선택된 세트는 시나리오의 파라미터화라고 지칭될 수 있다. 구성가능한 파라미터(들)은 파라미터 공간(시나리오 공간이라고도 함)을 정의하고 그리고 파라미터화는 파라미터 공간의 포인트에 해당한다. 이러한 맥락에서 "시나리오 인스턴스"는 시나리오 설명 및 (적용가능한 경우) 선택된 파라미터화에 기초하여 시뮬레이터에서 시나리오의 인스턴스화를 의미할 수 있다.
간결성을 위해 시나리오라는 용어는 시나리오 실행을 지칭하는데 사용될 수도 있을 뿐만 아니라, 보다 추상적인 의미의 시나리오를 지칭할 수도 있다. 시나리오라는 용어의 의미는 그것이 사용되는 맥락에서 명확해질 것이다.
궤적 플래닝(trajectory planning)은 현재 맥락에서 중요한 기능이며, "궤적 플래너", "궤적 플래닝 시스템" 및 "궤적 플래닝 스택"이라는 용어는 미래에 모바일 로봇에 대한 궤적을 계획할 수 있는 컴포넌트 또는 컴포넌트들을 지칭하기 위해 본 명세서에서 상호교환적으로 사용될 수 있다. 궤적 플래닝 결정은 에고 에이전트에 의해 실현된 실제 궤적를 궁극적으로 결정한다(비록, 일부 테스트 상황에서는 제어 스택에서 해당 결정의 구현 및 결과적인 제어 신호에 대한 에고 에이전트의 실제 또는 모델링된 동적 응답과 같은 다른 요인들의 영향을 받을 수 있음).
궤적 플래너는 단독으로 테스트되거나 하나 이상의 다른 시스템(예컨대, 인식, 예측 및/또는 제어)과 결합하여 테스트될 수 있다. 전체(full) 스택 내에서, 플래닝은 일반적으로 더 높은 레벨의 자율적 의사 결정 능력(가령, 궤적 플래닝)을 의미하는 반면, 제어는 일반적으로 이러한 자율적 결정을 수행하기 위한 저레벨의 제어 신호 생성을 의미한다. 그러나 성능 테스트의 맥락에서, 제어라는 용어는 더 넓은 의미로도 사용된다. 의심을 피하기 위해, 궤적 플래너가 시뮬레이션에서 에고 에이전트를 제어한다고 지칭되는 경우, 이는 반드시 제어 시스템(좁은 의미에서)이 궤적 플래너와 결합하여 테스트된다는 것을 의미하지는 않는다.
예시적인 AV 스택:
설명된 실시예에 관련 컨텍스트를 제공하기 위해, AV 스택의 예시적인 형태의 추가 세부사항이 이제 설명될 것이다.
도 2A는 AV 런타임 스택(100)의 개략적인 블록도를 도시한다. 런타임 스택(100)은 인식 (서브)시스템(102), 예측 (서브)시스템(104), 플래닝 (서브)시스템(플래너)(106) 및 제어 (서브)시스템(컨트롤러)(108)을 포함하는 것으로 도시된다. 언급한 바와 같이, (서브)스택이라는 용어는 전술한 컴포넌트(102-108)를 설명하는데 사용될 수도 있다.
실제 상황에서, 인식 시스템(102)은 AV의 온보드 센서 시스템(110)으로부터 센서 출력을 수신하고, 그리고 이러한 센서 출력을 사용하여 외부 에이전트를 감지하고 위치, 속도, 가속도 등과 같은 외부 에이전트의 물리적 상태를 측정한다. 온보드 센서 시스템(110)은 다양한 형태를 취할 수도 있지만, 일반적으로는 이미지 캡처 디바이스(카메라/광 센서), 라이다(LiDAR) 및/또는 레이더 유닛, 위성 위치확인 센서(GPS), 모션/관성 센서(가속도계, 자이로스코프 등) 등과 같은 다양한 센서를 포함한다. 따라서, 온보드 센서 시스템(110)은 풍부한 센서 데이터를 제공하며, 이로부터 주변 환경, 및 AV 상태, 및 해당 환경 내의 모든 외부 액터(차량, 보행자, 자전거 타는 사람 등)에 대한 자세한 정보를 추출할 수 있다. 일반적으로, 센서 출력은 하나 이상의 스테레오 광학 센서, 라이다(LiDAR), 레이더 등으로부터 스테레오 이미지와 같은 다양한 센서 양식의 센서 데이터로 구성된다. 다양한 센서 양식의 센서 데이터는 필터, 융합 컴포넌트 등을 사용하여 결합될 수 있다.
인식 시스템(102)은 일반적으로 다수의 인식 컴포넌트들을 포함하며, 이들은 함께 동작하여 센서 출력을 해석하고 그리고 예측 시스템(104)에 인식 출력을 제공할 수 있다.
시뮬레이션 상황에서, 테스트의 성격에 따라, 그리고 특히 테스트 목적으로 스택(100)이 "슬라이스되는" 경우(아래 참조)에 따라, 온보드 센서 시스템(100)을 모델링하는 것이 필요할 수도 있고 필요하지 않을 수도 있다. 고레벨 슬라이싱을 사용하면 시뮬레이션된 센서 데이터가 필요하지 않으므로 복잡한 센서 모델링이 불필요하다.
인식 시스템(102)으로부터의 인식 출력은 예측 시스템(104)에 의해 사용되어, 가령 AV 근처의 다른 차량과 같은 외부 액터(에이전트)의 미래 거동을 예측할 수 있다.
예측 시스템(104)에 의해 계산된 예측들은 플래너(106)에 제공되며, 플래너(106)는 주어진 운전 시나리오에서 AV에 의해 실행될 자율주행 운전 결정을 내리기 위해 상기 예측을 이용한다. 플래너(106)에 의해 수신된 입력은 일반적으로 운전가능 영역을 나타낼 것이며 그리고 운전가능 영역 내의 임의의 외부 에이전트(AV의 관점에서 볼 때 장애물)의 예측된 움직임을 캡처한다. 운전가능 영역은 HD(고화질) 지도와 같은 지도 정보와 결합하여 인식 시스템(102)으로부터의 인식 출력을 사용하여 결정될 수 있다.
플래너(106)의 핵심 기능은 예측된 에이전트 모션을 고려하여 AV(에고 궤적)에 대한 궤적들을 계획하는 것이다. 이는 궤적 플래닝이라 지칭될 수 있다. 시나리오 내에서 원하는 목표를 수행하기 위해 궤적이 계획된다. 예를 들어, 목표는 로터리로 진입하여 원하는 출구로 나가는 것; 앞의 차량을 추월하는 것; 또는 목표 속도에서 현재 차선을 유지하는 것(차선 추종)일 수 있다. 목표는 예를 들어, 자율 경로 플래너(미도시)에 의해 결정될 수 있다.
컨트롤러(108)는 적절한 제어 신호를 AV의 온보드 액터 시스템(112)에 제공함으로써 플래너(106)에 의해 취해진 결정을 실행한다. 특히, 플래너(106)는 AV에 대한 궤적들을 계획하고, 컨트롤러(108)는 계획된 궤적을 구현하기 위한 제어 신호를 생성한다. 전형적으로, 플래너(106)는 새로운 궤적이 플래너(106)에 의해 계획되기 전에, 계획된 궤적이 제어 레벨에서 부분적으로만 구현될 수 있도록 미래를 계획할 것이다. 액터 시스템(112)은 제동, 가속 및 조향 시스템, 보조 시스템(예컨대, 시그널링, 와이퍼, 헤드라이트 등)과 같은 "주요(primary)" 차량 시스템을 포함한다.
주어진 시간 순간에 계획된 궤적과 에고 에이전트가 따르는 실제 궤적 사이에는 차이가 있을 수 있다. 플래닝 시스템은 일반적으로 일련의 계획('플래닝' 또는 '계획' 이라함) 단계에 걸쳐 작동하며, 이전 계획 단계 이후의 시나리오 변경 사항(또는 더 정확하게는 예측된 변경 사항에서 벗어나는 모든 변경 사항)을 설명하기 위해 각각의 계획 단계에서 계획된 궤적을 업데이트한다. 플래닝 시스템(106)은 각 계획 단계에서 계획된 궤적이 다음 계획 단계를 넘어 확장되도록 미래를 추론할 수 있다. 따라서, 임의의 개별적으로 계획된 궤적은 완전히 실현되지 않을 수 있다(플래닝 시스템(106)이 격리되어, 시뮬레이션에서 테스트되는 경우, 에고 에이전트는 다음 계획 단계까지 정확히 계획된 궤적을 따를 수 있다. 하지만, 언급한 바와 같이, 다른 실제 및 시뮬레이션 상황에서, 계획된 궤적은 다음 계획 단계까지 정확하게 따르지 않을 수 있다. 왜냐하면 에고 에이전트의 행동은 제어 시스템(108)의 동작 및 에고 차량의 실제 또는 모델링된 역학과 같은 다른 요인에 의해 영향을 받을 수 있기 때문이다). 많은 테스트 콘텍스트에서, 궁극적으로 중요한 것은 에고 에이전트의 실제 궤적이며, 특히 실제 궤적가 안전한지 여부는 물론 편안함과 진행 상황과 같은 기타 요소도 포함된다. 하지만, 본 명세서의 규칙-기반 테스트 접근법은 계획된 궤적에도 적용될 수 있다(계획된 궤적이 에고 에이전트에 의해 완전히 또는 정확하게 실현되지 않더라도). 예를 들어, 에이전트의 실제 궤적이 주어진 안전 규칙들의 세트에 따라 안전한 것으로 간주되더라도, 순간적인 계획된 궤적은 안전하지 않을 수 있다. 플래너(106)가 안전하지 않은 액션 과정을 고려하고 있었다는 사실은 그것이 시나리오에서 안전하지 않은 에이전트 거동으로 이어지지 않았더라도 드러날 수 있다. 순간적인 계획된 궤적은 시뮬레이션의 실제 에이전트 동작 외에도 유용하게 평가될 수 있는 내부 상태의 하나의 형태를 구성한다. 내부 스택 상태의 다른 형태도 유사하게 평가될 수 있다.
도 2a의 일례는 분리가능한 인식, 예측, 플래닝 및 제어 시스템(102-108)을 구비한 상대적으로 "모듈형" 아키텍처를 고려한다. 서브-스택 자체는 예를 들어 플래닝 시스템(106) 내의 분리가능한 플래닝 모듈들을 갖춘 모듈형일 수도 있다. 예를 들어, 플래닝 시스템(106)은 다양한 물리적 상황들(예컨대, 단순한 차선 운전 vs 복잡한 교차로 또는 로터리)에 적용될 수 있는 다수의 궤적 플래닝 모듈들을 포함할 수 있다. 이것은 컴포넌트들(예컨대, 플래닝 시스템(106) 또는 이들의 개별 플래닝 모듈들)이 개별적으로 또는 다른 조합으로 테스트될 수 있도록 하기 때문에 위에서 언급한 이유로 시뮬레이션 테스트와 관련된다. 의심의 여지를 없애기 위해, 모듈형 스택 아키텍처에서, 스택이라는 용어는 전체 스택뿐만 아니라 개별 서브-시스템이나 모듈을 나타낼 수도 있다.
다양한 스택 기능들이 통합되거나 분리가능한 정도는 서로 다른 스택 구현예들에 따라 크게 다를 수 있다. 일부 스택에서, 일부 양상들은 구별될 수 없을 정도로 긴밀하게 결합될 수 있다. 예를 들어, 일부 다른 스택들에서는, 플래닝 및 제어가 통합될 수 있지만(예: 이러한 스택은 제어 신호 측면에서 직접 계획할 수 있음), 다른 스택들(예: 도 2a에 설명된 것과 같은)은 둘 사이에서 명확한 구분을 두는 방식으로 설계될 수 있다(예컨대, 궤적 측면에서의 플래닝 및 제어 신호 레벨에서 계획된 궤적을 가장 잘 실행하는 방법을 결정하기 위한 별도의 제어 최적화). 마찬가지로, 일부 스택에서는, 예측과 플래닝이 더 긴밀하게 결합될 수 있다. 극단적으로, 소위 "엔드 투 엔드(end-to-end)" 운전에서는, 인식, 예측, 플래닝 및 제어가 본질적으로 분리될 수 없다. 달리 명시하지 않는 한, 여기에 사용된 인식, 예측 플래닝 및 제어 용어는 해당 양상들의 특정한 결합 또는 모듈성을 의미하지 않는다.
"스택"이라는 용어는 소프트웨어를 포괄하지만 하드웨어도 포괄할 수 있다는 것이 이해될 것이다. 시뮬레이션에서, 스택의 소프트웨어는 물리적 차량의 온보드 컴퓨터 시스템에 최종적으로 업로드되기 전에 "일반" 오프-보드 컴퓨터 시스템에서 테스트될 수 있다. 그러나 "하드웨어-인-더-루프(hardware-in-the-loop)" 테스트에서, 테스트는 차량 자체의 기본 하드웨어까지 확장될 수 있다. 예를 들어, 스택 소프트웨어는 테스트 목적으로 시뮬레이터에 연결된 온보드 컴퓨터 시스템(또는 그 복제품)에서 실행될 수 있다. 이러한 맥락에서, 테스트 중인 스택은 차량의 기본 컴퓨터 하드웨어로 확장된다. 다른 일례로서, 스택(110)의 특정 기능들(예를 들어, 인식 기능)은 전용 하드웨어에서 구현될 수 있다. 시뮬레이션 맥락에서, 하드웨어-인-더-루프(Hardware-in-The Loop) 테스트는 합성 센서 데이터를 전용 하드웨어 인식 컴포넌트에 공급하는 것을 포함할 수 있다.
예시적인 테스트 패러다임:
도 2b는 자율주행 차량에 대한 테스트 패러다임의 개략적인 개요를 보여준다. 예를 들어, 도 2a에 도시된 종류의 ADS/ADAS 스택(100)은 시뮬레이터(202)에서 다수의 시나리오 인스턴스들을 실행하고 그리고 테스트 오라클(252)에서 스택(100)(및/또는 이들의 개별 서브-스택들)의 성능을 평가함으로써, 시뮬레이션에서 반복적인 테스트 및 평가를 받게 된다. 테스트 오라클(252)의 출력은 전문가(122)(팀 또는 개인)에게 정보를 제공할 수 있으며, 이를 토대로 전문가는 스택(100)의 문제를 식별하고 해당 문제를 완화하기 위해 스택(100)을 수정할 수 있다(S124). 상기 결과들은 또한 전문가(122)가 테스트를 위한 추가 시나리오를 선택하는데 도움을 줄 수 있으며(S126), 프로세스는 시뮬레이션에서 스택(100)의 성능을 반복적으로 수정, 테스트 및 평가하는 것을 지속한다. 개선된 스택(100)은 결국 센서 시스템(110) 및 액터 시스템(112)을 갖춘 실제 AV(101)에 통합된다(S125). 개선된 스택(100)은 일반적으로 차량(101)(미도시)의 온보드 컴퓨터 시스템의 하나 이상의 컴퓨터 프로세서에서 실행되는 프로그램 명령(소프트웨어)을 포함한다. 개선된 스택의 소프트웨어는 S125 단계에서 AV(101)에 업로드된다. 단계 S125는 기본 차량 하드웨어에 대한 수정을 포함할 수도 있다. AV(101)에 탑재된 개선된 스택(100)은 센서 시스템(110)으로부터 센서 데이터를 수신하고 액터 시스템(112)에 제어 신호를 출력한다. 실제 테스트(S128)는 시뮬레이션 기반 테스트와 결합하여 사용될 수 있다. 예를 들어, 시뮬레이션 테스트 및 스택 정제 프로세스를 통해 허용가능한 수준의 성능에 도달하면, 적절한 실제 시나리오가 선택될 수 있으며(S130), 이러한 실제 시나리오에서 AV(101)의 성능은 캡처될 수 있으며 테스트 오라클(252)에서 유사하게 평가될 수 있다.
시뮬레이션을 위한 시나리오는 수동 인코딩을 포함하여 다양한 방법으로 획득될 수 있다. 시스템은 또한 실제 실행으로부터 시뮬레이션 목적으로 시나리오를 추출할 수 있으므로, 실제 상황과 그 변형이 시뮬레이터(202)에서 재현될 수 있다.
도 2c는 시나리오 추출 파이프라인의 매우 개략적인 블록도를 보여준다. 실제 실행의 데이터(140)는 시나리오 그라운드 트루를 생성할 목적으로 '그라운드 트루' 파이프라인(142)으로 전달된다. 실행 데이터(run data)(140)는 예를 들어, 하나 이상의 차량들(자율주행, 인간 구동 또는 이들의 조합일 수 있음)의 온 보드에서 캡처/생성된 센서 데이터 및/또는 인식 출력들 및/또는 외부 센서(CCTV 등)와 같은 다른 소스들로부터 캡처된 데이터를 포함할 수 있다. 실행 데이터는 실제 실행(real-world run)에 대한 적절한 그라운드 트루(144)(트레이스(들) 및 컨텍스트 데이터)을 생성하기 위해, 그라운드 트루(ground truthing) 파이프라인(142) 내에서 프로세싱된다. 전술한 바와 같이, 그라운드 트루 프로세스는 '원시(raw)' 실행 데이터(140)에 대한 수동 주석에 기초할 수 있으며, 또는 프로세스가 완전히 자동화되거나(예를 들어, 오프라인 인식 방법(들)을 사용하여), 또는 수동 및 자동 그라운드 트루의 조합이 사용될 수 있다. 예를 들어, 3D 경계 상자들이 실행 데이터(140)에 캡처된 차량들 및/또는 다른 에이전트 주위에 배치될 수 있는바, 이는 이들의 트레이스들의 공간적 및 모션 상태를 결정하기 위한 것이다. 시나리오 추출 컴포넌트(146)는 시나리오 그라운드 트루(144)를 수신하고, 그리고 시나리오 그라운드 트루(144)를 프로세싱하여 시뮬레이션 목적으로 사용될 수 있는 보다 추상화된 시나리오 설명(148)을 추출한다. 시나리오 설명(148)은 시뮬레이터(202)에 의해 소비되어 다수의 시뮬레이션 실행들이 수행될 수 있게 한다. 시뮬레이션된 실행들은 오리지널 실제 실행의 변형이며, 가능한 변형의 정도는 추상화 정도에 따라 결정된다. 그라운드 트루(150)는 각 시뮬레이션 실행에 대해 제공된다.
실제 시나리오 그라운드 트루(144) 및 시뮬레이션된 그라운드 트루(150)는 인식 스택을 평가하기 위해 인식 분류 도구(152)에 의해 프로세싱될 수 있으며, 및/또는 그라운드 트루(144) 및 시뮬레이터 그라운드 트루(150)에 기초하여 스택을 평가하기 위해 테스트 오라클(252)에 의해 프로세싱될 수 있다.
현재의 오프-보드 콘텐츠에서는, 트레이스들을 실시간으로 추출할 필요가 없으며(또는 더 정확하게는 실시간 플래닝을 지원하는 방식으로 트레이스들을 추출할 필요가 없다), 오히려 트레이스들은 "오프라인"으로 추출된다. 오프라인 인식 알고리즘의 일례들은 비실시간 및 비인과적 인식 알고리즘을 포함한다. 오프라인 기술들은 "온라인" 기술과 대조되며, "온라인" 기술은 실시간 플래닝/의사 결정을 용이하게 하기 위해 AV 스택(100) 내에서 실행 가능하게 구현될 수 있다.
예를 들어, 비실시간 프로세싱을 사용하는 것이 가능하며, 이는 AV 온보드 컴퓨터 시스템의 하드웨어나 기타 실제적인 제약으로 인해 온라인으로 수행될 수 없다. 예를 들어, 하나 이상의 비실시간 인식 알고리즘이 실제 실행 데이터(140)에 적용되어 트레이스들을 추출할 수 있다. 비실시간 인식 알고리즘은 필요한 계산이나 메모리 리소스로 인해 실시간으로 실행될 수 없는 알고리즘일 수 있다.
이러한 맥락에서 "비인과적(non-casual)" 인식 알고리즘을 사용하는 것도 가능하다. 비인과적 알고리즘은 실행 시점에서 실시간으로 실행될 수도 있고 실행되지 않을 수도 있지만, 미래에 대한 지식이 필요하기 때문에 어떠한 경우에도 온라인 컨텍스트에서 구현될 수 없다. 예를 들어, 후속 데이터에 기초하여 특정 시점의 에이전트 상태(예: 위치, 자세, 속도 등)를 감지하는 인식 알고리즘은 온라인 콘텍스트에서 스택(100) 내의 실시간 플래닝을 지원할 수 없는데, 왜냐하면, 미래에 대한 지식이 필요하기 때문이다(그렇지 않다면 짧은 룩 어헤드 윈도우로 작동하도록 제한된다). 예를 들어, 역방향 전달(backward pass)을 사용한 필터링은 때때로 실시간으로 실행될 수 있는 비인과적 알고리즘이지만 미래에 대한 지식이 필요하다.
'인식(perception)'이라는 용어는 일반적으로 2D 또는 3D 경계 상자 검출, 위치 검출, 자세 검출, 모션 검출 등과 같이 현실 세계 데이터(140)의 구조를 인지하는 기술을 의미한다. 예를 들어, 트레이스는 관련 모션 정보(예컨대, 속도, 가속도, 저크 등)와 함께, 3D 공간 또는 2D 공간(예: 조감도 참조 프레임)에서의 시계열적 경계 상자들 또는 기타 공간 상태들로서 추출될 수 있다.
그라운드 트루 파이프라인
자율주행 차량 스택의 실제 성능을 테스트할 때 문제는 자율주행 차량이 방대한 분량의 데이터를 생성한다는 것이다. 이러한 데이터는 나중에 실제 세계에서 AV의 성능을 분석하거나 평가하는데 사용될 수 있다. 하지만, 잠재적인 과제는 이러한 영상(footage)에서 관련 데이터를 찾아내고 그리고 주행 중 어떤 흥미로운 이벤트가 발생했는지를 파악하는 것이다. 한 가지 옵션은 상기 데이터를 수동으로 파싱하고 그리고 사람이 주석을 첨부함으로써 흥미로운 이벤트를 식별하는 것이다. 하지만, 이것은 비용이 많이 들 수 있다.
도 3은 운전 중 실제 운전 데이터를 수동으로 태깅하는 일례를 보여준다. AV에는 카메라 등의 센서가 장착되어 있다. 영상은 예시 이미지(1202)에 도시된 바와 같이, 드라이브를 따라 카메라에 의해 수집된다. 자동차 도로(motorway)에서 인간 운전자에 의한 예시적인 드라이브에서, 운전자가 임의의 관심 사항을 주목하면(note), 운전자는 AV에 플래그를 제공하고 그리고 센서가 수집한 데이터 내의 프레임에 이를 태그할 수 있다. 이미지는 지도(1200) 상의 드라이브의 시각화를 보여주며, 여기서 버블들은 운전자가 무언가에 태그를 붙인 드라이브를 따라 있는 포인트들을 보여준다. 본 일례에서, 각각의 태그 포인트는 카메라 이미지의 프레임에 대응하며, 이는 드라이브 이후에 분석되는 데이터를 필터링하는데 사용되며, 따라서 태그가 지정된 프레임들만이 나중에 검사된다.
지도(1200)에 도시된 바와 같이, 태그된 프레임들 사이의 주행 경로에는 매우 큰 간격이 존재하며, 이러한 간격에서 수집된 데이터는 모두 태그되지 않으므로 이 데이터는 활용되지 않는다. 데이터를 필터링하기 위해 에고 차량 운전자의 수동 주석을 사용함으로써, 주행 데이터의 후속 분석은 인간 운전자 또는 테스트 엔지니어가 플래그를 지정할 만큼 충분히 중요하다고 판단하거나 충분한 시간을 가진 이벤트로만 제한된다. 하지만, 나머지 데이터를 통해 다른 시점들에서의 차량 성능에 대한 유용한 통찰력이 있을 수 있으며, 주행 성능을 보다 완전하게 프로세스 및 평가하는 자동 방법을 결정하는 것이 유용할 것이다. 또한, 동일한 분량의 데이터에 대해 수동 태깅보다 더 많은 문제들을 식별하면, 동일한 분량의 수집된 데이터에 대해 AV 시스템을 더 많이 개선할 수 있는 기회를 얻을 수 있다.
가능한 해결책은 동일한 메트릭을 이용하여 시나리오 시뮬레이션들과 실제 운전을 모두 평가하는 통합 분석 파이프라인을 만드는 것이다. 제 1 단계는 실제로 수집된 데이터에서 주행 트레이스들(driving traces)을 추출하는 것이다. 예를 들어, 에고 차량의 대략적인 위치와 다른 에이전트들의 대략적인 위치는 온보드 검출을 기반으로 추정될 수 있다. 하지만, 온보드 검출은 제한된 컴퓨팅 리소스 때문에 그리고 온보드 검출이 실시간으로 작동한다는 사실 때문에 불완전하다. 즉, 특정 검출을 알려주는 유일한 데이터는 센서가 그 시점까지 관찰한 것뿐임을 의미한다. 이는 검출에 잡음이 많고 부정확할 수 있음을 의미한다.
도 4a는 실제 데이터의 소정 세트에 대한 의사 그라운드 트루(144)을 결정하기 위해, 데이터 수집(ingestion) 파이프라인에서 데이터가 어떻게 프로세싱되고 정제되는지를 보여준다. 다음을 유의해야 하는바, 실제 데이터로부터는 '진정한(true)' 그라운드 트루가 추출될 수 없으며, 본 명세서에 설명된 그라운드 트루 파이프라인은 평가에 충분한 그라운드 트루의 추정치를 제공한다. 이러한 의사 그라운드 트루(144)는 또한 본 명세서에서 단순히 '그라운드 트루'로 지칭될 수도 있다.
데이터 수집 파이프라인(또는 '수집' 도구(ingest tool))은 주어진 스택 및 선택적으로는 수동 주석과 같은 다른 데이터 소스(1300)로부터 인식 데이터(140)를 취하고, 그리고 데이터를 정제하여 데이터에서 캡처된 실제 운전 시나리오에 대한 의사 그라운드 트루(144)를 추출한다. 도시된 바와 같이, 선택적으로는 오프라인 검출들 또는 수동 주석과 같은 추가 입력들과 함께, 차량들로부터의 센서 데이터 및 검출들이 수집된다. 이들을 프로세싱하여, 오프라인 검출기들(1302)를 원시 센서 데이터에 적용하거나 및/또는 차량의 온보드 인식 스택으로부터 수신된 검출들(1304)을 정제한다. 이후, 정제된 검출들은 시나리오에 대한 의사 그라운드 트루(144)로 출력된다. 그런 다음 이는 테스트 오라클(나중에 설명)에 의한 운전 규칙에 대한 그라운드 트루 평가, 의사 그라운드 트루와 차량 검출들을 비교하여 인식 에러들을 결정하는 것, 시뮬레이션을 위한 시나리오 추출 등을 포함하여 다양한 사용 사례의 기초로 사용될 수 있다. 예를 들어, 검출 또는 카메라 이미지 전체에 적용할 수 있는 인식 '경도' 스코어(perception 'hardness' score)(1306)를 포함하여 입력 데이터에 대한 다른 메트릭들이 계산될 수 있으며, 이는 올바르게 처리하기 위해서 소정 데이터가 인식 스택에 대해 얼마나 어려운지를 나타낸다.
도 4b는 정제(refinement) 전후의 경계 상자들의 예시적인 세트를 보여준다. 도 4b의 일례에서, 상단 이미지는 각각의 시간 단계에서 차량의 위치와 방향을 정의하는 3D 경계 상자들의 '정제되지 않은' 노이즈가 있는 세트를 보여주며, 여기서 이러한 경계 상자들은 추가된 노이즈가 있는 그라운드 트루를 나타낸다. 비록, 도시된 일례는 노이즈가 추가된 경계 상자에 적용되지만, 실제 운전 스택으로부터 차량 검출들을 정제하는데에도 동일한 효과가 달성된다. 도 4b에 도시된 바와 같이, 경계 상자에는 잡음이 있으며, 검출된 경계 상자들의 위치와 방향 둘다는 인식 에러로 인해 시간에 따라 달라진다.
정제 파이프라인은 다양한 방법을 사용하여 이러한 노이즈를 제거할 수 있다. 도 4b의 하단 궤적은 노이즈가 제거된 차량의 의사 그라운드 트루 트레이스(144)를 보여준다. 도시된 바와 같이, 차량의 방향과 위치는 프레임마다 일관되어 부드러운 주행 궤적을 형성한다. 이러한 평활화를 수행하기 위해 파이프라인에 의해 사용되는 여러가지 가능한 방법들은 자세히 설명되지 않을 것이다. 하지만, 파이프라인은 온라인 검출기들 보다 더 큰 컴퓨팅 파워를 활용하여 보다 정확한 검출기가 사용될 수 있게하며, 뿐만 아니라 과거 및 미래 검출들을 사용하여 궤적을 평활화하는 이점을 획득하는바 여기서, 자동차로부터 수집된 실제 검출들은 실시간으로 작동하며, 따라서 과거 데이터만을 기반으로 한다. 예를 들어, 객체가 시간 t에서 부분적으로 가려졌으나, 시간 t + n에서 자동차 센서에 의해 완전히 보여질 때, 오프라인 정제 파이프라인의 경우 시간 t + n에서의 검출들은 부분적으로 가려진 데이터에 기초하여 이전 검출들을 알리는데 사용될 수 있으며, 따라서 전체적으로 더 완벽한 검출이 가능하다.
다양한 유형의 오프라인 검출기들 또는 검출 정제 방법을 사용할 수 있다. 도 5a는 가능한 검출 정제 기술들의 테이블을 도시하며 도 5b는 향상된 검출들을 얻기 위해 센서 데이터에 적용될 수 있는 가능한 오프라인 검출기들의 테이블을 보여준다.
검출을 정제하기 위해 다양한 기술이 사용된다. 한 가지 예는 카메라 이미지에 적용되는 의미론적(semantic) 키포인트 검출이다. 정제 이후에, 상기 결과는 도 4b에 도시된 바와 같이 차량을 스무스하게 추적하는 올바른 크기의 직육면체를 이용한 안정적인 검출이다.
본 명세서에 참고로 포함된 국제 특허 공개 번호 WO2021/013792 가 참조된다. 전술한 참고문헌은 관심있는 각각의 에이전트에 대한 의사 그라운드 트루 트레이스를 추출하기 위해 그라운드 트루 파이프라인(400) 내에서 구현될 수 있는 오프라인 주석 방법의 클래스를 개시한다. 일련의 정제된 3D 경계 상자들(이 경우 에이전트 트레이스는 정제된 3D 상자들을 포함함)로 실제 실행(140)의 데이터에 주석을 달기 위해 자동화된 주석 기술을 적용하여 트레이스들이 추출된다.
이러한 방법은 광범위하게 다음과 같이 작동한다. 실제 실행 데이터(140)는 일련의 프레임들을 포함하며, 여기서 각각의 프레임은 3D 구조 포인트들의 세트(예를 들어, 포인트 클라우드)를 포함한다. 관심있는 각각의 에이전트(에고 에이전트 및/또는 다른 에이전트)는 여러 프레임들에 걸쳐서 객체로서 추적된다(에이전트는 전술한 참조문헌의 용어에서 '공통 구조 컴포넌트'이다).
본 맥락에서 "프레임"은 임의의 캡처된 3D 구조 표현을 의미한다. 즉, 3D 공간에서 구조를 정의하는 캡처된 포인트들(3D 구조 포인트들)을 포함하고 그리고 이는 해당 프레임에서 캡처된 3D 구조의 본질적으로 정적인 "스냅샷"을 제공한다(즉, 정적 3D 장면). 프레임은 단일 시점에 대응한다고 말할 수 있지만, 이것이 프레임 또는 프레임이 파생된 기본 센서 데이터가 순시적으로(instantaneously) 캡처되어야 함을 반드시 암시하는 것은 아니다. 예를 들어, 라이다(LiDAR) 측정값은 모바일 객체의 임의의 모션을 설명하기 위해 LiDAR 스윕에서, "비틀림 없이", 짧은 간격(예: 약 100ms) 동안 모바일 객체에 의해 캡처될 수 있어, 하나의 포인트 클라우드를 형성한다. 이 경우 단일 포인트 클라우드는 여전히 단일 시점에 해당한다고 말할 수 있다.
실제 주행 데이터는 여러 프레임들의 시퀀스 예를 들어, LiDAR, 레이더 및 깊이 프레임들의 2 이상의 개별 시퀀스들을 포함할 수 있다(본 문맥에서 깊이 프레임은 스테레오 또는 단안 심도 이미징과 같은 깊이 이미징을 통해 도출된 3D 포인트 클라우드를 나타냄). 프레임은 또한 다양한 센서들 및/또는 다양한 센서 양식들로부터의 여러 포인트 클라우드를 융합하여 계산되는 융합 포인트 클라우드로 구성될 수 있다.
본 방법은 관심있는 각 에이전트에 대한 3D 경계 상자 추정치들의 초기 세트(대략적인(coarse) 크기/포즈 추정)에서 시작되며, 이는 프레임 자체로부터 에이전트의 3D 모델을 구축하는데 사용될 수 있다. 여기서 포즈는 6D 포즈(3D 공간에서의 3D 위치 및 방향)를 의미한다. 다음의 일례들은 특히 라이더(LiDA)로부터 3D 모델을 추출하는 것을 고려하지만, 상기 설명은 다른 센서 양식에도 동일하게 적용된다. 여러 양식들의 센서 데이터의 경우, 대략적인(coarse) 3D 상자들은 예를 들어, 제 2 센서 양식 또는 양식들(예컨대, 레이더 또는 깊이 이미징)에 의해 제공될 수 있다. 예를 들어, 초기의 대략적인 추정치는 제 2 양식(또는 양식들)의 포인트 클라우드에 3D 경계 상자 검출기를 적용하여 계산될 수 있다. 대략적인 추정치는 추정치를 정제하는데 사용되는 후속 프로세싱 기술을 사용하여 동일한 센서 양식(이 경우 LiDAR)으로부터 결정될 수도 있다. 또 다른 예로서, 테스트 중인 인식 시스템(102)으로부터의 실시간 3D 상자들은, 초기 대략적인 추정치(예를 들어, 실제 주행 중에 차량에서 계산된 것처럼)로 사용될 수 있다. 후자의 접근 방식을 사용하면, 이 방법은 검출 정제의 한 형태로 설명될 수 있다.
각 에이전트에 대한 집계 3D 객체 모델을 생성하기 위해, 각 프레임의 대략적인 3D 경계 상자에 포함된 포인트들의 서브세트를 취함으로써, 해당 객체에 속한 포인트들이 여러 프레임들에 걸쳐 집계된다(또는 객체 포인트 추출을 위한 추가 "헤드룸"을 제공하기 위해 대략적인 3D 경계 상자가 약간 확장될 수 있음). 넓은 의미에서, 집계는 초기에 각 프레임의 포인트 서브세트를 에이전트의 참조 프레임으로 변환함으로써 작동한다. 에이전트 참조 프레임으로의 변환은 각 프레임의 에이전트 포즈가 대략적으로만 알려져 있기 때문에 이 시점에서는 정확히 알 수 없다. 변환은 대략적인 3D 경계 상자로부터 초기에 추정된다. 예를 들어, 각 프레임의 대략적인 3D 경계 상자의 축에 정렬되도록, 포인트 서브세트를 변환함으로서, 변환을 효율적으로 구현할 수 있다. 서로 다른 프레임들의 포인트 서브세트는 대부분 동일한 객체에 속하지만, 초기 포즈 추정의 에러로 인해 에이전트 참조 프레임에서 오정렬될 수도 있다. 오정렬을 수정하기 위해, 2개의 포인트 서브세트들을 정렬시키는 등록 방법(registration method)이 사용된다. 이러한 방법은 소정 형태의 매칭 알고리즘(예컨대, Iterative Closest Point)을 이용하여, 다른 것과 정렬되도록 객체 포인트들의 서브세트들 중 하나를 변환(회전/변환)함으로써 광범위하게 작동한다. 매칭에서는 포인트들의 2개의 서브세트들이 대부분 동일한 객체로부터 나온다는 지식을 사용한다. 이후, 이러한 프로세스는 후속 프레임들에서 반복되어, 객체의 조밀한 3D 모델을 구축할 수 있다. 조밀한 3D 모델을 이러한 방식으로 구축하면, 노이즈 포인트들(객체에 속하지 않음)을 실제 객체 포인트로부터 격리할 수 있으므로 훨씬 더 쉽게 필터링할 수 있다. 이후, 조밀하고 필터링된 3D 객체 모델에 3D 객체 검출기를 적용함으로써, 문제의 에이전트에 대해 보다 정확한 크기의 꼭 맞는 3D 경계 상자를 결정할 수 있다(이것은 엄격한(rigid) 에이전트를 가정하며, 따라서 3D 경계 상자의 크기와 모양이 프레임들에 걸쳐 변경되지 않으며, 각 프레임의 유일한 변수들은 위치와 방향이다). 마지막으로, 집계 3D 모델은 각 프레임의 대응하는 객체 포인트들에 매칭되어, 각 프레임에서 보다 정확한 3D 경계 상자를 정확하게 찾아내며, 따라서 각 프레임에 대해 정제된 3D 경계 상자 추정치를 제공한다(의사 그라운드 트루의 일부를 형성함). 이러한 프로세스는 이터레이티브하게 반복될 수 있으며, 이를 통해 초기 3D 모델이 추출되고, 포즈가 정제되고, 정제된 포즈를 기반으로 3D 객체 모델이 업데이트된다(기타 등등).
정제된 3D 경계 상자는 위치-기반 인식 출력(예: 런타임 상자, 포즈 추정 등)에 대한 인식 에러의 정도를 결정함에 있어서, 의사 그라운드 트루 위치 상태로서 역할을 한다.
모션 정보를 통합하기 위해, 3D 경계 상자들은 3D 모션 모델과 함께 최적화될 수 있다. 모션 모델은 문제의 에이전트에 대한 모션 상태들(예: 속도/속력, 가속도 등)를 제공할 수 있으며, 이는 런타임 모션 검출들(예컨대, 테스트 중인 인식 시스템(102)에 의해 계산된 속도/속력, 가속도 추정치들)에 대한 의사 그라운드 트루로서 사용될 수 있다. 모션 모델은 프레임들 걸쳐 사실적인(운동학적으로 실현가능한) 3D 상자들을 장려할 수 있다. 예를 들어, 공동-최적화는 집계 3D 모델과 각 프레임의 포인트들 간의 불일치에 페널티를 주는 동시에 프레임 간 에이전트 포즈의 운동학적으로 실행불가능한 변경에 페널티를 주는 비용 함수를 기반으로 공식화될 수 있다.
모션 모델은 또한 모션 모델에 기초하여 인접한 프레임들 사이에 3D 에이전트 포즈를 보간함으로써, 누락된 객체 검출들이 있는 프레임에서 3D 상자들이 정확하게 위치될 수 있게 한다(즉, 대략적인 추정치를 사용할 수 없는 경우, 이는 대략적인 추정치가 차량 내 검출(on-vehicle detections)이고 테스트 중인 인식 시스템(102)이 주어진 프레임에서 실패한 경우에 발생할 수 있다). 인식 분류 도구(152) 내에서, 이를 통해 누락된 객체 검출들이 식별될 수 있다.
3D 모델은 집계 포인트 클라우드 형태일 수도 있고 또는 표면 모델(예컨대, 거리 필드)이 포인트들에 맞춰질 수도 있다. 본 명세서에 참조로서 포함되는 국제 특허 공개 번호 WO2021/013791은 3D 객체 모델링 기술의 추가적인 세부사항을 개시하며, 상기 문헌에서 3D 객체 모델의 3D 표면은 추출된 포인트들에 맞는 (부호화된) 거리 필드로서 인코딩된다.
이러한 정제 기술의 적용은 에고 차량 및 외부 에이전트를 포함하여 장면의 에이전트들(144)에 대한 의사 그라운드 트루을 획득하는데 사용될 수 있다는 것이며, 여기서 정제된 검출들은 장면에서 에이전트에 의해 취해진 실제 트레이스들로서 취급될 수 있다. 이것은, 차량의 검출들과 의사 그라운드 트루를 비교함으로써 차량의 온-보드 인식이 얼마나 정확했는지를 평가하는데 사용될 수 있다. 또한, 의사 그라운드 트루는 테스트 중인 시스템(예: 에고 차량 스택)이 고속도로 규칙을 위반하여 어떻게 주행했는지 확인하는데 사용될 수도 있다.
또한, 의사 그라운드 트루 검출들(144)은 수집된 데이터에 대한 의미론적 태깅 및 질의를 수행하는데에도 사용될 수 있다. 예를 들어, 사용자는 '컷-인이 있는 모든 이벤트 찾기'와 같은 질의를 입력할 수 있으며, 여기서 컷-인은 에이전트가 에고 차량 앞에서 에고 차량의 차선으로 진입한 임의의 시간이다. 의사 그라운드 트루는 임의의 시간에서의 그들의 위치 및 방향과 함께 장면의 모든 에이전트들에 대한 트레이스들을 갖고 있으므로, 다른 차량 앞에서 차선에 진입하는 인스턴스들에 대한 에이전트 트레이스들을 검색함으로써 컷-인을 식별하는 것이 가능하다. 보다 복잡한 질의들이 작성될 수 있다. 예를 들어, 사용자는 '에이전트의 속도가 x 이상인 모든 컷-인을 찾아주세요'라는 질의를 입력할 수 있다. 데이터에서 추출된 의사 그라운드 트루 트레이들스에 의해서 에이전트 모션이 정의되므로, 에이전트가 지정된 속도 이상으로 이동하는 컷-인 인스턴스들에 대한 정제된 검출들을 검색하는 것은 간단하다. 이러한 질의들이 선택 및 실행되면, 데이터를 수동으로 분석하는데 필요한 시간이 감소한다. 이것은, 관심 영역을 실시간으로 식별하기 위해 드라이버에 의존할 필요가 없음을 의미하며, 그 대신, 수집된 데이터 내에서 관심 영역이 자동으로 검출될 수 있으며 그리고 추가 분석을 위해 흥미로운 시나리오들을 추출할 수 있다. 이를 통해 더 많은 데이터를 사용할 수 있으며 그리고 잠재적으로 인간 운전자가 간과할 수 있는 시나리오를 식별할 수 있다.
테스트 파이프라인:
테스트 파이프라인과 테스트 오라클(252)에 대한 추가 세부사항이 이제 설명될 것이다. 다음 예제들은 시뮬레이션 기반 테스트에 중점을 둔다. 그러나 언급한 바와 같이, 테스트 오라클(252)은 실제 시나리오에서 스택 성능을 평가하기 위해 동일하게 적용될 수 있으며, 아래의 관련 설명은 실제 시나리오에도 동일하게 적용된다. 특히, 아래에 설명된 테스트 파이프라인은 도 1-5에 설명된 바와 같이, 실제 데이터로부터 얻은 추출된 그라운드 트루 정보(144)와 함께 사용될 수 있다. 실제 데이터 분석 도구에서 인식 평가 파이프라인과 함께 설명된 테스트 파이프라인을 적용하는 방법은 나중에 더 자세히 설명된다. 다음의 설명은 예를 들어, 도 2a의 스택(100)을 참조한다. 그러나 언급한 바와 같이, 테스트 파이프라인(200)은 매우 유연하며 그리고 임의 레벨의 자율성에서 작동하는 임의의 스택 또는 서브 스택에 적용될 수 있다.
도 6a는 참조 번호 200으로 표시된 테스트 파이프라인의 개략적인 블록도를 도시한다. 테스트 파이프라인(200)은 시뮬레이터(202) 및 테스트 오라클(252)을 포함하는 것으로 도시된다. 시뮬레이터(202)는 AV 런타임 스택(100)의 전체 또는 일부를 테스트할 목적으로 시뮬레이션된 시나리오를 실행하며 그리고 테스트 오라클(252)은 시뮬레이션된 시나리오에서 스택(또는 서브-스택)의 성능을 평가한다. 논의된 바와 같이, 런타임 스택의 서브-스택만이 테스트될 수 있지만, 단순화를 위해 다음 설명에서는 (전체) AV 스택(100) 전체를 참조한다. 그러나, 설명은 전체 스택(100) 대신 서브 스택에도 동일하게 적용된다. "슬라이싱"이라는 용어는 본 명세서에서 테스트를 위한 스택 컴포넌트의 세트 또는 서브세트를 선택하는데 사용된다.
이전에 설명된 바와 같이, 시뮬레이션 기반 테스트의 아이디어는 테스트 중인 스택(100)의 제어 하에서 에고 에이전트가 네비게이팅해야만 하는 시뮬레이션 운전 시나리오를 실행하는 것이다. 일반적으로, 시나리오는 일반적으로 하나 이상의 다른 동적 에이전트들(예: 다른 차량, 자전거, 보행자 등)의 존재하에서 에고 에이전트가 네비게이팅해야 하는 정적인 운전가능 영역(예: 특정 정적 도로 레이아웃)을 포함한다. 이를 위해, 시뮬레이션된 입력(203)이 시뮬레이터(202)로부터 테스트 중인 스택(100)으로 제공된다.
스택의 슬라이싱은 시뮬레이션된 입력(203)의 형태를 결정한다. 예를 들어, 도 6a는 테스트 중인 AV 스택(100) 내의 예측, 계획 및 제어 시스템(104, 106 및 108)을 보여준다. 도 2a의 전체 AV 스택을 테스트하기 위해, 인식 시스템(102)이 테스트 중에 적용될 수도 있다. 이 경우, 시뮬레이션된 입력(203)은 적절한 센서 모델(들)을 사용하여 생성되고 실제 센서 데이터와 동일한 방식으로 인식 시스템(102) 내에서 프로세싱된 합성 센서 데이터를 포함한다. 이를 위해서는 충분히 현실적인 합성 센서 입력(예: 사실적인 이미지 데이터 및/또는 똑같이 현실적인 시뮬레이션 라이더/레이더 데이터 등)을 생성해야만 한다. 인식 시스템(102)의 결과적인 출력들은 더 높은 레벨의 예측 및 플래닝 시스템(104, 106)에 공급된다.
대조적으로, 소위 "플래닝-레벨" 시뮬레이션은 본질적으로 인식 시스템(102)을 바이패스한다. 대신에 시뮬레이터(202)는 더 간단하고 더 높은 수준의 입력(203)을 예측 시스템(104)에 직접 제공한다. 일부 상황에서, 다음과 같은 것이 적절할 수도 있다. 시뮬레이션된 시나리오로부터 직접 획득된 예측들(즉, "완벽한" 예측)에 대해 플래너(106)를 테스트하기 위해 예측 시스템(104)도 우회하는 것이 적절할 수도 있다.
이러한 극단들(extremes) 사이에서, 입력 슬라이싱의 다양한 많은 레벨들, 예컨대, 인식 시스템(102)의 서브 세트만을 테스트하는 것과 같은 범위가 존재한다(예를 들어, 하위 레벨 인식 컴포넌트들(가령, 객체 검출기, 경계 상자 검출기, 모션 검출기 등)로부터의 출력에 대해 작용하는 필터들 혹은 융합 컴포넌트들과 같은, "나중의(later)"(상위 레벨) 인식 컴포넌트들).
어떤 형태를 취하든, 시뮬레이션된 입력(203)은 플래너(108)에 의한 의사 결정을 위한 기초로서 (직접 또는 간접적으로) 사용된다. 컨트롤러(108)는 제어 신호(109)를 출력함으로써 플래너의 결정을 구현한다. 실제 상황에서, 이들 제어 신호는 AV의 물리적 액터 시스템(112)을 구동할 것이다. 시뮬레이션에서, 에고 차량 역학 모델(204)이 이용되어, 결과적인 제어 신호(109)를 시뮬레이션 내의 에고 에이전트의 현실적인 움직임으로 변환하며, 따라서 제어 신호(109)에 대한 자율 차량의 물리적 반응을 시뮬레이션한다.
대안적으로, 더 간단한 형태의 시뮬레이션은 에고 에이전트가 플래닝 단계들 사이에서 각각의 계획된 궤적을 정확하게 따른다고 가정한다. 이러한 접근 방식은 제어 시스템(108)을 우회하고(플래닝으로부터 분리가 가능한한) 그리고 에고 차량 역학 모델(204)에 대한 필요성을 제거한다. 이는 플래닝의 특정 측면을 테스트하는데 충분할 수 있다.
외부 에이전트가 시뮬레이터(202) 내에서 자율적인 거동/의사 결정을 나타내는 한, 그러한 결정을 수행하고 시나리오 내에서 에이전트 행동을 결정하기 위해 일부 형태의 에이전트 결정 로직(210)이 구현된다. 에이전트 결정 로직(210)은 복잡성 면에서 에고 스택(100) 자체와 비슷할 수 있거나 또는 더 제한된 의사 결정 기능을 가질 수 있다. 목표는, 에고 스택(100)의 의사 결정 능력을 유용하게 테스트할 수 있도록, 시뮬레이터(202) 내에서 충분히 현실적인 외부 에이전트 동작을 제공하는 것이다. 일부 상황에서 이는 에이전트 의사 결정 로직(210)을 전혀 필요로 하지 않으며(오픈-루프 시뮬레이션), 그리고 다른 상황에서는 기본 적응형 크루즈 제어(ACC)와 같은 상대적으로 제한된 에이전트 로직(210)을 사용하여 유용한 테스트가 제공될 수 있다. 적절한 경우, 보다 현실적인 에이전트 거동을 제공하기 위해 하나 이상의 에이전트 역학 모델(206)이 사용될 수 있다.
시나리오는 시나리오 설명(201a) 및 (적용가능한 경우) 시나리오의 선택된 파라미터화(201b)에 따라 실행된다. 시나리오는 일반적으로 시나리오 설명(201a)에 "하드 코딩"되거나 또는 설정가능하고 따라서 선택된 파라미터화(201b)와 결합하여 시나리오 설명(201a)에 의해 결정될 수 있는 정적 요소 및 동적 요소를 둘다 갖는다. 운전 시나리오에서 정적 요소는 일반적으로 정적 도로 레이아웃을 포함한다.
일반적으로, 동적 요소는 다른 차량들, 보행자들, 자전거들 등과 같은 시나리오 내의 하나 이상의 외부 에이전트를 포함한다.
각 외부 에이전트에 대해 시뮬레이터(202)에 제공되는 동적 정보의 범위는 다양할 수 있다. 예를 들어, 시나리오는 분리가능한 정적 계층과 동적 계층으로 설명될 수 있다. 소정의 정적 계층(예: 도로 레이아웃 정의)은 다양한 동적 계층들과 결합되어 다양한 시나리오 인스턴스를 제공하는데 사용될 수 있다. 각각의 외부 에이전트에 대해, 동적 계층은 에이전트가 따라갈 공간적 경로를 경로와 연관된 동작 데이터 및 거동 데이터 중 하나 또는 둘 다와 함께 포함할 수 있다. 간단한 오픈-루프 시뮬레이션에서, 외부 액터는 비반응성, 즉 시뮬레이션 내에서 에고 에이전트에 반응하지 않는 동적 계층에 정의된 공간적 경로와 모션 데이터를 단순히 따른다. 이러한 오픈-루프 시뮬레이션은 에이전트 결정 로직(210) 없이 구현될 수 있다. 그러나, 폐루프 시뮬레이션에서, 동적 계층은 그 대신 정적 경로(가령, ACC 거동)를 따라야 할 적어도 하나의 거동을 정의한다. 이 경우, 에이전트 결정 로직(210)은 반응형 방식으로, 즉 에고 에이전트 및/또는 기타 외부 에이전트(들)에 반응하는 방식으로 시뮬레이션 내에서 해당 거동을 구현한다. 모션 데이터는 여전히 정적 경로와 연관될 수 있지만 이 경우 덜 규정적이며 예를 들어 경로를 따라 타겟 역할을 할 수 있다. 예를 들어, ACC 거동의 경우, 에이전트가 일치시키려고 하는 경로를 따라 목표 속도가 설정될 수 있지만, 에이전트 결정 로직(210)은 전방 차량으로부터 목표 차간거리를 유지하기 위해, 경로를 따른 임의의 지점에서 목표 아래로 외부 에이전트의 속도를 줄이는 것이 허용될 수 있다.
이해되는 바와 같이, 시나리오는 임의 정도의 구성가능성과 함께 다양한 방식으로 시뮬레이션 목적으로 설명될 수 있다. 예를 들어, 에이전트의 수와 유형, 그리고 그들의 모션 정보는 시나리오 파라미터화(201b)의 일부로서 구성될 수 있다.
주어진 시뮬레이션에 대한 시뮬레이터(202)의 출력은 에고 에이전트의 에고 트레이스(212a) 및 하나 이상의 외부 에이전트들의 하나 이상의 에이전트 트레이스들(212b)(트레이스 212)를 포함한다. 각각의 트레이스(212a, 212b)는 공간 및 모션 컴포넌트를 모두 갖는 시뮬레이션 내에서 에이전트 거동의 완전한 이력이다. 예를 들어, 각각의 트레이스(212a, 212b)는 속도, 가속도, 저크(가속도 변화율), 스냅(저크 변화율) 등과 같은 경로를 따른 포인트들과 연관된 모션 데이터를 갖는 공간적 경로의 형태를 취할 수 있다.
트레이스(212)에 대한 컨텍스트를 보완하고 제공하기 위해 추가 정보가 또한 제공된다. 이러한 추가 정보는 "컨텍스트" 데이터(214)라고 한다. 컨텍스트 데이터(214)는 시나리오의 물리적 컨텍스트에 관한 것이며, 정적 컴포넌트(예: 도로 레이아웃) 및 동적 컴포넌트(예: 시뮬레이션 과정에서 어느 정도까지 변화하는 기상 조건)를 포함할 수 있다. 컨텍스트 데이터(214)는 시나리오 설명(201a) 또는 파라미터화(201b)의 선택에 의해 직접적으로 정의되고 따라서 시뮬레이션 결과에 영향을 받지 않는다는 점에서 "패스쓰루( passthrough)"일 수 있다. 예를 들어, 컨텍스트 데이터(214)는 시나리오 설명(201a) 또는 파라미터화(201b)로부터 직접 나오는 정적 도로 레이아웃을 포함할 수 있다. 그러나 일반적으로 컨텍스트 데이터(214)는 시뮬레이터(202) 내에서 파생된 적어도 일부 요소를 포함한다. 이것은, 예를 들어, 날씨 데이터와 같은 시뮬레이션된 환경 데이터를 포함할 수 있으며, 여기서 시뮬레이터(202)는 시뮬레이션이 진행됨에 따라 날씨 조건을 자유롭게 변경할 수 있다. 이 경우, 날씨 데이터는 시간 의존적일 수 있으며, 해당 시간 의존성은 컨텍스트 데이터(214)에 반영된다.
테스트 오라클(252)은 트레이스(212)와 컨텍스트 데이터(214)를 수신하고, 성능 평가 규칙 세트(254)와 관련하여 이들 출력에 점수를 매긴다. 성능 평가 규칙(254)은 테스트 오라클(252)에 대한 입력으로서 제공되는 것으로 도시된다.
규칙(254)은 본질적으로 범주형(categorical)이다(예를 들어 통과/실패 유형 규칙). 특정한 성능 평가 규칙은 궤적들을 "점수화"하는데 사용되는 수치적 성능 메트릭과도 연관된다(예: 성공 또는 실패 정도 또는 설명에 도움이 되거나 범주형 결과와 관련된 기타 수량을 나타냄). 규칙들(254)에 대한 평가는 시간 기반이다. 즉, 주어진 규칙은 시나리오의 다른 지점에서 다른 결과를 가질 수 있다. 스코어링도 또한 시간 기반이다. 각각의 성능 평가 메트릭에 대해, 테스트 오라클(252)은 시뮬레이션이 진행됨에 따라 해당 메트릭(점수)의 값이 시간에 따라 어떻게 변하는지 추적한다. 테스트 오라클(252)은 각 규칙에 대한 범주형(예: 통과/실패) 결과들의 시간 시퀀스(256a)와 각각의 성능 메트릭에 대한 점수-시간 플롯(256b)를 포함하는 출력(256)을 제공하며, 이는 나중에 더 자세히 설명된다. 결과들 및 점수들(256a, 256b)은 전문가(122)에게 정보를 제공할 수 있으며 그리고 테스트된 스택(100) 내의 성능 문제를 식별 및 완화하는데 사용될 수 있다. 테스트 오라클(252)은 또한 시나리오에 대한 전체적인(종합적인) 결과(예: 전체 통과/실패)를 제공한다. 테스트 오라클(252)의 출력(256)은, 출력(256)이 속하는 시나리오에 관한 정보와 연관되어 테스트 데이터베이스(258)에 저장된다. 예를 들어, 출력(256)은 시나리오 설명(210a)(또는 그 식별자) 및 선택된 파라미터화(201b)와 연관되어 저장될 수 있다. 시간 종속적인 결과들 및 점수들 뿐만 아니라 전체 점수도 시나리오에 할당될 수 있으며 출력(256)의 일부로 저장될 수 있다. 예를 들어, 각각의 규칙에 대한 집계 점수(예: 전체 통과/실패) 및/또는 모든 규칙(254)에 대한 집계 결과(예: 통과/실패)가 할당 및 저장될 수 있다.
도 6b는 슬라이싱의 또 다른 선택을 예시하며, 참조번호 100 및 100S를 사용하여 풀 스택 및 서브-스택을 각각 나타낸다. 도 6a의 테스트 파이프라인(200) 내에서 테스트 대상이 되는 것은 서브-스택(100S)이다.
다수의 "후속(later)" 인식 컴포넌트들(102B)은 테스트될 서브-스택(100S)의 일부를 형성하고 그리고 테스트 동안, 시뮬레이션된 인식 입력(203)에 적용된다. 후속 인식 컴포넌트(102B)는 예를 들어 필터링 또는 이전의(earlier) 여러 개의 인식 컴포넌트들로부터의 인식 입력들을 융합하는 다른 융합 컴포넌트를 포함할 수 있다.
풀 스택(100)에서, 후속 인식 컴포넌트(102B)들은 이전의 인식 컴포넌트(102A)로부터 실제 인식 입력(213)을 수신할 것이다. 예를 들어, 이전 인식 컴포넌트(102A)는 하나 이상의 2D 또는 3D 경계 상자 검출기(bounding box detectors)를 포함할 수 있으며, 이 경우 후속 인식 컴포넌트에 제공되는 시뮬레이션된 인식 입력은 레이 트레이싱(ray tracing)을 통해 시뮬레이션에서 도출된 시뮬레이션된 2D 또는 3D 경계 상자 검출들을 포함할 수 있다. 이전의 인식 컴포넌트(102A)는 일반적으로 센서 데이터에 직접 작용하는 컴포넌트(들)를 포함한다. 도 6B의 슬라이싱으로, 시뮬레이션된 인식 입력(203)은 이전의 인식 컴포넌트(102A)에 의해 일반적으로 제공되는 실제 인식 입력(213)에 형태적으로 대응할 것이다. 그러나 이전의 인식 컴포넌트(102A)는 테스트의 일부로서 적용되지 않고, 대신에 통계적으로 엄격한 방식으로 시뮬레이션된 인식 입력(203)에 현실적인 에러를 도입하는데 사용될 수 있는 하나 이상의 인식 에러 모델(208)을 훈련하는데 사용되며, 이는 테스트 중인 서브스택(100)의 후속 인식 컴포넌트(102B)에 공급된다.
이러한 인식 에러 모델은 인식 통계 성능 모델(PSPM: Perception Statistical Performance Model) 또는 동의어로 "PRISM"이라고 할 수 있다. PSPM의 원리와 이를 구축하고 훈련하기 위한 적절한 기술의 추가적인 세부사항은 국제 특허 공개 번호 WO2021037763 WO2021037760, WO2021037765, WO2021037761 및 WO2021037766에 속할될 수 있으며, 이들 각각은 그 전체가 본 명세서에 참조로 포함된다. PSPM의 배후에 있는 아이디어는 서브-스택(100S)에 제공되는 시뮬레이션된 인식 입력에 현실적인 에러들을 효율적으로 도입하는 것이다(즉, 이전 인식 컴포넌트(102A)가 실제 세계에 적용되면 예상되는 에러들의 종류를 반영하는 것이다). 시뮬레이션 상황에서, "완벽한" 그라운드 트루 인식 입력들(203G)은 시뮬레이터에 의해 제공되지만, 이들 입력들은 인식 에러 모델(들)(208)에 의해 도입된 현실적 에러와 함께 보다 현실적인 인식 입력(203)을 도출하는데 사용된다.
앞서 언급한 참고문헌들에 설명된 바와 같이, PSPM은 물리적 조건(들)을 나타내는 하나 이상의 변수들(교란 요인들 :confounders)에 따라 달라질 수 있으므로, 다양한 가능한 실제 조건들을 반영하는 상이한 레벨들의 에러가 도입될 수 있다. 그러므로, 시뮬레이터(202)는 기상 교란 요인(들)의 값을 단순히 변경함으로써 다양한 물리적 조건들(예를 들어, 다양한 기상 조건들)을 시뮬레이션할 수 있으며, 이는 결국 인식 에러가 도입되는 방식을 변경하게 될 것이다.
서브-스택(100S) 내의 후속 인식 컴포넌트(102b)는 전체 스택(100) 내에서 실제 인식 입력(213)을 프로세싱하는 것과 정확히 동일한 방식으로 시뮬레이션된 인식 입력(203)을 프로세싱하고, 그 출력은 차례로 예측, 플래닝 및 제어를 도출한다.
대안적으로, PRISM은 후속 인식 컴포넌트(208)를 포함하여 전체 인식 시스템(102)을 모델링하는데 사용될 수 있으며, 이 경우 PSPM(들)은 입력으로서 예측 시스템(104)에 직접 전달되는 현실적인 인식 출력을 생성하는데 사용된다.
구현예에 따라, 소정의 시나리오 파라미터화(201b)와 스택(100)의 소정 구성에 대한 시뮬레이션 결과 사이에는 결정론적 관계(deterministic relationship)가 있을 수도 있고 없을 수도 있다(즉, 동일한 파라미터화는 동일한 스택(100)에 대해 항상 동일한 결과를 가져올 수도 있고 그렇지 않을 수도 있음). 비결정론(non-determinism)은 다양한 방식으로 발생할 수 있다. 예를 들어, 시뮬레이션이 PRISM을 기반으로 하는 경우, PRISM은 시나리오의 각각의 주어진 시간 단계에서 가능한 인식 출력들에 대한 분포를 모델링할 수 있으며, 여기서 현실적인 인식 출력이 확률적으로 샘플링된다. 이것은 시뮬레이터(202) 내에서 비결정적론 거동(non-deterministic behaviour)으로 이어지며, 그에 따라 서로 다른 인식 출력이 샘플링되기 때문에, 동일한 스택(100) 및 시나리오 파라미터화에 대해 서로 다른 결과가 얻어질 수 있다. 대안적으로 또는 추가적으로, 시뮬레이터(202)는 본질적으로 비결정론적일 수 있는데, 예를 들어 날씨, 조명 또는 다른 환경 조건은 시뮬레이터(202) 내에서 어느 정도까지는 무작위적/확률적일 수 있다. 이해되듯이, 이것은 설계적 선택이다. 다른 구현예에서는, 다양한 환경 조건들이 시나리오의 파라미터화(201b)에서 완전하게 특정될 수 있다. 비결정론적 시뮬레이션을 사용하면, 각각의 파라미터화에 대해 여러 시나리오 인스턴스들이 실행될 수 있다. 집계된 통과/실패 결과는 예를 들어, 통과 또는 실패 결과들의 개수 또는 백분율로서 파라미터화(201b)의 특정 선택에 할당될 수 있다.
테스트 오케스트레이션(orchestration) 컴포넌트(260)는 시뮬레이션을 위해 시나리오를 선택하는 역할을 담당한다. 예를 들어, 테스트 오케스트레이션 컴포넌트(260)는 이전 시나리오들로부터의 테스트 오라클 출력(256)에 기초하여, 시나리오 설명(201a) 및 적합한 파라미터화(201b)를 자동으로 선택할 수 있다.
테스트 오라클 규칙들(Test oracle rules):
성능 평가 규칙들(254)은 테스트 오라클 내에 적용될 계산 그래프(규칙 트리)로 구성된다. 달리 명시되지 않는 한, 본 명세서에서 "규칙 트리(rule tree)"라는 용어는 주어진 규칙을 구현하도록 구성된 계산 그래프를 의미한다. 각각의 규칙은 규칙 트리로 구성되며, 여러 규칙들의 세트는 여러 규칙 트리들의 "숲(forest)"으로 지칭될 수 있다.
도 7a는 추출기 노드들(리프 객체들; leaf objects)(302)와 평가자 노드들(논-리프 객체들)(304)의 조합으로 구성된 규칙 트리(300)의 일례를 도시한다. 각각의 추출기(extractor) 노드(302)는 시나리오 데이터(310) 세트로부터 시간-가변 숫자(time-varying numerical)(예컨대, 부동 소수점) 신호(점수)를 추출한다. 시나리오 데이터(310)는 위에서 설명한 의미에서 시나리오 그라운드 트루의 형태이며 이와 같이 지칭될 수 있다. 시나리오 데이터(310)는 실제 또는 시뮬레이션 시나리오에서 궤적 플래너(예컨대, 도 2a의 플래너 106)를 배치함으로써 획득되었으며, 에고 및 에이전트 트레이스들(212) 뿐만 아니라 콘텍스트 데이터(214)를 포함하는 것으로 도시된다. 도 6 또는 도 6a의 시뮬레이션 콘텍스트에서, 시나리오 그라운드 트루(310)는 시뮬레이터(202)의 출력으로 제공된다.
각각의 평가자 노드(304)는 적어도 하나의 자식(child) 객체(노드)를 갖는 것으로 도시되며, 여기서 각각의 자식 객체는 추출기 노드(302)들 중 하나이거나 또는 평가자 노드(304)들 중 다른 하나이다. 각각의 평가자 노드(304)는 자신의 자식 노드(들)로부터 출력(들)을 수신하며 그리고 평가자 함수를 이들 출력(들)에 적용한다. 평가자 함수의 출력은 시계열적 범주형 결과들이다(time-series of categorical results). 다음 일례들은 간단한 이진 통과/실패 결과들을 고려하지만, 이러한 기술은 비이진(non-binary) 결과로 쉽게 확장될 수 있다. 각각의 평가자 함수는 미리결정된 원자 규칙(atomic ruke)에 따라 자식 노드(들)의 출력(들)을 평가한다. 이러한 규칙들은 원하는 안전 모델에 따라 유연하게 결합될 수 있다.
또한, 각각의 평가자 노드(304)는 그 자식 노드(들)의 출력(들)로부터 시간-가변 숫자 신호를 도출하는데, 이는 임계 조건(아래 참조)에 의해 범주형 결과와 관련된다.
최상위(top-level) 루트 노드(304a)는 임의의 다른 노드의 자식 노드가 아닌 평가자 노드이다. 최상위 노드(304a)는 결과들의 최종 시퀀스를 출력하고, 그리고 그 자손들(즉, 최상위 노드(304a)의 직접 또는 간접 자식인 노드들)은 기본 신호들(underlying signal) 및 중간 결과들을 제공한다.
도 7b는 평가자 노드(304)에 의해 계산된 도출된 신호(312) 및 대응하는 시계열 결과들(314)의 일례를 시각적으로 묘사한다. 결과들(314)은 도출된 신호(312)와 상관되는데, 도출된 신호가 실패 임계값(316)을 초과하는 경우(및 오직 그 경우에만) 통과 결과가 반환된다. 이해되는 바와 같이, 이는 결과들의 시간 시퀀스를 해당 신호에 관련시키는 임계 조건의 단지 하나의 일례일 뿐이다.
추출기 노드(302)에 의해서 시나리오 그라운드 트루(310)로부터 직접 추출된 신호는 평가자 노드(304)에 의해 계산된 "도출된(derived)" 신호와 구별하기 위해 "원시(raw)" 신호로 지칭될 수 있다. 결과들 및 원시 신호/도출된 신호는 시간에 따라 이산화될 수 있다.
도 8a는 테스트 플랫폼(200) 내에 구현된 규칙 트리의 예를 보여준다.
테스트 오라클(252)과 함께 구현될 규칙을 구성하기 위해 규칙 편집기(400)가 제공된다. 규칙 편집기(400)는 사용자(시스템의 최종 사용자일 수도 있고 아닐 수도 있음)로부터 규칙 생성 입력을 수신한다. 본 일례에서, 규칙 생성 입력은 도메인 특정 언어(DSL)로 코딩되고 그리고 테스트 오라클(252) 내에서 구현될 적어도 하나의 규칙 그래프(408)를 정의한다. 규칙들은 다음의 일례들에서 통과 및 실패를 각각 나타내는 TRUE 및 FALSE를 갖는 논리적 규칙들이다(인지하겠지만 이는 순전히 설계상의 선택이다).
다음의 일례들은 원자적 논리 서술부(atomic logic predicates)의 조합을 이용하여 공식화되는 규칙을 고려한다. 기본적인 원자적 서술부의 일례들은 기본적인 논리 게이트들(OR, AND 등) 및 "~~보다 크다"와 같은 논리 함수들, (Gt(a,b))(이것은 a가 b보다 크면 TRUE를 반환하고 그렇지 않으면 false를 반환함)을 포함한다.
Gt 함수는 에고 에이전트와 시나리오 내의 다른 에이전트(에이전트 식별자 "other_agent_id"를 가짐) 사이의 안전한 측면 거리 규칙을 구현할 것이다. 2개의 추출기 노드들(latd, latsd)은 LateralDistance 및 LateralSafeDistance 추출기 기능들을 각각 적용한다. 이러한 함수들은 시나리오 그라운드 트루(310)에서 직접 작용하여, 시간-가변 측면 거리 신호(에고 에이전트와 식별된 다른 에이전트 사이의 측면 거리 측정)와 에고 에이전트 및 식별된 다른 에이전트에 대한 시간-가변 안전 측면 거리 신호를 각각 추출한다. 안전 측면 거리 신호는 에고 에이전트의 속도 및 다른 에이전트의 속도(트레이스(212)에 캡처됨) 및 콘텍스트 데이터(214)에서 캡춰된 환경 조건들(예: 날씨, 조명, 도로 유형 등)과 같은 다양한 요인들에 따라 달라질 수 있다.
평가자 노드(is_latd_safe)는 latd 및 latsd 추출기 노드들의 부모이며 Gt 원자적 서술부에 매핑된다. 따라서, 규칙 트리(408)가 구현되면 is_latd_safe 평가자 노드는 시나리오의 각 시간 단계에 대한 참(true)/거짓(false)) 결과를 계산하기 위해 latd 및 latsd 추출기 노드들의 출력들에 Gt 함수를 적용하고, latd 신호가 latsd 신호를 초과하는 각각의 시간 단계에 대해 TRUE를 반환하고, 그렇지 않으면 FALSE를 반환한다. 이러한 방식으로, 원자적 추출기 함수들 및 서술부로부터 "안전 측면 거리" 규칙이 구성되었다. 측면 거리가 안전 측면 거리 임계값에 도달하거나 그 이하로 떨어지는 경우, 에고 에이전트는 안전 측면 거리 규칙을 위반한다. 이해되겠지만, 이것은 규칙 트리의 매우 간단한 일례이다. 임의의 복잡성을 갖는 규칙들도 동일한 원리에 따라 구성될 수 있다.
테스트 오라클(252)은 규칙 트리(408)를 시나리오 그라운드 트루(310)에 적용하고, 그리고 사용자 인터페이스(UI)(418)를 통해 결과를 제공한다.
도 8b는 도 8a의 그것에 해당하는 측면 거리 브랜치를 포함하는 규칙 트리의 일례를 보여준다. 또한 규칙 트리에는 안전 거리 메트릭을 구현하기 위한 종방향(longitudinal) 거리 브랜치와 최상위 OR 서술부(안전 거리 노드, is_d_safe)가 포함되어 있다. 측면 거리 브랜치와 유사하게, 종방향 거리 브랜치는 시나리오 데이터(추출기 노드 lond 및 lonsd 각각)에서 종방향 거리 및 종방향 거리 임계값 신호를 추출하고 그리고 종방향 안전 평가 노드(is_lond_safe)는 종방향 거리가 안전 종방향 거리 임계값 보다 높을 때 TRUE를 반환한다. 최상위 OR 노드는 측면 및 종방향 거리 중 하나 또는 둘다 안전할 경우(해당 임계값 미만인 경우), TRUE를 반환하고, 둘다 안전하지 않으면 FALSE를 반환한다. 이러한 맥락에서, 거리들 중 하나만이 안전 임계값을 초과하는 것으로 충분하다(예컨대, 2대의 차량이 인접한 차선에서 주행하는 경우 이들 차량이 나란히 있을 때 이들 차량 간의 종방향 분리는 0이거나 0에 가깝다. 하지만, 그러한 상황은 해당 차량들이 측면으로 충분히 분리되어 있으면 안전한 상황이다).
예를 들어, 최상위 노드의 숫자 출력은 시간에 따라 변하는 견고성 점수일 수 있다.
예를 들어, 주어진 안전 모델의 다양한 규칙들을 구현하거나, 다양한 안전 모델들을 구현하거나, 다양한 시나리오들에 규칙들을 선택적으로 적용하기 위하여, 다양한 규칙 트리들이 구성될 수 있다(주어진 안전 모델에서 모든 규칙이 반드시 모든 시나리오에 적용되는 것은 아니며, 이러한 접근 방식을 사용하면 다양한 규칙이나 규칙 조합이 다양한 시나리오에 적용될 수 있다). 이러한 프레임워크 내에서, 편안함(예: 순간 가속 및/또는 궤적을 따른 저크(jerk)에 기초하여), 진행 상황(예컨대, 정의된 목표에 도달하는데 걸리는 시간에 기초하여), 등을 평가하기 위해 규칙들이 구성될 수도 있다.
위의 일례에서는 OR, AND, Gt 등과 같은 단일 시간 인스턴스에서 결과들 또는 신호들에 대해 평가된 간단한 논리적 서술부가 고려된다. 그러나 실제로는 시간적 논리 측면에서 소정의 규칙들을 공식화하는 것이 바람직할 수 있다.
참조로서 그 전체 내용이 본 명세서에 통합되는 Hekmatnejad 등의 논문, "Encoding and Monitoring Responsibility Sensitive Safety Rules for Automated Vehicles in Signal Temporal Logic" (2019), MEMOCODE'19: Proceedings of the 17th ACM-IEEE International Conference on Formal Methods and Models for System Design 은 RSS 안전 규칙들에 대한 신호 시간 논리(STL: signal temporal logic) 인코딩을 공개한다. 시간 논리(temporal logic)는 시간 측면에서 한정되는 서술부를 구성하기 위한 공식적인(formal) 프레임워크를 제공한다. 이는 주어진 시점에서 평가자가 계산한 결과가 다른 시간 인스턴스(들)에서의 결과들 및/또는 신호 값들에 따라 달라질 수 있음을 의미한다.
예를 들어, 안전 모델의 요구 사항은 설정된 시간 프레임 내의 특정 이벤트에 대해 에고 에이전트가 응답하는 것일 수 있다. 이러한 규칙은 규칙 트리 내의 시간 논리 서술부를 사용하여 유사한 방식으로 인코딩될 수 있다.
위의 일례에서, 스택(100)의 성능은 시나리오의 각 시간 단계에서 평가된다. 전체 테스트 결과(예: 통과/실패)는 이로부터 도출될 수 있다. 예를 들어, 특정 규칙들(예컨대, 안전에 중요한 규칙들)은 만일, 상기 규칙이 시나리오 내의 어느 시점에서든 실패하는 경우, 전체 실패를 유발할 수 있다(즉, 시나리오에서 전체 통과를 획득하려면 모든 시간 단계에서 상기 규칙이 통과해야 한다). 다른 유형의 규칙의 경우, 전체 통과/실패 기준은 "보다 유연"할 수 있으며(예컨대, 해당 규칙이 일련의 순차적 시간 단계들에 걸쳐 실패하는 경우 특정 규칙에 대해서만 실패가 트리거될 수 있음), 이러한 기준은 상황에 따라 달라질 수 있다.
도 8c는 테스트 오라클(252) 내에서 구현된 규칙 평가의 계층 구조를 개략적으로 묘사한다. 규칙 세트(254)는 테스트 오라클(252)에서의 구현을 위해 수신된다.
특정 규칙은 에고 에이전트에만 적용된다(예컨대, 주어진 임의의 시간 순간에서 에고 궤적에 의해서 일부 최대 가속도 또는 저크 임계값이 초과되는지 여부를 평가하는 편안함 규칙이 그 일례가 될 수 있다).
다른 규칙들은 에고 에이전트와 다른 에이전트들과의 상호작용과 관련된다(예컨대, "충돌 없음" 규칙 또는 위에서 고려한 안전 거리 규칙). 이러한 각각의 규칙은 에고 에이전트와 다른 에이전트 사이에서 쌍을 이루는 방식으로 평가된다. 또 다른 예로서, "보행자 비상 제동" 규칙은 보행자가 에고 차량 앞으로 걸어올 때만 활성화될 수 있으며, 해당 보행자 에이전트에 대해서만 활성화될 수 있다.
모든 규칙들이 모든 시나리오에 반드시 적용되는 것은 아니며, 일부 규칙은 시나리오의 일부에만 적용될 수 있다. 테스트 오라클(252) 내의 규칙 활성화 로직(422)은 각 규칙(254)이 문제의 시나리오에 적용가능한지 여부와 시기를 결정하고, 적용되는 경우 규칙을 선택적으로 활성화한다. 따라서, 규칙은 시나리오 전체에 대해 활성 상태로 유지될 수도 있고, 특정 시나리오에 대해서는 활성화되지 않을 수도 있고, 일부 시나리오에 대해서만 활성화될 수도 있다. 또한, 시나리오 내의 여러 지점들에서 다양한 수의 에이전트들에 대해 규칙들이 평가될 수 있다. 이러한 방식으로 규칙들을 선택적으로 활성화하면, 테스트 오라클(252)의 효율성이 크게 증가될 수 있다.
특정 규칙의 활성화 또는 비활성화는 하나 이상의 다른 규칙들의 활성화/비활성화에 따라 달라질 수 있다. 예를 들어, 보행자 비상 제동 규칙이 활성화되 경우(보행자의 안전이 주요 관심사이기 때문에) "최적의 편안함" 규칙은 적용불가능한 것으로 간주될 수 있으며, 보행자 비상 제동 규칙이 활성화될 때마다 "최적의 편안함" 규칙은 비활성화될 수 있다.
규칙 평가 로직(424)은 활성 상태로 유지되는 임의의 기간 동안 각각의 활성 규칙을 평가한다. 각각의 상호작용 규칙은 에고 에이전트와 그것이 적용되는 다른 에이전트들 사이에서 쌍을 이루는 방식으로 평가된다.
규칙들을 적용하는 것에도 어느 정도의 상호의존성이 있을 수 있다. 예를 들어, 편안함 규칙과 비상 제동 규칙 사이의 관계를 다루는 또 다른 방법은, 적어도 하나의 다른 에이전트에 대해 비상 제동 규칙이 활성화될 때마다 편안함 규칙의 저크/가속 임계값을 증가시키는 것이다.
비록, 통과/실패 결과들이 고려되었지만 규칙들은 이진법이 아닐 수 있다. 예를 들어, 실패에 대한 2개의 카테고리들 즉, "허용 가능"과 "허용 불가능"이 도입될 수 있다. 다시 말하지만, 편안함 규칙과 비상 제동 규칙 사이의 관계를 고려하면, 상기 규칙은 실패했지만 비상 제동 규칙이 활성화된 시간에서 편안함 규칙에 대한 허용 가능한 실패가 발생할 수 있다. 따라서, 규칙들 간의 상호의존성은 다양한 방식으로 처리될 수 있다.
규칙들(254)에 대한 활성화 기준은 규칙 편집기(400)에 제공되는 규칙 생성 코드에서 지정될 수 있으며, 임의의 규칙 상호의존성의 특성 및 이러한 상호의존성을 구현하기 위한 메커니즘(들)도 지정될 수 있다.
그래픽 사용자 인터페이스:
도 9a는 시각화 컴포넌트(520)의 개략적인 블록도를 도시한다. 시각화 컴포넌트는 그래픽 사용자 인터페이스(GUI)(500) 상에 테스트 오라클(252)의 출력(256)을 렌더링하기 위해 테스트 데이터베이스(258)에 연결된 입력을 갖는 것으로 도시된다. GUI는 디스플레이 시스템(522)에서 렌더링된다.
도 9b는 GUI(500)의 예시적인 뷰를 도시한다. 상기 뷰는 다수의 에이전트들을 포함하는 특정 시나리오에 관한 것이다. 본 일례서 테스트 오라클 출력(526)은 여러 외부 에이전트와 관련되며, 결과들은 에이전트에 따라 구성된다. 각각의 에이전트에 대해, 시나리오의 일부 시점에서 해당 에이전트에 적용가능한 각 규칙에 대한 시계열적 결과들이 이용될 수 있다. 도시된 일례에서, 써머리 뷰가 "에이전트 01"에 대해 선택되었으며, 적용가능한 각각의 규칙에 대해 계산된 "최상위" 결과가 디스플레이된다. 각각의 규칙 트리의 루트 노드에서 계산된 최상위 결과들이 존재한다. 해당 에이전트에 대해 규칙이 비활성 상태인 기간, 활성 및 통과한 기간, 활성 및 실패한 기간을 구별하기 위해 색상 코딩이 사용된다.
각각의 시계열 결과들에 대해 제 1 선택가능 요소(534a)가 제공된다. 이를 통해 규칙 트리의 하위 레벨 결과들(즉, 규칙 트리의 아래쪽에서 계산된)에 액세스할 수 있다.
도 9c는 "규칙 02"에 대한 결과들의 제 1 확장 뷰를 도시하며, 여기서 하위 레벨 노드들의 결과들도 또한 시각화된다. 예를 들어, 도 4b의 "안전 거리" 규칙의 경우, "is_latd_safe" 노드 및 "is_lond_safe" 노드의 결과가 시각화될 수 있다(도 9c에서 "C1" 및 "C2"로 라벨링됨). 규칙 02의 제 1 확장 뷰에서는, C1 결과와 C2 결과 사이의 논리적 OR 관계에 의해서 규칙 02에 대한 성공/실패가 정의됨을 알 수 있다. C1과 C2 모두에서 실패가 발생한 경우에만 규칙 02가 실패한다(전술한 "안전 거리" 규칙에서와 같이).
각각의 시계열적 결과들에 대하여 제 2 선택가능 요소(534b)가 제공되며, 이는 연관된 수치적 성능 점수에 액세스할 수 있게 한다.
도 9d는 제 2 확장 뷰를 도시하며, 여기서는 규칙 02에 대한 결과들 및 "C1" 결과들이 확장되어, 에이전트 01에 대해 이들 규칙들이 활성화된 기간들에 대한 관련 점수들이 도시된다. 상기 점수들은 시각적 점수-시간 플롯으로 디스플레이되며, 이는 통과/실패를 나타내기 위해 유사하게 색상 코딩될 수 있다.
예시적인 시나리오:
도 10a는 에고 차량(602)과 다른 차량(604) 사이의 충돌 이벤트로 종료되는 시뮬레이터(202)의 컷인 시나리오의 제 1 인스턴스를 도시한다. 컷인 시나리오는 다중 차선 운전 시나리오라는 특징을 갖고 있으며, 여기서 에고 차량(602)은 제 1 차선(612)(에고 차선)을 따라 이동하고 있으며, 다른 차량(604)은 처음에는 인접한 제 2 차선(604)을 따라 이동하고 있다. 시나리오의 어느 시점에서, 다른 차량(604)은 에고 차량(602)의 앞에서(컷인 거리) 인접 차선(614)으로부터 에고 차선(612)으로 이동한다. 이러한 시나리오에서, 에고 차량(602)는 다른 차량(604)과의 충돌을 피할 수 없다. 제 1 시나리오 인스턴스는 충돌 이벤트에 응답하여 종료된다.
도 10b는 제 1 시나리오 인스턴스의 그라운드 트루(310a)로부터 획득된 제 1 오라클 출력(256a)의 일례를 묘사한다. "충돌 없음" 규칙은 에고 차량(602)과 다른 차량(604) 사이에서 시나리오 기간 동안 평가된다. 충돌 이벤트로 인해 시나리오가 끝날 때 이 규칙이 실패하게 된다. 또한, 도 4b의 "안전 거리" 규칙이 평가된다. 다른 차량(604)이 에고 차량(602)에 대해 측면 방향으로 가깝게 이동함에 따라, 안전 측면 거리 및 안전 종방향 거리 임계값이 모두 위반되는 시점(t1)이 발생하며, 결과적으로 시간 t2에서의 충돌 이벤트까지 지속되는 안전 거리 규칙이 실패하게 된다.
도 10c는 컷인 시나리오의 제 2 인스턴스를 보여준다. 제 2 경우, 컷인 이벤트는 충돌로 이어지지 않으며, 에고 차량(602)은 컷인 이벤트 이후에 다른 차량(604) 뒤에서 안전 거리에 도달할 수 있다.
도 10d는 제 2 시나리오 인스턴스의 그라운드 트루(310b)로부터 획득된 제 2 오라클 출력(256b)의 일례를 묘사한다. 이 경우 "충돌 없음" 규칙이 전체적으로 통과된다. 에고 차량(602)과 다른 차량(604) 사이의 측면 거리가 안전하지 않게 되는 시점 t3에서 안전 거리 규칙이 위반된다. 그러나 시점 t4에서 에고 차량(602)은 다른 차량(604) 뒤에서 안전 거리에 도달하였다. 따라서, 안전거리 규칙은 시점 t3에서 시점 t4 사이에서만 실패하게 된다.
인식 에러 프레임워크(Perception error framework)
전술한 바와 같이, 인식 에러 및 운전 규칙 둘다는 추출된 의사 그라운드 트루(pseudo ground truth)(144)에 기초하여 평가될 수 있으며, 의사 그라운드 트루(144)는 그라운드 트루 파이프라인(ground-truthing pipeline)(144)에 의해 결정되고 GUI(500)에 제시된다.
도 11은 인식 에러를 평가하기 위한 아키텍처를 보여준다. 인식 오라클(1108)을 포함하는 분류 도구(triage tool)(152)는 실제 운전 시나리오와 시뮬레이션된 운전 시나리오 모두에 대한 인식 에러를 추출하고 평가하는데 사용되며 그리고 테스트 오라클(252)의 결과와 함께 GUI(500)에 렌더링될 결과를 출력한다. 분류 도구(152)는 본 명세서에서 인식 분류 도구(perception triage tool)로 지칭되지만, 자율 차량 스택을 테스트하고 개선하는데 유용한 인식 데이터 및 운전 성능 데이터를 포함하여 운전 데이터를 추출하여 사용자에게 제시하는데 더 일반적으로 사용될 수 있다.
운전 실행(driving run)으로부터의 실제 센서 데이터(140)의 경우, 온라인 인식 스택(102)의 출력은 분류 도구(152)로 전달되어, 그라운드 트루 파이프라인(400)을 통해 실제 센서 데이터(140)와 온라인 인식 출력 둘다를 실행함으로써 획득된, 추출된 그라운드 트루(144)에 기초하여 수치적 '실제 세계' 인식 에러(1102)를 결정한다.
유사하게, 센서 데이터가 맨 처음부터(from scratch) 시뮬레이션되고 그리고 인식 스택이 시뮬레이션된 센서 데이터에 적용되는 시뮬레이션된 운전 실행의 경우, 시뮬레이션된 인식 에러(1104)는 인식 스택으로부터의 검출들과 시뮬레이션 그라운드 트루와의 비교에 기초하여 분류 도구(152)에 의해 계산된다. 하지만, 시뮬레이션의 경우, 그라운드 트루는 시뮬레이터(202)로부터 직접 획득될 수 있다.
인식 스택의 출력을 시뮬레이션하기 위해 시뮬레이터(202)가 인식 에러를 직접 모델링하는 경우, 시뮬레이션된 검출들과 시뮬레이션 그라운드 트루 사이의 차이, 즉 시뮬레이션된 인식 에러(1110)는 알려져 있고, 그리고 이것은 인식 오라클(1108)에 직접 전달된다.
인식 오라클(1108)은 사용자 인터페이스를 통해 정의되거나 나중에 더 자세히 설명되는 도메인 특정 언어로 작성될 수 있는 인식 규칙 정의들(1106)의 세트를 수신한다. 인식 규칙 정의(1106)는 인식 에러 및 그 한계를 정의하는 임계값 또는 규칙을 적용할 수 있다. 인식 오라클은 상기 정의된 규칙들을 운전 시나리오에 대해 획득된 실제 또는 시뮬레이션 인식 에러에 적용하고 그리고 인식 에러가 정의된 규칙을 위반한 부분을 결정한다. 이러한 결과는 렌더링 컴포넌트(1120)로 전달되며, 렌더링 컴포넌트(1120)는 그래픽 사용자 인터페이스(500)에 디스플레이하기 위해 상기 평가된 인식 규칙들의 시각적 표시자를 렌더링한다. 테스트 오라클에 대한 입력은 명확성을 이유로 도 11에 표시되지 않았지만 테스트 오라클(252)은 또한 그라운드 트루 파이프라인(400) 또는 시뮬레이터(202)로부터 획득된 그라운드 트루 시나리오에 의존한다.
추출된 그라운드 트루에 대한 실제 운전 스택의 인식 에러를 평가하기 위한 프레임워크의 추가적인 세부사항이 이제 설명될 것이다. 위에서 언급한 바와 같이, 테스트 오라클(252)에 의한 인식 에러와 운전 규칙 분석은 모두 아래에서 더 자세히 설명되는 실제 운전 분석 도구에 통합될 수 있다.
모든 에러의 중요성이 동일하지는 않다. 예를 들어, 에고로부터 10미터 떨어진 에이전트의 10cm 변환 에러(translation error)는 100미터 떨어진 에이전트에 대한 동일한 변환 에러보다 훨씬 더 중요하다. 이러한 문제에 대한 간단한 해결책은 에고 차량과의 거리에 따라 에러를 스케일링하는 것이다. 하지만, 다양한 인식 에러들의 상대적 중요성 또는 다양한 에러들에 대한 에고의 주행 성능 민감도는 해당 스택의 사용 사례에 따라 달라진다. 예를 들어, 직선 도로에서 주행하기 위한 크루즈 컨트롤 시스템을 설계하는 경우, 이것은 변환 에러에 민감해야 하지만, 방향 에러에 특별히 민감할 필요는 없다. 그러나 로터리(roundabout) 진입을 핸들링하는 AV는 검출된 에이전트의 방향을 에이전트가 로터리를 떠나는지 여부와 로터리에 진입하는 것이 안전한지 여부에 대한 지표로 사용하므로 방향 에러에 매우 민감해야 한다. 따라서, 다양한 인식 에러에 대한 시스템의 민감도를 각각의 사용 사례에 맞게 설정할 수 있도록 하는 것이 바람직하다.
도메인 특정 언어는 인식 에러를 정의하는데 사용된다. 이것은 예를 들어, 변환 에러에 대한 허용가능한 한계를 정의함으로써 인식 규칙(1402)(도 14 참조)을 생성하는데 사용될 수 있다. 이러한 규칙은 에고로부터의 다양한 거리에 대해 구성가능한 안전 에러 레벨들의 세트를 구현한다. 이는 테이블(1400)에 정의되어 있다. 예를 들어, 차량이 10미터 미만 떨어져 있는 경우, 차량 위치의 에러(즉, 차량의 검출과 정제된 의사 그라운드 트루 검출 사이의 거리)는 10cm 이하로 정의될 수 있다. 에이전트가 100미터 떨어져 있는 경우, 허용가능한 에러는 최대 50cm로 정의될 수 있다. 룩업 테이블을 사용하면, 특정 사용 사례에 맞게 규칙을 정의할 수 있다. 이러한 원칙을 바탕으로 더 복잡한 규칙을 만들 수 있다. 예를 들어, 에고 차도가 다가오는 트래픽과 분리대에 의해서 분리되는 경우에 다가오는 차선에 있는 에이전트와 같이, 에고 차량에 대한 다른 에이전트의 위치에 기초하여 상기 다른 에이전트의 에러가 완전히 무시되도록 규칙이 정의될 수 있다. 정의된 컷-오프 거리를 넘어서는, 에고 뒤의 트래픽도 또한 규칙 정의에 따라 무시될 수 있다.
이후, 적용될 모든 규칙을 포함하는 인식 에러 사양(perception error specification)(1600)을 정의함으로써, 규칙들의 세트가 소정의 운전 시나리오에 함께 적용될 수 있다. 사양(1600)에 포함될 수 있는 전형적인 인식 규칙들은 종방향 및 측면 변환 에러(종방향 및 측면 방향 각각에서의 그라운드 트루에 대한 검출의 평균 에러 측정), 방향 에러(해당 그라운드 트루와 정렬하기 위해 방향을 회전하는데 필요한 최소 각도를 정의함), 사이즈 에러(감지된 경계 상자의 각 차원에 대한 에러 또는 볼륨 델타를 얻기 위해 정렬된 그라운드 트루와 감지된 상자의 합집합에 대한 교차점)에 대한 임계값들을 정의한다. 추가적인 규칙들은 에이전트의 속도 및 가속도 에러와 분류 에러(예컨대, 자동차를 보행자 또는 대형트럭(lorry)으로 잘못 분류한 경우 페널티 값 정의)를 포함한 차량 다이내믹스를 기반으로 할 수 있다. 규칙들은 검출 레이턴시 뿐만 아니라 허위 양성(false positives)나 탐지 누락(missed detections)도 포함할 수 있다.
정의된 인식 규칙들에 기초하여, 견고성 점수(robustness score)를 구축하는 것이 가능하다. 효과적으로, 이는 검출들이 규칙들의 지정된 임계값 내에 있으면 시스템이 안전하게 운전할 수 있어야 하고, 그렇지 않은 경우(예: 너무 시끄러운 경우) 에고 차량이 처리하지 못할 수도 있는 나쁜 일이 발생할 수 있으며, 이는 공식적으로 캡처되어야 한다고 말하는데 사용될 수 있다. 예를 들어, 시간 경과에 따른 검출들을 평가하고 복잡한 날씨 종속성을 통합하기 위해 복잡한 규칙 조합들이 포함될 수 있다.
이러한 규칙들은 UI에서의 시나리오 재생과 에러들을 연관시키는데 사용될 수 있다. 도 14에 도시된 바와 같이, 다양한 인식 규칙들이 해당 규칙의 타임라인에서 다양한 색상으로 나타나며, 이는 DSL에 소정 규칙 정의를 적용한 것으로부터 상이한 결과들에 대응한다. 이것은 DSL의 주요 사용 사례이다(예컨대, 분류 도구의 시각화). 사용자가 DSL에 규칙을 작성하면 해당 규칙이 UI의 타임라인에 나타난다.
DSL은 또한, 정의된 규칙에 대해 계산된 견고성 점수에 기초하여 시스템의 인식 스택과 계획 스택 간의 계약을 정의하는데 사용될 수 있다. 도 15는 소정의 에러 정의(예: 번역 에러)에 대한 견고성 점수 그래프의 일례를 보여준다. 견고성 점수가 정의된 임계값(1500)을 초과하는 경우, 이는 인식 에러가 예상 성능 내에 있으며 시스템 전체가 안전하게 운전해야 함을 나타낸다. 견고성 점수가 도 15에 도시된 바와 같이 임계값 아래로 떨어지면, 에러는 '계약 외 사항(out-of-contract)'인데, 왜냐하면 플래너(106)가 해당 레벨의 인식 에러에 대해 안전하게 운전할 것으로 기대할 수 없기 때문이다. 이러한 계약은 본질적으로 인식 시스템에 대한 요구사항 사양이 된다. 이것은 인식이나 계획 중 하나에 책임을 할당하는데 사용될 수 있다. 만일, 차량이 오작동(misbehaving)할 때 에러가 계약 내(in-contract)로 식별되면, 이는 인식 문제가 아닌 플래너의 문제를 가리키며, 반대로 인식이 계약을 벗어난 나쁜 행동의 경우 인식 에러에 책임이 있다.
계약 정보는 인식 에러가 계약 내(in-contract) 또는 계약 외(out-of-contract)로 간주되는지 여부를 주석을 달아서 UI(500)에 디스플레이될 수 있다. 이는 DSL에서 계약 사양을 가져오고 프런트-엔드에서 계약-외 에러를 자동으로 플래그하는 메커니즘을 사용한다.
도 16은 다양한 양식들(예: 실제 세계와 시뮬레이션)에 걸쳐 인식 에러들을 통합하는 제 3 사용 사례를 보여준다. 위의 설명은 실제 자동차가 주행하여 데이터를 수집하고, 개선 기술과 분류 도구(152)가 인식 에러를 계산하고 이러한 에러가 계약 내인지 계약 외인지 여부를 계산하는 실제 운전과 관련된다. 하지만, 에러를 평가하기 위한 인식 에러 규칙들을 특정하는 동일한 인식 에러 사양(1600)이 시뮬레이션된 운전 실행들에도 적용될 수 있다. 시뮬레이션은 인식 스택에 의해 프로세싱될 시뮬레이션된 센서 데이터를 생성하거나 또는 앞서 도 11을 참조하여 설명한 대로 인식 에러 모델을 사용하여 그라운드 트루로부터 직접 검출들을 시뮬레이션하는 것일 수 있다.
첫번째 경우, 시뮬레이션된 센서 데이터(1112)를 기반으로 하는 검출들은 에러(1104)를 갖게 될 것이며, DSL을 사용하여 이러한 에러가 계약 내인지 또는 계약 외인지 정의할 수 있다. 이는 또한 인식 에러 모델(208)(즉, 객체 목록에 노이즈 추가)을 기반으로 한 시뮬레이션으로 수행될 수 있으며, 여기서 시뮬레이터(202)가 모델링될 것으로 예상되는 것을 모델링하고 있는지를 확인하기 위해, 주입된 에러(1110)를 계산 및 검증하는 것이 가능하다. 또한 이는 순전히 인식 에러 때문에 상기 스택이 실패하는 것을 방지하기 위하여, 계약 외 에러를 주입하는 대신 계약 내 에러를 의도적으로 주입하는데 사용될 수도 있다. 하나의 사용 사례에서는, 계약 내이지만 계약의 에지(edge)로 향하는 에러들이 시뮬레이션에 주입되어, 플래닝 시스템이 예상되는 인식 성능을 고려하여 올바르게 수행되는지가 검증될 수 있다. 이것은 인식 개발과 플래닝을 디커플링하는데, 왜냐하면 인식과 플래닝은 이러한 계약에 대해 별도로 테스트될 수 있기 때문이며 그리고 일단 인식이 계약을 충족시키고 플래너가 계약 범위 내에서 작업하면 시스템은 만족스러운 표준에 따라 함께 작동해야만 한다.
인식 모델이 분할되는 위치에 따라, 예를 들어 융합을 수행하는 경우, 시뮬레이터에서 무엇이 나올지에 대해서 거의 알려지지 않을 수 있으므로, 계약 내 에러와 계약 외 에러에 대해 이를 평가하는 것은 시뮬레이션된 시나리오를 분석하는데 매우 유용하다.
DSL의 또 다른 적용은 의사 그라운드 트루(144) 자체의 정확성을 평가하는 것이다. 불완전한 검출들을 정제함으로써(refining) 완벽한 그라운드 트루를 획득하는 것은 불가능하지만, 안정적으로 사용되기 위해 정제 파이프라인이 도달해야만 하는 허용가능한 정확도가 존재할 수 있다. DSL 규칙들을 이용하여, 현재 시간에서의 의사 그라운드 트루를 평가하고, 그리고 '진정한(true)' GT에 현재 얼마나 가깝고 앞으로 얼마나 더 가까워져야 하는지 결정할 수 있다. 이것은 의사 그라운드 트루에 대해 계산된 온라인 인식 에러를 확인하는데 사용되는 것과 동일한 계약을 사용할 수 있지만, 정확도에 더 엄격한 경계를 적용함으로써, 평가될 온라인 검출들에 대해 의사 그라운드 트루가 충분히 '정확'하다는 충분한 확신이 있다. 의사 그라운드 트루에 대해 허용가능한 정확도는 '진정한' 그라운드 트루에 대해 측정할 때 계약 내의 에러들로 정의될 수 있다. 소정의 임계값 내에서는 정제 이후에도 약간의 에러가 발생하는 것은 허용된다. 서로 다른 시스템들이 서로 다른 사용 사례를 갖는 경우, 각 시스템은 서로 다른 DSL 규칙 세트를 적용할 것이다.
정제된 검출들이 평가되는 '진정한' 그라운드 트루는 실제 데이터 세트를 선택하고, 수동으로 주석을 달고, 정의된 DSL 규칙에 따라 이러한 수동 GT에 대해 의사 GT를 평가하고, 그리고 허용가능한 정확도가 달성되었는지를 결정함으로써 획득된다. 정제 파이프라인(refinement pipeline)이 업데이트될 때마다, 정제된 검출들에 대한 정확도 평가를 다시 실행하여 파이프라인이 회귀되지 않는지를 확인할 수 있다.
DSL의 또 다른 적용은 일단 인식(102)과 플래닝(106) 사이에서 계약이 정의되면, 인식 계층에서 수행되어야 하는 테스트 유형을 분할할 수 있다는 것이다. 이는 도 17에 도시되어 있다. 예를 들어, 인식 계층에는 모두가 계약 내라고 간주되는 에러들을 포함하는 일련의 센서 판독값이 제공될 수 있다. DSL 규칙을 적용하여 그러한 경우인지를 확인할 수 있다. 플래닝 계층의 경우에도 마찬가지로, 그라운드 트루 테스트(1702)가 먼저 적용될 수 있으며, 이것이 통과되면, 계약 내 테스트(1704)가 적용되며, 따라서 시스템에는 계약 내 에러를 갖는 객체 목록이 제공되고, 플래너가 안전하게 작동하는지 확인한다.
하나의 예시적인 테스트 방식에서, 플래너는 '주어진' 것으로 간주될 수 있으며, 시뮬레이션은 인식 에러를 생성하고 그리고 플래너가 의도한 대로 수행하는데 허용될 인식 정확도의 제한들을 찾는데 사용될 수 있다. 이러한 제한들은 인식 시스템에 대한 계약을 반자동으로 생성하는데 이용될 수 있다. 일련의 인식 시스템들이 이러한 계약에 대해 테스트되여 이를 충족하는 시스템을 찾아내거나 또는 상기 계약은 인식 시스템을 개발할 때 가이드로 사용될 수 있다.
실제 운전 분석 도구(Real-World Driving Analysis Tool)
앞서 설명된 테스트 프레임워크, 즉 테스트 오라클(252)과 인식 분류 도구(152)는 실제 운전 분석 도구에 결합될 수 있으며, 여기서 인식과 운전 평가 둘다는 도 2c에 도시된 바와 같이 그라운드 트루 파이프라인(400)에서 추출된 인식 그라운드 트루에 적용된다.
도 12a는 실제 데이터에서 추출된 운전 시나리오를 분석하기 위한 사용자 인터페이스의 일례를 보여준다. 도 12a의 예에서, 장면의 오버헤드 개략 표현(1204)은 포인트 클라우드 데이터(예를 들어, LiDAR, 레이더 또는 스테레오 또는 모노 심도 이미징에서 파생된 데이터)를 기반으로 표시되며 해당 카메라 프레임(1224)은 삽입되어 표시된다. 도로 레이아웃 정보는 고화질 지도 데이터로부터 얻을 수 있다. 카메라 프레임(1224)에는 검출들에 대한 주석이 추가될 수도 있다. UI는 LiDAR, 레이더, 카메라 데이터 등과 같은 운전 중에 수집된 센서 데이터도 도시할 수 있다. 이는 도 12b에 도시된다. 장면 시각화(1204)는 또한 파생된 의사 그라운드 트루 뿐만 아니라 온보드 인식 컴포넌트로부터의 검출들에 기초한 주석으로 오버레이된다. 도시된 일례에는 3대의 차량이 있으며, 각 차량에는 상자로 주석이 표시되어 있다. 솔리드 상자(solid boxes)(1220)는 장면의 에이전트들에 대한 의사 그라운드 트루를 보여주는 반면에, 윤곽선(1222)은 에고의 인식 스택(102)으로부터의 정제되지 않은 검출들을 보여준다. 시각화 메뉴(1218)가 도시되며, 시각화 메뉴(1218)에서 사용자는 디스플레이할 어떤 센서 데이터, 온라인 및 오프라인 검출들을 선택할 수 있다. 이것은 필요에 따라 온 및 오프로 토글링될 수 있다. 차량의 검출들 및 그라운드 트루 검출들과 함께 실제 센서 데이터를 보여주면, 사용자는 차량의 검출에서 소정의 에러들을 식별하거나 확인할 수 있다. UI(500)는 선택된 장면(footage)의 재생을 허용하며 그리고 타임라인 뷰가 도시되는바, 타임라인 뷰에서 사용자는 영상의 임의의 지점(1216)을 선택하여 선택된 시점에 대응하는 카메라 프레임과 조감도(bird's eye view)의 스냅샷을 표시할 수 있다.
전술한 바와 같이, 인식 스택(102)은 정제된 의사 그라운드 트루(144)과 상기 검출들을 비교함으로써 평가될 수 있다. 인식은 특정 AV 스택의 사용 사례에 따라 달라질 수 있는 정의된 인식 규칙(1106)에 대해 평가된다. 이러한 규칙들은 위치, 방향 또는 자동차 검출들의 스케일과 의사 그라운드 트루 검출들의 그것들 사이의 불일치에 대한 다양한 범위들의 값들을 지정한다. 상기 규칙들은 도메인 특정 언어로 정의될 수 있다(도 14를 참조하여 위에 설명됨). 도 12a에 도시된 바와 같이, 다양한 인식 규칙 결과들은 인식 규칙들의 결과들을 집계하는 운전 시나리오의 '최상위' 인식 타임라인(1206)을 따라 도시되며, 임의의 인식 규칙이 위반될 때 타임라인 상의 기간들이 플래그된다. 이는 정의된 규칙 각각에 대한 개별 인식 규칙 타임라인들(1210)의 세트를 표시하도록 확장될 수 있다.
인식 에러 타임라인은 운전 실행의 더 긴 기간을 표시하기 위해 '줌 아웃'될 수 있다. 줌 아웃된 뷰에서는, 줌 인되었을 때와 동일한 세분성으로 인식 에러를 디스플레이하는 것이 불가능할 수 있다. 이 경우, 타임라인은 시간 윈도우에 대한 인식 에러들의 집계를 디스플레이하여, 줌 아웃된 뷰에 대한 인식 에러들의 요약된 세트를 제공할 수 있다.
제 2 운전 평가 타임라인(1208)은 의사 그라운드 트루 데이터가 운전 규칙에 대해 어떻게 평가되는지를 보여준다. 집계된 운전 규칙은 최상위 타임라인(1208)에 표시되며, 이는 각각의 정의된 운전 규칙에 대한 성능을 표시하는 개별 타임라인 세트(1212)로 확장될 수 있다. 도시된 바와 같이, 각각의 규칙 타임라인은 주어진 규칙에 대해 시간에 따른 수치적 성능 점수의 플롯(1228)을 디스플레이하기 위해 추가로 확장될 수 있다. 이는 도 9c를 참조하여 앞서 설명한 선택가능한 요소(534b)에 대응한다. 이 경우, 의사 그라운드 트루 검출들은 장면에 있는 에이전트들의 실제 운전 거동으로 간주된다. 에고 거동은 정의된 운전 규칙들에 대해 평가될 수 있는바, 예를 들어 디지털 고속도로 코드(Digital Highway Code)를 기반으로 차량이 주어진 시나리오에서 안전하게 행동했는지를 확인할 수 있다.
요약하면, 인식 규칙 평가와 운전 평가는 둘다, 실제 운전으로부터의 검출들을 정제하기 위해, 앞서 설명한 오프라인 인식 방법을 사용하는 것을 기반으로 한다. 운전 평가의 경우, 정제된 의사 그라운드 트루(144)을 사용하여 운전 규칙에 대한 에고 거동을 평가한다. 도 2c에 표시된 것처럼 이는 테스트용 시뮬레이션 시나리오를 생성하는데에도 사용될 수 있다. 인식 규칙 평가를 위해, 인식 분류 도구(152)는 기록된 차량 검출들 오프라인의 정제된 검출들을 비교하여 가능한 인식 실패들을 신속하게 식별 및 분류한다.
드라이브 노트는 또한 운전자 노트 타임라인 뷰(1214)에 디스플레이될 수 있으며, 여기에는 운전 중에 표시된 주목할만한 이벤트가 디스플레이될 수 있다. 예를 들어, 드라이브 노트는 차량이 브레이크를 밟거나 방향을 바꾸는 포인트나 또는 인간 운전자가 AV 스택을 해제(disengage)하는 포인트를 포함할 것이다.
사용자가 잠재적인 문제를 디버깅하고 분류하는데 도움이 되도록 사용자 정의 메트릭이 표시되는 추가적인 타임라인이 디스플레이될 수 있다. 사용자 정의 메트릭은, 에러들 또는 스택 결함을 식별할 뿐만 아니라 에러들이 발생할 때 이들 에러들을 분류하기 위해 정의될 수 있다. 사용자는 주어진 AV 스택의 목표에 따라 커스텀 메트릭을 정의할 수 있다. 예시적인 사용자 정의 메트릭은 메시지가 순서 없이 도착할 때, 또는 인식 메시지들의 메시지 레이턴시를 플래그할 수 있다. 이것은 플래너의 실수로 인하여 또는 늦게 도착한 혹은 잘못된 순서로 도착한 메시지로 인하여 플래닝이 발생했는지를 결정하는데 이용될 수 있기 때문에 분류에 매우 유용하다.
도 12b는 삽입 뷰(insec view)에 디스플레이되는 카메라 프레임(1224)과 함께 센서 데이터가 디스플레이되는 UI 시각화(1204)의 일례를 보여준다. 일반적으로, 센서 데이터는 시간에 따른 단일 스냅샷으로부터 도시된다. 하지만, 고화질 지도 데이터를 사용할 수 없는 경우, 각각의 프레임은 정적 장면 지도를 얻기 위해 여러 시간 단계들에 걸쳐 집계된 센서 데이터를 도시할 수도 있다. 왼쪽에 도시된 것처럼, 가령, 실제 시나리오 동안 수집된 카메라, 레이더 또는 LiDAR 데이터 또는 에고 차량 자신의 인식으로부터의 온라인 검출들과 같은 데이터를 디스플레이하거나 숨기기 위한 여러 시각화 옵션들(1218)이 존재한다. 본 일례에서, 차량으로부터의 온라인 검출들은 그라운드 트루 정제 검출들을 나타내는 단색 상자(solid box)(1220) 위에 오버레이된 윤곽선(1222)으로 표시된다. 그라운드 트루와 차량의 검출들 사이에서 방향 에러가 나타날 수 있다.
그라운드 트루 파이프라인(400)에 의해 수행되는 정제(refinement) 프로세스는 다수의 툴들에 대한 기초로서 의사 그라운드 트루(144)을 생성하는데 사용된다. 도시된 UI는 인식 분류 도구(152)로부터의 결과를 디스플레이하며, 이는 테스트 오라클(252)을 이용하는 단일 운전 사례에 대한 ADAS의 운전 능력을 평가하고, 결함들을 검출하고, 문제를 재현하기 위해 시나리오를 추출하고(도 2C 참조) 그리고 스택을 개선하기 위해 개발자에게 식별된 문제를 전송할 수 있게한다.
도 12c는 시나리오의 하위 섹션에서 사용자가 줌인을 할 수 있도록 구성된 사용자 인터페이스의 일례를 보여준다. 도 12c는 도 12a에 대해 전술한 바와 같이, 개략적인 표현(1204) 및 삽입 뷰에 도시된 카메라 프레임(1224) 뿐만 아니라, 시나리오의 스냅샷을 보여준다. 전술한 바와 같이, 인식 에러 타임라인들의 세트(1206, 1210), 뿐만 아니라 확장가능한 운전 평가 타임라인(1208) 및 운전자 노트모 타임라인(1214)도 도 12c에 도시되어 있다.
도 12c에 도시된 일례에서, 운전 시나리오의 현재 스냅샷은 모든 타임라인 뷰들에 걸쳐 동시에 확장되는 스크러버 바(1230)에 의해 표시된다. 이것은, 단일 재생 바(single playback bar) 상의 시나리오에서 현재 포인트의 표시(1216) 대신에 사용될 수 있다. 사용자는 운전 시나리오에 대한 임의의 시점으로 바를 선택 및 이동시키기 위해 스크러버 바(1230)를 클릭할 수 있다. 예를 들어, 사용자는 예컨대, 빨간색으로 표시된 섹션 내의 포인트 또는 위치 에러 타임라인 상의 에러를 포함하는 섹션으로 표시된 포인트와 같은 특정 에러에 관심이 있을 수 있으며, 여기서 이러한 표시는 '그라운드 트루'와 표시된 섹터에 대응하는 시간 기간에서의 검출들의 사이의 해당 시간에서 관찰된 위치 에러에 기초하여 결정된다. 사용자는 스크러버 바를 클릭하고, 위치 에러 타임라인 내에서 관심 포인트로 스크러버 바를 드래그할 수 있다. 대안적으로, 사용자는 스크러버가 확장되는 타임라인 상의 임의의 포인트를 클릭하여, 스크러버를 해당 포인트에 위치시킬 수 있다. 이는 개략도(1204)와 삽입도(1224)를 업데이트하여, 선택된 시점에 대응하는 각각의 탑-다운 개략도와 카메라 프레임을 보여준다. 그런 다음 사용자는 개략 뷰 및 이용가능한 카메라 데이터 또는 기타 센서 데이터를 검사하여, 위치 에러를 확인하고 인식 에러의 가능한 원인을 식별할 수 있다.
'눈금자(ruler)' 바(1232)는 인식 타임라인(1206) 위와 개략도 아래에 도시된다. 이것은 운전 시나리오의 시간 인터벌들을 나타내는 일련의 '노치들(notches)'을 포함한다. 예를 들어, 타임라인 뷰에 10초의 시간 간격이 디스플레이되는 경우, 1초 간격을 나타내는 노치들이 표시된다. 일부 시점에는 숫자 표시(예: '0초', '10초' 등)가 표시된다.
사용자 인터페이스 하단에는 줌 슬라이더(1234)가 제공된다. 사용자는 줌 슬라이더를 따라 표시자(indicator)를 드래그하여 타임라인 상에 도시되는 운전 시나리오의 부분을 변경할 수 있다. 대안적으로, 표시자가 이동될 슬라이더 바 상의 원하는 포인트를 클릭함으로써, 표시자의 위치를 조정할 수 있다. 현재 선택된 줌 레벨을 나타내는 백분율이 표시된다. 예를 들어, 전체 운전 시나리오의 길이가 1분인 경우, 타임라인들(1206,1208,1214)은 1분 동안의 운전에 대한 각각의 인식 에러들, 운전 평가 및 운전자 노트를 도시하고, 줌 슬라이더는 100%를 표시하며, 버튼은 가장 좌측 위치에 있다. 줌 슬라이더가 200%로 표시될 때까지 사용자가 버튼을 슬라이드하면, 시나리오의 30초 스니펫(snippet)에 해당하는 결과만을 표시하도록 타임라인이 조정될 것이다.
스크러버 바의 위치에 따라 타임라인의 디스플레이된 부분을 조정하도록 줌(zoom)이 구성될 수 있다. 예를 들어, 1분 시나리오에 대해 줌이 200%로 설정된 경우, 줌-인된 타임라인은 30초 스니펫을 보여줄 것이며, 여기서 스크러버가 위치하는 선택된 시점은 중앙에 있을 것이다. 즉, 타임라인의 15초는 스크러버가 가리키는 포인트 전후에 표시된다. 대안적으로, 시나리오의 시작 등과 같은 기준점에 대하여 줌이 적용될 수도 있다. 이 경우, 확대 이후 타임라인에 표시되는 줌-인된 스니펫은 항상 시나리오 시작 부분에서 시작된다. 타임라인이 확대되거나 축소되는 정도에 따라, 눈금자 바(1232)의 노치들 및 숫자 라벨들의 입도가 조정될 수 있다. 예를 들어, 3초의 스니펫(snippet)을 보기 위해 시나리오를 30초로부터 줌인하는 경우, 숫자 라벨은 줌인하기 전에 1초 간격의 노치들과 함께 10초 간격으로 디스플레이될 수 있으며, 줌인 이후에 숫자 라벨은 1초 간격으로 디스플레이되고 노치는 100ms 간격으로 디스플레이될 수 있다. 타임라인들(1206,1208,12140에서 시간 단계들(timesteps)의 시각화는 줌인된 스니펫들에 대응하도록 늘어난다(stretched). UI 내의 타임라인의 디스플레이에서 시간 상의 더 작은 스니펫들이 더 큰 영역에 의해 표현될 수 있으므로, 줌인된 뷰의 타임라인들 상에 더 높은 레벨의 세부정보가 디스플레이될 수 있다. 따라서, 긴 시나리오 내에서 매우 짧은 시간 동안 발생하는 에러는 줌인된 이후의 타임라인 뷰에서만 보여질 수 있다.
다른 줌 입력들이 타임라인을 조절하는데 이용되어, 시나리오의 더 짧거나 더 긴 스니펫들을 디스플레이할 수 있다. 예를 들어, 사용자 인터페이스가 터치 스크린 디바이스에서 구현되는 경우, 사용자는 핀치 제스처를 적용함으로써 타임라인에 줌을 적용할 수 있다. 다른 일례에서, 사용자는 줌 레벨을 변경하기 위해 마우스의 스크롤 휠을 앞뒤로 스크롤링할 수 있다.
운전 시나리오의 서브세트만을 보여주기 위하여 타임라인이 줌인되는 경우, 디스플레이된 부분을 시간 상으로 시프트하도록 타임라인이 시간 상으로 스크롤링될 수 있으며 따라서, 타임라인 뷰에서 시나리오의 상이한 부분들이 사용자에 의해 검사될 수 있다. 사용자는 타임라인 뷰 하단에서 스크롤 바(미도시)를 클릭 앤 드래그하거나, 또는 예를 들어 UI가 실행 중인 해당 디바이스의 터치 패드를 이용하여 스크롤링할 수 있다.
사용자는 예를 들어, 추가 분석을 위해 송출되거나 또는 시뮬레이션의 기초로서, 시나리오의 스니펫들을 선택할 수 있다. 도 12d는 사용자가 운전 시나리오의 섹션을 선택하는 방법을 보여준다. 사용자는 눈금자 막대(1232)의 관련 지점을 커서로 클릭할 수 있다. 이는 임의의 줌 레벨에서 수행될 수 있다. 이는 사용자 선택에 대한 제 1 제한을 설정한다. 사용자는 선택한 시점으로 선택 영역을 확장하기 위해 타임라인을 따라 커서를 드래그할 수 있다. 줌인의 경우, 시나리오의 디스플레이된 스니펫의 끝 부분까지 계속 드래그하면 타임라인들이 앞으로 스크롤되어 선택이 더욱 확장될 수 있다. 사용자는 언제든지 드래그를 멈출 수 있으며, 사용자가 멈추는 지점이 사용자 선택에 대한 종료 제한(end limit)이다. 사용자 인터페이스 하단의 막대(1230)는 선택된 스니펫의 시간 길이를 디스플레이하며, 이러한 값은 사용자가 선택을 확장하거나 축소하기 위해 커서를 드래그함에 따라 업데이트된다. 선택된 스니펫(1238)은 눈금자 막대 상에서 음영처리된 섹션으로 표시된다. 다수의 버튼(1236)들이 도시되어 있으며, 이는 선택에 대응하는 데이터를 추출하기 위해 '트레이스 시나리오 추출(Extract Trace Scenario)'과 같은 사용자 액션을 제공한다. 이것은 추출된 시나리오의 데이터베이스에 저장될 수 있다. 이것은 추가 분석이나 유사한 시나리오를 시뮬레이션하기 위한 기초로 사용될 수 있다. 선택을 한 후, 사용자는 줌인 또는 줌아웃할 수 있고 그리고 눈금자 막대(1232) 상의 선택(1238)은 또한 눈금자 및 인식, 운전 평가 및 운전 노트 타임라인을 따라 늘어나거나 줄어들 수 있다.
의사 그라운드 트루 데이터는 데이터 탐색 도구와 함께 사용되어 데이터베이스 내에서 데이터를 검색할 수도 있다. 이러한 도구는 새 버전의 AV 스택이 배포될 때 사용될 수 있다. 새로운 버전의 소프트웨어의 경우, 데이터를 수집하기 위해 일정 기간(예: 일주일) 동안 차량이 운행될 수 있다. 이러한 데이터 내에서 사용자는 특정 조건에서 자동차가 어떻게 거동하는지 테스트하는데 관심이 있을 수 있으며, 따라서 사용자는 '모든 야간 운전을 보여줘' 또는 '비가 올 때 보여줘' 등과 같은 질의를 제공할 수 있다. 데이터 탐색 도구는 관련 영상을 추출할 것이며 그리고 분류 도구를 사용하여 조사할 수 있다. 데이터 탐색 도구는 추가 분석을 위한 일종의 진입점(entry point) 역할을 수행한다.
예를 들어, 새로운 소프트웨어 버전이 구현되고 그리고 AV가 한동안 운행되어 특정 분량의 데이터를 수집한 경우, 추가 평가 도구가 이용되어 차량의 집계 성능에 대한 아이디어를 얻기위해 데이터를 집계할 수 있다. 이러한 자동차에는 새로 개발된 일련의 피처들 예컨대, 표시자(indicator) 사용, 로터리 진입 및 진출이 있을 수 있으며, 이러한 피처들에 대해 자동차가 얼마나 잘 작동하는지에 대한 종합적인 성능 평가를 원할 수 있다.
마지막으로, 회귀 문제를 체크하기 위해 새로운 스택에서 센서 데이터를 실행함으로써 오픈-루프 시뮬레이션을 실행하는데 재시뮬레이션 도구가 이용될 수 있다.
도 13은 시나리오 시각화(1204) 및 인식 에러 타임라인(1206, 1210) 상의 포커싱된 뷰와 함께 인식 분류 도구(152)에 대한 예시적인 사용자 인터페이스를 보여준다. 좌측에 도시된 바와 같이, 실제 시나리오 동안 수집된 카메라, 레이더 또는 라이다(LiDAR) 데이터, 또는 에고 차량 자체 인식으로부터의 온라인 검출 등과 같은 데이터를 표시하거나 숨길 수 있는 여러 시각화 옵션(1218)이 존재한다. 이 경우 시각화는 정제된 검출들 만으로 제한되는바, 즉 솔리드 상자로 도시된 정제를 통해 오프라인으로 검출된 에이전트들만으로 제한된다. 각각의 솔리드 상자는 관련된 온라인 검출(표시되지 않음)을 갖는데, 이는 해당 스냅샷에서 에러 수정/정제 이전에 에이전트가 인식된 방식이다. 전술한 바와 같이, 그라운드 트루(144)와 오리지널 검출 사이에는 소정 분량의 에러가 있다. 허위 양성(false positives) '고스트' 검출들 및 검출 누락 뿐만 아니라, 장면 내 에이전트들의 스케일, 위치 및 방향 에러들을 포함하는 다양한 에러들이 정의될 수 있다.
앞서 설명한 바와 같이, 모든 에러들이 동일한 중요성을 갖는 것은 아니다. 인식 규칙들에 대한 DSL을 사용하면, 필요한 사용 사례에 따라 규칙들을 정의할 수 있다. 예를 들어, 직선 도로에서 주행하기 위한 크루즈 컨트롤 시스템을 설계하는 경우, 이것은 변환 에러(translation error)에 민감해야 하지만 방향 에러에 특별히 민감할 필요는 없다. 그러나 로터리 진입을 처리하는 AV는 검출된 에이전트의 방향을 에이전트가 로터리를 떠나는지 여부와 로터리에 진입하는 것이 안전한지 여부에 대한 지표로서 사용하므로 방향 에러에 매우 민감해야 한다. 인식 에러 프레임워크를 사용하면 해당 사용 사례에 대한 소정의 변환 에러 또는 방향 에러의 상대적 중요성을 나타내는 별도의 테이블과 규칙을 정의할 수 있다. 도 13의 에고 차량 주위에 표시된 상자들은 인식 규칙이 목표로 정의될 수 있는 관심 영역을 보여주기 위한 예시용이다. 규칙 평가 결과는 인식 에러 타임라인(1210) 내에서 사용자 인터페이스에 표시될 수 있다. 규칙의 시각적 표시자는 또한 예를 들어 특정 규칙이 정의된 영역에 플래그를 지정하여 도식적 표현(1204)에 표시될 수 있다. 이는 도 13에 도시되어 있지 않다.
운전 실행의 단일 스냅샷에 대한 결과를 디스플레이하는 것 외에도, 질의(querying) 및 필터링을 적용하여 인식 평가 결과에 따라 데이터를 필터링하고 분석을 수행하는 사용자에게 더 많은 컨텍스트를 제공할 수 있다.
도 18a 및 도 18b는 실제 주행에 대한 인식 결과를 필터링하고 디스플레이하기 위한 그래픽 사용자 인터페이스(500)의 일례를 도시한다. 주어진 실행에 대해, 모든 인식 에러들에 대한 집계된 규칙 평가가 포함된 인식 에러 타임라인(1206)이 이전에 설명된 대로 디스플레이된다. 날씨 조건, 도로 특징, 다른 차량들 및 취약한 도로 사용자들과 같은 운전 장면의 특징을 나타내는 타임라인의 제 2 세트(1226)가 도시될 수 있다. 이들은 인식 에러 규칙을 정의하는데 사용되는 동일한 프레임워크 내에서 정의될 수 있다. 다양한 운전 조건에 따라 다양한 임계값이 적용되도록 인식 규칙이 정의될 수 있다는 점에 유의해야 한다. 도 18a는 또한 사용자가 평가에 적용할 질의를 선택할 수 있는 필터링 피처(1800)를 보여준다. 이러한 일례에서, 사용자 질의는 취약한 도로 사용자(VRU)가 존재하는 운전 실행의 '슬라이스들'를 찾아내는 것이다.
질의는 처리되어 취약한 도로 사용자가 태그되는 운전 시나리오 표현의 프레임들을 필터링하기 위해 처리 및 사용된다. 도 18b는 필터가 적용된 이후의 인식 타임라인의 업데이트된 뷰를 보여준다. 도시된 바와 같이, 오리지널 타임라인의 서브세트가 표시되며, 이러한 서브세트에서는 'VRU' 타임라인에 표시된 대로 취약한 사용자가 항상 존재한다.
도 19a는 그래픽 사용자 인터페이스(500) 내에서 분석을 수행하는데 사용될 수 있는 또 다른 피처를 도시한다. 사용자가 조정할 수 있는 한 세트의 에러 임계값 슬라이더(1900)가 도시되어 있다. 에러들의 범위는 인식 규칙들에 대해 DSL에 정의된 인식 에러 한계값에 의해 알려질 수 있다. 사용자는 해당 에러에 대해 원하는 신규 임계값으로 마커를 슬라이딩하여 특정 에러에 대한 임계값을 조정할 수 있다. 예를 들어, 사용자는 31m의 번환 에러에 대한 실패 임계값을 설정할 수 있다. 그런 다음 이 임계값은 앞서 설명된 인식 규칙 DSL에 작성된 인식 규칙 사양 내에 정의된 변환 에러로 피드백되어, 새로운 임계값을 고려하도록 규칙 정의를 조정할 수 있다. 새로운 규칙 평가는 프런트 엔드로 전달되고, 새로운 임계값에 대해 현재 발생하고 있는 규칙 실패들은 주어진 에러에 대해 확장된 타임라인 뷰(1210)에 표시된다. 도 19a에 도시된 바와 같이, 허용할 수 없는 에러 값에 대한 임계값을 감소시키면, 더 많은 에러가 타임라인에 플래그된다.
도 19b는 계산된 인식 에러들에 기초하여 가장 관련성이 높은 프레임들을 사용자가 선택하고 검사할 수 있도록, 운전 시나리오의 선택된 슬라이들에 집계 분석을 어떻게 적용할 수 있는지를 보여준다. 앞서 설명된 바와 같이, 사용자는 필터링 피처(1800)를 사용하여 취약한 도로 사용자가 존재하는 프레임만을 표시하도록 시나리오를 필터링할 수 있다. 매칭되는 프레임 내에서, 사용자는, 타임라인(1206)을 따라 드래그되고 관심 기간을 포함하도록 확장될 수 있는 선택 도구(1902)를 이용하여, 시나리오를 특정 스니펫으로 추가로 '슬라이스'할 수 있다. 선택된 스니펫에 대해, 일부 집계 데이터가 디스플레이(1904)에서 사용자에게 표시될 수 있다. 선택된 스니펫 내에서 캡처된 인식 에러의 다양한 속성이 선택되어 서로에 대해 그래프로 표시될 수 있다. 도시된 일례에서, 에러 유형과 에러 크기가 그래프화되며, 따라서 사용자는 시나리오의 선택된 부분에 대해 각 유형의 가장 중요한 에러를 시각화할 수 있다. 사용자는 그래프 상의 임의의 지점을 선택하여, 폐색(occlusion)과 같은 장면의 다른 변수들와 함께 해당 에러가 발생한 해당 프레임에 대한 카메라 이미지(1906)를 디스플레이할 수 있으며, 사용자는 에러를 유발할 수 있었던 임의의 요인들에 대해 프레임을 검사할 수 있다.
앞서 언급한 데이터 탐색 및 집계 평가 도구를 포함하여, 차량의 성능을 질의, 집계 및 분석하는 추가 도구 뿐만 아니라, 인식 분류 도구(152) 및 테스트 오라클(252)과 함께 그라운드 트루 파이프라인(400)이 이용될 수 있다. 그래픽 사용자 인터페이스(500)는 위에서 설명된 스냅샷 보기에 더하여 이러한 도구로부터의 결과를 표시할 수 있다.
비록 위의 일례들에서는 AV 스택 테스트를 고려하지만, 이러한 기술은 다른 형태의 모바일 로봇의 컴포넌트들을 테스트하는데에도 적용될 수 있다. 예를 들어, 내부 및 외부 산업 구역에서 화물 공급품을 운반하기 위한 여러 모바일 로봇이 개발되고 있다. 이러한 모바일 로봇에는 사람이 탑승하지 않으며, UAV(무인 자율 차량)라는 모바일 로봇 클래스에 속한다. 자율 에어 모바일 로봇(드론)도 개발 중이다.
본 명세서에서 컴포넌트들, 기능들, 모듈들 등에 대한 참조는 다양한 방식으로 하드웨어 레벨에서 구현될 수 있는 컴퓨터 시스템의 기능적 컴포넌트들을 나타낸다. 컴퓨터 시스템은 실행 하드웨어를 포함하며, 실행 하드웨어는 본 문서에 개시된 방법/알고리즘 단계들을 실행하거나 및/또는 본 기술을 사용하여 트레이닝된 모델을 구현하도록 구성될 수 있다. 실행 하드웨어라는 용어는 관련 방법/알고리즘 단계들을 실행하도록 구성된 하드웨어의 모든 형태/조합을 포함한다. 실행 하드웨어는 프로그래밍이 가능하거나 또는 프로그래밍이 불가능할 수 있는 하나 이상의 프로세서들의 형태를 취할 수 있으며, 프로그래밍 가능 하드웨어와 프로그래밍 불가능 하드웨어의 조합이 사용될 수도 있다. 적합한 프로그래밍 가능 프로세서의 일례는 CPU, GPU/가속기 프로세서 등과 같은 명령어 세트 아키텍처를 기반으로 하는 범용 프로세서를 포함한다. 일반적으로, 이러한 범용 프로세서는 프로세서에 연결된 또는 프로세서 내부의 메모리에 유지되는 컴퓨터 판독가능 명령들을 실행하고 그리고 이들 명령들에 따라 관련 단계들을 수행한다. 다른 형태의 프로그래밍가능 프로세서는 필드 프로그래밍가능 게이트 어레이(FPGA)를 포함하며, 이는 회로 서술 코드(circuit description code)를 통해 프로그래밍가능한 회로 구성을 갖는다. 프로그래밍이 불가능한 프로세서의 일례는 ASIC(주문형 집적 회로)를 포함한다. 코드, 명령 등은 일시적 또는 비일시적 매체에 적절하게 저장될 수 있으며, 비일시적 매체의 일례는 솔리드-스테이트, 자기 및 광학 저장 디바이스 등을 포함한다. 도 2a의 런타임 스택의 서브시스템(102-108)은 프로그래밍 가능 프로세서 또는 전용 프로세서(들), 또는 이 둘의 조합, 테스트 등의 맥락에서 차량 내장 또는 외장 컴퓨터 시스템에서 구현될 수 있다. 시뮬레이터(202) 및 테스트 오라클(252)과 같은 도11 및 도 6을 포함하는 도면들의 다양한 컴포넌트들은 프로그래밍 가능 및/또는 전용 하드웨어에서 유사하게 구현될 수 있다.
Claims (33)
- 센서 장착 차량에 배치하기 위한 실시간 인식 시스템(real-time perception system)을 테스트하기 위한 컴퓨터 시스템으로서,
센서 장착 차량에 의해 수행된 적어도 하나의 실제 운전 실행(real-world driving run)의 데이터를 수신하는 적어도 하나의 입력, 상기 데이터는 (i) 센서 장착 차량에 의해 캡처된 시계열적(time-series) 센서 데이터 및 (ii) 테스트 중인 상기 실시간 인식 시스템에 의해 그로부터 추출된 적어도 하나의 관련된 시계열적 런타임 인식 출력들을 포함하며;
그래픽 사용자 인터페이스(GUI)를 렌더링하기 위한 렌더링 데이터를 생성하는 렌더링 컴포넌트, 상기 그래픽 사용자 인터페이스는 인식 에러 타임라인을 포함하고, 상기 인식 에러 타임라인은 상기 적어도 하나의 실제 운전 실행의 다수의 시간 단계들 각각에 대해, 해당 시간 단계에서 발생한 인식 에러의 시각적 표시를 가지며;
상기 런타임 인식 출력들과 비교하도록 적어도 하나의 시계열적 그라운드 트루 인식 출력들을 추출하기 위해 적어도 하나의 비실시간 및/또는 비인과적(non-causal) 인식 알고리즘을 적용함으로써, (i) 상기 시계열적 센서 데이터 및 (ii) 상기 시계열적 런타임 인식 출력들 중 적어도 하나를 프로세싱하도록 구성된 그라운드 트루 파이프라인(ground truthing pipeline); 및
상기 시계열적 그라운드 트루 인식 출력들과 상기 시계열적 런타임 인식 출력들을 비교하고, 그리고 이에 의해서 인식 에러 타임라인을 생성하기 위해 하나 이상의 시간 간격들에서 발생한 인식 에러들을 식별하도록 구성된 인식 오라클(perception oracle)
을 포함하는 것을 특징으로 하는 컴퓨터 시스템. - 제1항에 있어서,
상기 인식 오라클은, 상기 시계열적 런타임 인식 출력들과 상기 시계열적 그라운드 트루 인식 출력들 사이의 수치적 에러 값들을 계산하고, 그리고 상기 수치적 에러 값들을 적어도 하나의 인식 에러 임계값과 비교함으로써 인식 에러들을 식별하는 것을 특징으로 하는 컴퓨터 시스템. - 제2항에 있어서,
상기 수치적 에러 값이 적어도 하나의 인식 에러 임계값들 중 하나 이상을 초과하는 경우, 수치적 에러 값은 인식 에러로서 식별되는 것을 특징으로 하는 컴퓨터 시스템. - 제2항 또는 제3항에 있어서,
상기 적어도 하나의 인식 에러 임계값은 고정되어 있는 것을 특징으로 하는 컴퓨터 시스템. - 제2항 또는 제3항에 있어서,
상기 적어도 하나의 인식 에러 임계값은 하나 이상의 장면 변수에 따라 가변적인 것을 특징으로 하는 컴퓨터 시스템. - 제2항 내지 제5항 중 어느 한 항에 있어서,
상기 에러 임계값은 그래픽 사용자 인터페이스를 통해 조정가능한 것을 특징으로 하는 컴퓨터 시스템. - 제2항 내지 제6항 중 어느 한 항에 있어서,
상기 에러 임계값은 상기 인식 오라클에 제공되는 규칙 정의 명령을 통해 조정가능한 것을 특징으로 하는 컴퓨터 시스템. - 제7항에 있어서,
도메인 특정 언어(DSL: Domain Specific Language)로 코딩된 규칙 정의 명령을 포함하는 인식 에러 사양(specification)을 정의하기 위해 규칙 편집기(rule editor)가 사용되는 것을 특징으로 하는 컴퓨터 시스템. - 제5항에 있어서,
상기 하나 이상의 장면 변수는 인지된 객체와 에고 에이전트 사이의 거리를 포함하고, 가변 임계값은 객체와 에고 에이전트 사이의 거리에 따라 증가되는 것을 특징으로 하는 컴퓨터 시스템. - 제4항에 있어서,
상기 수치적 에러 값은 하나 이상의 장면 변수에 따라 가중되는 것을 특징으로 하는 컴퓨터 시스템. - 제2항 내지 제10항 중 어느 한 항에 있어서,
상기 수치적 에러 값은 미리 결정된 범위로 정규화되는 것을 특징으로 하는 컴퓨터 시스템. - 제2항 내지 제11항 중 어느 한 항에 있어서,
상기 식별된 인식 에러들과 함께 상기 수치적 에러 값이 GUI를 통해 액세스 가능하게 렌더링되는 것을 특징으로 하는 컴퓨터 시스템. - 제1항 내지 제12 항 중 어느 한 항에 있어서,
상기 인식 에러는,
이진 표시자(binary indicator);
이진이 아닌 범주형 표시자(non-binary categorical indicator)
중 적어도 하나를 포함하는 것을 특징으로 하는 컴퓨터 시스템. - 제1항 내지 제13항 중 어느 한 항에 있어서,
상기 인식 에러는 다수의 객체들 및/또는 센서들 및/또는 센서 양식들 및/또는 시간 윈도우들에 걸쳐 계산된 집계된 에러를 포함하는 것을 특징으로 하는 컴퓨터 시스템. - 제14항에 있어서,
복수의 하위 레벨 인식 에러 타임라인이 정의되고, 탑(top) 레벨 집계 인식 에러 타임라인은 상기 하위 레벨 인식 에러 타임라인에 미리결정된 규칙을 적용함으로써 채워지는 것을 특징으로 하는 컴퓨터 시스템. - 제15항에 있어서,
상기 탑 레벨 타임라인은 상기 하위 레벨 타임라인을 보기 위해 확장가능한 것을 특징으로 하는 컴퓨터 시스템. - 제1항 내지 제16항 중 어느 한 항에 있어서,
상기 인식 오라클은 상기 운전 실행의 적어도 하나의 시간 간격을 필터링하도록 구성되고, 상기 시간 간격은 상기 인식 에러 타임라인에서 생략되고, 상기 필터링은 하나 이상의 필터링 기준에 기초하여 수행되며, 상기 하나 이상의 필터링 기준은 인식 에러 및/또는 실제 운전 실행과 관련된 하나 이상의 태그/라벨을 포함하는 것을 특징으로 하는 컴퓨터 시스템. - 제17항에 있어서,
상기 태그는 GUI를 통해 액세스가능한 것을 특징으로 하는 컴퓨터 시스템. - 제1항 내지 제18항 중 어느 한 항에 있어서,
운전 실행의 개략적인 표현(schematic representation)이 GUI 상에 디스플레이되고, 상기 개략적인 표현은 현재 시간 단계에서 운전 실행의 정적 스냅샷을 디스플레이하며, 상기 현재 시간 단계는 GUI에 대한 명령을 통해 선택가능한 것을 특징으로 하는 컴퓨터 시스템. - 제19항에 있어서,
인식 에러 타임라인 상에 현재 시간 단계를 마킹하도록 시각적 표시자가 변경되는 것을 특징으로 하는 컴퓨터 시스템. - 제19항 또는 제20항에 있어서,
적어도 하나의 운전 실행의 센서 데이터가 GUI 상에 디스플레이되는 것을 특징으로 하는 컴퓨터 시스템. - 제1항 내지 제21항 중 어느 한 항에 있어서,
상기 센서 데이터는,
라이다(lidar) 포인트 클라우드;
레이더 포인트 클라우드;
모노/스테레오 깊이 이미지; 또는
2D 카메라 이미지
중 적어도 하나를 포함하는 것을 특징으로 하는 컴퓨터 시스템. - 제19항 또는 제19항을 인용하는 임의의 청구항에 있어서,
상기 시계열적 그라운드 트루 인식 출력들이 이용되어 상기 개략적인 표현을 GUI 상에 렌더링하는 것을 특징으로 하는 컴퓨터 시스템. - 제23항에 있어서,
상기 시계열적 런타임 인식 출력들은, 상기 시계열적 그라운드 트루 인식 출력들과의 시각적 비교를 위해 GUI를 통해 디스플레이되는 것을 특징으로 하는 컴퓨터 시스템. - 제24항에 있어서,
상기 시계열적 런타임 인식 출력들은 상기 개략적인 표현 위에 오버레이되는 것을 특징으로 하는 컴퓨터 시스템. - 제1항 내지 제25항 중 어느 한 항에 있어서,
상기 시계열적 그라운드 트루 인식 출력들은 각각의 에이전트에 대한 트레이스의 형태이고, 트레이스는 에이전트의 공간 및 모션 상태들의 시간 시퀀스를 포함하는 것을 특징으로 하는 컴퓨터 시스템. - 제1항 내지 제26 항 중 어느 한 항에 있어서,
운전 성능 평가를 상기 그라운드 트루 인식 출력들에 적용하는 테스트 오라클을 더 포함하고, 상기 운전 성능 평가의 결과는 GUI 상에 또한 디스플레이되는 제 2 성능 타임라인에 전달되는 것을 특징으로 하는 컴퓨터 시스템. - 제1항 내지 제27 항 중 어느 한 항에 있어서,
센서 데이터는 2개 이상의 센서 양식들로부터의 데이터를 포함하고, 적어도 하나의 센서 양식은 적어도 하나의 다른 센서 양식에 대한 그라운드 트루를 제공하는데 사용되는 것을 특징으로 하는 컴퓨터 시스템. - 제1항 내지 제28항 중 어느 한 항에 있어서,
수동으로 라벨링된 그라운드 트루 데이터가 시스템 내에서 사용되어 상기 그라운드 트루 인식 출력의 정확성을 측정하는 것을 특징으로 하는 컴퓨터 시스템. - 제1항 내지 제29항 중 어느 한 항에 있어서,
수동으로 라벨링된 그라운드 트루 데이터가 시스템 내에서 사용되어 상기 런타임 인식 출력의 정확성을 측정하는 것을 특징으로 하는 컴퓨터 시스템. - 제1항 내지 제30항 중 어느 한 항에 있어서,
시뮬레이션된 운전 실행으로부터 도출된 인식 에러들 및/또는 그라운드 트루 인식 출력이 없이 실제 운전 데이터로부터 도출된 인식 에러들이 상기 GUI에서 렌더링되는 것을 특징으로 하는 컴퓨터 시스템. - 실시간 인식 시스템을 테스트하기 위한 컴퓨터 구현 방법으로서, 상기 실시간 인식 시스템은 센서 장착 차량에 배치하기 위한 것이며, 상기 방법은,
센서 장착 차량에 의해 수행된 적어도 하나의 실제 운전 실행(real-world driving run)의 데이터를 입력에서 수신하는 단계, 상기 데이터는 (i) 센서 장착 차량에 의해 캡처된 시계열적 센서 데이터 및 (ii) 테스트 중인 상기 실시간 인식 시스템에 의해 그로부터 추출된 적어도 하나의 관련된 시계열적 런타임 인식 출력들을 포함하며;
렌더링 컴포넌트에 의해, 그래픽 사용자 인터페이스(GUI)를 렌더링하기 위한 렌더링 데이터를 생성하는 단계, 상기 그래픽 사용자 인터페이스는 인식 에러 타임라인을 포함하고, 상기 인식 에러 타임라인은 상기 적어도 하나의 실제 운전 실행의 다수의 시간 단계들 각각에 대해, 해당 시간 단계에서 발생한 인식 에러의 시각적 표시를 가지며;
상기 런타임 인식 출력들과 비교하도록 적어도 하나의 시계열적 그라운드 트루 인식 출력들을 추출하기 위해 적어도 하나의 비실시간 및/또는 비인과적(non-causal) 인식 알고리즘을 적용함으로써, (i) 상기 시계열적 센서 데이터 및 (ii) 상기 시계열적 런타임 인식 출력들 중 적어도 하나를 그라운드 트루 파이프라인(ground truthing pipeline)에서 프로세싱하는 단계; 및
인식 오라클(perception oracle)에서, 상기 시계열적 그라운드 트루 인식 출력들과 상기 상기 시계열적 런타임 인식 출력들을 비교하고, 그리고 이에 의해서 인식 에러 타임라인을 생성하기 위해 하나 이상의 시간 간격들에서 발생한 인식 에러들을 식별하는 단계
를 포함하는 것을 특징으로 하는 방법. - 제32항의 방법을 구현하도록 컴퓨터 시스템을 프로그래밍하기 위한 실행가능한 프로그램 명령들을 포함하는 컴퓨터 프로그램.
Applications Claiming Priority (9)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB2108182.3 | 2021-06-08 | ||
| GBGB2108182.3A GB202108182D0 (en) | 2021-06-08 | 2021-06-08 | Support tools for autonomous vehicle testing |
| GB2108958.6 | 2021-06-22 | ||
| GBGB2108958.6A GB202108958D0 (en) | 2021-06-22 | 2021-06-22 | Support tools for autonomous vehicle testing |
| GBGB2108952.9A GB202108952D0 (en) | 2021-06-22 | 2021-06-22 | Support tools for autonomous vehicle testing |
| GB2108952.9 | 2021-06-22 | ||
| GBGB2111765.0A GB202111765D0 (en) | 2021-08-17 | 2021-08-17 | Support tools for autonomous vehicle testing |
| GB2111765.0 | 2021-08-17 | ||
| PCT/EP2022/065509 WO2022258671A2 (en) | 2021-06-08 | 2022-06-08 | Support tools for autonomous vehicle testing |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR20240019231A true KR20240019231A (ko) | 2024-02-14 |
Family
ID=82319838
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020247000255A KR20240019231A (ko) | 2021-06-08 | 2022-06-08 | 자율주행 차량 테스트를 위한 지원 도구 |
| KR1020247000569A KR20240019268A (ko) | 2021-06-08 | 2022-06-08 | 자율주행 차량 테스트를 위한 지원 도구 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020247000569A KR20240019268A (ko) | 2021-06-08 | 2022-06-08 | 자율주행 차량 테스트를 위한 지원 도구 |
Country Status (4)
| Country | Link |
|---|---|
| EP (2) | EP4338057A2 (ko) |
| KR (2) | KR20240019231A (ko) |
| IL (2) | IL308792A (ko) |
| WO (2) | WO2022258660A1 (ko) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB202210981D0 (en) | 2022-07-27 | 2022-09-07 | Five Ai Ltd | Object detection |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114365200A (zh) | 2019-07-19 | 2022-04-15 | 法弗人工智能有限公司 | 结构注释 |
| GB201912145D0 (en) | 2019-08-23 | 2019-10-09 | Five Ai Ltd | Performance testing for robotic systems |
| US11351995B2 (en) * | 2019-09-27 | 2022-06-07 | Zoox, Inc. | Error modeling framework |
-
2022
- 2022-06-08 EP EP22735316.6A patent/EP4338057A2/en active Pending
- 2022-06-08 EP EP22735094.9A patent/EP4338056A1/en active Pending
- 2022-06-08 KR KR1020247000255A patent/KR20240019231A/ko unknown
- 2022-06-08 WO PCT/EP2022/065487 patent/WO2022258660A1/en active Application Filing
- 2022-06-08 WO PCT/EP2022/065509 patent/WO2022258671A2/en active Application Filing
- 2022-06-08 IL IL308792A patent/IL308792A/en unknown
- 2022-06-08 KR KR1020247000569A patent/KR20240019268A/ko unknown
- 2022-06-08 IL IL308799A patent/IL308799A/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| IL308792A (en) | 2024-01-01 |
| WO2022258671A3 (en) | 2023-02-09 |
| KR20240019268A (ko) | 2024-02-14 |
| EP4338057A2 (en) | 2024-03-20 |
| WO2022258671A2 (en) | 2022-12-15 |
| WO2022258660A1 (en) | 2022-12-15 |
| IL308799A (en) | 2024-01-01 |
| EP4338056A1 (en) | 2024-03-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20220297709A1 (en) | Performance testing for robotic systems | |
| US20230234613A1 (en) | Testing and simulation in autonomous driving | |
| US20230289281A1 (en) | Simulation in autonomous driving | |
| US20240043026A1 (en) | Performance testing for trajectory planners | |
| KR20240019231A (ko) | 자율주행 차량 테스트를 위한 지원 도구 | |
| CN116171455A (zh) | 自主驾驶中的运行设计域 | |
| US20240194004A1 (en) | Performance testing for mobile robot trajectory planners | |
| US20240143491A1 (en) | Simulation based testing for trajectory planners | |
| EP4374261A1 (en) | Generating simulation environments for testing autonomous vehicle behaviour | |
| WO2024115772A1 (en) | Support tools for autonomous vehicle testing | |
| WO2024115764A1 (en) | Support tools for autonomous vehicle testing | |
| CN117425882A (zh) | 自主车辆测试支持工具 | |
| KR20240019294A (ko) | 테스트 시각화 툴 | |
| EP4373726A1 (en) | Performance testing for mobile robot trajectory planners | |
| CN117501249A (zh) | 测试可视化工具 | |
| WO2023227776A1 (en) | Identifying salient test runs involving mobile robot trajectory planners | |
| JP2024522598A (ja) | テスト視覚化ツール | |
| CN116964563A (zh) | 轨迹规划器的性能测试 | |
| CN117242449A (zh) | 移动机器人轨迹规划器的性能测试 | |
| WO2023017090A1 (en) | Perception testing | |
| WO2023021208A1 (en) | Support tools for av testing |