NVIDIA Jetson（産業用途にも使われる小型AIエッジコンピュータ）を使ってロボットを開発しているエンジニアや、ROS 2（ロボット向けの分散通信フレームワーク）とモバイル/デスクトップUIの連携を検討している方に向けた内容です。CPU・GPU・温度・電源モードといったハードウェア状態を、どう安全に可視化するかという設計の話を整理します。
ロボットの運用現場では「動いているかどうか」より「なぜ止まったか」を知りたい場面が多くあります。Jetsonの温度上昇でクロックが落ちた、電源モードが変わって推論が遅くなった、といった原因はログだけでは追いにくいものです。これをFlutter（GoogleのクロスプラットフォームUIフレームワーク）製のダッシュボードで見える化する構成が、実運用でどこまで使えるかを見ていきます。
何が新しいのか：テレメトリを「制御」から切り離す発想
この構成のポイントは、テレメトリ（機器の稼働状態を収集するデータ）を観測用データとして扱い、制御チャネルとは明確に分離することです。
ロボットのUIというと、つい「ボタンを押したら動く」制御画面を想像しがちです。しかしCPU負荷やGPU使用率、温度、電源モードの表示は本来、モニタリング専用の情報です。制御コマンドと同じ経路に混ぜてしまうと、UI側のバグや通信遅延が誤操作につながるリスクが生まれます。
そのため推奨される構成では、Flutterアプリは直接ROS 2グラフ（ノード・トピック・サービスの通信構造）を叩くのではなく、間に「ロボットゲートウェイ」を挟みます。データフローは次のようになります。
Flutter
| HTTPS / WebSocket
ロボットゲートウェイ
| ROS 2
Jetson
|
ロボット本体この分離により、Flutter側は読み取り専用のテレメトリ購読者として振る舞い、制御コマンドの発行経路とは別レイヤーで動作します。ROS 2をインターネットに直接晒さない設計は、セキュリティ観点でも重要な判断基準になります。
段階的に見る構築の流れ
実際の構築は、いきなりダッシュボードを作るのではなく、下から積み上げる手順が推奨されています。
まずJetson本体の環境確認です。uname -a と cat /etc/os-release でカーネルとOSリリースを確認し、sudo apt update でパッケージメタデータを最新化します。ここで重要なのは、搭載しているJetPack（NVIDIAが提供するJetson向けソフトウェアスタック）のバージョンと、これから使うROS 2ディストリビューションの対応関係を崩さないことです。
次にROS 2のセットアップです。インストール後は source /opt/ros/<ros-distro>/setup.bash でシェルに読み込み、ros2 --help で疎通確認します。この一文を ~/.bashrc に追記しておけば、新しいターミナルを開くたびに手動でsourceする手間が省けます。
そのうえでワークスペースを作成します。
mkdir -p ~/robot_ws/src
cd ~/robot_ws
colcon build
source install/setup.bashcolconはROS 2の標準ビルドツールで、src 配下のパッケージをまとめてビルドします。ビルド後は build/ install/ log/ の各ディレクトリが生成され、install/setup.bash を読み込むことでパッケージが利用可能になります。
パッケージ作成では言語選択も判断ポイントです。Python版は ros2 pkg create --build-type ament_python robot_ai_demo、C++版は ament_cmake ビルドタイプを指定します。テレメトリ収集のように高頻度・低レイテンシが求められる処理はC++、UI連携やスクリプト的な集計処理はPythonといった使い分けが現実的です。
最後に、パブリッシャー（データ発行ノード）とサブスクライバー（購読ノード）の疎通を確認します。
cd ~/robot_ws
colcon build --symlink-install
source install/setup.bash
ros2 run robot_ai_demo publisher別ターミナルで ros2 topic list と ros2 topic echo /robot_status を実行し、トピックが流れているかを目視確認します。カメラやAIモデル、モーター制御を組み込む前に、この最小構成で通信が成立していることを確かめておくと、後段のトラブルシュートが格段に楽になります。
既存のロボット監視手法との比較
Jetson単体の状態確認だけなら、NVIDIA公式ツールの tegrastats や、Linux標準の top・nvidia-smi相当のツールで十分な場合もあります。実際、開発初期の動作確認ではこうしたCLIツールで温度やクロックを見るだけでも十分です。
しかし複数台のロボットを遠隔で運用するフェーズになると話は変わります。オペレーターが端末にSSHして tegrastats を都度叩くのは現実的ではありません。ここでROS 2トピックとして構造化されたテレメトリを流し、Flutterで一元的に可視化する構成の価値が出てきます。ROS 2のtopic/service/action（それぞれ非同期配信・同期呼び出し・長時間処理の抽象化）の使い分けに慣れているエンジニアであれば、テレメトリはtopicで垂れ流し、異常時のみactionやserviceで詳細取得、という設計にも展開しやすいはずです。
また、データフロー全体の設計思想は「センサー → ROS 2ドライバ → 認知/測位 → 意思決定 → 安全レイヤー → モーター制御」という層構造が示されています。テレメトリ収集ノードやフリートゲートウェイは、この主経路とは独立したコンポーネントとして扱うべきだとされています。UI用のデータをこの主経路に混ぜないという原則は、マイクロサービス的な責務分離の考え方とも重なります。
今日確認できること
自分のプロジェクトがこの構成に当てはまるか、次の点をチェックリストとして使えます。
- JetPack・ROS 2ディストリビューション・Isaac ROS（NVIDIAのロボット向け認知パイプライン）のバージョン組み合わせを、NVIDIA公式のサポートマトリクスで確認したか
- Flutterアプリ（あるいは他のUI）が、ROS 2グラフに直接アクセスしていないか、ゲートウェイを経由しているか
- テレメトリ用のトピックと、制御コマンド用のトピックが名前空間やノードレベルで分離されているか
ros2 topic echoで流れているデータが、UI側の想定するJSON構造やスキーマと一致しているか- 温度・電源モード変化時にJetson側でクロックダウンが起きた場合、その事実がUIに反映される経路があるか
特に最初の項目は見落とされがちです。JetPack・CUDA・TensorRT・Isaac ROS・ROS 2の対応関係は時期によって変わるため、異なるリリースのコマンドを混在させるとビルドエラーや実行時の不整合を招きます。導入前に必ず対象ボードの公式ドキュメントで組み合わせを確認しておくのが安全です。
まとめ
JetsonのCPU・GPU・温度・電源モードをFlutterで可視化する構成は、テレメトリを制御チャネルから分離するという一点に集約されます。
実装は「Jetson環境確認 → ROS 2セットアップ → ワークスペース作成 → パッケージ作成 → データフロー設計 → 最小構成での疎通確認」という順で積み上げると、途中のトラブルの切り分けがしやすくなります。
今日からできる一歩としては、まず ros2 topic list で現在のシステムにどんなトピックが流れているかを棚卸しし、制御系とテレメトリ系が名前空間レベルで混在していないかを確認することです。既存のダッシュボードやUIがROS 2グラフに直接繋がっている場合は、ゲートウェイ層を挟む余地がないかも合わせて見直しておくと安心です。