인터넷 을 통해 로봇 텔레오퍼레이션: 지연 및 패킷 손실을 처리
인터넷에서 원격 로봇 원격 통신을 위한 엔지니어링 전략 <unk> 지연 보상, 비디오 스트리밍, 제어 법률 적응 및 연결 요구 사항
[전용사 안내]
[← 블로그]
인터넷에서 원격 원격 원격 통신은 전세계적으로 데이터 수집을 확장하는 데 필수적입니다. 이것이 안정적으로 작동하기 위해 필요한 것입니다.
작업별로 지연 요구 사항
모든 텔레오퍼레이션 작업은 같은 지연 용납성을 가지고 있지 않습니다. 실제적으로 중요한 세 가지 단계:
- ** 정확성 접촉 작업 (<30ms 요구):** Peg 삽입, 표면 추적, 연결기 결합. 이러한 용인에서는 로컬-아레오 네트워크 텔레오퍼레이션만이 실행가능합니다. 50ms조차도 정확한 접촉 판단이 신뢰할 수 없게 하기 위해 운영자의 피드백 루프에 충분한 단계 지연을 도입합니다.
- ** 중간 정확성 작업 (100
300ms 허용):** 5mm 이상 용납량, 큰 물체의 조작, 이동 제어. 이 곳에서 보상 전략이 있는 넓은 영역 인터넷이 작동합니다. 이것은 조작 데이터 수집 작업의 대부분을 포함합니다. - ** 높은 지연 작업 (>500ms
직접 제어에는 실행되지 않습니다):** 이 지연 시, 반응 제어가 필요한 모든 작업에 대해 직접적인 텔레오퍼레이션이 끊어집니다. 감독 제어 (고급 명령어를 전송, 로봇이 자율적으로 실행) 는 500ms 이상 유일한 실행 가능한 모드입니다.
지연원 및 최적화
| Pipeline Stage | Typical 지연시간 | Optimization |
|---|---|---|
| Network propagation (US coast-to-coast) | 70–90ms | Operator geographic routing — match operators to nearby robots |
| Video encoding (H.264 software) | 50–100ms | Switch to WebRTC VP8 hardware encode: 15–30ms |
| Video decoding (browser) | 10–30ms | Enable hardware acceleration in browser |
| Control command serialization/deserialization | 2–5ms | Binary protocol (MessagePack/protobuf) vs JSON |
| Robot controller loop overhead | 5–20ms | High-priority RT thread for command processing |
| Camera capture + USB frame delivery | 10–33ms | USB3 camera at 60fps: 16ms max frame age |
지연성 보상 전략
- ** 스미스 예측기:** 알려진 일정 지연을 가진 시스템들을 위한 고전적 제어 보상 기술. 스미스 예측기는 반방행 지연에 의해 이동되는 로봇 역학의 내부 모델을 병렬로 실행하므로, 운영자는 지연된 실제 출력보다는 모델 출력을 효과적으로 제어하고 있다. 지연이 안정적이고 공장 모델이 정확할 때 잘 작동한다. 변수 인터넷
(±30ms의 변동은 일정 지연 가정을 깨고) 와 함께 붕괴됩니다. - 비주얼 리드: 운영자는 비디오에서 현재 표시되는 장소보다는 로봇이 어디에 있는지 목표로 훈련받습니다. 운영자 인터페이스에 있는 시각적 초연은 마지막 명령과 알려진 지연을 기반으로 예측된 로봇 위치를 보여줍니다. 간단하고 효과적이며 모델 정확성이 필요하지 않습니다. 대부분의 실제 배포에 선호하는 방법.
- ** 래텐시 계층에 의한 작업 선택:** 가장 강력한 전략. 세션 시작 시 반여행 지연을 측정하고 자동으로 적절한 작업에 운영자를 노트합니다. <50ms RTT의 운영자는 접촉 비중있는 작업을 얻습니다. 100
200ms RTT의 운영자는 표준 선택지를 얻습니다. 250ms 이상의 운영자는 탐색 또는 감독 작업에 할당됩니다.
비디오 스트리밍 기술 비교
| Technology | Glass-to-Glass 지연시간 | Bandwidth | Recommendation |
|---|---|---|---|
| WebRTC VP8 (hardware encode) | 30–50ms | 2–8 Mbps | Best for teleoperation — use this |
| WebRTC H.264 | 40–80ms | 1.5–5 Mbps | Good fallback if VP8 not available |
| H.264 over RTSP | 100–150ms | 1–3 Mbps | Acceptable for supervisory control |
| MJPEG over HTTP | 100–300ms | 10–50 Mbps | Avoid — high bandwidth, high latency |
| JPEG frames over WebSocket | 200–500ms | 5–20 Mbps | Do not use for teleoperation |
지연성 파이프라인: 모든 밀리초가 가는 곳
텔레오퍼레이션 시스템에서 전체 엔드-투-엔드 지연시간은 여러 파이프라인 단계의 합으로, 각각의 파이프라인이 독립적으로 기여한다. 이 파이프라인을 이해하는 것은 다양한 단계가 다른 솔루션을 필요로 하기 때문에 최적화에 필수적이다.
일반적인 미국 내 텔레오퍼레이션 세션 (SF에서 운영자, 뉴욕에서 로봇) 은 총 파이프라인을 가지고 있습니다: 카메라 캡처 (16ms에서 60fps) + 비디오 코딩 (25ms WebRTC VP8) + 네트워크 전파 (75ms 해안에서 해안) + 비디오 디코딩 (15ms) + 운영자 인식 및 반응 (150-300ms) + 명령 시리얼링 (3ms) + 네트워크 복귀 여행 (75ms) + 명령 디세리얼링 (3ms) + 로봇 컨트롤러 처리 (10ms) = 372-522ms 전체 루프 지연시간. 이 중, 운영자의 반응 시간은 지배한다. 엔지니어링 제어 가능한 부분은 (인류 반응을 제외한 모든 것) 은 약 222ms이며, 네트워크 전파는 제어 가능한 지연의 68%를 차지한다.
이 분해는 중요한 통찰력을 보여줍니다. 100ms에서 25ms (75ms의 향상) 까지 비디오 코딩을 최적화하는 것은 운영자를 로봇에 1,000km 가까이 이동시키는 것과 거의 동일한 영향을 미친다 (이 때문에 1,000km당 RTT는 약 10ms로 감소합니다). 비디오 파이프라인의 소프트웨어 최적화는 거의 항상 지리적 공동 위치보다 비용 효율적입니다.
진보 된 지연 보상: 파동 변수 및 예측 방법
**파변 변수 형식:**파변수 (Niemeyer and Slotine, 1991) 는 속도-힘 제어 신호를 통신 채널을 통해 전파 변수로 변환한다. 이것은 파동 변수를 변수 지연 네트워크에 대한 양방향 강력 피드백 텔레오퍼레이션에 대한 이론적으로 올바른 접근법으로 만듭니다.
실제에서 파동변동 구현은 투명성을 위해 안정성을 거래합니다. 운영자는 뚜렷한 파동 피드백보다는 "무쉬" 반응을 느낀다. 파동 변환은 파동 신호를 부드럽게 하기 때문입니다. 파동 피드백 품질이 작업 완료에 따라 차원적일 수 있는 데이터 수집 작업에서는 이러한 타협은 받아들여진다. 힘 투명성이 중요하게 작용하는 수술적 텔레오퍼레이션에서 파동 변수는 소극성을 침해하지 않고 인식된 투명성을 향상시키는 로컬 힘 모델과 결합된다.
** 예측자 기반 보상:** 스미스 예측자 (이 일정 지연을 가정하는) 를 넘어, 시간적 지연 예측자는 현재 추정 지연에 대한 로봇의 상태를 예측하기 위해 로컬 동적 모델을 사용합니다. 칼만 필터 기반 예측기는 가장 흔하다: 그것은 원격 로봇의 상태를 추정하고 로봇의 동적 모델과 가장 최근의 제어 명령을 사용하여 앞으로 전파합니다. 실제 로봇에서 지연된 관측이 도착하면 칼만 필터는 예측을 수정합니다. 이 접근법은 변수
** 모델 중재된 텔레오퍼레이션:** 운영자는 원격 환경의 현지 가상 복제와 상호작용한다. 복제자는 실제 로봇의 센서 데이터에서 비동이적으로 업데이트된다. 운영자는 0 지연으로 가상 복제를 제어하고, 실제 로봇은 네트워크가 부과하는 지연으로 가상 복제 상태를 추적한다. 이 방법은 운영자의 경험을 네트워크 품질과 완전히 분리합니다. 비용: 가상 복사본은 복사본이 모델링하지 않는 방식으로 환경이 변하면 현실과 다를 수 있습니다 (물질이 움직이고, 사람이 작업 공간에 들어갑니다). 우주 원격 통신 및 점점 더 지상 원격 데이터 수집에 성공적으로 사용됩니다.
프로토콜 비교: TCP vs UDP vs QUIC vs WebRTC
| Protocol | Control Commands | Video | NAT Traversal | Recommendation |
|---|---|---|---|---|
| TCP (WebSocket) | Reliable delivery; head-of-line blocking adds 10-50ms on packet loss | Usable but suboptimal -- retransmits stale frames | Works everywhere | Use for non-time-critical data (logs, config) |
| UDP | Lowest latency; no retransmit; application handles loss | Requires custom codec integration | Often blocked by firewalls | Best for control commands if NAT is not an issue |
| QUIC | Independent streams -- no HOL blocking; built-in encryption | Promising; no mature video-over-QUIC stack yet | Built on UDP; ICE-like traversal needed | Future-best; not mature enough for production in 2026 |
| WebRTC | DataChannel (SCTP/UDP): reliable or unreliable modes | Native video codec support; adaptive bitrate; congestion control | ICE + STUN/TURN built-in | Production choice for 2026 -- handles video + control + NAT |
RCSV의 텔레오프 플랫폼은 비디오 (미디어 채널) 와 제어 명령 (불신뢰된 데이터채널) 모두에서 WebRTC를 사용합니다. 신뢰할 수 없는 데이터채널 모드는 실시간 제어에 대한 올바른 행동으로, 이를 다시 전송하는 대신 구석기 제어 명령을 떨어뜨립니다. 100ms 오래된 위치 명령은 전혀 명령보다 더 나쁘습니다. 안전성 중요한 신호 (e-stop) 에 대해서는, 평행성 신뢰할 수 있는 TCP WebSocket이 보장된 전달을 보장합니다.
실제 세계 게이트ન્સી 측정
RCSV는 다양한 네트워크 조건에서 500 개 이상의 원격 텔레오퍼레이션 세션에서 지연 데이터를 수집했습니다. 생산 데이터에서 주요 발견은:
| Route | Median RTT | P95 RTT | Packet Loss | Data Quality Impact |
|---|---|---|---|---|
| Same city (fiber) | 8ms | 15ms | <0.01% | Indistinguishable from local |
| SF to NYC (fiber) | 72ms | 95ms | 0.02% | 5-8% lower demo quality (slower, more hesitant) |
| US to Europe (fiber) | 130ms | 180ms | 0.05% | 15-20% lower demo quality; contact tasks degraded |
| US to Asia (fiber) | 175ms | 250ms | 0.1% | 25-35% lower quality; pick-place only |
| Home WiFi (shared) | 35ms | 250ms | 0.5-2% | Jitter is the killer -- intermittent 200ms+ spikes cause jerky demos |
데이터 품질 영향 열은 지역 원격 작업과 비교하여 시범의 매끄러움 (평균
패킷 손실 처리
인터넷 패킷 손실은 일반적으로 0.01-0.5%에 달하지만, 혼잡을 때 2-5%까지 증가할 수 있습니다. 50 Hz로 전송되는 제어 명령어에서는 1% 손실은 2 초마다 한 명령어를 떨어뜨리는 것을 의미합니다. 영향은 수신 컨트롤러가 놓친 명령을 처리하는 방법에 따라 달라집니다.
- ** 마지막 명령 (허로 순서 유지):** 로봇은 새로운 명령이 도착하기 전까지 마지막 수신 명령을 계속 실행합니다. 속도 명령에 안전합니다 (로봇은 마지막 명령 속도에서 계속합니다). 위치 명령에 위험합니다 (로봇은 중지하여 불안정한 접촉 상태에 빠질 수 있습니다).
- 엑스트라폴레이션 (첫 번째 순위 유지): 로봇은 마지막 두 가지 수신된 명령에 따라 명령 궤도를 추출한다. 부드러운 움직임 연속성을 위해 더 좋지만 운용자가 늦추고 있다면 초과 할 수 있다. 탈출을 방지하기 위해 속도 규모 제한을 사용한다.
- ** 인터폴레이션 버퍼:** 2-3 개의 미래 명령어를 버퍼하여 (40-60ms 지연을 추가) 그리고 그 사이에 인터폴레이션합니다. 단일 패킷 손실을 완전히 완화합니다. 절대 최저 지연보다 일관된 궤도 품질이 중요하게있는 데이터 수집에 권장됩니다.
RCSV는 적응 깊이를 가진 2 명령어 인터폴레이션 버퍼를 사용합니다. 버퍼는 높은 손실 기간 동안 증가합니다 (파킷 간 간 간 간격을 모니터링함으로써 감지됩니다) 그리고 안정적인 기간 동안 줄어들습니다. 이것은 약간 변하는 지연 (50-100ms 추가 버퍼가 최악의 경우) 비용으로 일관된 동작 품질을 제공합니다.
관련 독서
- [전체 수술 피로 및 에르고노믹스 연구]
- [로봇 훈련 데이터: 수집 방법 및 우수한 관행]
- [로봇 궤도 해상: 도전과 품질 표준]
- [로봇 배포 체크리스트]
- [RCSV 텔레오프 플랫폼]
- [RCSV 데이터 수집 서비스]
지터 관리: 과소 평가 된 문제
네트워크 지연은 관심을 끌지만, 지연의 변화인 지저도는 절대 지연보다 원격 조작 품질에 더 큰 피해를 입게 됩니다. 시각적 리드 기술로 일관된 100ms 지연은 관리 가능합니다. 30ms에서 200ms 사이에 오슬링되는 연결은 운영자가 적응할 수 없는 어색하고 예측할 수 없는 로봇 행동을 만들어냅니다.
** jitter 측정.** RCSV는 30초의 창에서 반방향 시간 (IQR) 으로 jitter를 측정한다. 건강한 연결은 10ms 이하의 IQR를 가지고 있다. 소외 연결은 10-30ms의 IQR를 보여줍니다. 30ms 이상의 IQR의 연결은 입증되는 품질이 낮은 시연을 생성하고 네트워크 조건이 개선될 때까지 세션 휴식을 유발해야 한다.
** 지터 버퍼링.** 표준 완화 방법은 로봇 측면의 지터 버퍼로, 수신된 명령을 실행하기 전에 구성 가능한 기간 동안 유지합니다. 50ms 지터 버퍼는 추가 지연시간 50ms의 비용으로 대부분의 지터 유물을 제거합니다. 버퍼 깊이는 적응력이 있어야 합니다. 95 번째 퍼센틸 RTT 미이너스 중반 RTT로 설정되어 10 초마다 업데이트됩니다. 안정적인 기간 (저기기동력) 에, 버퍼는 지연을 최소화하기 위해 줄어들게 됩니다. 불안정한 기간 (고기동력) 에, 버퍼는 원활한 통제를 유지하기 위해 성장합니다.
# adaptive_jitter_buffer.py -- Adaptive jitter buffer for teleop commands
import collections
import time
import numpy as np
class AdaptiveJitterBuffer:
"""Buffer incoming teleop commands to smooth out network jitter."""
def __init__(self, min_depth_ms=10, max_depth_ms=100):
self.min_depth = min_depth_ms / 1000.0
self.max_depth = max_depth_ms / 1000.0
self.rtt_history = collections.deque(maxlen=100) # Last 100 RTT samples
self.buffer = collections.deque() # (release_time, command) pairs
self.current_depth = self.min_depth
def update_rtt(self, rtt_seconds):
"""Feed in a new RTT measurement."""
self.rtt_history.append(rtt_seconds)
if len(self.rtt_history) >= 20:
p50 = np.percentile(list(self.rtt_history), 50)
p95 = np.percentile(list(self.rtt_history), 95)
self.current_depth = np.clip(p95 - p50, self.min_depth, self.max_depth)
def enqueue(self, command):
"""Add a command with its scheduled release time."""
release_time = time.monotonic() + self.current_depth
self.buffer.append((release_time, command))
def dequeue(self):
"""Return the next command if its release time has passed."""
now = time.monotonic()
if self.buffer and self.buffer[0][0] <= now:
return self.buffer.popleft()[1]
return None # No command ready; use hold-last or extrapolation
레이텐시용 운영체 인터페이스 설계
운영자의 UI는 예측 시각화 및 상태 피드백을 통해 지연의 인식되는 영향을 크게 완화시킬 수 있습니다.
- ** 예측된 위치 덮개:** 로봇의 반 투명한 유령을 마지막 전송 명령과 현재 추정된 지연을 기반으로 로봇이 도달할 위치에 표시합니다. 이것은 운영자가 지연된 실제 상태를 보는 것이 아니라 명령된 상태를 볼 수 있습니다. 구현: 명령어를 즉시 처리하고 지연된 비디오 피드와 함께 예측을 수행하는 로컬 운동 모델을 유지하십시오.
- ** 늦도 지표:** 현재 RTT를 운영자 인터페이스에서 눈에 띄게 표시하십시오. 녹색/ 노란색/ 빨간색 코딩을 사용하십시오. 녹색은 100ms 이하, 노란색은 100-200ms, 빨간색은 200ms 이상입니다. 운영자는 현재 늦도 레벨에 따라 속도와 주의 수준을 조정해야합니다. RCSV의 플랫폼은 텔레오프 시선의 오른쪽 상단에 지연 측정기를 사용합니다.
- ** 힘 피드백 스칼링:** 촉각 피드백 장치를 사용할 때, 힘 피드백의 갱신 속도를 늦추는 것과 반대로 확장하십시오. 낮은 지연 (< 50ms) 에서, 전력 피드백은 유용한 연락처 정보를 제공합니다. 높은 지연 (> 150ms) 에서, 높은 이득 힘 피드백은 운영자 입력과 힘 응답 사이의 단계 지연이 안정성 지장을 초과하기 때문에 진동을 유발합니다. 150ms+ 지연으로 이득을 30-50%로 줄이십시오.
- ** 속도 제한:** 지연이 증가함에 따라 자동으로 명령된 최대 속도를 줄입니다. 50ms RTT에서 풀 스피드 동작을 허용하십시오 (1.0m/s 최종 효과). 150ms RTT에서 0.3m/s로 제한하십시오. 300ms RTT에서 0.1m/s로 제한하십시오. 이러한 제한은 운영자가 시각 피드백이 지연되어 지나가는 동작을 명령하지 못하게합니다.
원격 세션에 대한 데이터 품질 평가
원격 텔레오퍼레이션 세션에서의 시범 품질은 지역 세션과 별도로 평가되어야 합니다. RCSV는 원격 시범능이 훈련 데이터 품질 표준을 충족하는지 여부를 결정하기 위해 세 가지 측정치를 사용합니다.
- ** 궤도 순수성 (중앙상급
어):** 최종 효과자 위치 궤도의 세 번째 파생물을 계산한다. 100ms 이상의 지연이 있는 원격 시범은 같은 작업의 지역 시범보다 40-80% 더 높은 평균 어 표시한다. 지역 기본 라인 2x 이상의 어 있는 시범은 검토를 위해 표시되어야 한다. 그들은 여전히 성공할 수 있지만 더 큰 어 훈련 신호를 생성한다. - ** 작업 완공 시간 비율:** 원격 시범은 지역 시범보다 더 오래 걸립니다. 2.0x 이상의 완공 시간 비율 ( 원격 시범은 지역보다 두 배 이상 오래 걸립니다) 는 퇴화된 시범 품질 ( 과도한 주저, 교정 운동) 과 상관관계를 맺습니다. 이러한 에피소드는 교육 중에 검토되고 잠재적으로 배제되거나 중계되어야 합니다.
- ** 명령 순조로움:** Опера터의 원시 명령 스트림을 중단성 - 갑작스러운 속도 반전, 긴 일시 중지 및 빠른 진동에 대해 분석합니다. 이것은 운영자가 지연성을 싸우는 것을 나타냅니다. 간단한 선택 장소 작업에 한 에피소드당 3 개 이상의 반전은 품질 플래그입니다.
RCSV의 경험에 따르면, 100ms 미만 이하의 RTT에서 수집된 원격 시범은 훈련 목적으로 지역 시범과 구별할 수 없습니다. 100-200ms 사이에서는 시범이 사용 가능하지만 훈련 세트에서 지역 시범과 2:1를 혼합해야합니다. 200ms 이상에서는 시범은 접촉하지 않은 이동 및 탐색 작업에만 사용해야합니다.
로봇 원격 조작을 위한 WebRTC 구성
웹RTC는 로봇 텔레오퍼레이션에서 실시간 비디오 스트리밍을 위한 표준 프로토콜이므로 NAT 트로스레이스, 적응 비트레이트, 그리고 잇터 버퍼링을 네이티브로 처리한다. 그러나 기본 웹RTC 구성은 비디오 컨퍼런스, 로봇 제어에 최적화되어 있다. 텔레오퍼레이션의 주요 구성 변경 사항은:
// WebRTC configuration optimized for robot teleoperation
const rtcConfig = {
iceServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{ urls: 'turn:turn.roboticscenter.ai:3478',
username: 'teleop', credential: 'token' }
],
iceCandidatePoolSize: 10, // Pre-gather candidates for faster connection
};
// Video encoder settings for low-latency robot camera streams
const videoConstraints = {
width: { ideal: 640, max: 1280 },
height: { ideal: 480, max: 720 },
frameRate: { ideal: 30, max: 30 },
};
// SDP modifications for low latency (apply to offer/answer)
function optimizeSdp(sdp) {
// Force VP8 (lower latency than H.264 in software encode)
// Set max bitrate to prevent congestion-induced latency spikes
sdp = sdp.replace(/a=fmtp:(\d+) /, 'a=fmtp:$1 max-fr=30;max-fs=3600;');
// Add x-google-max-bitrate for Chrome
sdp = sdp.replace(/a=mid:video\r\n/,
'a=mid:video\r\nb=AS:2000\r\n'); // 2 Mbps cap
return sdp;
}
키 조정 결정: (1) 하드웨어 코딩이 사용할 수 없는 경우 H.264보다 VP8를 사용하십시오. VP8는 소프트웨어 코딩 지연이 낮습니다. (2) 네트워크 계층에서 버퍼 부풀이를 방지하기 위해 카메라당 2 Mbps의 캡 비트레이트를 사용하십시오. (3) 720p 또는 1080p 대신 640x480 해상도를 사용하십시오. (4) 프레임 속도를 30fps로 설정하고 15fps로 떨어뜨리는 것은 대역폭을 절약하지만 빠른 작업에서 운영자의 성능을 20%로 떨어뜨립니다.
예측적 인 표시: 시각적 지연을 보완 하는 것
예측 디스플레이는 100-300ms 지연으로 운영자의 성능을 유지하는 가장 효과적인 기술이다. 시스템은 지연된 카메라 이미지에 예측된 로봇 상태를 덮어, 이미지가 촬영되었을 때보다 로봇이 지금 어디에 있는지 (예측) operat원을 보여줍니다.
구현은 다음과 같이 요구됩니다: (1) T_latency 초에 결합된 위치를 예측할 수 있는 로봇의 운동 모델, (2) 카메라 피드 위에 예측된 로봇 포즈를 보여주는 3D 렌더링 오버레이, (3) 예측 지평을 실제 반여행 지연에 맞추는 지연 추정기를 유지하는 로봇의 시연 모델.
간단한 움직임 (자유 공간에 도달) 에 있어서, 마지막 명령된 궤도를 이용한 앞진 운동학 예측은 충분하며 무시할 수 있는 계산을 추가한다. 접촉 작업에 대해서는 예측은 예상되는 접촉 힘과 잠재적 궤도 경각심을 고려해야 하며, 이는 동적 모델이나 학습된 예측자를 필요로 한다. RCSV의 평가에서 예측 디스플레이는 선택 및 위치 작업에 대해 0%의 지연 기준의 90% 내로 150ms RTT에서 운영자의 성능을 유지하고 있으며 삽입 작업에 대해서는 70% 내로 유지됩니다.
멀티 카메라 스트림 관리
생산 텔레오퍼레이션 설정은 일반적으로 2-4 카메라 (오버헤드, 손목, 사이드뷰) 를 사용합니다. 지연 제한된 연결을 통해 여러 비디오 스트림을 관리하는 것은 신중한 우선순위를 필요로합니다.
- 주류 (목목모 카메라): 최상위 우선순위. 전원 해상도 (640x480), 30fps, 최저 압축. 이것은 미세한 조작을 위한 운영자의 주요 공간 참조입니다.
- 중차 흐름 (오버헤드): 중간 우선순위. 320x240, 자유 공간 이동 동안 15fps; 640x480, 포착 단계에서 30fps. 오버헤드 뷰는 작업 공간 맥락을 제공하지만 프레임-비-프레임보다 덜 중요합니다.
- 제곱류 (사이드뷰): 최저 우선순위. 320x240, 10fps 정상적으로. 운영자가 명시적으로 조사를 선택했을 때만 완전한 해상도로 활성화됩니다. 이러한 스트림은 기본 스트림이 더 많은 대역폭을 필요로 할 때 복구 할 수있는 대역폭 예비입니다.
이 구성의 전체 대역폭은 3-6 Mbps 유지, 8 Mbps 최고. 가용 대역폭이 4 Mbps 이하로 떨어지면, 초등을 떨어뜨리기 전에 중등 및 중등 스트림을 점차 줄이십시오. RCSV의 플랫폼은 실시간 대역폭 모니터링으로 이 우선 순위 제도를 자동으로 구현합니다.
관련 독서
이미테이션 학습 가이드 · 디모네스트 분석당 비용 · 모바일 ALOHA 설정 가이드 · 데이터 해상문제 도전 · 데이터 서비스 · RCSV 플랫폼
제어 명령 프로토콜: UDP vs. TCP vs. WebSocket
제어 명령에 대한 운송 프로토콜의 선택은 텔레오퍼레이션 지연 및 신뢰성에 상당한 영향을 미칩니다. 각 프로토콜은 로봇 제어에 대한 다른 타협점을 가지고 있습니다.
| Protocol | 지연시간 Overhead | Reliability | NAT Traversal | Best Use Case |
|---|---|---|---|---|
| Raw UDP | Minimal (< 1ms) | Unreliable (no retransmit) | None (need VPN or port forward) | LAN teleoperation with direct network access |
| WebRTC DataChannel | Low (2-5ms) | Configurable (ordered/unordered, reliable/unreliable) | Built-in (STUN/TURN) | Internet teleoperation (RCSV recommendation) |
| WebSocket (TCP) | Medium (5-20ms) | Reliable (TCP retransmit) | Easy (HTTP upgrade) | Monitoring, non-time-critical control |
| gRPC (HTTP/2) | Medium (5-15ms) | Reliable | Requires proxy | Structured control APIs, microservice architecture |
** 프로토콜 선택 안내서:** LAN 전용 배포 (로봇과 같은 건물의 운영자) 에 있어서, 원료 UDP는 최소한의 복잡성을 가진 최저 지연을 제공합니다. NAT 및 방화벽을 통해 인터넷 기반의 텔레오퍼레이션에서, WebRTC 데이터캐널은 명확한 선택입니다. 그들은 자동으로 NAT 통로를 처리하고 TCP의 헤드 오프 라인 차단 문제 없이 구성 가능한 신뢰성을 제공합니다. TCP에 대한 WebSocket은 신뢰성이 지연보다 더 중요하게 작용하는 데시보드 또는 비시간적 명령어 (start/stop recording, change task parameters) 를 모니터링하는 데만 적합합니다. gRPC는 마이크로 서비스 아키텍처의 구조화된 제어 API에 유용하지만 높은 주파수 제어 루프에 적합하지 않은 일련의 오버헤드를 추가합니다.
RCSV는 제어 명령어들을 위해 "불신뢰하고 순서하지 않은" 모드로 구성된 WebRTC 데이터채널을 사용합니다. 이것은 내장된 NAT 통로를 가진 UDP와 같은 지연을 제공합니다. 제어 명령어는 50 Hz로 순서 번호로 전송됩니다. 수신기는 순서하지 않은 명령을 다시 순서하기보다는 버린다 (무슨 명령은 건너뛰는 것보다 더 나쁘다). 상태 피드백 (공동 위치, F/T 판독) 에 대해서는 별도의 "신뢰롭고 질서있는" 데이터채널이 리트랜스미션에서 약간 더 높은 지연의 비용으로 상태 업데이트가 손실되지 않도록 보장합니다.
데이터 수집 품질에 대한 지연성 보상
다른 지연수준에서 수집된 원격 텔레오퍼레이션 시범은 훈련 파이프라인에서 다른 처리가 필요합니다. 높은 지연수와 낮은 지연수 시범을 맹목적으로 혼합하면 정책의 질을 떨어뜨릴 수 있습니다. 왜냐하면 지연수 유물 (중심, 수정, 진동) 은 정책에 의해 의도적인 행동으로 해석되기 때문입니다.
- ** 수집 지연을 가진 디모네스트를 태그.** 각 에피소드의 평균 및 P95 RTT를 기록하십시오. 이 메타 데이터는 훈련 중에 지연을 인식하는 데이터 필터링과 중량을 가능하게 합니다.
- 연속성 품질에 의한 무게 시범. 훈련 중에 수집연속도에 반사적으로 비례하는 무게를 지정하십시오. 무게 = 50ms 이하의 경우 1.0; 50-100ms의 경우 0.8; 100-200ms의 경우 0.5; 200ms의 경우 0.3.
- ** 궤도 순조로 필터.** 각 에피소드 에 대한 평균
(위치 제3 추리) 를 계산 한다. 작업 평균 과의 표준 deviations 2 이상 에피소드 는 아마도 지연성 저하 이다. 이 를 훈련 집합 에서 제외 하거나 낮은 무게를 부여 한다. - ** 후처리로서 시간 순조가.** 높은 지연의 에피소드의 행동 궤도에 Savitzky-Golay 필터를 (창 = 11, 순서 = 3) 적용하여 훈련에 사용한다. 이것은 지연을 보상하는 운영자 행동으로 인해 발생하는 높은 주파수 오스컬레이션을 제거하고, 그 중도 궤도 형태를 유지한다.
- 연속성 계층형 훈련. 변수 네트워크 조건에서 수집된 대규모 데이터 집합에 대해, 낮은 지연 (<50ms) 및 높은 지연 (50-200ms) 하위 집합에 대한 별도의 정책을 훈련하고, 성능을 비교하십시오. 낮은 지연 하위 집합 정책이 결합 데이터 정책보다 크게 우수한 성능을 발휘한다면, 높은 지연 데이터는 교육을 저하하고, 배제하거나 크게 저하중치를 받아야합니다. RCSV 경험에서, 30% 이상의 에피소드가 100ms 이상의 RTT를 가진 데이터 세트는 지연기 기반 필터링의 혜택을 누립니다.
생산 데이터 수집을 위한 텔레오퍼레이션 세션 관리
시간대를 통해 여러 원격 운영자를 관리하는 것은 기본적인 WebRTC 연결을 넘어 세션 관리 인프라가 필요합니다.
- ** 세션 전 네트워크 자격.** 각 수집 세션 전에 RTT, jitter, 패킷 손실 및 사용 가능한 대역폭을 측정하는 30 초 네트워크 품질 테스트를 실행하십시오. 네트워크가 최소 임의 (RTT < 200ms, jitter IQR < 30ms, 대역폭 > 5 Mbps) 를 충족하지 않으면 세션을 연기하십시오. 퇴화된 네트워크에 대한 데이터를 수집하는 것은 운영자 시간 낭비이며 폐기해야 할 품질 낮은 시범을 생산합니다. 30초의 투자는 시간 동안 낭비되는 수집 노력을 방지합니다.
- 운동자 스케줄링. 지연수 계층에 따라 로봇 역에 운영자를 할당하십시오. 50ms 이하의 RTT (robot와 같은 지역) 를 가진 운영자는 정밀 작업 (L3/L4) 에 우선권을 얻습니다. 100-200ms의 RTT를 가진 운영자는 간단한 선택 장소 작업 (L1/L2) 에 할당됩니다.
- ** 자동 세션 품질 모니터링.** 실시간으로 RTT, jitter, 패킷 손실, 프레임 속도 및 운영자 처리량을 추적하십시오. 세션 수감자는 품질 측정값이 문턱 이하로 떨어지면 경고하십시오 (RTT > 200ms > 30초, jitter IQR > 50ms, 프레임 속도 < 20fps).
- ** 세션 기록의 완전성.** 동기화된 HDF5 파일에서 전체 세션 상태를 (카메라 피드, 공동 상태, F/T 데이터, 운영자 명령어, 네트워크 매트릭스) 기록하십시오. 네트워크 품질 매트릭스를 별도의 관찰 채널로 포함하여 하류 훈련 파이프라인이 데이터 중량에 대한 지연 정보를 사용할 수 있습니다.
- 운전자 피로 관리. 15분간의 휴식과 함께 45분 동안 최대 연속적인 텔레오퍼레이션 세션을 시행한다. 45분 이상, 네트워크 품질에 관계없이 피로 때문에 디모 품질은 15-25% 감소한다. 자세한 내용은 [ 피로 및 에르고노믹스 연구]
T16 ) 를 참조하십시오.
로봇 비디오 피드에서 적응적인 비트레이트 스트리밍
버퍼링이 허용되는 엔터테인먼트 비디오 스트리밍과 달리, 로봇 텔레오퍼레이션 비디오는 대역폭 변동에도 불구하고 일정하게 낮은 지연성을 유지해야합니다. RCSV의 적응 비트레이트 시스템은 지연률 천장을 유지하기 위해 실시간으로 비디오 품질을 조정합니다.
| Bandwidth Available | Resolution | Frame Rate | Bitrate | Operator Impact |
|---|---|---|---|---|
| > 20 Mbps | 1280x720 | 30 fps | 4-6 Mbps | Full quality; no perceptible degradation |
| 10-20 Mbps | 960x540 | 30 fps | 2-3 Mbps | Slightly reduced clarity; no throughput impact |
| 5-10 Mbps | 640x480 | 30 fps | 1-2 Mbps | Noticeable compression; 5-10% throughput reduction |
| 2-5 Mbps | 640x480 | 15 fps | 0.5-1 Mbps | Choppy motion; 15-25% throughput reduction; L1/L2 tasks only |
| < 2 Mbps | 480x360 | 10 fps | 0.3-0.5 Mbps | Significant degradation; pause session if sustained > 60 seconds |
핵심 원칙: 항상 프레임 속도보다 해상도를 희생하십시오. 운영자는 640x480 해상도에 좋은 성능을 발휘할 수 있지만 시각 피드백 지연이 정확한 위치를 어렵게 하기 때문에 15fps 이하로 어려움을 겪습니다. 로봇 측의 비디오 코더 (인텔/NVIDIA에서 하드웨어 코드인VP8 또는 VP9 소프트웨어 코드) 는 프레임 큐링을 방지하기 위해 200ms 이내에 대역폭 추정에 응답해야 하며, 이는 해상도 감소보다 더 나쁜 지연을 추가합니다.
측정 및 보고서 통신 데이터 품질
각 텔레오퍼레이션 데이터 수집 세션은 시범 데이터와 함께 품질 보고서를 작성해야 합니다. 이러한 측정은 하류 소비자 (ML 엔지니어 훈련 정책) 에 데이터 필터링 및 중량에 대한 정보화 된 결정을 내릴 수 있도록 합니다.
- ** 에피소드 당 네트워크 품질 측정:** 평균 RTT, P95 RTT, jitter IQR, 패킷 손실 비율, 평균 대역폭 사용량. HDF5 에피소드 메타 데이터에 저장하십시오.
- 운영자 성능 측정: 작업 완료 시간, 궤도 순조리 (평균
) , 수정/중개 (속도 제로 경로에서 검출된), 비활성 시간 비율. - ** 수집 시 하드웨어 상태:** 카메라 프레임 속도 안정성 (어떤 프레임도 떨어지는), 공동 코더 읽기 속도, F/T 센서 소음 수준. 하드웨어 해상도는 종종 점진적이며 체계적인 모니터링을 통해서만 감지됩니다.
- **회담 보고서는:**회담 끝에서 수집된 전체 에피소드, 성공률, 평균 품질 점수, 네트워크 품질 계층 분배, 운영자 ID 및 작업 시간. 이 보고서는 자동으로 생성되어 데이터 세트와 함께 저장되어야 합니다.
RCSV의 [데이터 플랫폼] (
예측 디스플레이: 인식된 지연을 줄이는 것
예측 표시 기술은 운용자의 명령에 따라 카메라 피드에 덮여 있는 로봇의 예측 미래 상태를 제공합니다. 이것은 예측 지평선 (일반적으로 50-150ms) 에 의해 인식되는 지연을 감소시킵니다. 실제 네트워크 지연이 높을 때에도 텔레오퍼레이션이 더 반응성이 느껴집니다.
가장 간단한 효과적인 예측자는 운동적인 전향 모델입니다. 현재 명령된 공동 속도를 고려하면 로봇이 앞으로 100ms가 될 곳을 예측하고 비디오 피드에 예측된 최종 효과자 위치의 유령 덮개를 제공합니다. 이 접근 방식은 학습된 모델이 필요하지 않습니다. 로봇의 앞 운동학 (URDF에서 사용할 수 있습니다) 및 명령속도가 달성 될 것이라는 가정만 필요합니다. [OpenArm 1]
더 진보된 예측자들은 학습된 역학 모델을 사용하여 전체 시각 장면의 진화를 예측하지만, 이들은 부분적으로 인식의 이익을 상쇄하는 계산 지연을 추가합니다. 운동적인 유령 초록은 생산 데이터 수집에 대한 실용적인 선택입니다. 그것은 빠르고 (< 1ms 계산), 신뢰할 수 있으며, 다음 움직임을 계획하기 위해 필요한 중요한 정보를 (예측된 최종 효과자 위치) 운영자에게 제공합니다.
연결 요구 사항
- ** 대칭 섬유 (집 또는 사무실):** RTT는 일반적으로 <30ms 국내, <80ms 대륙간. 지속 가능한 텔레오퍼레이션 세션에서 가장 신뢰할 수 있습니다. 4 시간 이상의 세션을하는 운영자에게 최소한으로 권장합니다.
- ** 5G mmWave:** 10
20ms RTT, 100Mbps+ 대역폭. 사용 가능할 때 훌륭하다. 커버리는 여전히 밀집한 도시 지역에 국한되어 있으며, 이동통신 사업자 설정에 신뢰할 수 없습니다. - ** 4G LTE:** 30
80ms RTT 일반적으로 변수. 중도 정밀 작업에 적합하다. Jitter는 주요 문제입니다. - Starlink: 25-60ms RTT, 50-200 Mbps 다운로드. RTT는 위성 위치와 함께 달라지며 위성 전달 (모든 15-30 분) 동안 주기적인 지연성 스피크 (200-500ms) 를 경험합니다. jitter 버퍼링을 가진 L1/L2 작업에 적합하지만 정밀 작업에 권장되지 않습니다. 주기적인 지연은 jitter 버퍼가 5-10x 정상적인 변이를 처리하도록 요구합니다. RCSV는 Starlink을 농촌 사이트에서 원격 데이터 수집을 위해 테스트했으며 적절한 구성된 jitter 버퍼를 가진 간단한 선택 장소 작업에 적합하다고 판단했습니다.
- ** 가정용 와이파이가 공유된다:** 20
100ms 변수, 가정용 교통 기간 동안 잠재적인 200 500ms 스피크를 가진다. 생산 데이터 수집 세션에 대해 운영자가 이더넷을 통해 연결할 것을 요구합니다.
RCSV 텔레오프 플랫폼 는 세션 시작 시 RTT를 측정하고, 운영자를 적절한 작업 줄을 자동으로 로우트하고, 모든 비디오 스트림에 하드웨어 코딩을 가진 WebRTC VP8를 사용합니다.
네트워크 상에서의 긴급 정지 및 안전
원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원격 원형 원형 원형 원격 원격 원격 원형 원격 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원형 원
- ** 심장 박동 모니터링.** 운영자 클라이언트는 10 Hz에서 심장 박동 신호를 전송합니다. 로봇 컨트롤러가 500ms 동안 심장 박동을 받지 않으면 (5 미실 박동) 는 자동으로 속도 램프 다운을 200ms 이상으로 발생시키고, 이어 관절 브레이크의 작동을 유발합니다. 이것은 네트워크 연결이 완전히 떨어지면에도 로봇이 안전하게 멈출 것을 보장합니다.
- 다중 경로 전자 중지. 운영자 UI에 소프트웨어 전자 중지 버튼을 구현하여 기본 WebRTC 데이터채널과 과잉 WebSocket 연결을 통해 중지 명령을 전송합니다. 로봇 컨트롤러는 명령어를 전달하는 경로 중 어느 쪽이 경우 긴급 중지을 유발합니다. 이 두 개의 경로 접근 방식은 단일 채널 오류를 극복합니다.
- 지역 안전 모니터. 로봇 컨트롤러의 별도의 프로세스는 네트워크 연결에 관계없이 공동 속도, 힘 및 작업 공간 경계를 모니터링합니다. 로봇이 작업 공간 경계에 접근하거나 구성 가능한 안전 부피로 정의되는) 힘 임대를 초과하면, 지역 모니터는 운영자 명령에 관계없이 전자 정지기를 유발합니다. 이것은 네트워크 오류와 악성 또는 잘못된 운영자 명령에 대한 방어 기능을 제공합니다.
- 시션 시작 안전 확인. 텔레오퍼레이션 제어 기능을 활성화하기 전에: 카메라가 스트리밍되고, 공동 코더가 보고하고, 전자 정지 회로가 반응 (실동 및 방출 테스트) 이며, 작업 공간이 깨끗하다 (안전 카메라가 감지하는 장애물이 없습니다). 이 체크리스트는 세션 시작 시 자동으로 실행되며 모든 검사가 통과될 때까지 텔레오퍼레이션을 차단합니다.
이러한 안전 조치는 2-5ms의 지연 시간을 추가합니다 (심박수 검증, 경계 모니터링) 하지만 생산 원격 조작에 대해 협상할 수 없습니다. RCSV의 플랫폼은 네 가지 계층을 구현하고 세션 후 검토를 위해 모든 안전 이벤트를 기록합니다.
원격 텔레오퍼레이션 인프라
RCSV의 플랫폼은 네트워크 스택, 지연 보상 및 원격 데이터 수집을 위한 운영자 라우팅을 처리합니다.
[플랫폼을 보]