Unitree G1で二次開発を行うなら、最初に購入・契約上の機体がG1 EDUであることを確認してください。Unitreeの公式比較表では、一般G1のSecondary Developmentは対応を示す表記がなく、G1 EDUだけがYESです。一般G1の開始価格は13,500米ドルですが、G1 EDUはContact salesであり、同じ価格ではありません。
安全な初回接続では動作命令を送りません。unitree_ros2が推奨するUbuntu 22.04とROS 2 Humble、CycloneDDS 0.10.2の組み合わせを基準に、Ethernetを設定し、G1/H1系の低レベル状態を読み取れるところまでを一つの合格点にします。機体の違いはUnitree R1・G1・H1・H2比較で先に整理できます。
SDK開発用ならG1 EDUかどうかが最初の分岐になる
Unitree G1公式ページは一般G1とG1 EDUを同じ表に載せていますが、開発条件は同じではありません。Secondary Developmentの欄は一般G1がスラッシュ、G1 EDUがYESです。13,500米ドルという表示は一般G1の開始価格で、税・送料を含まず、G1 EDUの価格ではありません。
G1 EDUはContact salesです。注文時には、手、手首、腰、計算モジュール、ネットワーク、ファームウェア、SDK権限を確認します。公式の自由度は23〜43 DoFという幅があり、選択した手や関節構成によって例の配列長や利用できるサービスが変わり得ます。サンプルが手元の機体へそのまま一致すると考えないでください。
機体は約35kg以上の動力付きヒューマノイドです。公称バッテリー時間は約2時間、保証は18か月と案内されていますが、運動、搭載物、計算負荷、温度で稼働時間は変わります。デスク上の開発ボードとは違い、電源を入れる前から転倒範囲と退避経路を確保します。
価格と開発可否を混同しやすい場合は、Unitreeロボットの価格・購入ガイドでモデルごとの購入状態を確認し、SDK作業は本記事のG1 EDU条件に限定してください。
| 確認項目 | 一般G1 | G1 EDU | 開発前の判断 |
|---|---|---|---|
| Secondary Development | 対応を示す表記なし | YES | SDK用途ならEDUを契約で確認 |
| 価格 | 13,500米ドルから、税・送料別 | Contact sales | 二つの価格を同一視しない |
| 自由度 | 構成による | 23〜43 DoF | 関節・手の構成を記録 |
| 重量 | 構成による | 約35kg以上 | 支持設備と安全距離を用意 |
| バッテリー | 製品表を確認 | 約2時間 | 作業条件で実測 |
| 保証 | 契約資料を確認 | 18か月 | 保証冊子と注文条件を照合 |
SDK2、Python、ROS 2は三つの入口として分ける
unitree_sdk2はUnitreeのC++通信・制御ライブラリです。現在のREADMEは事前ビルド環境としてUbuntu 20.04 LTS、aarch64またはx86_64、GCC 9.4.0を示し、ビルドにはCMake 3.10以上、GCC 9.4.0、Makeを挙げています。これはROS 2の推奨環境を示す文ではありません。
unitree_sdk2_pythonはPython 3.8以上、CycloneDDS 0.10.2、NumPy、OpenCVを要件とします。Pythonの依存関係だけを最新版へ上げると、ロボット側DDSとの互換性問題を作る可能性があります。まず公式の組み合わせを再現し、変更は一つずつ評価します。
unitree_ros2はROS 2からUnitreeのDDSメッセージと例を扱う別経路です。ROS 2もDDSを使いますが、SDK2を入れればROS 2が自動的に完成するわけでも、ROS 2を入れれば全G1機能が利用できるわけでもありません。用途、OS、コンパイラー、メッセージ、起動手順を一つの経路にそろえます。
| 経路 | 公式の基準環境 | 主な用途 | 初回に避けること |
|---|---|---|---|
| C++ SDK2 | Ubuntu 20.04、GCC 9.4.0 | C++でUnitree通信・制御 | ROS 2要件との無計画な混在 |
| Python SDK2 | Python 3.8以上、CycloneDDS 0.10.2 | Pythonで状態・APIを扱う | DDSだけ任意の最新版に変更 |
| ROS 2 Humble | Ubuntu 22.04、Humble推奨 | トピックとUnitree例の利用 | 未知のトピック名へ命令送信 |
| ROS 2 Foxy | Ubuntu 20.04、Foxy | 公式テスト組み合わせの一つ | Humble向け手順との混在 |
UbuntuとCycloneDDSの版をロボット側に合わせる
公式unitree_ros2 READMEのテスト表はUbuntu 20.04＋FoxyとUbuntu 22.04＋Humbleを示し、Humbleを推奨しています。また、ロボット側CycloneDDSを0.10.2と説明します。Foxy向け手順はreleases/0.10.xのビルドを含み、Humbleではその個別ビルド段階を省けると記載されています。
ここでの0.10.2は、2026年8月6日に確認した公式文書の互換基準です。将来にわたり固定されるという意味ではありません。README、機体ファームウェア、購入時の開発資料を発行・試験直前に再確認し、環境ファイルへ版とコミットを記録します。
複数プロジェクトを一台のPCで扱うなら、SDK2用とROS 2用をコンテナーまたは別のワークスペースに分けます。共有ライブラリの探索順、DDS実装、ROS_DOMAIN_ID、環境変数が混ざると、ビルド成功後も発見できない、別ネットワークへ送るといった再現しにくい障害になります。
QoSは通信が見えてから調整します。状態が一部欠ける、命令系とセンサー系で挙動が違う場合は、ROS 2 QoSのセンサー・命令設定を参照し、reliability、durability、historyをトピックごとに照合してください。
Ethernet接続は一つのNICと固定IPv4から始める
公式ROS 2手順の例では、PCとロボットをEthernetでつなぎ、PC側を192.168.123.99、サブネットマスク255.255.255.0に設定します。これは例のネットワークであり、社内LANへ無断で同じアドレスを設定する指示ではありません。ロボット専用の有線区間を作り、競合がないことを確認します。
CycloneDDSの設定では、READMEのプレースホルダーではなく、実際の有線インターフェース名をCYCLONEDDS_URIの構成へ入れます。Wi-Fi、VPN、Dockerブリッジ、複数Ethernetを同時に残すと、DDSが意図しないNICを選び、トピック発見が不安定になります。最初は利用する一つだけを明示します。
疎通確認は、リンクアップ、PCのIPv4、同一サブネット、インターフェース名、CycloneDDS設定、ROS 2環境のsourceという順で行います。通信が見えない段階で制御コードを修正しても原因を増やすだけです。PC時刻、ファイアウォール、マルチキャスト制限も変更前後を記録します。
| 順番 | 確認するもの | 合格の目安 | 失敗時に見る場所 |
|---|---|---|---|
| 1 | 機体とPCの有線リンク | NICが接続状態 | ケーブル、ポート、電源 |
| 2 | PCの固定IPv4 | 192.168.123.99/24の例と整合 | アドレス競合、サブネット |
| 3 | DDSインターフェース | 実在する有線NICを指定 | CYCLONEDDS_URI、複数NIC |
| 4 | ROS 2発見 | 期待するトピックを列挙 | source、domain、ファイアウォール |
| 5 | 状態メッセージ | IMU・関節・電池が継続受信 | 型、QoS、ファームウェア |
最初の合格点は読み取り専用の状態受信
ROS 2環境を読み込んだら、まずros2 topic listで実際に公開されるトピックを確認します。名前を資料から推測し、存在しない命令トピックへ試し打ちしてはいけません。機体、ファームウェア、サービス構成で公開範囲が変わる可能性があります。
現在のunitree_ros2にはG1 low-level例、G1/H1/H1-2系のread_low_state_hg、無線コントローラーの例があります。最初はread_low_state_hgまたは確認済みの状態トピックで、IMU、関節位置、バッテリーなどが継続的に届くかを見ます。これはネットワーク、DDS、型、機体の組み合わせを動かさずに検査できる方法です。
README上部の紹介はGo2、B2、H1を列挙する一方、例の一覧にはG1関連が含まれます。この差から言えるのはG1のメッセージや例が存在することまでです。G1の全機能、全構成、全ファームウェアがROS 2で完全に支援されると拡大解釈せず、必要機能を一つずつ確認します。
状態を記録して再現試験を行う際は、受信周期、欠落、タイムスタンプ、関節数、型の版を保存します。公式経路と一般的な制御統合の違いはros2_controlハードウェアインターフェースで補えます。
動作例を開く前に停止手段と作業空間を確認する
UnitreeはG1が複雑で強い動力を持つため、人から十分な距離を取り、注意して使用するよう公式ページで警告しています。状態受信が成功しても、歩行、特殊動作、low-level torque命令を続けて実行する理由にはなりません。通信の成功と動作の安全は別の試験です。
動作段階へ進む前に、機体の正確な関節数、ファームウェアとAPI版、支持装置、床面、可動範囲、立入禁止区域、監視者、電源遮断、物理非常停止を確認します。コントローラーで止められることだけに依存せず、通信断やプロセス停止時にどうなるかも事前に決めます。
非常停止と保護停止は目的が異なります。ロボットの非常停止・保護停止を参照し、試験モード、速度・力の上限、復帰手順を現場のリスク評価に合わせてください。メーカー例を動かすことは、現場の安全検証を省略する許可ではありません。
最初の動作試験を行う場合も、メーカーと組織の承認手順の下で、支持された機体、無人の限定区域、低い出力、単一の確認済み関節または機能から始めます。本記事は具体的な動作コマンドを掲載せず、読み取り専用通信までを入門の完了点とします。
接続記録を残すと次の試験が安全になる
初回接続の記録には、G1 EDUの注文構成、シリアル、自由度、手の型、ファームウェア、OS、ROS 2、SDKのコミット、CycloneDDS、NIC名、IPv4、受信したトピックと型を残します。担当者の記憶ではなく、同じ機体を翌日再現できる状態を成果物にします。
問題が起きたら、モデル権限、ネットワーク、DDS発見、メッセージ型、QoS、アプリの順に切り分けます。全てを一度に更新せず、既知の構成へ戻せるよう依存関係を固定します。一般G1とG1 EDU、C++ SDK2とROS 2、例の存在と完全対応という三つの区別を保つだけでも、多くの誤診を避けられます。
結論として、G1 EDUのSDK入門はロボットを歩かせる競争ではありません。正しい機体を選び、公式の版を合わせ、一つの有線NICでDDSを発見し、読み取り専用状態を安定して受けることが第一段階です。その証拠と安全手順がそろってから、制御を別の試験計画として始めます。
よくある質問
一般のUnitree G1でもSDK2やROS 2を使えますか？
公式製品表は一般G1のSecondary Developmentに対応を示さず、G1 EDUだけをYESとしています。一般G1の価格だけで開発可否を判断せず、G1 EDUの注文構成、ファームウェア、SDK権限をUnitreeへ確認してください。
Ubuntu 22.04とROS 2 Humbleは公式の組み合わせですか？
はい。unitree_ros2はUbuntu 22.04＋Humbleをテスト済みの推奨組み合わせとして示します。ただしC++ SDK2の事前ビルド基準はUbuntu 20.04＋GCC 9.4.0で、二つの経路を同じ要件と考えてはいけません。
G1 EDUの初回接続では何を実行すればよいですか？
ros2 topic listと、read_low_state_hgのような状態読み取り経路で、IMU・関節・バッテリー情報が継続受信できるかを確認します。歩行やtorque命令は、機体構成と安全設備を確認した別段階に残してください。
確認した公式情報
- Unitree：G1・G1 EDU公式製品ページ
- Unitree Robotics：unitree_sdk2
- Unitree Robotics：unitree_sdk2_python
- Unitree Robotics：unitree_ros2
最終確認日：2026年8月6日