Jetson × ROS × CARLA環境で自動運転シミュレーション
はじめに
自動運転技術の研究や開発において、現実の車両を使わずに仮想環境で検証できる「シミュレーション」は不可欠です。
本記事では、NVIDIA Jetson（組込みAIコンピュータ）、ROS（Robot Operating System：ロボット向けミドルウェア）、CARLA（自動運転シミュレーター）を連携させたシミュレーション環境の構築方法を解説します。
連携の課題と解決策（疎結合構成の採用）
CARLAは、その基盤技術の制約上、主に デスクトップOS環境（Windows, Ubuntu x86/x64） で動作します。一方、JetsonはARMベースであるため、CARLAを直接Jetson上で動かすことはできません。
この課題を解決するため、本記事ではCARLAをWindows環境で動かし、JetsonとはROS経由で通信する疎結合構成を採用します。この構成により、JetsonはCARLAの環境やOSに依存せず制御・データ取得が可能になります。
要素技術の概要
ここでは、システムを構成する主要技術の役割を説明します。
CARLAとは
CARLAは自動運転用に開発されたオープンソースのシミュレーターで、Unreal Engine上で構築されています。（CARLA公式ページ）
-
主な特徴:
- 車両、歩行者、信号、センサー、天候など、AD/ADASシミュレーションに必要な要素を網羅。
- Python APIを提供し、外部からの操作が可能。
Jetsonとは
JetsonはNVIDIAが提供する組込み向けAIプラットフォームで、GPUを搭載した小型コンピュータです。（NVIDIA Jetson公式ページ）
-
採用理由:
- 車載環境に適したフォームファクタ: 小型・低消費電力でPoCや実車評価に組み込みが容易。
- ROSとの高い親和性: LinuxベースでUbuntu環境でのROSやPythonの構築が容易。
ROSとは
ROS（Robot Operating System）は、ロボットや自動運転システム向けの分散通信フレームワーク（ミドルウェア）です。（ROS公式ページ）
-
役割:
- ノード間のデータ交換を 標準化された手法（トピック） で実行可能。
- 今回のシステムでは、JetsonとCARLA間で車両状態や制御指令をやり取りする通信基盤として機能。
疎結合構成の採用理由とシステム構築
CARLAとJetsonのアーキテクチャの違いから、本システムではROS Bridgeを介した疎結合構成が必須となります。
carla-ros-bridgeの役割
carla-ros-bridge は、CARLAシミュレーターとROSを接続するための公式ブリッジです。これを導入することで、CARLA内の車両状態やセンサー情報をROSトピックとして公開し、Jetson上のROSノードから制御指令を送信することが可能になります。
疎結合構成のメリット
- 疎結合構成の利点: CARLAとJetsonをROS Bridgeで分離することで、依存関係を減らし、保守性・拡張性が向上します。
- 開発効率の向上: シナリオ生成と制御検証を分離できるため、並行作業が容易になり、検証サイクルが短縮されます。
- 再利用性: Jetson側のノードはROS標準で構築されているため、他プロジェクトや実車評価への転用が容易です。
- ネットワーク柔軟性: CARLAとJetsonは異なる環境でもROSトピックで連携でき、クラウドや分散システムにも対応可能です。
システム構成図と技術的な制約
CARLAはWindows上で動作し、ROS Bridgeを動かすためにWSL2（Ubuntu）を仲介させ、Jetsonと通信するシステム構成を採用します。
なぜWSL2を仲介するのか？
ROSはLinuxベースであり、Windowsネイティブでは動作が困難です。WSL2を使うことでUbuntu環境を構築し、ROS Noeticやcarla-ros-bridgeを安定して動作させることができます。
Pythonバージョン管理の注意点
ROSノードやcarla-ros-bridgeは特定のPythonバージョン（例：ROS NoeticはPython 3.8）で実装されています。通信はROSのシリアライズで行われますが、各環境で動作させるROS/CARLAの依存パッケージの互換性を保つため、Jetson、WSL2、WindowsでPythonバージョンを統一することを推奨します。
ノードとトピックの役割（シミュレーションのインターフェース）
| ノード名 | 役割 |
|---|---|
/carla_ros_bridge |
CarlaとROS間の通信を仲介 |
/brake_control_node |
Jetson上で動作するブレーキ制御アルゴリズム |
/acceleration_control_node |
Jetson上で動作する加速制御アルゴリズム |
| トピック名 | 役割 |
|---|---|
/carla/ego_vehicle/odometry |
後続車の位置・速度データ（CARLA → Jetson） |
/carla/ego_vehicle/vehicle_control_cmd |
アクセル・ブレーキ指令（Jetson → CARLA） |
/carla/brake_enable |
ブレーキ制御ON/OFFフラグ |
シミュレーション概要
本記事で想定するシミュレーションは、プリクラッシュセーフティを想定した車間距離制御の検証です。
- シナリオ: 先行車は一定速度で走行し、指定位置で停止します。後続車はJetsonから制御し、先行車との車間距離を維持します。
-
制御ロジックの概要: Jetson上のノードが
/carla/ego_vehicle/odometryで距離・速度を取得し、制御指令を/carla/ego_vehicle/vehicle_control_cmdに送信します。
起動手順
ここでは、構築済みの環境での通信確立とシミュレーションの開始に焦点を当てた手順を解説します。
① CARLA起動（Windows）
CARLAシミュレーション環境を起動し、ポート3000で待機させます。
cd C:\\work\\user\\Carla\\CARLA_0.9.13\\WindowsNoEditor
.\\CarlaUE4.exe -carla-port=3000
② WSL起動とIP確認・設定
コマンドプロンプトを2つ開き、それぞれ wsl を実行します。
WSLのネットワーク設定を確認し、固定IPアドレスを設定します。
# 現在のネットワーク設定を確認
ip a
# 固定IPアドレスを設定（設定値は環境に合わせて適宜変更）
sudo ifconfig eth0 192.168.0.101 netmask 255.255.255.0
パスワードを問われたら、WSL環境のパスワードを入力してください。
下記のようになっていたら、IPアドレス設定ができています。
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether (MACアドレス) brd ff:ff:ff:ff:ff:ff
inet 192.168.0.101/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
③ ROS環境設定（WSLターミナル）
WSLのターミナルでROS環境を設定し、carla-ros-bridge のワークスペースを有効にします。
# ROS Noetic環境を有効化
source /opt/ros/noetic/setup.bash
# carla-ros-bridgeのワークスペースを有効化
cd ~/carla-ros-bridge/catkin_ws/
source devel/setup.bash
④ 接続後、シミュレーションを開始する
この後、先行車のスポーンやJetson側での制御ノードの起動など、シミュレーションのシナリオを実行する操作を行います。
まとめ
この疎結合構成は、環境依存性をなくし、開発の効率性、制御ロジックの再利用性を向上します。
-
疎結合構成の利点
CARLAとJetsonをROS Bridgeで分離することで、依存関係を減らし、保守性・拡張性が向上 -
開発効率の向上
シナリオ生成と制御検証を分離できるため、並行作業が容易になり、検証サイクルが短縮 -
再利用性
Jetson側のノードはROS標準で構築されているため、他プロジェクトや実車評価への転用が容易 -
ネットワーク柔軟性
CARLAとJetsonは異なる環境でもROSトピックで連携でき、クラウドや分散システムにも対応可能
タグ
CARLA ROS Jetson WSL2 自動運転 シミュレーション