Bash/Linux

SLAM開発はLinux上で行われる。ロボットはLinuxで動作し、データセットはLinuxサーバー上で処理され、事実上すべてのSLAMコードベースはLinuxツールチェーンを前提としている。コマンドラインへの習熟は交渉の余地がない。

中核となるスキル

いくつかの複合パターンで、日々のログ・データ作業の大半をカバーできる:

grep -rn "tracking lost" logs/            # すべてのトラッキング失敗を見つける
grep "ATE" results.txt | sort -k2 -n      # 誤差でランを並べ替える
find data/ -name "*.bag" | xargs -I{} du -h {}   # すべてのbagのサイズ
watch -n1 nvidia-smi                      # モデル実行中のGPU負荷

CLIテキストエディタとtmux

ロボットにSSH経由でログインしているとき、IDEは存在しないため、ターミナルエディタ ―― Vim(あるいはフォールバックとしてnano)―― を、設定ファイルを編集し、起動スクリプトを修正し、抜け出せる程度に使えるようにしておく必要がある。Vim生存に必要な基本: 挿入するには i、保存して終了するには Esc の後 :wq、検索するには /

tmux(または screen)はターミナルマルチプレクサである: 切断後もセッションを生かし続け、1つのSSH接続を複数のペインに分割できる。典型的なロボットセッションでは、1つのペインでSLAMノードを実行し、もう1つで htop、さらにもう1つでトピックのechoを実行する ―― そしてWi-Fiの切断にも耐える。最小限のワークフロー:

tmux new -s slam      # 名前付きセッションを作成
# Ctrl-b %  -> 垂直分割,  Ctrl-b o -> ペインを切り替え
# Ctrl-b d  -> デタッチ
tmux attach -t slam   # 再接続後にアタッチ

シェルスクリプティング

小さなBashスクリプトが実験をつなぎ合わせる: データセット内のすべてのシーケンスに対してSLAMシステムをバッチ実行する、フォーマットを変換する、評価パイプラインを起動するなど。変数、ループ、パイプ、終了コードを学ぶこと ―― run_all_sequences.sh を書けるくらいで十分である:

#!/usr/bin/env bash
set -euo pipefail                      # エラーやタイプミスで即座に失敗する

for seq in data/sequences/*/; do
    name=$(basename "$seq")
    echo "=== $name ==="
    ./build/slam_app --config cfg.yaml --input "$seq" \
        > "results/${name}.log" 2>&1 || echo "FAILED: $name"
done

set -euo pipefail の行と明示的な終了コードの処理が、一晩中信頼できるスクリプトと、2番目のシーケンスでクラッシュした後も黙って「成功」してしまうスクリプトの違いを生む。

よくある落とし穴

SLAMにおける意義

SLAMエンジニアの日々のループ ―― CMakeでビルドし、SSH経由でロボットにデプロイし、tmux内で実行し、rosbagを記録し、ログをgrepする ―― は完全にコマンドライン主導である。ここでの流暢さがアルゴリズムを良くするわけではないが、それが欠けていると、実行するすべての実験が遅くなる。

関連ノート