생산에 로봇 정책을 도입: 신뢰성 엔지니어링 가이드
훈련된 로봇 정책을 안정적으로 배치하는 방법 <unk> 배치 전 테스트, 모델 서비스, 모니터링, 후퇴 전략 및 재교육 트리거
[← 가이드]
연구소에서 생산에 대한 격차를 줄이는 것: 팀들이 모방 학습 정책을 벤치에서 24/7 배포로 옮기는 시스템 엔지니어링 가이드
연구소 에서 생산 간 격차
80%의 실험실 성공률은 80%의 생산 성공률을 의미하지는 않습니다. 이것은 로봇 정책 배포에 있어서 가장 중요한 교훈입니다.
생산 환경은 실험실과 다르게 보이지 않는 방식으로 실패를 일으키는 데까지 다릅니다. ** 새로운 조명 조건** (일간의 다른 시간, 계절의 빛 각, 상류 장치 교체), ** 착용에 의해 유발된 파동** ( 50,000 회전 후에 합동 반작용이 증가하고, 지갑 패드 착용이 잡기 메커니즘을 변경합니다), ** 물체의 변동** (전업자가 제품 포장지를 약간 변경하고, 물체는 비통통칙적인 지향에 도착합니다) 및 ** 컨텍스트 파동** ( 작업 공간이 약간 재편되고, 배경 물체는 이동됩니다). 이 각각의 개별적으로 정책 성능은 5~20%로 감소한다. 합쳐져 80% 연구실 정책은 3개월 이내에 40% 생산 성능으로 떨어질 수 있다.
해결책은 더 나은 실험실 성능이 아닙니다. 그것은 부패를 감지하고 안전하게 실패하고 자동으로 복구하는 시스템을 구축합니다.
배치 전제 체크리스트
어떤 정책이 생산에 들어가기 전에, 그것은 일반화를 조사하기 위해 설계된 조건에서 구조화된 평가를 통과해야합니다.
- 3 새로운 조명 조건: 시험은 오버헤드만, 천연 빛 + 오버헤드, 그리고 훈련과는 다른 위치에서 배치된 책상등을 이용한다. 정책은 각 조건에서 ≥70%의 성공률을 달성해야 한다.
- 5 새로운 객체 위치: 훈련 중에 보이지 않는 위치, 작업 공간 경계 근처에도 목표물들을 배치하십시오. 선언된 작업 공간 경계 내에서 어떤 위치도 처리되어야 합니다.
- 10 방해물: 훈련 중에 없는 객체를 작업 공간에 추가합니다. 잘 훈련된 정책은 방해물들이 존재할 때 기본 성공률의 ≥85%를 유지해야 합니다.
- ** 100개의 연속적인 시험 평가:** 100개의 시험을 자율적으로 밤새 실행한다. 이 결과, 간헐적 오류가 발생한다 (30개의 주기를 지나면 압축이 막혀, 45분 후에 열성 마신)
- ** 엣지 케이스 시나리오:** 명시적으로 테스트: 표면 표면 외면으로 약간 떨어져 있는 물체, 꽉 잡는 부분이 부분적으로 폐쇄되어 있고, 팔 관절은 거의 제한 위치, 카메라가 부분적으로 방해를 당하고 있습니다.
서비스 인프라 모델
인퍼런스 지연은 로봇 제어 속도에 직접적으로 영향을 미칩니다. 10 Hz (100 ms 제어 기간) 에서 실행되는 정책에서는 통신 오버헤드에 대한 범위를 남겨두고 <80 ms 내에 인퍼런스가 완료되어야 합니다.
- TorchServe: PyTorch 정책을 모델 아카이브 (.mar) 로 배포한다. HTTP 및 gRPC 추론 최종점, 배팅, 모델 버전 및 매트릭을 제공합니다. 전용 모델 서버가 보장되는 경우 <50 ms 추론 시간을 가진 정책에 적합합니다.
- TensorRT: NVIDIA GPU에서 3
5x 추론 속도를 높이기 위해 정책을 TensorRT 엔진으로 변환합니다. PyTorch에서 80 ms를 소요하는 ACT 정책은 일반적으로 TensorRT FP16에서 18 25 ms로 실행됩니다. 변환을 위해 T0 을 사용합니다. - ** 늦추기 목표:** p99 추론 지연은 <100 ms여야 합니다. p99 (99 번째 퍼센틸) 는 평균보다 더 중요하므로 1% 최악의 경우 지연은 제어 루프의 최악의 경우 기저를 결정합니다. 시뮬레이션 생산 부하에서
T1 을 프로파일합니다. - ** 건강 검사 최종점:** 가짜 추론 패스를 실행하고 지연 측정으로 200 OK를 반환하는
T2 최종점을 노출하십시오. 로봇 컨트롤러는 이 최종점을 시작 시 조사하고 p99 > 100 ms를 배포하는 경우 배포를 거부해야합니다.
모니터링 전략
감시 없이 생산하는 정책은 타임폭탄입니다. 첫 날부터 감시를 구축하세요. 첫 번째 사건 이후가 아닙니다.
- ** 에피소드 당 성공률:** 각 에피소드 에 성공/실패 기록. 7 일 동안의 평균을 추적. 배포 기준보다 5% 이상 감소할 때 경고.
- 실실 분류: 에피소드가 실패할 때, 실패 모드를 분류하십시오. 포착 실패, 배치 실패, 충돌, 타임아웃 또는 기타. 다른 실패 모드는 다른 근본 원인과 다른 수정 사항을 나타냅니다.
- ** 텔레메트리 로그:** 각 에피소드 에 대한 관절 위치, 속도, 힘, 정책 신뢰 점수 및 추론 지연을 로그. 최소 90 일 동안 저장하십시오. 이러한 데이터는 근본 원인 분석 및 재교육에 필수적입니다.
- 인력 검토열: 24시간 이내에 모든 실패한 에피소드를 인간 검토로 표시합니다. 실패당 5분간의 인간 검토는 카스케이드되기 전에 체계적인 문제를 (새로운 객체 변종, 증가하는 파동) 파악합니다.
은혜 로 훼손 된 것
생산 로봇은 안전하게 실패해야 합니다. 최악의 결과는 침묵의 실패입니다.
- ** 신뢰 점수 임계:** 많은 정책들은 행동과 함께 신뢰 또는 확실성 추정치를 생성한다. 신뢰 <0.7 경우, 로봇을 멈추고 운영자를 계속하기 전에 경고한다. 이것은 정책이 확신하지 못하는 새로운 상황에서의 재난적 포착을 방지한다.
- 파우즈 및 알림: 파우즈 트리거가 발사되면, 팔을 안전한 가정 위치로 이동하고, 시각 지표를 (붉은 상태등) 를 켜고, [플랫폼] (
T6 ) 를 통해 운영자의 패시보드와 모바일 장치에 알림을 보내십시오. - Teleop에 대한 탈락: 고부가가치 또는 위험 높은 작업에 대해, 리모트 운영자가 VR 헤드셋 또는 웹 인터페이스를 통해 정기를 촉발하면 제어기를 취하는 텔레오프 탈락을 구현하십시오. 운영자는 에피소드를 수동으로 완료하고 데이터를 재교육에 기록합니다.
- ** 최대 연속 실패 제한:** 5 개의 연속 실패 에피소드 에 경우, 자동으로 정책 을 중단 하 고 상위 사업자 로 확대 하 고. 실패 정책 주기 를 무한 히 허용 하지 마십시오.
버전 관리
소프트웨어
- A/B 테스트: 새로운 정책 버전을 배포할 때, 작업의 10%를 새로운 버전에, 90%를 현재 제작 버전에 로우팅하십시오. 완전한 배포 전에 200+ 에피소드 이상의 성공률을 비교하십시오. 이것은 [플랫폼] (
T7 ) 래시보드에서 작업 로우팅 논리를 필요로합니다. - ** 캐나리 출범:** A/B 테스트가 개선된 후, 주간 간격으로 25% → 50% → 100%의 트래픽으로 출범하고, 어떤 단계에서 성공률이 5% 이상 떨어지면 자동으로 다시 출범한다.
- Rollback 절차: 마지막 3개의 생산 정책 버전은 배포 가능한 유물으로 유지된다. 이전 버전으로의 rollback는 < 5분 이내에 실행될 수 있어야 하며, 이상적으로는 함대 패시보드에서 하나의 버튼을 통해 실행될 수 있다.
재 훈련 의 촉매
재교육은 일회적인 일이 아닙니다.
- >5% 성공률 감소: 근본 원인을 조사합니다. 분배 변화 (새로운 객체, 변경된 작업 공간) 에 의해 발생하면, 새로운 조건을 다루는 50
200개의 시범을 수집하고 정교하게 조정합니다. - 새로운 작업 변종: 사업자가 새로운 SKU, 제품 변종 또는 작업 흐름 변경을 도입할 때, 변종이 생산량을 달성하기 전에 데이터 수집 캠페인을 시작합니다.
- 분기 리프레쉬: 특정 트리거 없이도, 생산 실패 에피소드를 모두 포함해 분기 리프레쉬를 실시 합니다.
사건 실행 책 템플릿
| Phase | Actions | Owner | Time Target |
|---|---|---|---|
| Detect | Alert fires (success rate drop or consecutive failures) | Automated | <5 min |
| Classify | Review failure clips, classify failure mode | On-call operator | <30 min |
| Contain | Suspend affected policy, route tasks to manual/teleop | On-call operator | <15 min |
| Diagnose | Identify root cause: hardware drift, distributional shift, infrastructure issue | ML engineer | <4 hr |
| Resolve | Deploy fix: rollback, hotfix, or retrain | ML engineer | <24 hr |
| Post-mortem | Document cause, impact, fix, and prevention measures | Team lead | <1 week |
모델 서비스 비교: 어떤 프레임워크를 사용해야 하는가
| Framework | Typical Inference (ACT) | Versioning | Rollback | Best For |
|---|---|---|---|---|
| Raw PyTorch | 60-100 ms (RTX 4070) | Manual (file paths) | Manual | Prototyping, single robot |
| TorchServe | 70-110 ms | Built-in model store | API-driven | Multi-model serving, A/B testing |
| TensorRT FP16 | 18-30 ms (RTX 4070) | Manual (engine files) | Manual | Low-latency production, Jetson edge |
| Triton Inference Server | 20-35 ms (with TRT backend) | Model repository | API-driven | Fleet-scale, multi-GPU, mixed models |
| FastAPI + ONNX Runtime | 35-60 ms | Custom | Custom | Simple REST integration, CPU fallback |
| ROS2 Service Node | 65-100 ms | Launch file | Node restart | Native ROS2 integration, single robot |
생산 중인 단일 로봇에 대해 가장 낮은 지연을 위해 TensorRT FP16 변환을 시작하십시오. 5+ 로봇의 함대에서는 Triton 인퍼런스 서버에 투자하십시오. 그 모델 저장소와 동적 배팅 기능은 설비 복잡성을 정당화합니다.
배포 구조: 단일 로봇과 함대
** 단일 로봇 배포:** 정책은 로봇의 내장 GPU (Jetson Orin, RTX 4060 작업 스테이션) 에서 실행됩니다. 관찰은 카메라와 공동 코더에서 직결 과정으로 흐른다. 제어 루프에서 네트워크 지연이 없습니다. 이것은 가장 간단하고 가장 신뢰할 수있는 건축입니다.
Edge-cloud 하이브리드 (함대용으로 권장): 로봇의 내장 컴퓨터에서 낮은 수준의 제어 (안전, 공동 세르보, e-stop) 가 실행됩니다. 정책 추론은 고급 GPU를 가진 가장자리 서버 (5~10 로봇당 하나) 에서 실행됩니다. 통신은 <5 ms 지연성 1 Gbps LAN를 통해 이루어집니다. 가장자리 서버는 또한 모니터링, 로깅 및 모델 업데이트를 처리합니다.
** 클라우드 기반 추론 ( 조작을 권장하지 않습니다):** 정책 추론은 클라우드 GPU에서 실행됩니다. 네트워크 지연은 제어 루프에 20-100 ms를 추가하여 10+ Hz에서 접촉 부양한 조작에 적합하지 않습니다. 모바일 로봇 탐색 또는 매우 느린 선택 및 위치 작업에서만 실행 가능합니다.
롤백 절차: 단계 가 단계
- 단계 1 -- 퇴진을 감지: 성공률 감소 > 5% 또는 > 3 연속 실패에 대한 시범 알림
- 단계 2 - 현재 정책을 중지하십시오: 플랫폼 래시보드 또는 CLI:
T3 를 통해 로봇은 안전한 비동기 상태에 들어갑니다. - ** 단계 3 - 이전 버전을 활성화하십시오:**
T4 . 이전 버전은 (로봇에 로컬로 저장되어 있습니다) <30초에 로드됩니다. - ** 4 단계 -- 확인:** 이전 버전에서 10 개의 자동 테스트를 실행하십시오. 성공률이 기본으로 돌아간다면, 역전환이 완료된 것을 확인합니다.
- ** 5 단계 -- 뿌리 원인 분석:** v2.3의 실패 이유를 조사합니다. 일반적인 원인은: 훈련 데이터 분포 전환, 과다 파라미터 회귀 또는 인프라 변경 (카메라 캘리브레이션 파동) 입니다.
전체 롤백 시간 목표: < 5 분, 발견 후 이전 버전의 작동을 재개하기까지.
관련 가이드
- 거래함대 관리 -- 모니터링 인프라 및 OTA 업데이트 절차
- [로봇 학습을 위한 교육과정 설계] (
T10 ) -- 생산에 더 잘 보편화된 교육 정책 - 데이터 수집 서비스 구매자의 안내 -- 재교육을 위한 고품질 교육 자료를 공급하는
- 로봇 안전 위험 평가 -- 생산 로봇 배치에 대한 안전 요구 사항
- 하우스 배치 체크리스트 -- 종결부터 종결까지 생산 배치 계획
RCSV와 작업
RCSV는 연구소에서 생산에 대한 격차를 인프라, 모니터링 및 지속적인 데이터 수집 지원으로 다룰 수 있도록 팀들을 돕습니다.
- 데이터 플랫폼 -- 정책 모니터링 래시보드, A/B 테스트, 함대 관리 및 자동으로 돌아가는
- 데이터 수집 서비스 -- 생산 정책이 악화될 때 신속한 재교육 데이터 수집
- Robot Leasing -- 생산에 준비된 로봇 시스템, 통합된 모니터링 및 유지보수
- [우리와 연락하세요] -- 우리 엔지니어링 팀과 배치 준비 검토를 계획하세요
자신감 있게 배치
RCSV 플랫폼은 생산 로봇 배포를 위한 정책 모니터링, 함대 패시보드 및 A/B 테스트 인프라를 제공합니다.
[ 플랫폼 특징을 참조]