タイ、日本間でロボットの遠隔操作実験を行いました

なぜタイから日本のロボットを遠隔操作したのか

近年、フィジカルAIへの注目が高まる中、VLAをはじめとするAIを活用したロボット制御の研究が進んでいます。人手不足が深刻な現場での業務や、技術者が不足している専門的な作業、あるいは危険を伴う作業をロボットが代替することが大きく期待されています。

一方、複雑な実環境において、AIだけでロボットを安定して自律制御するには、精度、安全性、例外発生時の対応など、依然として多くの課題があります。

そこでACCESSでは、AIによる完全な自律制御だけでなく、人が離れた場所からロボットを操作する遠隔操作についても検討しています。

遠隔操作であれば、作業者が現地に移動することなく、地理的に離れた場所から作業に参加できます。

将来的には、日本国内に限らず、海外を含む離れた地域の作業者が、ロボットを介して日本国内の作業に参加する形も考えられます。

ただし、このような仕組みを実現するには、国をまたぐ通信の遅延や不安定さが、ロボットの操作にどの程度影響するのかを把握する必要があります。

そこで今回、「タイから日本のロボットを遠隔操作することは、一般的なインターネット環境でどの程度可能なのか」を確認するため、簡易的な実証実験を行いました。

以降では、実験システムの構成、通信品質の測定結果、および実際の操作を通じて確認できた課題について説明します。

この実験の位置づけ

今回の実験は、専用線や特別な帯域保証のない一般的なインターネット環境（レンタルオフィスやホテルのWi-Fiなど）で、ロボットアームの遠隔操作がどこまで実用になるかを確認する目的で実施しました。本記事では、この環境下での接続検証と通信品質の計測結果をまとめています。

実験システムの構成

実験は2026年7月にタイ・バンコクで2日間実施しました。タイ側の通信環境は、レンタルオフィスおよびホテルの一般利用者向けWi-Fiを利用しています。

遠隔操作にはオープンソースのロボットアーム「SO-101」を用い、操作する側（リーダーアーム）をタイ現地に、操作される側（フォロワーアーム）を日本のオフィスにそれぞれ設置しました。

今回用いたロボット制御フレームワークは、リーダーとフォロワーの両方が同じPCにUSB接続されている前提で設計されています。しかし今回は2台のアームが国をまたいで配置されているため、フレームワークには手を加えず、遠隔のリーダーアームを日本側のPCからローカルのUSBデバイスとして認識させる手段として「USB/IP」を採用しました。

USB/IPはLinuxカーネルに組み込まれた機能で、USBデバイスへのリクエストをTCP経由でネットワーク転送します。リーダー側（タイ）のPCでロボットアームをネットワーク経由で共有し、フォロワー側（日本）のPCがそれをローカルデバイスとしてマウントする構成にしました。人がタイでリーダーアームを動かすと、その姿勢がUSB/IP経由で日本へ伝わり、フォロワーアームが追従して動作します。

ただし、USB/IPは本来LAN内での利用を想定したプロトコルです。今回のような高遅延かつパケットロスが生じる長距離ネットワークではTCPの輻輳制御の影響を受けやすく、この点は後述の測定結果にも顕著に表れています。

伝送するデータは以下の2種類です。

操作信号

USB/IPで伝送するロボットの姿勢データ。中継サーバーを経由してインターネット越しに送受信しました。

カメラ映像

日本のフォロワー側の様子をタイの操作者に確認させるための映像。複数台のカメラを利用し、操作信号とは別プロトコルで配信しています。

実際に操作してみた

この構成を用いて、タイ側の操作者が日本にあるフォロワーアームを実際に動かしてみました。

次の動画は、SO-101でUSBケーブルをつまみ、ポートに差し込もうとしている様子です。

実際の操作感としては、ゆっくり手を動かすペースであれば、タイ側のリーダーアームの動きに日本のフォロワーアームが追従し、遠隔操作自体は成立します。動画のように通信が安定している短いタイミングであれば、意図した通りに動かすことができました。

一方で、操作中にアームが数秒間まったく反応しなくなる現象が頻発し、スムーズな連続操作を維持するのは困難でした。この接続の不安定さがネックとなり、当初計画していた本格的な操作タスクの実施は、現状の構成では課題があることが分かりました。

この「数秒間の停止」がどこで、なぜ起きているのか原因を切り分けるため、実験中の通信品質を測定しました。

通信品質の測定結果

遅延はどこで生まれるか

全体の遅延量に加え、それが経路のどこで発生しているかの切り分けも行いました。東京リージョンのEC2を中継した構成にて、SSHトンネルの2区間（日本国内と国際区間）の往復時間を約7分間（184サンプル）計測した結果が下図です。

区間	往復時間	ジッタ	再送
日本国内（フォロワー〜中継サーバー）	約3.5ミリ秒	ほぼ一定（標準偏差0.03ミリ秒）	0回
国際区間（中継サーバー〜現地）	約232ミリ秒	標準偏差17ミリ秒	断続的に発生

計測の結果、往復時間の大部分（約98％）が東京の中継サーバーからタイ側PCまでの国際区間で発生していることが確認できました。対照的に、日本側PCから東京リージョンまでの区間は約3.5ミリ秒と非常に安定しています。このことから、遅延や通信の揺らぎの主原因は、東京からタイ現地に至る経路側にあると言えます。

（※中継サーバーをシンガポールに配置した場合は、日本〜シンガポール間も国際回線となるため、この遅延割合とは異なる傾向になります。）

操作信号の往復時間の分布

操作信号の往復時間（遅延）の分布を確認すると、極端な偏りがあることがわかりました。東京のEC2インスタンスを中継した2つのセッション（レンタルオフィス環境での約50秒間、ホテル環境での約1分10秒間、計1,444リクエスト）について、日本側のフォロワーPCでパケットをキャプチャし、往復時間を算出した結果が下図です。場所も時間帯も異なる検証ですが、どちらも明確に同じパターンを描いています。

分布が二峰性を示しています。往復100〜200ミリ秒の状態と、1,000ミリ秒を超える状態の2つに割れ、その中間がほとんど存在しません。

USB/IPでは、データ転送の下位層にTCPが使われています。TCPでは、パケットロスが発生すると失われたデータの再送が行われますが、再送処理が終わるまで後続のデータ処理が待たされてしまうため、今回のような高遅延の回線では影響が長引く傾向があります。実際の計測データでも、TCPの再送が発生したタイミングで、操作信号の応答時間が1秒を超える状態がまとまって観測されました。

この影響は、下図のように応答の到着頻度の周期的な変動として現れます。TCPの輻輳制御による送信制限と回復が繰り返されることで、フォロワーPC側への応答頻度が毎秒15〜20回（正常時）と毎秒5〜8回（悪化時）の間で変動します。スループット悪化時はロボットへの制御指示が半分以下に落ち込むため、フォロワーアームの追従が遅延したり動作がカクついたりし、操作者には止まっているように感じられます。

中継サーバーの配置による違い

中継用のEC2インスタンスを東京リージョンからシンガポールリージョンへ切り替えたところ、通信品質に下図のような変化が見られました。なお、シンガポール構成では操作開始前に応答がタイムアウトして切断される事象が頻発したため、十分なパケットをキャプチャできていません。表の数値は切り替え直後のデータに基づく推定値であり、あくまで参考値となります。

EC2インスタンスの配置リージョン	制御信号のレート	500ミリ秒以上の割合	操作の成否
東京リージョン	毎秒12〜13回	43〜44％	短時間だけ動作（数秒〜約1分で切断）
シンガポールリージョン	毎秒1〜3回	15％	通信は改善したが、全軸検出が不安定で動作せず

シンガポール構成では再送による遅延の頻度は下がったものの、ロボットアームの全軸検出が安定せず、結果的に操作を開始できませんでした。全軸検出は6軸すべてからの応答が揃うのを待つ仕組みのため、ネットワークの遅延や揺らぎによって一部の応答が間に合わなかったと考えられます。なお、この接続の不安定さについては、通信遅延だけでなく、USB/IPの接続確立プロセスや中継サーバーの設定など、別の要因が引き金になっていることも考えられます。

測定結果から見えた課題

今回の実験を通して、遠隔操作のボトルネックとなる要因が数値として見えてきました。特に、日本側PCから東京リージョンまでの区間は安定していたのに対し、東京リージョンからタイ側PCまでの区間に遅延と変動が集中していたことは大きな収穫でした。ただし、この区間には国際回線だけでなく、タイ国内のアクセス回線や現地のWi-Fi環境が混在しているため、今回の測定だけではどこが根本原因かまでの切り分けには至っていません。

一連の検証から、遠隔操作を安定させるための課題として以下の4点が見えてきました。

操作信号の送り方

今回はUSB/IPを使い、リーダー側の姿勢を60Hzという高頻度で読み取る構成でした。そのため、TCPの再送待ちが発生すると新しいデータが取得できず、制御ループが詰まってしまいます。目標とする姿勢や軌道をアプリケーション層でまとめて送る方式に切り替えれば、通信が一時的に乱れても影響を局所化でき、同じネットワーク環境でも操作を維持しやすくなる可能性があります。

タスクの選び方

操作信号の往復時間は、正常時でも約194ミリ秒（60Hz制御の約12周期分）かかっています。素早い位置決めや繊細な力加減が求められる作業には厳しいため、まずは遅延の影響を受けにくい、ゆったりした掴み動作や配置作業などから適用していくのが現実的です。

映像の伝送方法

既存の配信ツールを使った今回の映像伝送では、タイ・日本間で約400ミリ秒の遅延がありました。国内LANでの別検証では遅延の約84％がカメラの内部処理とバッファによるものだったため、カメラ側の処理が大きなボトルネックになり得ます。そのため、ハードウェアの選定も含めた見直しが必要です。

ロボット側の安全制御

不安定なインターネット環境を使う以上、通信が数秒途切れてもアームが暴走せず、安全に一時停止して待機できるフェイルセーフの仕組みづくりが不可欠です。

今回の結果は、長距離ネットワークでUSB/IPをそのまま利用したことによる影響が大きく、一般的なインターネット回線での遠隔操作そのものが不可能なわけではありません。

まとめ

今回の実験を通じて、タイと日本の間でロボットを遠隔操作した場合に、通信遅延や通信品質の変動が操作性にどのような影響を与えるのかを確認できました。

また、遠隔操作を安定して行うためには、単に通信速度を高めるだけでなく、映像伝送の方法、操作コマンドの送信方式、通信の揺らぎへの対応、ロボット側での安全制御など、システム全体を考慮する必要があることも分かりました。

ACCESSは、ネットワークOS「OcNOS」をはじめとするネットワーク関連製品の開発を通じて、通信やネットワーク制御に関する知見を蓄積してきました。今後は、これらの知見にロボット制御やAI技術を組み合わせ、遠隔操作の安定性向上や、遠隔操作とAIによる半自動制御を組み合わせた仕組みについても検討を進めていきます。

人手不足が課題となっている現場へのロボット遠隔操作の導入、海外を含む遠隔地からの作業支援、AIと遠隔操作を組み合わせた段階的な自動化などにご関心がございましたら、お問い合わせフォームよりご連絡ください。