はじめに

本記事はROS 2 Advent Calendar 2025 22日目の記事です。

こんにちは。Decwestと申します。現在後期博士課程に在籍していて、自律移動ロボットのナビゲーションに関する研究をしています。
本記事では、なんと、自分の提案手法 (DWPP) をNav2公式に統合するという夢のような経験をすることが出来たので、その体験談を共有しようと思います！
本記事を読んで、Nav2への貢献を身近に感じ、貢献してみようと思うきっかけになれば幸いです！

Nav2貢献の流れ

Nav2リポジトリ(https://github.com/ros-navigation/navigation2) にIssueを立てる
変更が承認されたらPull Requestを出す
メンテナーにコードレビューしていただく
（新機能を追加する場合は）Nav2ドキュメントリポジトリ(https://github.com/ros-navigation/docs.nav2.org) に説明を追加する
マージされて完了！

1. Issueを立てる

追加機能やバグ修正のアイデアをIssueとして立てます。
メンテナーの方（Steve Macenskiさん）は非常に親切な方で、貢献を歓迎してくださるので、気楽にIssueを立ててみると良いと思います。（今思えば...）

というのも、かくいう自分は少し特殊で、公開していた非公式Nav2プラグインがNav2のIssueで話題に上がり、それ経由でPRを立てさせていただきました。
該当のIssue: https://github.com/ros-navigation/navigation2/issues/5524
前向きに統合を打診してくださり、とても嬉しかったです。Nav2の機能改善に関する貢献はとても前向きに検討してくださいますので、ぜひ積極的にIssueを立てられればと思うし、自分も継続的に立てていければと思います！

↓ Steveさんからのオファー

2. Pull Requestを出す

変更が承認されたら、実装して、Pull Requestを出します。
自分の例：https://github.com/ros-navigation/navigation2/pull/5591

Pull Requestを出す手順は、以下の通りです。

Nav2を自分のリポジトリにfork
mainブランチから作業用ブランチを切る（命名規則は特になし）
実装する。mainブランチはROS 2 Rolling環境でビルドできます（環境構築方法は後述）
変更をpushし、Nav2公式リポジトリのmainブランチに向けてPRを作成する

実装の内容は、新機能を追加した自分の場合は以下の通りでした。

新機能のコード
新機能追加分のテスト（研究だと蔑ろにしがちだけど、結構大事）
READMEの変更

3. メンテナーからのコードレビュー

メンテナーの方に変更を確認していただき、コメントを頂いたらそれを修正する作業を繰り返します。
自分の場合は大きな変更だったため、約2か月を要しました。
Steve Macenskiさんがコードレビューしてくださったのですが、非常に丁寧に対応してくださり、可読性向上のノウハウを色々身に付けることができました。本当に感謝です...（ノウハウは後述）

なお、メンテナーの方は忙しいので、時々返信が遅くなってしまうことがあります。
（他にもPRが山積みだったり、本家ROSConの後にvacationを取っていたり、サンクスギビングで休暇を取っていたりなどなど...個人的には、休むときにしっかり休める働き方はいいなぁ～って思います）
そんなときは、friendly pingと打つと、角を立てずにリマインドをすることができたりします
（HansRoboさんの体験談参照：https://hans-robo.hatenablog.com/entry/2024/12/07/000043 ）

また、Steveさんと交流のあるROS 2メンテナーの藤田さんやROSCon JPオーガナイザの高瀬先生によると、Steveさんはとてもいい方で、学術貢献にも理解のある方なので、論文執筆のために統合を急いでいます！のように急いでいることを伝えると可能な範囲で対応をしてくださるなど、親身に柔軟な対応してくださいました。

4. Nav2ドキュメントリポジトリに説明を追加

新機能やパラメータの追加がある場合は、Nav2ドキュメントリポジトリ (https://github.com/ros-navigation/docs.nav2.org )側にも変更を加え、Pull Requestを立てます。
自分の例：https://github.com/ros-navigation/docs.nav2.org/pull/802

変更の内容は、新機能を追加した自分の場合は以下の通りでした。

5. マージ！

本記事執筆段階ではまだマージされていないので、進展があり次第追記します！

マージされると、変更がmainブランチに取り込まれます。
その後に、backportといって過去のバージョンへ反映されます。
Nav2の場合は、Kilted, Jazzyがbackportの対象です。
（つまり、Humbleはbackportの対象外なので（マ～～？？）、Nav2を使うならJazzy以降を用いることを強く推奨します！）

貢献してよかった点

さいごに

本記事では、Nav2貢献の一連の流れについて説明いたしました。
もともと自分はNav2やROS 2に貢献したいという気持ちはありましたが、その方法や人脈を持っておらず、Nav2やROS 2を変えようとせずに、自分の環境を変えて対応したり、非公式パッケージを公開したりしていました。
しかし、今回の経験を経て、まずIssueやPRを立てれば、メンテナーの方々はすごいWelcomeで対応してくれることがわかりました。
なので、Nav2やROS 2への貢献に興味のある方がいらっしゃったら、まずはIssueを立てるところから！そして本記事がその後押しになれば幸いです。

余談：日本からのROS 2公式への貢献を増やそう！というROS Japan Developer会議というグループがROSConJP 2025で発足し、ROS 2貢献へのチャンスだと思って自分も参加しています。こちらもぜひ！

付録：技術的なお話

ROS 2 Rolling 環境構築

そもそも、Rollingとは？

ROS 2の開発版バージョンです。常にRollingは存在していて、毎年Rollingから切り出される形で新しいバージョンがリリースされています。

ROS 2 Rolling Docker環境

自分がNav2統合時に使っていたRolling Docker環境は以下です。
https://github.com/Decwest/dwpp_test_environment/blob/feature/nav2_integration/docker/Dockerfile.rolling

ベースイメージはosrf/ros:rolling-desktop-fullを用いました。
Nav2のturtlebotを用いたチュートリアル(ros2 launch nav2_bringup tb3_simulation_launch.py)を実行するために、以下をDocker環境にマウントし、rosdep installとソースビルドをしました。

navigation2
nav2_minimal_turtlebot_simulation (https://github.com/ros-navigation/nav2_minimal_turtlebot_simulation )：turtlebotのシミュレーション用
rviz (https://github.com/ros2/rviz)
- navigation2のビルド時にQt関連のエラーが出たので、ベースイメージに入っているRVizをいったん全部消して、ソースビルドしていました
  - 最新のNav2はQt6前提なのにベースイメージにはQt5が入っているから、消して、Qt6入れて、RvizのソースビルドをしてQt6環境にして対応したみたいな話だった記憶
- 開発版バージョンだから、こういう不安定なことは日常茶飯事
BehaviorTree.CPP (https://github.com/BehaviorTree/BehaviorTree.CPP)
- これは元々入れていなかったのですが、11月頃に急にこれ無しでは動かなくなりました... (https://github.com/ros-navigation/navigation2/pull/5591#issuecomment-3575668154)
- osrf/ros:rolling-desktop-fullに更新が入って内部にプリインストールされたBehaviorTree.CPPのバージョンが変わり、nav2と不整合を起こし、セグフォを起こしていたようです。セグフォなのでエラーメッセージが全く出てこず、これは直すのが本当に本当に大変でした、、、、
- 開発版バージョンだから、こういう不安定なことは日常茶飯事

PR作成、コーディングのノウハウ

commitする際は必ずsigned-offをつける
- signed-offとは：署名のこと。git commit -sオプションで付けられる
- DCO (Developer Certificate of Origin) checkというものが走り、signed-offされていないコミットが一つでもあるとマージできない
  - 自分は、PRの立て直しが必要になってしまった... 旧PR, 新PR
一度のPRで追加する機能は一つだけ
- 追加する機能に関する差分以外はすべて元と同じコードにする
  - メンテナーの負担を削減するため
- もし別の問題に気づいたら、それは別のPRとして立ててそちらで対処する。
テストを書く
- <package_name>/testディレクトリ内にテストを見よう見まねで書く
- 追加したコードの全てのエッジケースに対応するようなテストを書くことがマージするためには必要
- colcon build後に、colcon test --packages-select <package_name>でテストを実行し、全て通ることが必要
コードのフォーマットを整える
- フォーマットが整っていないと、テストで弾かれる
- パッケージのディレクトリに移動し、ament_uncrustify --reformatと打てば自動でフォーマット整形してくれ、これで大体は対応できる
変数名やコメントアウトの書き方はNav2の他のコードとの整合性を意識して決める
- tempなんて絶対にダメ。Don't name things "temp", that's bad SE practice. Name it meaningfully（原文ママ）
パラメータのデフォルト値は変更しない
- もし新しいパラメータを追加する場合は、他のパッケージで類似したパラメータがあればその値を使う

複数個の変数をreturnしたいとき、場合によっては参照渡しによるimplicit returnではなく、tupleを活用

悪い例

速度指令値を算出する関数で、暗黙的にlinear_vel, angular_velの値を更新する

void computeVelocityCommands(const float & max_linear_vel, ..., 
    float & linear_vel, float & angular_vel){
    // linear_vel, angular_velに対する処理
}

computeVelocityCommands(max_linear_vel, ..., linear_vel, angular_vel);

良い例

速度指令値を算出する関数で、明示的にlinear_vel, angular_velの値を更新する

std::tuple<double, double> computeVelocityCommands(const float & max_linear_vel, ...){
    // linear_vel, angular_velに対する処理
    return std::make_tuple(linear_vel, angular_vel);
}

std::tie(linear_vel, angular_vel) = computeVelocityCommands(max_linear_vel, ...);

Gazeboの真値情報に基づくTurtlebotシミュレータの開発

新たな経路追従器を追加したので、性能評価のためにオドメトリやAMCL等の自己位置推定ではなく、Gazeboの真値情報に基づいたオドメトリをpublishするTurtlebotモデルを作りました。

以下のツイートに示す変更をしました。大変だった、、、

ファイルは以下のGitHubリポジトリで公開しているので良かったら参考にしてみてください。