Git/GitHub
GitはほぼすべてのSLAM研究・産業向けコードで使われているバージョン管理システムであり、GitHubはそのコードが置かれる場所である。SLAMは異例なほどオープンソース中心の分野であり、後のレベルで学ぶシステム(ORB-SLAM3、VINS-Fusion、OpenVINS、DSO、その他多数)はすべてGitHubリポジトリであり、日々の作業はそれらをクローン、ビルド、改造することを中心に回っていく。
習熟すべきGitの中核スキルは以下の通りである。
- 日常の基本ループ:
clone、status、add、commit、push、pull。コミットは小さく頻繁に行い、なぜその変更をしたかを説明するメッセージを付ける。 - ブランチ運用:機能や実験をブランチ上で開発し、後でマージまたはリベースする。研究においてはブランチは安価に作れる並行世界であり、実験のアイデア1つにつき1ブランチを用いる。
- 履歴の読解:
log、diff、blame、bisect。git bisectはSLAMデバッグにおける必殺技であり、データセット上での精度が悪化したとき、bisectはそれを破壊したコミットを見つけ出す。 - サブモジュール:SLAMリポジトリは依存関係(DBoW2、g2o、Pangolin)をサブモジュールとしてベンダリングするのが日常茶飯事である。
git clone --recursiveとgit submodule update --initを知っておくこと。 - タグとリリース:論文は特定のバージョンを参照する。タグに固定することが、報告された結果を再現する方法である。
何百回も入力することになるクローンのパターン。
git clone --recursive https://github.com/<org>/<slam-system>.git
cd <slam-system>
git checkout <tag-from-the-paper> # pin the exact version being reported
git submodule update --init --recursive # in case the checkout moved submodules
そして、これまでのGit学習の投資を一度に回収できるデバッグパターン、データセットの指標に対する自動bisectである。
git bisect start
git bisect bad HEAD # accuracy is broken here
git bisect good <old-tag> # ...and was fine here
git bisect run ./scripts/check_ate.sh # exits non-zero when ATE exceeds a threshold
Gitは履歴を歩きながら各ステップで評価スクリプトを実行し、軌跡を悪化させた正確なコミットを教えてくれる。
GitHub側では次のような点がある。
- Issueはこの分野の集合的なデバッグ記憶である。ORB-SLAM3が手元のOpenCVバージョンに対してビルドできないとき、すでに誰かがそれを報告している。issueを検索することは正当な研究スキルである。
- コードレビューを伴うプルリクエストは、研究室でも企業でも標準的な共同作業の単位である。
- フォークを使えば、アップストリームプロジェクトを追跡しながら自分の変更(新しいセンサー、修正されたビルド)を維持できる。
- ActionsはCI/CDに連携し、プッシュごとに自動的にコードをビルドし、データセットの回帰テストを実行する。
実験の再現性のための衛生管理
SLAM研究における実用的な習慣は、すべての実験をコミットとして扱うことである。推定システムはわずかなパラメータ変化に敏感であり、「その軌跡を得たとき、コードは正確にどのような状態だったか」に答えられることが、再現可能な研究と伝承とを分ける。具体的には次の点に注意する。
- コミットで結果に印を付ける —
git rev-parse --short HEADをすべての出力ログや結果ファイル名に書き込む(多くのプロジェクトはビルド時にバイナリへそれを焼き込む)。 - 汚れた作業ツリーでベンチマークを取らない —
git status --porcelainが空でない場合、その数値は定義上再現不可能である。まずコミットまたはstashすること。 - 大きなバイナリを履歴から外す — 語彙ファイル、ネットワーク重み、データセットは通常のコミットではなくGit LFSや外部ストレージに置くべきである。ビルドディレクトリとデータセットパスは初日から
.gitignoreする。 - 設定をコードとともにバージョン管理する — 特徴点数を設定したYAMLも、C++コードと同じくらい実験の一部である。
SLAMにおける意義
Gitなしでは現代のSLAMに参加することはできない。システムの入手、各ベンチマーク数値の背後にある正確なコードバージョンの追跡、アップストリームへの修正の貢献、共有コードベースでの共同作業はすべてGitを通じて行われる。バージョン管理の規律は科学的な信頼性にも直結する。軌跡の指標は、それを生成したコードの状態が復元可能である場合にのみ意味を持つ。