2017年11月29日水曜日

つくばチャレンジ2017

思い立ったので2011年以来,6年ぶりに更新.
ブログの更新は止まっていましたが,2013年以降はProject C.G.Sという社会人サークルを作ってつくばチャレンジMBZIRCに参加しています.

今年も例年通り,つくばチャレンジに参加してきました.

探索対象発見へ向かう様子(大会本走行時)


まとめ

  • 探索・信号課題のクリア,および積極的な障害物回避を課題にシステムを開発
  • Gazeboによるシミュレーションを開発に導入
  • 本走行の結果は,走行距離 1,300m / 発見探索対象数 1人



つくばチャレンジ2017 課題

2013年からの第2ステージ共通して,「コースの自律走行」と「人の探索」の大きく2つのテーマがあり,それに基づき課題が設定されている.(つくばチャレンジ2017課題

  • コースの自律走行
    一般の歩行者がいる屋外・屋内そして横断歩道(信号も要自律判断)を含む全長2,000mのコースの自律走行.
  • 人の探索
    指定された探索エリア内に4名いる,特定の色の帽子・ベストを着用した人の探索および発見通知.
    なお,探索対象付近には看板が置かれている.


チーム目標の設定

昨年は「確実なコース完走」を目標として,2,000mのコース(信号なし)を完走した.
システムは,探索や信号にはトライせず障害物回避も必要最小限に留めるなど不確実性を極力排する方針で開発した.

今年は,「つくばチャレンジ課題達成」を目標として,システムの作り込み・完成度を高めるより,不安定でも新しい機能を積極的に導入する方針を定めた.
具体的には,探索・対象発見,信号認識判断,そして積極的な障害物回避・追い越し.

 

システム

2017年のシステム構成


昨年までの実績より,自己位置推定(青色)はつくばチャレンジで使われるエリアでは十分な精度で機能することが分かっていた.
そのため,今年は目標達成のための機能として,探索対象認識&信号認識(緑色),課題のためのミッション管理(紫色),そして経路・軌道計画(黄色)の新規・更新開発を行った.
以下,簡単な概要:

  • 自己位置・姿勢推定
    Monte Carlo Localizer (MCL) [1] で実装.参考文献とは尤度関数の実装が異なり,事前に用意した3次元マップと走行中に生成した3次元シーンの最近傍点の位置関係を尤度に使用している.[2]
  • 探索対象認識
    Single Shot Multi-Box Detector (SSD) [3] にて画像から看板を検出し,上記3次元シーンと画像上の検出位置の対応付けにより,3次元上での探索対象の位置を同定する.
    SSDの学習は,事前のテスト走行で取得した実画像に,明度を変えた水増し画像を加えて実施.
  • 信号認識・判定
    L*a*b*空間に変換を行い,a* - b*平面の位置から赤信号に該当するピクセル,青信号に該当するピクセル,その他に分類し,ピクセル数の関係から信号状態を判定する.
    分離直線に用いるパラメタは事前に取得したログから算出した.
  • 経路・軌道計画
    ミッション管理から与えられた走行経路を障害物を回避しつつ追従する制御を生成する.実装では,自機位置からみて指定経路上5m先をサブゴールとして,Dynamic Window Approach (DWA) [4]で制御指令を生成した.コスト関数も原論文同様の実装をした.
    後述するGazeboシミュレータで動作確認・大まかなパラメタ調整を行った上,実機で最終調整を実施.
  • ミッション管理
    現在の状態を管理し,コース追従と探索の切り替え,発見動作,あるいは横断歩道モードの切り替えなど,機体が取るべきアクションの決定を行う.
    これも単体テストに加え,システム動作の確認をGazeboシミュレータで確認した.


シミュレーション

昨年までは事前に敷いた経路を正確に追従することが課題であり,システムでも自己位置推定・経路に沿う制御指令が出せているかの確認で,センサログによる動作確認で十分であった.一方,今年は探索やDWAでの障害物回避など,状態に応じた動作遷移・また指令に対する機体動作の確認が必要となった.
現状,我々のチームは実機を走行させられる機会が公式試走会以外になく,実機テストの回数が限られる.そのため,今年はGazeboによるシミュレーションを導入し,機能の動作確認を行った.
今年は特に経路・軌道計画モジュールおよびミッション管理モジュールの動作確認(上記システム図中の紫〜黄色のモジュール)を目的として,機体形状および水平LiDARをモデル化した.

大清水公園出口付近(右折してスロープ)を模擬した環境
シミュレーションにより機能の動作・大まかなパラメタは実機テスト前に確認することができ,実機で狙い通りに動作させることができた.ただし,実機とのモデル誤差や今回シミュレータに反映できなかった動的障害物への対応が実機調整で必要となり,その点は課題が残る.


大会結果

本走行スタート待ちの様子
  • 走行距離: 1,300 m 
  • 探索対象発見: 1 人 
結果としては課題達成に至らず,走行距離も前回より短くなった.
ただし,昨年まではできなかった探索対象の発見や,テストでは信号判定に成功するなど,機能的には進歩があった.あとは手持ちの機能を作りこめば,課題達成は狙えると考える.(実際はここからがまた大変ではあるのだが...)
ターゲット発見時のロボット認識データ (rvizで可視化)
走行に関しては,静的障害物は安定して回避.動的障害物に対しても停止・回避が働き衝突することはなかった.ただし,自分よりやや遅いロボットに対し,相手軌道が予測できておらず追い越しに失敗することが見られた.また,アグレッシブな回避・追い越しを試みることで,道幅いっぱいに左右に振れるなど,やや社会規範に欠ける動作が見られた.

探索対象発見については,カメラのオートエクスポージャが狙いに反して空の明るさの影響を受け探索対象が暗く写ってしまった.結果,発見成功した対象の他に二人検出射程に入ったものの発見できなかった.

1,300m地点で走行停止となったが,原因は建物の壁面を探索対象と誤認識.そこに経路生成のソフトバグが重なり露天の敷地に入り込みそうになり走行停止.

壁の誤認識に関しては,SSDの学習時に使用したトレーニングセット,評価セットが妥当でなかった考えられる.この点に関しては,チームとして知見が不十分なため,今回の結果から分析を行い開発へのフィードバックが必要である.

経路生成ミスについては本走行前に更新したコード,かつ手間を惜しんでテストをスキップした点が本番で発生した.よく言われることだが,手間を惜しんだところは本番で発生する.可能であるなら手間を惜しまずテストをすることが必要である.


今後の課題

現実的なロボットに適用すべき技術課題として,
  • 探索対象の認識能力(Precise / Recall)の向上 
  • 動的障害物の軌道を予測したうえで,必要最小限動作での回避・追い抜き
開発推進面では,
  • より実機に近いモデル,そして動的障害物含めた様々なシミュレーション環境の充実
  • テストによるバグの低減(可能な限り自動化)
また,より将来的な観点では,ブルーシートを広げた露天のような,空間的には走行可能だが社会規範的には走行すべきでない場所の取り扱いである.現状人の手で走行禁止エリアとしているが,社会に溶け込む実用性を考えたらこうした規範面も課題となると感じた.

参考文献

[1] S. Thrun, W. Burgard, and D. Fox. : Probabilistic Robotics. MIT Press, Cambridge, MA, 2005.
[2] Project C.G.S. : Project C.G.S.のつくばチャレンジ2016における取り組み,つくばチャレンジ2016 参加レポート集,2016.
[3] Wei Liu, et al.: SSD: Single Shot MultiBox Detector, arXiv:1512.02325, 2015.
[4] D Fox, W Burgard, S Thrun: The dynamic window approach to collision avoidance, Technical Report IAI-TR-95-13, University of Bonn, 1995.

0 件のコメント:

コメントを投稿