zume | ブログ記事

【第1章】ROS2×Isaac Sim 強化学習環境の構築：完全自動化セットアップ編

全10章シリーズ | カテゴリ: 環境構築チュートリアル

本シリーズでは、全10章にわたり、ROS2とIsaac Simを活用してUniversal Robots（UR）の強化学習環境を構築し、チーム開発を行うための完全なガイドを提供します。

第1章となる本記事では、次章（第2章）で「VS Codeを開いてすぐに開発を始められる状態」を完璧に作り上げるための、インフラストラクチャのセットアップを徹底解説します。

作業の効率化と確実性を高めるため、GUI（マウス操作）を極力排除し、コピー＆ペーストで実行できるコマンドライン（CLI）中心の手順に再構成しました。GitHubの認証設定からGPUコンテナの基盤構築まで、この章の内容を完遂すれば、環境構築のハードルは9割超えたと言っても過言ではありません。

🎯 本章のゴール:

ホストPC（GPU）とノートPC（クライアント）のVPN接続確立
ホストPCのNVIDIA/Docker基盤の完全構築
GitHub CLIを用いたセキュアなSSH認証とGit設定の完了
ノートPCの開発ツール（VS Codeと拡張機能）のCLIインストール

1. システムの最新化と基本ツールの導入（両PC共通）

まずは、ホストPC（GPU搭載）とノートPC（クライアント）の両方でターミナルを開き、OSのパッケージを最新状態にして必須ツールをインストールします。

            sudo apt update && sudo apt upgrade -y

            sudo apt install -y curl git wget build-essential software-properties-common

2. ネットワーク構築（Tailscale）（両PC共通）

外出先からホストPCに安全にアクセスするためのメッシュVPN「Tailscale」を導入します。

            # インストールスクリプトの実行

            curl -fsSL https://tailscale.com/install.sh | sh

            # Tailscaleの起動と認証

            sudo tailscale up

※ tailscale up 実行後、ターミナルに認証用のURLが表示されます。Ctrlキーを押しながらクリックしてブラウザを開き、両方のPCで同じアカウント（GoogleやGitHubなど）でログインしてください。

            # 接続確認（ホストPCのIPアドレスを確認してメモしておきます）

            tailscale status

3. ホストPC（GPUマシン）の専用セットアップ

ここからはホストPC（GPUを搭載している側）のみで行う作業です。リモート接続の受付、GPUドライバ、Docker基盤を一気に構築します。

3.1 SSHサーバーの構築

ノートPCのVS Codeからリモート接続するために必須のSSHサーバーを立てます。

            sudo apt install -y openssh-server

            sudo systemctl enable ssh

            sudo systemctl start ssh

            sudo ufw allow ssh # ファイアウォールでSSH通信を許可

3.2 NVIDIAドライバの導入

            # 最適なプロプライエタリ・ドライバを自動判定してインストール

            sudo ubuntu-drivers autoinstall

            # ※ここで一度ホストPCを再起動する必要があります

            # sudo reboot

            # 再起動後、ドライバが認識されているか確認

            nvidia-smi

3.3 Docker と NVIDIA Container Toolkit の完全導入

Docker環境と、コンテナ内からGPUを叩くためのToolkitをCLIで連続してセットアップします。sudo なしでDockerコマンドを実行できる権限付与も行います。

            # 1. Docker Engineのインストール

            curl -fsSL https://get.docker.com -o get-docker.sh

            sudo sh get-docker.sh

            # 2. 現在のユーザーをdockerグループに追加（sudoなしで実行するため）

            sudo usermod -aG docker $USER

            # ※設定反映のため `newgrp docker` を実行するか、ログアウト・ログインが必要です。

            # 3. NVIDIA Container Toolkitのリポジトリ追加とインストール

            curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

            curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \

              sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \

              sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

            sudo apt update

            sudo apt install -y nvidia-container-toolkit

            # 4. DockerランタイムをNVIDIA用に構成して再起動

            sudo nvidia-ctk runtime configure --runtime=docker

            sudo systemctl restart docker

            # 5. 動作確認（コンテナ内からGPUが見えるかテスト）

            docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

※ 最後のコマンドでホスト側と同じ nvidia-smi の表が表示されれば、ホストPCのGPUコンテナ基盤は完璧に完成しています。

4. GitHub連携の自動化（GitHub CLI）（両PC共通）

2人で共同開発を行うため、Gitの設定とGitHubへのセキュアなSSH接続設定を行います。ブラウザを行き来する面倒なSSH鍵登録も、gh コマンドを使えばターミナル上で完結します。

            # 1. GitHub CLIのインストール

            curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg

            sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg

            echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null

            sudo apt update && sudo apt install gh -y

            # 2. Gitの初期設定（自分の名前に変更してください）

            git config --global user.name "Your Name"

            git config --global user.email "your.email@example.com"

            git config --global init.defaultBranch main

            # 3. GitHubへのログインとSSH鍵の自動生成・登録

            gh auth login

※ gh auth login を実行すると対話型のプロンプトが出ます。
GitHub.com → SSH → Y (Generate a new SSH key) → Login with a web browser の順に選択し、表示されたワンタイムコードをブラウザに入力するだけで、面倒な公開鍵の登録がすべて自動で完了します。

5. ノートPC（クライアント）の専用セットアップ

最後に、ノートPC側で開発ツールであるVS Codeと、リモート開発に必須の拡張機能をコマンドラインから一括インストールします。

            # VS Codeのインストール（Snapを利用）

            sudo snap install --classic code

            # 必須拡張機能（Remote SSH と Dev Containers）のCLIインストール

            code --install-extension ms-vscode-remote.remote-ssh

            code --install-extension ms-vscode-remote.remote-containers

            code --install-extension ms-vsliveshare.vsliveshare

⚠️ Omniverse Streaming Client について:
画面描画を受信するためのクライアントソフトは、パッケージマネージャからインストールできません。ノートPCのブラウザから NVIDIA Omniverse 公式サイトにアクセスし、「Omniverse Launcher」のLinux版（AppImage）をダウンロードして実行権限を付与（chmod +x）し、GUI上から「Streaming Client」をインストールしておいてください。

補足A: この章の全体像（なぜ2台構成にするのか）

本シリーズでは「GPUホストPC」と「ノートPC（クライアント）」の2台構成を前提にしています。理由はシンプルで、重い計算と描画はホストPCに集約し、クライアントは入力と表示に徹することで、開発が安定し、チーム開発もスムーズになるからです。

ホストPC（GPU）: Docker/Isaac Sim/学習/ビルドなど、重い処理を担当
ノートPC: VS Code からリモート編集・実行、Streaming Clientで画面表示
両者を繋ぐ: Tailscale（VPN）+ SSH（リモート作業）で安全に接続

この構成にしておくと「環境を壊さない」「性能を引き出す」「再現性を保つ」の3点が取りやすくなります。

補足B: 事前に用意するもの（詰まらないための前提）

手順自体はCLI中心で進みますが、事前に準備できていないと途中で止まりやすい要素があります。最初にこのリストを埋めておくと、後半が一気に楽になります。

事前準備チェック:

GitHubアカウント（2人とも）
Tailscaleにログインできるアカウント（2人とも。Google/GitHub連携でOK）
ホストPCがUbuntuで安定稼働し、インターネットに接続できる
ホストPCのストレージ空き（Docker/シミュレータで増えやすい）
ノートPC側にブラウザと基本ツールがある（ダウンロード確認など）

さらに、作業中に参照する値（IPやユーザー名）をメモしておくと、後で迷いません。

            # メモしておくと良い値（例）

            - ホストPCのTailscale IP（100.x.y.z）

            - ホストPCのユーザー名（例: ubuntu）

            - GitHubのユーザー名（2人分）

            - NVIDIAドライバの状態（nvidia-smiが通るか）

補足C: Tailscale接続の“成功条件”と確認コマンド

Tailscaleは導入が簡単な反面、いざ繋がらないときに「どこで詰まっているか」が分からなくなりがちです。ここでは “成功している状態” をコマンドで確認できるようにします。

成功条件: 両PCで tailscale status を実行すると、相手PCが一覧に出て、100.x.y.z のIPが見える
次の成功条件: ノートPCからホストPCへ ssh が通る（第2章のRemote-SSH接続につながる）

            # 両PCで実行（相手が見えるか）

            tailscale status

            # 可能なら疎通確認（相手のデバイス名やIPへ）

            tailscale ping <相手のデバイス名またはIP>

補足: ここで疎通が取れない場合は「ログインアカウントが一致しているか」「両方がオンラインか」「ネットワークが制限されていないか」を先に疑うのが近道です。

補足D: SSHで詰まるポイント（鍵・権限・ポート）

第2章のRemote-SSHへ進む前に、SSHが安定している状態を作っておくとスムーズです。まずはホストPC側でSSHが起動しているかを確認します。

            # ホストPCで確認

            systemctl status ssh --no-pager

            sudo ss -tulpn | grep -E ':(22|ssh)'

ノートPC側からは、まず素のSSHで接続できることを確認しておくと、VS Code側の問題かどうか切り分けできます。

            # ノートPCで実行（例）

            ssh -v <ユーザー名>@<ホストPCのTailscale_IP>

ポイント: VS Code Remote-SSHは内部的にSSHを使います。まずCLIのSSHが通る状態を作ると、問題の切り分けが一段階ラクになります。

補足E: NVIDIA/Docker基盤の“成功条件”とトラブルシュート

Isaac Simや学習系の作業では、GPUが使えないと話になりません。ここでは「どこまでできていればOKか」をはっきりさせます。

成功条件1: ホストPCで nvidia-smi が通る（ドライバOK）
成功条件2: コンテナ内で nvidia-smi が通る（Container Toolkit + Docker OK）

            # 1) ホスト側のGPU確認

            nvidia-smi

            # 2) Docker自体の確認

            docker --version

            docker info | head -n 30

            # 3) コンテナ内からGPUが見えるか

            docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

もし最後のテストが失敗する場合、次の切り分けが有効です。

dockerがsudo必須: usermod -aG docker 後にログアウト/ログイン、または newgrp docker を実行したか
nvidia-smiがホストで失敗: ドライバ未導入、または再起動が未実施、セキュアブート影響などを疑う
コンテナだけ失敗: toolkit導入やDocker再起動が未完了の可能性。sudo systemctl restart docker を含め手順を再確認

補足F: GitHub CLI の状態確認（第2章で困らないために）

第2章ではリポジトリ作成やPushを行うため、ここでGitHubの認証が正しく通っているか確認しておくと安心です。

            # 認証状態の確認

            gh auth status

            # SSH疎通（成功すると認証メッセージが出ます）

            ssh -T git@github.com

補足: 初回のSSH疎通ではホスト鍵の確認が出ることがあります。内容を確認した上で進めてください。

補足G: ノートPC側VS Codeの確認（拡張機能が入ったか）

VS CodeをCLIでインストールした場合、意図どおり入ったかを確認しておくと安心です。特に拡張機能は、後で「見つからない」となるとハマりやすいポイントです。

            code --version

            code --list-extensions | grep -E 'remote-ssh|remote-containers|vsliveshare'

ポイント: 第2章ではRemote-SSHとDev Containersの両方を使います。拡張が入っていれば、作業が途切れません。

第2章に進む前のチェックリスト

最後に、第2章へ進む前に最低限ここだけは満たしておきたいポイントをまとめます。

両PCでTailscaleログインが完了し、tailscale status で相手が見える
ホストPCでSSHが起動しており、ノートPCから ssh ユーザー名@IP が通る
ホストPCで nvidia-smi が通る
ホストPCで docker run ... nvidia-smi が通る（コンテナ内GPUが見える）
ノートPCで code が起動でき、Remote-SSH / Dev Containers拡張が入っている
GitHub CLIでログインできている（gh auth status がOK）

ここまでできていれば、第2章の「Remote-SSHで接続してDev Containerを起動する」フェーズにスムーズに入れます。

補足H: よくあるトラブルQ&A（ここで詰まりやすい所）

環境構築は「正しい順序」と「切り分け」がすべてです。ここでは、実際に起きやすい詰まりどころをQ&A形式でまとめます。

Q. Tailscaleにログインしたのに相手が見えない
A. まずは両PCで tailscale status を実行し、同じアカウント（同じtailnet）になっているか確認します。片方だけオフラインのときは、PCのスリープやネット断が原因のことがあります。
Q. Tailscaleは見えるがSSHが繋がらない
A. ホストPC側でSSHサービスが起動しているか（systemctl status ssh）と、ファイアウォール/設定の影響を確認します。まずはノートPCから ssh -v で詳細ログを出すのが近道です。
Q. SSHは繋がるのにVS Code Remote-SSHが失敗する
A. まずCLIのSSHで確実に繋がる状態を作り、その後にVS Code側のログ（Remote-SSH出力）を確認します。鍵の場所やユーザー名が微妙に違うだけでも失敗します。
Q. dockerがsudoなしで動かない
A. ユーザーが docker グループに入っているか確認します（groups）。追加後はログアウト/ログインが必要です。
Q. nvidia-smiがホストで通らない
A. ドライバ未導入か、導入後の再起動が未実施の可能性があります。Secure Bootの影響でドライバがロードされないケースもあるため、状況に応じてBIOS設定も視野に入れます。
Q. ホストではnvidia-smiが通るが、コンテナ内では失敗する
A. NVIDIA Container ToolkitやDocker設定が不完全な可能性があります。まずはテスト用の docker run ... nvidia-smi で最小構成を確認し、次に docker info やDocker再起動で切り分けます。
Q. ディスクが急に足りなくなる
A. Dockerイメージ/キャッシュが膨らみやすいです。第1章のうちに docker system df で状況を把握できるようにしておくと、後で慌てません。

補足I: 不具合時のログ採取（相談するときに役立つ）

うまくいかないときは「何を試したか」と「ログ」があるだけで解決速度が段違いです。ここでは最低限のログ採取コマンドをまとめます。

            # ホストPC（GPU）で採取したい情報

            uname -a

            lsb_release -a 2>/dev/null || cat /etc/os-release

            nvidia-smi

            docker --version

            docker info | head -n 60

            # SSH関連（ホストPC）

            systemctl status ssh --no-pager

            sudo journalctl -u ssh --no-pager -n 200

            sudo ss -tulpn | grep -E ':(22|ssh)'

            # Tailscale関連（ホストPC）

            tailscale status

            sudo journalctl -u tailscaled --no-pager -n 200

ノートPC側では、SSHの詳細ログが特に強力です。

            # ノートPC（クライアント）での切り分け

            tailscale status

            ssh -v <ユーザー名>@<ホストPCのTailscale_IP>

コツ: これらの結果をテキストで残しておくと、同じ問題が再発しても早く復旧できます。

補足J: ディスク/キャッシュ肥大化の対策（Dockerの掃除）

シミュレータや学習環境は、Dockerイメージ・コンテナ・ビルドキャッシュが増えやすいです。第1章の段階で「現状確認」と「安全な掃除」を知っておくと安心です。

            # 空き容量の確認

            df -h

            # Dockerがどれだけ使っているか

            docker system df

            # 使っていないコンテナ/ネットワークなど（比較的安全）

            docker system prune

より強力な削除（未使用イメージ等）もありますが、必要なイメージまで消してしまう可能性があります。

注意: 次のコマンドは削除範囲が大きいです。状況を理解してから使いましょう。
docker system prune -a

補足K: 2人開発のための“運用ルール”を先に決める

本シリーズは2人チーム前提なので、環境構築の時点から「誰が何を触ったか」が分かるようにしておくと後で揉めません。第2章以降の開発速度に直結します。

ホストPCの更新タイミング: いつ apt upgrade するか（開発が止まらないように）
鍵/アカウントの管理: SSH鍵の置き場所、GitHubの認証方法（HTTPS/SSH）を統一する
トラブル時の情報共有: 何が起きたか、どのコマンドを打ったか、ログをどこに貼るかを決めておく
環境を壊さない原則: いきなり大量に設定を変えず、最小変更で切り分ける（この章の方針）

ここを押さえると、第2章でGitHub運用・コンテナ運用に入ったときのブレが減り、結果的に早く進めます。

補足L: リソース監視（重くなった時の見方）

シミュレーションや学習を回し始めると「重い」「固まる」「描画が遅い」といった症状が出ることがあります。第1章のうちに、最低限の“見える化”コマンドだけは覚えておくと、原因がGPUなのかCPUなのか、ディスクI/Oなのかが判断しやすくなります。

            # GPU状況（ホストPC）

            nvidia-smi

            # CPU/メモリ状況（標準コマンド）

            top

            free -h

            # ディスク空き容量

            df -h

コツ: まずは「GPUが100%なのか」「メモリが枯れているのか」「ディスクが逼迫しているのか」を見て、対策（設定/容量/掃除）を選びます。

補足M: うまくいかない時の切り分けフロー（簡易）

第1章は要素が多いぶん、問題が起きたときに「戻る場所」を決めておくのが重要です。以下は最低限の切り分けフローです。

            1) そもそも相手PCが見える？

               - tailscale status（両PC）

            2) 見えるならSSHは通る？（ノートPC→ホストPC）

               - ssh -v user@100.x.y.z

            3) SSHが通るなら、ホストの基盤はOK？

               - nvidia-smi（ホスト）

               - docker info（ホスト）

               - docker run ... nvidia-smi（ホスト）

            4) ここまでOKなら、VS Code側の設定/拡張/鍵の問題に寄っている可能性が高い

この順番で確認すれば「ネットワーク」「SSH」「GPU/Docker」「VS Code」のどこが原因かを、短時間で切り分けられます。

補足N: 最低限のセキュリティ（Tailscale前提でもやっておく）

第1章の主目的は開発環境の準備ですが、ホストPCは長時間動かし続けることが多いので、最低限の運用を押さえておくと安全です。特に「SSHをインターネットに直に晒さない」「更新を止めない」が重要です。

ネットワーク: 基本はTailscale経由でアクセスし、不要なポートを外部へ開けない
更新: 依存関係が多いほど脆弱性が混ざりやすいので、定期的に更新する
認証: SSHは鍵ベースを基本にし、パスワード依存にしない
権限: 2人で触る場合は「誰が何をしたか」を追えるようにする（同一ユーザー使い回しを避けるのが理想）

            # 更新（ホストPC）

            sudo apt update && sudo apt upgrade -y

            # どのポートが待ち受けているか（ホストPC）

            sudo ss -tulpn | head -n 30

            # SSHの最近のログ（ホストPC）

            sudo journalctl -u ssh --no-pager -n 100

補足: セキュリティ設定は環境や方針により最適解が変わります。第1章では「把握できる状態を作る」ことを重視し、過剰な設定変更は避けます。

補足O: Remote-SSH向け `~/.ssh/config` テンプレ（任意）

第2章ではVS Code Remote-SSHを使いますが、先にノートPC側で接続先をエイリアス化しておくと、接続ミス（ユーザー名/ホスト名の打ち間違い）が減ります。以下は最小テンプレです。

            # ノートPC: ~/.ssh/config（例）

            Host isaac-host

              HostName 100.x.y.z

              User ubuntu

              ServerAliveInterval 60

              ServerAliveCountMax 3

              IdentitiesOnly yes

              IdentityFile ~/.ssh/id_ed25519

この設定を入れると、CLIでも ssh isaac-host のように接続でき、VS Code側でも同じホスト名を選べるようになります。

補足: ここでの値（IP/ユーザー/鍵ファイル）は環境に合わせて置き換えてください。

第1章のまとめと次章の予告

お疲れ様でした。これで「ホストマシンのGPU/Docker基盤」「セキュアな通信網」「GitHubの認証」「ノートPC側のエディタ」という、開発を始めるための全インフラが完璧に整いました。（Dockerfile や devcontainer.json などのプロジェクトファイル群は、次章以降のGitHubリポジトリ構築フェーズで扱います）。

続く【第2章】では、いよいよノートPCからホストPCへVS Code Remoteで接続し、最初のIsaac Lab × ROS2コンテナを起動して、チーム開発のワークフローを回す手順について実践的に解説します。準備が整ったノートPCを手元に置いて、次章へお進みください！

zume ブログ