2019/09/02 ■ オープンソースの自動運転化キットで既存の車をハックする話 #車ハック　Twitterでつぶやくこのエントリーをブックマークに追加このエントリーを含むはてなブックマーク

元値730万円の新車が60万円で買えるようになったのでハックして遊ぶとすごく楽しい、という話の続編です。オープンソースの自動運転化キットを後付けして既存の車に自動運転機能を追加します。


【超重要】注意事項

本記事には自動車の根本的な制御に介入し、運転のコントロールを乗っ取るという非常に危険な内容が含まれます。実施する場合は、自分がどのような制御・どのような操作をしているのか、それにはどのようなリスクがあり、どんな事態が起こりえるのか、事故を起こさないためにはどのような対応をすればいいのか、といったことを必ず自分の責任において理解した上で行ってください。すべては実施者ならびに運転者の責任となります。

  • 自動運転システムの公道実証実験については、警察庁が自動走行システムに関する公道実証実験のためのガイドライン(PDF)というガイドラインを出しています。
    • 現行法令では、自動運転車であっても交通違反ならびに交通事故が発生した場合はテストドライバーの責任となります。逆にいえば、 テストドライバーが安全を担保することができるのであればテストドライバーは必ずしも常にハンドルを把持する必要はない とされています。
  • システムのエラー・誤認識によって違反や事故が発生することを 防止する義務はテストドライバーにあります 。自動運転システムも 含めて 車両の運行に関しては「テストドライバーの運転」とみなされます（ので、自動運転装置が運転している状況であってもテストドライバーは該当車両の運転免許が必要です）。シンプルに言えば、事故が起こったらテストドライバーのせい。究極的には、テストドライバー「が」事故や違反を起こさせなければよい、というわけです。
    • なので、ハックする人とテストドライバーは同一であることを非常に、非常に、非常に強く推奨します。 全ての責任がテストドライバーにある ことをテストドライバー自身が 完全に理解している必要がある ためです。
  • ハックする場合は どんな場合でも、どのような場面でも最終的にはテストドライバーの介入で機械の操作をキャンセルないしはオーバーライドできる必要があります し、たとえいつどんな挙動をしてもすかさず運転を引き継いで絶対に事故や違反を起こさないと保証できる状況で運転する必要があります。市販車の既存機構のハックをする場合は、 既存機構がどのような構成で動作していて、最悪の場合でもどのような選択肢がありどのような操作が運転者に残されているのか は把握しておく義務があります。

以上のことをよくよくご理解いただいた上で、先に進んでください。



comma.aiによる「オープンソースの自動運転化キット」

オープンソースの自動運転化キット。そんなものがあるのか！という人も多いとおもうのですが、あるんです。通称「Geohot」ことジョージ・ホッツ氏― 弱冠17歳のときに、個人として初めてiPhoneのジェイルブレイクに成功したことで有名なハッカー ―が、次に「車」をハッキングし開発した自動運転システムです。

もともと最近の自動車はCAN(Controller Area Network)というネットワークでさまざまなセンサとコンピュータが繋がっています。また、車種によってはオートクルーズやステアリングアシストつきのLDA（レーンディパーチャーアラート＝車線逸脱警報機能）、自動駐車機能など「アクセル・ブレーキ・ステアリング」をコンピュータから制御する機構も既に備わっているのです。もちろん、 これらもすべてCANに繋がっています 。

つまり
CANを支配すれば、車のセンサを使い、車のアクセル・ブレーキ・ステアリングをも自由にコントロールできる
というわけです。

これを真面目にハックし実践したのが先のジョージ・ホッツ氏。ここに2015年ころの動画がありますが、自宅ガレージでハックして自動運転車を自作している様子が見えます。当初はホンダ車をベースに開発されていましたが、その後トヨタ車もサポートされました。

comma.aiが提供している自動運転化キットはいろいろコンポーネントがあってちょっとわかりにくいのですが、以下のような構成になっています

  • ハードウェア
    • EON DevKit https://comma.ai/shop/products/eon-gold-dashcam-devkit
      • 中華スマホ(LeEco Le Pro 3 X727)をベースとして作られた自動運転向けダッシュボードコンピュータ。ざっくり言うとスマホ＋放熱筐体＋ファン＋電源基板。
    • Panda https://comma.ai/shop/products/panda-obd-ii-dongle
      • OBD2コネクタ（車の診断用コネクタ規格）型の自動運転用CAN - コンピュータ間インタフェースモジュール。危険なCAN制御が行われないような、機械の介入を強制キャンセルできるような安全機構もPanda内に備えている。EON DevKitを車のCANに繋ぐために必要。
      • Pandaは現在White Panda（WiFi接続可）とGrey Panda（精細位置取得用GPSモジュールつき、有線接続専用）の二種バリエーションがある
        • 今後信号や一時停止などの自動制御はGPS座標を使う想定でいるらしく（日本で使えるかはどうかは別として）高度な自動運転はGrey Pandaで対応する予定、と言われています。
    • Giraffe https://comma.ai/shop/products/giraffe
      • 車にPandaを接続するためのコネクタ基板。車のフロントガラス中央上方に、メーカー純正の運転補助システム用の前方監視カメラ・ユニットがあるのですが、そのユニットにささっているケーブルを抜き、間に挟むようにして使います。
      • そして、そのGiraffeにPandaを差してEON DevKitを車に接続します。
        • 車→Giraffe→Panda→EON DevKit、という接続
      • つまり、Giraffeは車メーカーごとに形状が異なります
  • ソフトウェア
    • NEOS https://github.com/commaai/eon-neos
      • Androidをベースとした自動運転用OS。EON DevKit上で動作します
    • OpenPilot https://github.com/commaai/openpilot
      • NEOS上で動作する、自動運転ソフトウェア。Giraffeを経由してPandaから取得した車のデータと、カメラの画像から運転制御を決定し、Pandaを通して車を制御します。自動運転のアルゴリズムも含め主にPythonで書かれており、必要に応じて書き換えることも可能です。
    • Comma connect

かんたんにまとめると、

  • 車に合った「Giraffe」を車の前方監視カメラユニット部に接続し
  • GiraffeについているOBD2コネクタにPandaを接続し
  • PandaにEON DevKitを接続する。

そして

  • EON DevKitにNEOSをインストールし（インストールされていて）
  • NEOSにOpenPilotをインストールする
  • 自分のスマホにComma connectをインストールして
  • Comma connectとOpenPilotをペアリングする

という構成だと理解しておけばだいじょうぶです。
（ほか、車によってはGiraffeに別途常時電源「Comma Power」を接続する必要があったりします）



comma.ai から EON DevKitを買う

EON DevKitは comma.ai shopから買うことができます。PayPal決済で、ポチッとしてから4～5日ほどで届きます。


EON DevKitには、EON DevKit本体、車のフロントガラスに装着するためのマウント、miniUSBケーブル


Giraffe + Grey Pandaには、必要に応じてCommaPowerやGPSアンテナを固定するためのマウントなども。

基本的に、一式買うと車へのマウントも含めて必要なものはひととおり入っています。EON DevKitのカメラを車線認識などに使う都合もあり本体の車への設置（マウント）は取付け/取り外しにともない角度がかわったりしないようガッチリと固定する必要があるため、標準添付のマウントをそのまま使うのが安心です。



取付け


トヨタ車の場合、フロントガラス中央上部にFRC(Forward Recognition Camera)と呼ばれるユニットがあり、ルームミラーの裏側にあるカバーをスライドさせるだけで簡単に露出させることができます。
ここに刺さっているケーブル（CAN）を引っこ抜き、Giraffeを間に挟みこむことで車全体のCANネットワークをハイジャックするわけです。


GiraffeをFRCとそのケーブルの間に挟み込んだら、GiraffeにPandaを接続、PandaをEON DevKitに接続します。Grey Pandaの場合はそのほかにGPSアンテナが付属しますので、これも適当なところに設置します。
ほかにもDSU（Driving Support Unit）というECUがある車はOpenPilotからコントロールできるよう切断します（このあたりは車種によってやるべきことが変わります）。


GiraffeはFRCと車の間に割り込んで、OpenPilotからコントロール可能にします。つまりOpenPilotが本来動作すべきFRC（やDSU）の挙動をエミュレーションしてFRC・DSUの代わりに車を制御するわけです。これは言い換えると、OpenPilotが動作していない状態だと車がFRC・DSUの不具合としてエラーを検出する…ということです。
GiraffeはFRCと車の間に割り込みますが、トヨタ車のこの部分には「車のイグニッションがONのとき」にだけ電源が通電されます。OpenPilotの動作として、通電されたことを検出しOpenPilotが起動し…という流れだとFRCのエミュレーションが間に合わずエラーとなってしまうため、常時通電の電源ラインを別に確保する必要があります。そのための配線が「Comma Power」と呼ばれる電源線で、通常はOBD2ポートから取得します。



OpenPilotの動作と安全機構

OpenPilotの安全性について。オープンソースの自動運転化キットであるOpenPilotですが、安全性にも相応の配慮がなされています。詳しくはこのopenPilot safety というページを読んでいただきたいのですが、車種（メーカー）によって実装が異なるものの、おおむね以下のような形で安全性を確保しています

  • OpenPilotは「自動運転」ではなく運転補助機構であり、ドライバーは常に状況を監視する責務を負う
    • EON DevKitのインカメラを使ってドライバーが路上をきちんと注視しているかをチェックし、よそ見していると警告・オートパイロットを切る機構も用意されている
    • ステアリングにかかっているトルクを検出し、手放し状態が続くとそれを検出し警告・オートパイロットを切る機構もある
  • オートパイロットのためのステアリング操作・アクセル・ブレーキ操作は既存の（当初から車に装備されている）オートクルーズ機構のシステムメッセージを使用して実現されており、オートクルーズ機構がONになっていないと動作しない
    • オートクルーズ機構自体がブレーキ操作・アクセル操作などのきっかけで即時OFFするようになっており、OFFになったあとはそもそも制御信号が流せないか、効かないようになっている
  • ステアリング操作・アクセル・ブレーキ操作は一定以上の急操作はできないようにリミッタが設けられており、リミット以上のデータが流れないようになっている

また、たとえばステアリング操作はステアリングに「トルクをかける」ことで実現されており、またそのトルクの最大値も決まっているためどうしても制御を（人間が）取り戻したいときは力をかけてステアリングを回せば普通に操作できます。
そういったことも含め、安全性は既存の、車メーカーによるシステムによってある程度担保された上で構築されているともいえます。



MIRAI対応移植


トヨタ車のサポートは広いOpenPilotですが、今回取付けたトヨタMIRAIは非対応でした。そこで、対応作業を自分でやってみることにします。
OpenPilotの他機種対応はおおまかに以下のような手順を踏みます

  • OpenPilotが車種を識別することができるよう、車種情報を追加する
    • これを「FingerPrint」と呼んでいます。車に定常的に流れるCANデータは車種によって異なるので、一定時間の間に流れるCANデータをダンプして「こんなデータが流れていたらこの車」という形で判別します。
    • ターゲットとする車のFingerPrintを取得し、識別できるようにします
  • CANを流れるパケットの、どのアドレスにどういうデータが入っているか、マッピング情報を整える
    • dbcファイルという形式で各車種ごとに記述されているので、これを記述します。CANを流れるデータをダンプして、他車種の記述と見比べながらデータの違いをdbcファイルに反映します。
  • 車の基本情報、ほかのロジックなどを記述する
    • ハンドルのロック・トゥ・ロックの回転数やホイールベース、車重などの基本情報、さらにほかのロジックなどで調整が必要なところを記述します

トヨタ車むけのポーティングガイドは親切なドキュメントがあります。一部記述が古くなっている（fingerprintを記述する場所が違うなど）ところはありますが、この手順に沿えば間違いないです。

というわけで、調べた結果MIRAIはTSS2.0(Toyota Safety Sense 2.0)の他の車とだいたい一緒…なんだけれども、

  • ステアアングルが、他の車と異なりトルクセンサ（STEER_TORQUE_SENSOR）のパケットに入っていない。STEER_ANGLE_SENSORのパケットに入っているのでこちらを使う必要がある
  • GAS_PEDALのパケットサイズが違う
  • BRAKE_PRESSUREのビット数が違う
    といった違いがありました。これをvalue.py、dbcファイルやcarstate.pyの処理などに反映していきます。

…というわけで、動きました！
トヨタ車の制御としては確立したものをそのまま使えたので、思ったよりも楽でした（当初MIRAIがTSS2であることに気がつかず少し時間を無駄にしましたが…）


OpenPilotによる自動運転レビュー

OpenPilotが現在実現しているのは、あくまでも 「高速道路の前車追従・レーンキープ」レベルの運転補助 です。テスラに限らず、このレベルの『自動運転』はすでに各社採用が進んでおり、BMWでは日本で初めて「高速道路の渋滞時に手放し運転を公式に許可する」制御を実現していますし、秋には日産も手放し運転を実現します。手放しでなければ、もっと広範に対応車種があります。
そういう意味では「目新しい」「最新の」システムではまったくないのですが、そのような機構がついていない既存車種に後付で、しかもオープンソースで！構築できるというのは特別な感慨があります。

さて。
では実際OpenPilotの『自動運転』はどの程度のレベルなのでしょうか？

  • そもそもの前提として、MIRAIへの後付でいうと、もとのレベル（Toyota Safety Sense、前車追従、LDA）と比べるとだいぶできることは広がっています
  • 見通しの良い高速道路での前車追従、レーンキープ走行はなかなか優秀です。ただしブラインドで急なコーナーが続く首都高のような道はだいぶあぶなっかしかったりします
    • 定速走行、前車追従、渋滞時の減速・ストップ＆ゴーについてはそこそこスムース
    • 急なカーブなどはハンドルの操作トルクが安全リミットに負ける？のか曲がりきれないことがあります。これはまだMIRAIでの設定が追い切れていないからかもしれませんが。（手で補助してやれば曲がれます）
  • センサーは前方のレーダーと前方カメラによる車線認識。左右や後方は現状では見ていないので、割り込みなどには人間がある程度対応する必要があります
    • ユーザによるカスタムフォークでは、左右後方のセンサも参照した上でウインカー操作からの自動レーンチェンジを実現している実装もあるそうです
      • というように、無い機能を各自で作ってしまえるのがなんというかハック感あります
  • 一般道でも機能をONにすること自体はできますが、都心のごみごみした道路ではそもそも定速で同一車線を走り続けるということがなく突発状況に対応できるわけでもないので素直に人力運転したほうがよいです
    • 交差点で微妙に中央分離帯に向かおうとしたり、妙に車線の中央から外れそうになったり…ということがままあります。非常に多様な路面状況に対して認識精度を高めるのは本当に難しいんだなあ、と実感できます。
    • アンダーパスなど急なアップダウンがある道だと、上り坂をレーダーが先行車と誤認して減速！なんてこともあります
  • 先述のとおり、OpenPilotでも手放し警告はあります。インカメラによるドライバー監視のほか、ハンドルのトルクを検出して手放し状態を警告します。
    • しかしこれもオープンソースなので自分で解除することもできる（！）わけです。推奨はできませんが…

総じて、

  • 既存の機構と比べるとできることが増えて、最近の先進装備並になるのは大きなメリット
  • 自動運転の精度はメーカー製（特にテスラ）と比べるとまだあぶなっかしいところがある
    • しかし、オープンソースなのでアップデートも頻繁にあり、自力改造も含めて精度やできることは向上している

comma.aiは高精度GPSのデータなども使って今後「レーンキープ」レベルよりもさらに上の自動運転を狙っているみたいですが、実際使ってみるとこのままこのシステムの延長でフル自動運転が待っているかというとかなり厳しそうという印象があります。「自動運転」の世界はテスラやGoogle(Alphabet)のようにセンサを山盛り追加した車で、圧倒的な物量の開発が要る世界です。現状の小規模なオープンソース開発ではどうしても限界がありますし、それをバザールモデルで乗り越えようというのは相当にキツい。しかし、この限界があるからこそ、ハック魂や夢を感じるのもまた事実です。

現状の完成度は「自動運転だから車に運転を任せる」というレベルではとてもありませんが（そもそも絶対にそうするべきではない）ハンドルに手を添えてOpenPilotによるハンドル操作を手で感じとりながら、リラックスして状況を監視していればいい…というのはやはりとても楽です。特に 渋滞気味の高速道路で前車追従していくのは運転の気疲れが8割減 という感覚があります。

いっぽうで、運転終了・下車時にはEON DevKitを車から取り外していく必要があり（夏の車内の高温環境に耐えるデバイスではないほか、常時通電されているのでバッテリーが上がってしまう）乗車時の装着など若干不便です。また、EON DevKitが接続/起動されていない状態で車のイグニッションをONにすると大量のエラーメッセージが出る（車にもともと装着されているクルーズントロールまわりのECUのメッセージをOpenPilotが模倣して応答するため、起動し接続されていないとその部分がすべてエラーとなる）ので装着するまでエンジンをかけられない、ということもあります。このあたり日常の運用に一手間かかるのが気になる人は気になるかもしれません。


自動運転のミライ

（※写真は駐車中に撮影したものです）

煽り運転が話題の昨今ですが、車を運転していて「イライラする」のは、車の運転するにあたり「こう動きたい」という自分のペース、自分の意思があるにもかかわらず、その思い通りにいかない、という「自分の意思が実現しない、意思と現実のギャップ」に起因するのではないでしょうか。
これが、自動運転で「車に運転を任せている」と、そもそも自分が運転の意思をもたない（こう走りたい、という意識をしない）ために「意思と現実のギャップ」が発生しません。要するに、まったくイライラすることがありません。

よほど時間がなく焦っているときは別として、タクシーやバスに乗っているときにいちいち「この車じゃまや！！どけ！！」なんて思うかどうかという話で、車に運転を委ねるというのは実際に体験してみると思った以上に「感覚として楽」になります。これは、逆に言うといかに今まで単調なドライブに対してストレスを感じていたか、ということでもあります。
今後は「車を運転する」という行為が、より本質として「移動する」と「運転を楽しむ」に分解され、それぞれが技術によって最適化されていく…という未来が感じられます。よく「自動運転なんて要らない！運転する楽しさがいいんだ！」と言われたりしますが、楽しい運転と特に楽しくない運転があると思うんですよね。すべてを人間が運転「しなければならない」というわけではないはずです。

で、そのとき…
オープンソースのOpenPilotによる「“移動”を最適化する」こと自体を「楽しむ」なんて新時代の楽しみ方ができてくるのかもしれません。さすがにその楽しみ方は一般化はしないでしょうけれども！



※最後に再度注意※

EON DevKit/EOS/OpenPilotは、非常に大きな危険性もはらむシステムです。かならず自己責任で、すべてを理解した上で取り扱う必要があります。本blog記事でそこそここまかくは書きましたが、肝心なポイント（インストール手順やこまかい使用方法など）はあえてステップ・バイ・ステップで誰にでもわかる…ようには 書いていません 。こういう存在があって、どういうものなのか、ということを紹介するべく記事を書きましたが、これを 推奨し誰でも使えるようにという意図はまったくありません 。より詳細な情報が必要な人は、かならず、本家サイトの英語ドキュメントをしっかりご自分で読んで、ご自分で使い方を理解し、ご自分でリスクとメリットを判断し、ご自分の判断で、ご自分で取り扱ってください。 人に「使い方」を尋ねなければ使えない人はそもそも触るべきではありません し、 もし何かあっても誰も責任はとってくれません 。



Related Posts with Thumbnails
時刻: 12:00:00
ラベル: