インターネット上でロボットテレオペレーション:遅延とパケット損失を処理する
インターネット上の遠隔ロボットテレ操作のための技術戦略 遅延補償,ビデオストリーミング,制御法の適応,接続要件
[テレオペレーションガイド]
[←ブログ]
インターネットの遠隔操作は グローバルにデータ収集を拡大するために不可欠です. これが信頼性の高い機能を作るのに必要なことです.
任務による遅延要求
遠隔操作の作業は全て同じ遅延耐性を持つわけではありません.
- 精度接触作業 (<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の改善) に最適化することは,オペレーターをロボットに近づく1000kmほど移動するほどほぼ同じ影響を与える (RTTを1000kmあたり約10ms減少させる).ビデオパイプラインのソフトウェア最適化は,地理的位置よりもほぼ常にコスト効率的です.
遅延補償:波変数と予測方法
**波変形式:**波変数 (Niemeyer and Slotine, 1991) は,速度力制御信号を通信チャンネルを通じて伝播する波変数に変換する. これにより,波変数は,変数遅延ネットワーク上の二国間フォースフィードバックテレオペレーションの理論上正しいアプローチとなります.
波変数実装は透明性のために安定性を交換する - 操作者は,波変形が力信号を滑らかにするので,鋭い力反射ではなく"むら"の反応を感じます. 力の反射品質が任務の完了に次要であるデータ収集作業では,この妥協は受け入れられます. フォース透明性が重要である外科の遠隔操作では,波変数は,被動性を侵害せずに知覚した透明性を向上させる局部フォースモデルと組み合わせます.
予測者ベースの補償: スミス予測器 (恒久的な遅延を想定する) を超えて,時間変化による遅延予測器は,現在の推定遅延によってロボットの先進状態を予測するために,ローカルダイナミックモデルを使用します. カルマンフィルターベースの予測器は最も一般的なものです. 遠隔ロボットの状態の推定を保持し,ロボットの動力学モデルと最新の制御コマンドを使用してそれを前進させる. 遅延した観測が実際のロボットから到着すると,カルマンフィルターは予測を修正します. このアプローチは変数ジッターをうまく処理しますが リモートロボットの正確な動力モデルが必要です
モデル介護の遠隔操作: オペレーターはリモート環境のローカル仮想レプリカと相互作用する.レプリカは実際のロボットのセンサーデータからアシンクロン的に更新される. オペレーターはゼロ遅延で仮想レプリカを制御し,実際のロボットはネットワークが課す遅延によって仮想レプリカの状態を追跡する. 費用:仮想レプリカは,環境がレプリカがモデル化しない方法で変化した場合,現実から異化することが可能 (オブジェクトが移動し,人物は作業スペースに入ります).宇宙の遠隔操作およびますます地上からの遠隔データ収集に成功的に使用されています.
プロトコル比較: 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のテレオッププラットフォームは,ビデオ (メディアチャンネル) と制御コマンド (信頼性の低い DataChannel) の両方で WebRTC を使用します.信頼性の低い DataChannel モードは,リアルタイム制御のための正しい行動であるリトランスミットよりも,時代遅れの制御コマンドを落とします. 安全性・重要な信号 (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 |
データ品質影響列は,ローカルテレオペレーションと比較して示範の滑らかに (平均のジラ) とタスク完了時間の測定違いを反映しています.重要な発見:100ms RTT未満の遅延は,標準のピックプレスタスクのローカルコントロールから統計的に区別できない示範を生成します.100ms以上では,遅延と質はほぼ線上的に低下します. 200ms以上では,遅い接触のない作業のみが使用可能な示範データを生成します.
パケット損失処理
インターネットパケットの損失は,通常,良好な接続で0.01-0.5%ですが,渋滞中に2~5%まで増加します.50Hzで送信される制御コマンドの場合,1%の損失は,2秒ごとにコマンドが落下することを意味します.影響は受信コントローラが欠けているコマンドをどのように処理するかによって異なります.
- 最後のコマンドを保持 (ゼロ順序保持): ロボットは新しいコマンドが来るまで最後の受信コマンドを実行し続けます.速度コマンドに安全 (ロボットは最後の命令速度で継続します).位置コマンドに危険 (ロボットは停止し,不安定な接触状態に置き去ります).
- Extrapolate (第一順位保持): ロボットは,最後の2つの受信されたコマンドに基づいてコマンド軌道を外出します.滑らかな動き連続性のためによりよいが,操作者が遅くなっていた場合過越することができます.逃走を防ぐために速度大度制限を使用します.
- Interpolation buffer: バッファーは,未来のコマンド2〜3 (40~60ms遅延を追加) をバッファリングし,それらの間をインターポレーションする.単行パケットの損失を完全に平滑させる. 一貫した軌道の質が絶対最小遅延よりも重要であるデータ収集に使用推奨.
RCSVは,適応深さを持つ2コマンドのインターポレーションバッファを使用します.バッファは高損失期間に成長し (パケット間の間隔の監視によって検出されます) そして安定期間に縮小します.これはわずかに変動する遅延 (50-100msの追加バッファが最悪の場合) のコストで一貫した動作品質を提供します.
関連 読書
- [テレオペレーションの疲労とエロゴノミクス研究]
- [ロボット訓練データ:収集方法と最良の実践]
- [ロボット軌道の注記:課題と品質基準]
- [ロボット配備チェックリスト]
- [RCSVテレオッププラットフォーム]
- [RCSVデータ収集サービス]
投機管理: 低評価された問題
ネットワーク遅延は注目されるが,時間とともに遅延の変動は,絶対遅延よりも遠隔操作品質に害を及ぼすことが多い.視覚的なリード技術で一貫した100ms遅延は管理できます.30msから200msの間を振動する接続は,操作者が適応できない,不具合的で予測できないロボット行動を生成します.
Jitterを測定. RCSVは30秒間の窓間に回帰時間の間隔 (IQR) としてジートを測定する.健全な接続は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.0 m/s エンドエフェクター) を許可します. 150ms RTT で,0.3 m/s に制限します. 300ms RTT で,0.1 m/s に制限します.これらの制限は,視力フィードバックが遅れてしまうため,操作者が超越する動作を命令することを妨げます.
リモートセッションのデータ品質評価
遠隔操作セッションでの示範品質は,現地セッションとは別々に評価されるべきである.RCSVは,遠隔操作セッションがトレーニングデータ品質基準を満たしているかどうかを判断するために3つの指標を使用する.
- 軌道滑らか (平均震動): 末エフェクター位置軌道の第三次導体を計算する. 100ms 以上の遅延を持つ遠隔デモは,通常同じ作業のローカルデモよりも40~80%高い平均震動を示します.ローカルベースラインの2倍以上の震動を持つデモは,レビューのためにマークする必要があります.それでも成功するかもしれませんが,より騒音なトレーニング信号を生成します.
- タスク完成時間比: リモートデモは,ローカルデモよりも時間がかかる.2.0x以上の完成時間比 (リモートではローカルよりも2倍以上時間がかかる) は,演示品質の低下 (過度な躊躇,修正的な動き) と関連している.これらのエピソードは,訓練中にレビューされ,排除または減重される可能性がある.
- コマンドの滑らか: 操作者の原始コマンドストリームを突然の速度逆転,長い休憩,そして高速の振動を分析する.これらは操作者が遅延を戦っていることを示します.単純なピックプレスタスクでエピソードごとに3回以上の逆転は品質の旗です.
RCSVの経験では,100ms以下のRTTで収集されたリモートデモは,訓練目的で現地デモと区別できない.100-200msの間,デモは使用可能だが,トレーニングセット内の現地デモと2:1を混合する必要があります.200ms以上では,デモは接触のない移動とナビゲーション作業のみに使用されるべきです.
ロボット遠隔操作のための WebRTC 設定
WebRTCは,ロボットテレオペレーションにおけるリアルタイムビデオストリーミングの標準プロトコルである.NATのトラスレ,適応ビットレート,ジッターバッファリングをネイティブに処理しているため.しかし,デフォルト WebRTCの設定は,ロボット制御ではなくビデオ会議のために最適化されています.テレオペレーションの主要な設定変更:
// 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) ネットワーク層のバッファ膨張を防ぐために,1カメラあたり2 Mbpsのキャップビットレートは低い. (3) 720pや 1080pではなく640x480分辨率を使用する. (4) フレームレートを30fpsに設定する. 15fpsに低下すると帯域幅が節約されるが,高速作業での操作者のパフォーマンスは20%低下する.
予測 機能: 視界 の 遅延 を 補償 する
予測表示は,操作者の性能を100-300ms遅延で維持するための最も効果的な技術である.このシステムは,遅延カメラ画像に覆われた予測ロボット状態を表示し,画像が撮影されたときにロボットがどこにいたかではなく,現在 (予測) に操作者に示します.
実施には: (1) 将来のT_latency秒間の関節位置を予測できるロボットの кинеマティックモデル, (2) 予測されたロボットがカメラフィードの上部に位置している3Dレンダリングオーバーレイ,および (3) 予測の視界を実際の往復遅延に匹敵させる遅延推定器が必要です.
単純な動き (自由空間に到達) において,最後の命令された軌道を利用した前進運動学予測は十分であり,軽い計算を加えます.接触作業では,予測は予想される接触力と潜在的な軌道の偏差を考慮する必要があります.これはダイナミックモデルまたは学習された予測が必要である. RCSVの評価では,予測ディスプレイは,ピックアンド・プレイスタスクのゼロ遅延ベースラインの90%以内に,挿入タスクの70%以内に, 150ms RTTでオペレーターのパフォーマンスを維持します.
多カメラストリーム管理
生産遠隔操作設定では通常,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 DataChannels は明確な選択です. WebSocket over TCP は,遅延よりも信頼性が重要である場合,ダッシュボードや非時間・重要なコマンド (スタート/ストップ記録,タスクパラメータ変更) を監視する場合にのみ適しています. gRPC はマイクロサービスアーキテクチャにおける構造化制御 API に有用ですが,高周波制御ループに不適したシリアル化オーバーヘッドを追加します.
RCSVは制御コマンドのために"信頼できない,秩序のない"モードで設定されたWebRTC DataChannels を使用します.これは内蔵されたNAT横断でUDPのような遅延を提供します.制御コマンドはシーケンスの番号で50Hzで送信されます.受信機は,命令を再編する代わりに,命令を退却します (旧なコマンドは,跳ね出された命令よりも悪い). 状態反
遅延 データの収集品質の補償
遅延レベルによって収集される遠隔操作デモは,訓練パイプラインで異なる処理を必要とする. 遅延率の高いと遅延率低いデモを盲目的に混合することは,遅延のアーティファクト (躊躇,修正,振動) が,意図的な行動として政策によって解釈されるため,政策の質を低下させる可能性があります.
- 収集遅延性のある示範をタグする. 各エピソードにおける平均とP95 RTTを記録する.このメタデータは,訓練中に遅延意識のデータフィルタリングと重量化が可能になります.
- ** 遅延品質による重量示例.** 訓練中に,収集遅延に逆比例する重量を割り当てます. 体重 =50ms 以下の場合は1.0,50ms,50-100ms の場合は0.8,100-200ms の場合は0.5,200ms の場合は0.3ms. これは,完全に排除せずに,遅延を低下させるエピソードの影響を減らす.
- 軌道滑らかに別れ. 各エピソードにおける平均震動 (位置の3番目の導体) を計算する.任務平均から標準偏差2以上の震動があるエピソードは,遅延度が低下している可能性が高い.これらのことをトレーニングセットから除外するか,低い重量を与えます.
- ** 処理後として時間滑らか.** 高遅延エピソードのアクション軌道を訓練に使用する前に,サビッツキー-ゴレイフィルター (ウィンドウ=11,順序=3) を適用します.これは,遅延を補償する操作者の行動によってもたらされる高周波振動を除去し,粗大軌道を保持します.
- 遅延層次訓練. 変数ネットワーク条件で収集された大規模なデータセットについて,低遅延 (<50ms) と高遅延 (50-200ms) のサブセットについて別々のポリシーを訓練し,パフォーマンスを比較します.低遅延子セット政策が組み合わせデータ政策を大幅に上回っている場合,高遅延データではトレーニングを劣化しており,排除または重量低下する必要があります. RCSVの経験では,エピソードの30%以上が 100msを超える RTT を持つデータセットは,遅延ベースのフィルタリングから恩恵を受けています.
生産データ収集のためのテレオペレーションセッション管理
時間帯を介して複数のリモートオペレーターを管理するには,基本的な WebRTC 接続を超えたセッション管理インフラストラクチャが必要です.
- セッション前のネットワーク資格* 各収集セッション前に,RTT, jitter,パケット損失,利用可能な帯域幅を測定する30秒間のネットワーク品質テストを実行します.ネットワークが最低限の限界値 (RTT < 200ms, jitter IQR < 30ms,帯域幅 > 5 Mbps) を満たしていない場合は,セッションを延期します. ネットワークの劣化に関するデータを収集することは,オペレーターの時間を無駄にしたり,廃棄する必要がある低品質の示範を生産したりします.30秒の投資は,時間の無駄な収集努力を防ぐ.
- オペレータースケジューリング. 遅延レベルに基づいてロボットステーションにオペレーターを割り当てます.50ms未満のRTT (ロボットと同じ地域) のオペレーターには精度作業 (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 を参照してください.
ロボットビデオフィードのための適応性ビットレートストリーミング
ブロードキャプターによるビデオ配信は,ブロードキャプターによるビデオの流出に適しています. ブロードキャプターによるビデオの流出は,ブロードキャプターによるビデオの流出に適しています.
| 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解像度で良いパフォーマンスを発揮できますが,視覚フィードバック遅延により正確な位置付けが困難です. ロボット側にあるビデオエンコード (Intel/NVIDIAのVP8ハードウェアコード,またはVP9ソフトウェアコード) は,フレームキューを防ぐために,帯域幅推定値に 200ms以内に反応する必要があります.これは,解像度削減よりも遅延を悪化させる.
測定と報告のテレオペレーションデータ品質
遠隔操作データ収集セッションごとに示範データとともに品質報告が作成されるべきです. これらの指標は,下流消費者に (MLエンジニアの訓練政策) データのフィルタリングと重量化に関する知的な決定を可能にします.
- ** ネットワーク品質メトリック各エピソード:** 平均RTT,P95RTT,ジッター IQR,パケット損失割合,平均帯域幅利用. HDF5エピソードメタデータに保存する.
- オペレーターのパフォーマンスメトリック: 任務完了時間,軌道の滑らしさ (平均の揺れ),修正/猶予数 (速度ゼロクロスから検出),無動時間割合. 生産量の25パーセント以下に一貫して稼働するオペレーターは追加の訓練または転職を受ける.
- **収集時にハードウェアの状態:**カメラフレーム速度の安定性 (任意の落としたフレーム),コイントエンコーダー読み率,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は衛星位置によって変化し,衛星移転中に (200-500ms) 周期的な遅延ピークを経験する. (毎回15-30分).JitterバッファリングのL1/L2作業に有効だが精度作業では推奨されません.周期的なピークは, jitterバッファが正常な変数を5〜10倍処理することを要求し,遅延を補償する. RCSVは,Starlinkを農村部からのリモートデータ収集にテストし,適切な設定されたジッターバッファで簡単なピックプレス作業に適当であると判断した.
- **家庭WiFi (共有):**20
100ms変数,家庭交通中に200500msのピークが起こり得る.生産データ収集セッションのためにオペレーターからイーサネットで接続を要求する.
RCSV teleop platform はセッション開始時にRTTを測定し,オペレーターに適切なタスクキューを自動的にルーティングし,すべてのビデオストリームにハードウェアコード付きWebRTC VP8を使用します.
ネットワーク上で緊急停止と安全
遠隔操作は,安全性のユニークな課題を提示します.操作者はロボットから物理的に分離され,物理的なe-stopボタンを押すことはできません.ネットワークベースの安全構造は,同様の保護を提供する必要があります.
- 心拍数モニタリング. オペレータークライアントは10 Hzで心拍数信号を送信します.ロボットコントローラが500ms (5ミットミットミットミット) の間に心拍数を受け取らない場合,自動速度をゼロに減らし,その後関節ブレーキを起動します.これはネットワーク接続が完全に落ちてもロボットが安全に停止することを保証します.
- ダブルパースのe-stop. 操作者UIにソフトウェアのe-stopボタンを実装し,既主要WebRTC DataChannel および冗長なWebSocket接続の両方でストップコマンドを送信します. ロボットコントローラーはいずれかのパースがコマンドを送信した場合,緊急停止を起動します.このダブルパースアプローチはシングルチャネル故障を生き残ります.
- ローカル・セーフティ・モニター. ロボットコントローラ上の別プロセスは,ネットワーク接続から独立して,関節速度,力,作業空間境界を監視する. ロボットが作業空間境界に近づく場合 (設定可能な安全量によって定義される) または力限界を超えると,ローカル・モニターは,操作者のコマンドを問わず,電子ストップを起動します. これはネットワーク故障と悪意のある操作者命令の両方に対して防御を提供します.
- セッション開始安全チェック. 遠隔操作制御を有効にする前に,カメラがストリーミングされていること,コアントエンコードが報告していること,電子ストップ回路が応答性 (トリガーとリリーステスト) と作業場がクリア (安全カメラが検知する障害物はない) を確認してください.このチェックリストはセッション開始時に自動的に実行され,すべてのチェックが通過するまで遠隔操作をブロックします.
これらの安全対策は, 2-5ms の遅延 (心拍数チェック,境界監視) を追加しますが,生産遠隔操作では交渉できません.RCSV のプラットフォームは,セッション後のレビューのために4 つの層をすべて実装し,すべての安全イベントを記録します.
リモートテレオペレーションインフラストラクチャ
RCSVのプラットフォームは,ネットワークスタック,遅延補償,そして遠隔データ収集のオペレータールーティングを処理します.
[プラットフォームを見る]