こんにちは。newmo 自動運転開発室のyui_tangです。
先日、自動運転開発室のオンボーディングと技術理解の共有を目的として、JetRacer を用いた社内ハッカソン合宿「ロボライダー」を開催しました。合宿の様子や背景は note に まとめています。
👉
本記事ではイベントレポートではなく、合宿で再現した開発サイクルと、実機を扱う際に 顕在化した課題を書き記します。
小さくしても、問題は小さくならない
JetRacer は NVIDIA Jetson を搭載した小型の自律走行車プラットフォームです。カメラ 画像を入力としてニューラルネットワークが操舵角とスロットル値を推論し、その結果を もとに車両を制御します。
FaBo JetRacer 環境では PyTorch による回帰モデルが採用されており、画像入力から操舵角（steering）とスロットル値（throttle）という連続値を直接出力する構成になってい ます。分類ではなく回帰として制御量を学習する点が特徴です。
サイズは小さいものの、
- センサー入力
- 教師データ作成
- 機械学習
- 推論最適化
- 実機制御
という、自動運転システムの最小構成が一通り含まれます。
今回の環境は FaBo Platform の JetRacer Docs をベースに構築しました。 https://faboplatform.github.io/JetracerDocs/
JetRacerのような小型自律走行車を用いた競技は国内外でも行われており、例えば以下が 参考になります。
なぜ JetRacer を選んだのか
今回の合宿では、自動運転開発の全体像を短期間で体験できることを重視し、JetRacer を採用しました。
実車開発では、
- 車両準備
- 安全管理
- 実験環境確保
- センサー調整
といった準備コストが大きく、オンボーディングや横断的な理解共有を目的とした短期イ ベントとして実施することは容易ではありません。
JetRacer は以下の点で適していました。
- 自動運転に必要な要素（認識・学習・制御）が一通り揃っている
- 室内環境で安全に実験できる
- セットアップ手順が公開されている
- 個人・チーム単位で再現可能なコストに収まる
参考:
まずは「走らせて失敗する」ところから始まる
合宿では interactive regression ワークフローに沿って開発を進めました。
interactive regression は、人が操縦した走行データを教師データとして学習を行う模倣学習（Imitation Learning）の一種です。
基本的な流れは次の通りです。
- 走行して画像データを収集
- 不要データを整理
- 画像ごとに操舵角とスロットル値の教師データを付与
- 学習
- 推論走行
- 失敗区間を追加して再学習
教師データは画像フレームに操舵角・スロットル値を紐付ける形式で保存され、連続値回 帰として車両制御を学習します。
最初から正解モデルを作るのではなく、失敗を観察しながらデータを増やして改善してい きます。
また、学習後には Jetson 上での推論速度向上を目的として TensorRT 最適化を行いまし た。推論レイテンシは制御周期に直接影響するので、最適化の有無で走行の安定性が目に 見えて変わりました。
床の色を変えただけで、車は迷い始めた
今回のコースでは途中で床の色や素材が変化する区間を設けました。
これは学習時に取得された画像分布と実行時入力の分布が一致しないことで発生する問題 であり、interactive regression が繰り返し前提としている状況でもあります。
改善はモデル変更ではなく、該当区間の教師データ追加で進むケースが多く、データ中心 で開発が進む性質が、小さな車でもはっきり見えました。
ソフトウェアの前に、物理がある
JetRacer 経験者のメンバーが事前にマウント部品を設計し、3Dプリンタで生成したパーツを全チーム共通で使用しました。
同時に、センサー固定位置や視野角のわずかな差が、収集されるデータ分布そのものに影 響することも共有されました。
合宿中に生まれた技術的なチャレンジ
標準的な interactive regression による開発だけでなく、各チームでは異なるアプロー チも試みられました。
視覚言語モデル（VLM）を用いた教師データ生成
走行画像に対する操舵ラベル付与を自動化する試みとして、VLM を利用した教師データ生 成が試されました。短期間で実用的な精度には至りませんでしたが、手作業によるラベリ ング負荷をどこまで削減できるかという観点での探索でした。
強化学習による走行方策の学習
教師データに依存しないアプローチとして、報酬関数に基づいて走行を学習させる強化学 習にも挑戦がありました。実機環境では試行コストが高く、短時間で安定した方策を得る ことの難しさが明確になりました。
2D LiDAR を用いた環境再構築
2D LiDAR によって取得したデータから occupancy map を生成し、仮想空間上での学習を 試みたチームもありました。実機走行とシミュレーションを往復する、いわゆる sim-to-real に近い発想です。
いずれも完成度を競うものではなく、「どこに改善の余地があるのか」を探る探索的な試 みとして行われました。
モデルは正しかったが、車は曲がらなかった
事前走行で良い結果が出ていたチームが、本番直前に期待通りの走行をしなくなる事象が 発生しました。
原因はラジコン内部のケーブルがシャフト付近に挟まり、操舵機構の動作を物理的に阻害 していたことでした。
ソフトウェア上では推論は正常に行われていましたが、ハードウェアが期待通り動作しな ければシステムとして成立しません。フィジカルAIでは、モデル・データ・機械的状態の どれが欠けても走れない。それを実感した場面でした。
同様の取り組みは比較的容易に再現できる
JetRacer は教育・研究用途として広く利用されており、比較的容易に同様のイベントを実施できます。
NVIDIA JetRacer Developer Kit
特別な実験施設を必要とせず、社内勉強会やオンボーディング、ワークショップにも向い ています。
今回の合宿では、プロダクト開発以外のメンバーも多く参加し、実際に手を動かしながら 自動運転開発の制約を体感できた点がよかったと思います。
小さな車で起きたことは、実車でも起きる
JetRacer は 1/10 スケールの車両ですが、開発の過程で直面する問題の種類は実車とほとんど変わりませんでした。
モデルの精度を疑っていた問題が、配線の干渉によって引き起こされていたこともありま した。環境条件が少し変わるだけで挙動が崩れ、改善はアルゴリズムではなくデータ追加 で進むこともありました。
今回の合宿では、特別に新しい手法を導入したわけではありません。むしろ既に知られて いる手法を、短い周期で実機に適用し続けただけです。
それでも、実際に手を動かして開発サイクルを回してみると、自動運転開発がソフトウェ ア開発の延長線上には単純に置けないことがよく分かります。モデル、データ、環境、そ して物理的な状態が同時に影響し合うため、どこを改善すれば前進するのかは常に後から 分かる形になります。
今回の合宿で確認できたのは、新しい知識というよりも、自動運転開発が持っている問題 の構造そのものでした。小さな車両であっても、その構造は変わりません。
短期間の取り組みでしたが、同じ環境を共有しながら試行錯誤を繰り返したこと自体が、 チームにとっての共通言語になった手応えがあります。
🎉４月２２日（水）newmo Autonomy Beer Bash (自動運転開発室meet up) 開催🎉 https://newmo-tech.connpass.com/event/390222/
newmo Autonomy初のイベントを開催します。 自動運転タクシー開発の関わるあらゆる技術領域に少しでも興味のある方、 newmo Autonomyの開発メンバーとお話しませんか？ 上記URLからお気軽にご参加ください！ 美味しい食べ物とドリンクをご用意してお待ちしています🍻
また、newmoの自動運転開発室は、チーム拡大の為採用を強化しております。 多数の職種で採用を行っておりますので、ご興味ある方はぜひご覧ください。
