Unitree Go2 と AWS で自律巡回する警備ロボットを作る【前編】
2026-11-04 | Author : 永井 祥太
はじめに
アマゾン ウェブ サービス ジャパン合同会社でソリューションアーキテクトをしている永井です。2026 年に入社し、製造業のお客様を担当しています。
Unitree 社の四足歩行ロボットは、展示会や動画などで目にする機会が増えています。本記事では、興味を持って個人で購入した Unitree Go2 Pro を使い、倉庫などの巡回警備を想定した自律巡回ロボットを AWS と組み合わせて構築した内容を紹介します。
前編では、構築したシステム全体と、処理の配置 (Go2、エッジ、AWS のどこで何を実行するか) の判断を中心に説明します。SLAM の原理や実行手順などの細部は、別途 後編記事で補足予定です。
本記事で扱う内容は次のとおりです。
- Go2 Pro の特徴と制約
- システム構成と、処理の配置
- SLAM による地図作成と、自律巡回
- AWS を使った検知 (Amazon Rekognition、Amazon Bedrock) と違反レポート
- 停止設計
※ 本記事は Go2 Pro を対象とし、2026 年 8 月から 10 月の実機検証に基づきます。数値は屋内の単一環境で測定した参考値です。
写真 : 購入した Unitree Go2 Pro
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
1. Go2 Pro の特徴と制約
Go2 には、下位から Air、Pro、X、EDU のモデルがあります。Pro は中間に位置し、LiDAR・カメラ・IMU・関節状態の取得と、移動速度や姿勢などの高レベルな指令を行えます。リモコンも付属しており、手動操作 (テレオペレーション) も可能です。一方、各関節 (サーボ) への直接指令は EDU に限定されています。実機で確認した、開発上の主な制約は次のとおりです。
|
項目
|
確認結果
|
開発上の意味
|
|---|---|---|
|
SSH (:22)
|
Wi-Fi・有線のいずれも closed |
機体上で独自のプロセスを実行できない |
|
メーカーのクラウドリレー
|
機体側で無効 |
インターネットから機体へ直接は到達できない |
|
関節の低レベル制御
|
EDU 限定 |
移動は速度・角速度の指令で行う |
|
ローカルのシグナリング (:9991)
|
open (WebRTC) |
同一ネットワークから、アプリと同様の API で通信できる |
この制約から、機体上には何も導入せず、同一 LAN 上に置いたエッジ側の計算機が機体と WebRTC で通信し、その計算機が AWS と接続する構成にしました。
2. システム構成と、処理の配置
2-1. 全体構成
機体には Jetson AGX Orin と 3D LiDAR (Livox Mid-360) を搭載し、Jetson 上の AWS IoT Greengrass V2 が AWS IoT Core と接続します。Jetson と Go2 は有線 LAN で接続しています。
ロボット側の仕組み
Jetson 内では、3 つのプロセスがローカルの ZeroMQ バスで接続されています。Go2 との唯一の WebRTC 接続を保持して走行を担う go2_link、検知を担う perception (CUDA コンテナ)、SLAM と経路計画を担う slam (ROS 2 コンテナ) です。WebRTC は機体との同時接続が 1 つに限られるため、機体との通信は go2_link に集約し、音声の再生も同じ接続で行います。
写真 : Jetson AGX Orin と Mid-360 を載せて歩行する Go2
2-2. どこで何を実行するか
|
配置
|
実行する処理
|
配置の理由
|
|---|---|---|
|
Jetson (エッジ)
|
自己位置推定と地図作成 (SLAM) 、経路計画、停止判定、エッジ側の検知 |
走行と安全に直結し、通信断でも継続する必要がある |
|
AWS
|
メッセージ中継 (AWS IoT Core)、検知 (Amazon Rekognition、Amazon Bedrock)、違反レポートの保存 (Amazon S3)、LAN 外からの監視・操作 (Amazon EC2、Amazon CloudFront) |
重い推論と、現地に依存しない運用を担う |
配置の判断には、遅延の実測を用いました。Go2 が動作指令を受けてから動き始めるまでに約 115 ms を要し、ネットワークの往復時間 (機体との間が 5.4 ms、AWS 東京リージョンまでが 7.3 ms) より一桁大きい値でした。この値に AWS までの往復を加えた増分は、東京で約 6 %、バージニア北部では約 157 % です。制御周期を 10 Hz とすると、通信時間が占める割合は東京で 12.7 %、バージニア北部で 185 % となるため、AWS のリージョンには東京を選択しました。一方で、停止判定や自己位置推定のようにリアルタイム性と通信断への耐性が求められる処理は、リージョンの選択にかかわらずエッジに置いています。
※ 遅延は 2026 年 8 月 14 日に、状態問い合わせ API を各 30 回呼び出して測定した中央値です。
結果として、クラウドは「推論・保存・運用」を担い、エッジは「走行と安全」を担う分担になっています。
2-3. AWS 側の構成
Jetson から AWS への接続は、IoT Greengrass V2 のコンポーネント cloudlink が担います。ローカルバスのデータを AWS IoT Core のトピックに中継し、LAN の外にいる閲覧者にも、ローカルのダッシュボードと同じデータを届けます。
|
方向
|
トピック (go2/<thing>/…)
|
内容
|
頻度
|
|---|---|---|---|
|
上り
|
frame |
カメラ画像 (JPEG、幅 640 px) |
3 Hz |
|
上り
|
state |
機体の状態 (点群は 400 点に間引き) |
5 Hz |
|
上り
|
detect |
検知結果 (edge / cloud) |
検知ごと |
|
上り
|
slam、slam_map |
自己位置、占有地図 (PNG) |
2 Hz、0.5 Hz |
|
下り
|
cmd |
操作・巡回・モード切替などの指令 |
操作ごと |
AWS IoT Core の 1 メッセージの上限は 128 KB のため、画像は幅 640 px の JPEG に縮小し、127 KB 以内に収めています。バイナリは「4 バイトの長さ + JSON のメタ情報 + 本体」の形式で 1 つのペイロードに詰めています。QoS は 0 にしています。画像や状態は最新の値だけが必要で、再送された古い値が届くことが望ましくないためです。
認証には、デバイス証明書と IoT Core の認証情報プロバイダー (ロールエイリアス) を使います。Jetson と、その上のコンテナは、一時的な認証情報で S3 などにアクセスするため、長期のアクセスキーを機体に置いていません。権限は用途に絞っており、検知を担う Jetson のロールには、違反レポートの保存先 (reports/*) への s3:PutObject と、暗号化に必要な AWS KMS の GenerateDataKey だけを付与しています。閲覧側の EC2 のロールには reports/* の読み取りだけを付与しています。保存先の S3 バケットは AWS KMS で暗号化しています。
LAN の外からの閲覧は、EC2 上の Web サーバー (hub) が AWS IoT Core のトピックを WebSocket で購読し、Amazon CloudFront を経由して配信します。指令は逆方向に、cmd トピックを通じて Jetson に届きます。
保守は SSH を使わずに行います。IoT Greengrass の named shadow に実行するコマンドを書き込むと Jetson が実行する仕組み (ops shell) と、Amazon S3 を経由したファイル配布により、現地の LAN 構成に依存せずにコードを更新できます。EC2 側の更新は、S3 に置いた成果物を AWS Systems Manager の Run Command で配布しています。IAM ロールの変更などのインフラの更新は、AWS CloudFormation の変更セットで内容を確認してから適用しています。
2-4. 有線 LAN
調査の初期には、マニュアルに記載がないことから「Pro に有線 LAN ポートはない」と整理していましたが、実機にコネクタがあることを確認しました。機体側のアドレスは固定 (192.168.123.161) で DHCP は配布されないため、ホスト側に静的 IP の設定が必要です。往復時間は 0.68 ms で、Wi-Fi の 3.9 ms より短く測定されました。一方、開いているポートや LiDAR の受信レート (約 7.7 Hz) は Wi-Fi と変わりませんでした。
3. SLAM による地図作成と、自律巡回
3-1. SLAM とは
SLAM (Simultaneous Localization and Mapping) は、ロボットが周囲をセンサーで観測しながら、自分の位置の推定と地図の作成を同時に行う技術です。本構成では、Livox Mid-360 (1 スキャンあたり約 2 万点、約 10Hz) の点群を FAST-LIO で処理して自己位置を求め、5 cm 格子の 2D 占有地図に変換しています。これらは Jetson 上のコンテナで実行しており、位置の推定結果は約 10 Hz で、走行を担当するプロセスに渡されます。
電源を入れ直すたびに、FAST-LIO の座標の原点は起動位置になります。このため、保存した地図に対して現在位置を合わせ直す再定位を実装しています。別途公開する記事で補足予定です。
3-2. 経路計画と巡回
地図が得られたあとの走行は、Jetson 上の経路計画 (Navigator) が担当します。占有格子上の A* で経路を求め、動く物体を迂回し、未観測の領域との境目 (フロンティア) を目標にして探索します。
巡回の経路は、地図から自動で生成します。障害物を 0.35 m 膨らませ、壁から 0.6 m 離した周回路を 0.5 m 間隔の点列として求め、先読み距離 0.8 m で追従します。巡回中に地図が広がった場合は、周回路を作り直します。また、SLAM の出力が途絶えた場合は、座標系が異なる走行距離計 (オドメトリ) に切り替わるため、その間は巡回を一時停止します。
経路計画は Jetson で実行するため、会場のネットワークが切断されても、ローカルの画面 (Jetson 上のダッシュボード) からの操作と巡回は継続できます。
図 : ダッシュボードの地図パネル。5 cm 格子の占有地図に、走行した軌跡 (緑) と現在の位置・向き (オレンジ) を重ねて表示する
4. AWS を使った検知と違反レポート
巡回中に映像から安全上の違反を検知する処理は、エッジとクラウドの 2 通りを実装し、画面上でモードを切り替えて (edge / cloud / both) 比較できるようにしています。想定する用途は倉庫などの巡回警備で、ヘルメットや保護ベストの未着用、立入禁止区画への侵入などを対象にしています。
|
モード
|
処理
|
実行場所
|
|---|---|---|
|
edge
|
人物検出 (YOLOX-s) → 姿勢推定 (RTMPose) → 属性判定 (CLIP のゼロショット) → ルール判定 |
Jetson |
|
cloud
|
保護具検出・ラベル検出 (Amazon Rekognition) → 情景の説明と危険判定 (Amazon Bedrock、Amazon Nova Lite) が出力する JSON をルール判定へ |
AWS (東京リージョン) |
クラウド側では、Amazon Rekognition の保護具検出 (DetectProtectiveEquipment) とラベル検出の結果を Amazon Nova Lite に渡し、画像の内容の説明と危険の有無を JSON で返させています。画像中の物体を検出するだけでなく、文脈を踏まえた解釈をモデルに行わせる点が、エッジ側のパイプラインとの違いです。
エッジとクラウドの両方に検知を実装した理由
エッジとクラウドの両方に検知を実装した理由は、工場や倉庫では、通信環境が不安定になったり、オフラインになったりする可能性があるためです。クラウドの検知は大規模なモデルによる文脈の解釈ができる一方、通信が前提になります。エッジの検知は、通信がなくても動作します。ローカルのダッシュボードからの操作と、エッジの検知は、クラウドへの接続がなくても継続できるように構成しています。なお、edge と cloud の切り替えは画面上の操作で行います。通信状態に応じて自動で切り替える機能は、2026 年 10 月時点では実装していません。違反レポートの送信については、通信断の間もエッジ側で検知と保存を続け、復旧後にまとめて送信します (後述)。
実機で測定した結果、cloud モードの Amazon Rekognition と Bedrock の処理時間は 984 ms でした。ダッシュボードに表示する遅延の平均は 3.46 s でしたが、初回の呼び出しに 17.6 s を要したコールドスタートを含んでいたため、表示を中央値に変更しています。
違反を検知した場合は、リスクが中以上かつ確信度が 0.6 以上のものについて、枠を描いた画像と内容の JSON (時刻、検知元、違反の種別、確信度、地図上の発生位置) を作成します。同じ違反の重複を避けるため、同一の種別と人物は 30 秒、報告全体は 5 秒の間隔を空けています。
図 : cloud モードで検知した違反のイベント一覧 (E-5 ヘルメット未着用など)。種別・リスク・確信度を表示する
違反レポートの送信
違反レポートの送信は、通信断を前提に設計しています。レポートの正本 (source of truth) はエッジのローカルディスクとし、Amazon S3 と Amazon SNS への送信状況は、レポートの隣に置く空ファイル (マーカー) で管理します。
|
状態
|
マーカー
|
意味
|
|---|---|---|
|
未送信
|
なし |
S3 へ未送信 |
|
S3 送信済み
|
.uploaded |
画像と JSON を S3 に配置済み |
|
通知済み
|
<id>.notified |
SNS への Publish 済み |
レポート送信フローと障害時リカバリー
送信は 2 段階です。違反を検知した直後に、別スレッドが S3 へ送信し (バックオフを挟んで 3 回まで再試行)、成功したら SNS に通知します。通信断などで送れなかった分は、ディスクに未送信のまま残ります。別のスレッドが 30 秒ごとに未送信のレポートを調べ、通信が戻っていれば古い順に送信します。失敗が続く間は、確認の間隔を 60 秒、120 秒と倍々に延ばし (上限 300 秒)、通信が戻って送信が成功したら 30 秒に戻します。未送信かどうかの判定をメモリではなくディスク上のマーカーで行うため、プロセスや Jetson が再起動しても取りこぼしを防ぐ設計にしています。また、S3 への送信が成功し SNS だけが失敗した場合は、S3 に二重に送らず、通知だけを再送します。
SNS 通知の仕様と配信保証
SNS の通知は、通信断の間に溜まった分も復旧後に送信されます。古い違反が「今」起きたものと誤解されないように、遅延が 120 秒以上の通知は、件名に「遅延通知」と付け、本文に遅延秒数 (delay_seconds) を含めています。本文には、違反の種別・リスク・確信度・地図上の位置・画像の S3 キーを載せます。通知は少なくとも 1 回届く (at-least-once) 設計で、復旧の途中で再起動した場合などに、同じ通知が重複して届く可能性があります。
違反レポートの同期 (通常時と、通信断からの復旧時)
図 : 違反レポートの同期 (通常時と、通信断からの復旧時)
SNS トピックのセキュリティと権限設計
SNS のトピックは AWS KMS のカスタマーマネージドキーで暗号化し、トピックポリシーで TLS 以外の Publish を拒否しています。Publish の権限は、Jetson の IAM ロールにこのトピックに限って付与しており、AWS KMS は SNS 経由の利用に限定しています。これらは AWS CloudFormation のテンプレートで定義しています。購読 (メール等) は、確認メールを人が承認する運用のため、テンプレートには含めていません。
ダッシュボードでの違反レポート閲覧
保存した違反レポートは、EC2 上のダッシュボードに一覧表示され、地図上に発生位置が表示されます。
※ 保護具の検出には、Amazon Rekognition の学習済みの機能を利用しています。独自のデータセットによる追加学習は行っていません。
5. 停止設計
5-1. 3 層の停止設計
機体が屋内を移動する以上、移動の設計に先立って停止の設計が必要です。下位の層ほど単純・高速・自律になるように、3 層に分けました。
|
層
|
配置
|
判定内容
|
|---|---|---|
|
L0
|
機体内蔵 |
メーカー実装の転倒保護、障害物回避 |
|
L1
|
エッジ (Jetson) |
点群から前方の障害物・段差を判定し、停止指令を直接発行する。クラウドに依存しない (反応時間の目標は 100 ms 未満) |
|
L2
|
AWS・計画層 |
巡回の中止、立入禁止区画の判定 |
L1 の判定
L1 の判定は次のとおりです (設計値)。前方の扇形領域 (±30°、高さ 0.05〜0.5 m) で、点群までの最小距離が 0.4 m 未満なら減速、0.25 m 未満なら停止します。また、前方の床面が推定した床より 0.15 m を超えて下がる、または点群が欠損する場合は、床がないものとして停止します。手動操作の指令には 0.8 秒の有効期限があり、期限を過ぎると速度ゼロとして扱います。デモ構成では、移動速度の上限を 0.15 m/s に設定しています。
図 : 3 層の停止設計
まとめ
本記事では、Go2 Pro と AWS を組み合わせた巡回警備ロボットについて、次の判断を紹介しました。
- 機体には何も導入せず、同一 LAN 上のエッジ (Jetson AGX Orin) から WebRTC で通信し、AWS IoT Greengrass V2 と AWS IoT Core で AWS に接続した
- SLAM と経路計画は、遅延と通信断への耐性の観点から Jetson に配置した。クラウドは検知、保存、LAN 外からの運用を担う
- 検知は、エッジとクラウドの 2 方式を実装し、画面上で切り替えて比較できるようにした
- 停止の判断は、クラウドから独立した層 (L1) が持つ
- 違反レポートはエッジのローカルに先に保存し、通信が戻ってから S3 と SNS へ送る。未送信かどうかはディスク上のマーカーで管理し、再起動しても取りこぼさない
今後の課題は、Amazon Bedrock のエージェントが検知結果を踏まえて巡回の指示を出す機能と、通信状態に応じた edge / cloud 検知の自動切り替えです (いずれも 2026 年 10 月時点では未実装です)。
ロボットを AWS に接続する際の参考になれば幸いです。
筆者プロフィール
永井 祥太 (ながい しょうた)
アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。
2026 年入社。製造業のお客様を担当し、Physical AI に関する検証を行っている。
