Hatena::ブログ(Diary)

rider2.0研究会 このページをアンテナに追加 RSSフィード

2016-05-03

ラップタイム読み上げマシン

少し前にベストラップ更新中であることを音で知らせるメカを作った

http://d.hatena.ne.jp/kitaring/20160412/1461163659

確かに有り難いが画期的に便利というほどではなく、その割に設置の手間が掛かりすぎるので結局1度しか使っていないのだった。

先日、Takadamaさんに頂いた、Arduino UNOの互換品を試してみたところ、Laspberry Piで散々苦労して結局実現できなかった2Dのラップトリガーの受信に成功。

Arduinoにはアナログ入力が存在して、かつ5Vでも大丈夫なので、何も考えずにセンサーの信号線をアナログポートに突っ込むだけで事足りた、

2Dの赤外線センサーはテスターで調べても挙動が判然としないけれど、Arduinoのアナログポートにつなぐと、整数値が入力され続けて、発信機に向けたときにだけ0が入力されるので大変分かりやすい。

というわけでArduinoRaspberry Piを連携させることで、当初の計画であった、ラップタイム読み上げ機能が完成した。

ほぼアナログポートの為だけにArduinoを使う辺りからポンコツ感が漂うけれど、落としどころとしては無難かもしれない。

ArduinoRaspberry PiUSB経由でシリアル通信できて、かつArduinoの電源も兼用するので配線もそれほど煩雑にならない。カメラユニットも必要ないので設置場所の制限も大幅に緩和された。

机の上で実験したときの様子を動画にした。トラックパッドをどかすと、発信機からの赤外線が届いてタイムが計測される。

D

arduino側でセンサー入力値がゼロ付近の値であった場合に、millis()で取得したプログラムの累積実行時間を前回取得時と比較してラップタイムを算出、Raspberry Pi送信する。Raspberry Piは受信したラップタイムをespeakを使って読み上げる。

赤外線を受信した直後は、再受信を無視する処理やベストラップ通知などもあるけれど、概ねこれだけで実現できた。

声が機械的過ぎるのをもう少しどうにかしたい。Ingressのシステムボイスのようなアンニュイな感じで、できれば日本語にしたい。

日本語の場合、込み入った音声合成エンジンはRaspberry Pi上では動かせない事や、1分と1秒で1の読み方が違うことなどを考慮すると、リアルタイムに音声合成する方式ではなく

VOICEROID+ 結月ゆかり EX

VOICEROID+ 結月ゆかり EX

VOICEROID+ 結月ゆかり EX ダウンロード版 [ダウンロード]

VOICEROID+ 結月ゆかり EX ダウンロード版 [ダウンロード]

こんな感じのボイスロイド、もしくは本物の人間が、1から59分と1から59秒を別々に読み上げ、別の音声ファイルに録音したうえで、ラップタイムに合わせて連結して再生する方式のほうが自然なイントネーションが得られると予想する。


結局、この記事を書き終わる前に作ってしまった。

D

分と秒で別々に音声ファイルを作るのは予想通り面倒で、さらに小数点以下の値は、0から99まで必要なうえに、例えば21を「にじゅういち」ではなく「にーいち」と読ませたいので、100個分ルビを入力する必要があった。

実際に車両に取り付けて検証してみたところ、受信機の信号線を分岐させてArduinoのアナログ入力に入れているせいか、車両側のラップタイマーが誤作動する問題が起きて、解決できる気がしないので素直に車両とArduinoで別々の受信機を使うしか無さそう。

2016-04-29

富士ショートでステップ交換ほか

エビスのベストラップを更新できたものの、既に先が無い予感がする。

感触としてはフロントを上げる方向にタイムアップの余地が残っていそうで、フォークの突き出しは既にゼロだから、リアの車高を下げる事を試してみる。

ゴールデンウイークの初日にもかかわらず道路は思ったよりは混雑せず、コース上は予想通りの密度だけれど、検証作業なのでそれほど問題にならなかった。

S1000RRのノーマルのリアサスにはオーリンズのような車高調整機能は無いけれど、フレームへの取り付け部分のスリーブを反転させる事で2段階には調整できる。自分の2015モデルは、出荷状態では車高が高い方にセットしてあったので、リアを下げる余地は残っている。

リアサスの取り付けボルトを抜いてスリーブを反転させるには、ステップスタンドを使ってフレーム側で車体を持ち上げる必要があり、その為にはステップバーを固定式のものに交換する必要があり……まあとにかく苦労した。

リアを下げると富士ショートは走り難くなると予想出来るので、極端にタイムが悪化しなければ成功と考える。ベストタイムは確認できた範囲では32秒7。このバイクでのタイムとしては悪くない方なので問題無しと判断した。

減速時にリアタイヤがすっぽ抜けず、操縦の自由度が増えて楽しく走れるようにもなった。

メガネのカスタマイズ

走行中は上目遣いに前を見るので、レンズが視界から外れがちな問題を解決できた。

一番高い位置に設定すると走行中にレンズが視界の中央に入る。

サイズが大小あり、大きい方が男性用みたいなイメージで注文したら、思ったよりもかなり大きかった。

遠近両用メガネに装着して、頻繁にアジャストする本来の使い方では、Amazonレビューにもある通りすぐに壊れそうだけど、一番高い位置のみの使用なので耐久性も問題無いはず。

2016-04-26

マエダコ走行会、(新)自己ベスト更新 58秒5

前回に引き続きエビス東の自己ベストを更新。

D

サーキット走行をする方のブログyoutubeの走行動画のタイトルで、安易に「自己ベスト更新」みたいな文言を入れると、社内のファイルサーバーで散見される、

見積書2_new(修正).xls

こんなファイル名の如く、どれが最新なのか分からない状態になりがちなのを思い出した。

ベストラップが出た時のセッティングは、フロントのプリロードを足した以外は前回と同様。さらにペースを上げるとフロントが先に破綻しそうな感触だけど、これ以上少しでもプリロードやダンパーを足すと、タイヤが跳ねて遅くなる。リアサス取り付け部のスリーブを反転させてリアの車高を落とす選択肢は残っているので試してみても良いかも。


中古タイヤをホイールに装着すると、タイヤ単体で見た時よりも減って見える現象

逆履きさせれば30分位は使えそうに見えたタイヤが、意外と溝が残っておらず10分程度で終了。予想外に早く新品交換する羽目になり、結果良いタイムは出たものの、また微妙な減り具合のタイヤが生産されたのだった。

新品のタイヤを無慈悲に痛めつければ58秒台に入る事は分かったので、次はもう少し使用感のあるタイヤでもタイムを維持できるようにしたい。と思っていたところでマイナートラブル発生。

何もしてないのにブレーキが壊れた

という程ではないけれど自己ベスト更新以降の走行ではブレーキの遊びがランダムに変わる現象に悩まされる。

通常通り握り始めて直ぐに効く事もあれば、エアを噛んだ時のようにストロークの最初の2センチ位は反応が無い場合もある。

常に遊びが大きければ、それに合わせてブレーキを握れば良いけれど、遊びが大きい前提でブレーキを掛けて普通に効くと前転しそうだし、普通に効くつもりで反応が無いと心臓に悪い。

どちらに合わせてレバーを握るか、ブレーキングの度に丁半博打めいたライディングが必要で大変走り難い。少し気温が高めな事と、足回りのバランスが正常化されて強くブレーキを掛けるようになった事は大いに影響ありそう。

去年は起きなかった現象なので

原因はこの辺りか。とりえあずブレーキのフルードとパッドは注文した。


ビープ音でベストラップ更新お知らせメカ(仮)

http://d.hatena.ne.jp/kitaring/20160412/1461163659

実際に使ってみた。

現地で微調整する必要もなく最初から概ね期待通りの動作をしてくれた。時々緑ランプに反応していない事があるが、恐らくカメラを固定するステーが振動でブレて明後日の方向を撮影していると思われる。

特にデメリットは無く、画期的に便利という程では無いけど、ベストラップ更新中かどうかを視線を動かさずに知る事が出来て、どのタイミングで後れを取ったのかも分かるので、メーカーオプションにして欲しい位には便利。

ただ、得られるメリットに対して着脱作業が面倒過ぎる。事前にRaspberryPi本体とカメラユニットを支える為のステーを用意してきたものの、完全に固定するには、狭いカウルの隙間に手を突っ込んで、USBポート等を塞がずに、雑に扱うと抜けてしまうカメラユニットのケーブルにも無理な力を掛けないように、慎重にガムテープでグルグル巻きにする必要があって、尚且つ取り外す際にもケーブル等に注意しつつそれらを慎重に剥がす作業も発生する。

f:id:kitaring:20160426222901j:image

少なくともこの取り付け方法だと面倒過ぎてすぐに使わなくなりそう。


電源はこれを使用。

バッテリー直結なので、走行しない間は毎回手動でRaspberryPiのUSBケーブルを外す必要がある。そしてすぐに面倒になり、ピットインしてエンジンを停止している間もUSBケーブルを外さず、RaspberryPiの電源が入ったまま放置していたけど特に問題は起きなかった。

S1000RRアクセサリ電源コネクタの謎

(多分2015モデルから)車両左前方の、フロントのストロークセンサーを取り付けるコネクタと同じ辺りに、アクセサリ電源用のコネクタが存在する。車両の説明書によるとカーナビ(バイクナビ?)等の取り付けに用いるそうなのだけど、ネットで探してもこのコネクタに接続するアクセサリが見つからない。

ここに接続するUSBポートのようなものがあれば、恐らく車両のメインスイッチに連動して電源を入れる事が出来るはずで、本当はRaspberryPiの電源もここから取りたかったのだけど、必要な部品を発見できず。

ディーラーに問い合わせると、このコネクタドイツのなんとか規格(名前忘れた)に対応していて、本国には多少は対応するアクセサリーが存在するらしい。あとディーラーでコンピューターの設定を変えないと電気が来ない仕組み(要確認)かもしれない。との事。


また、下記の海外フォーラムでは、

purple wire is constant power-all the time

brown wire is ground

Red wire is switched power

http://www.s1000rrforum.com/forum/new-members-must-start-here/133769-aux-power-supply-3.html#post1288105

このように書かれていたので、実際にテスターで測ってみたところ、

自分の車両の場合*1は、紫と赤のケーブルどちらも車両のスイッチに連動して電気が流れる様子。紫の方も車両の電源がオフの場合は電気が来ない。

赤の方はエンジンを始動して、回転数を上げるとある程度連動して電圧が上がる様子。紫の方はエンジンの状態とは無関係に常に9V強の電気が来る。

ピッタリなコネクタは見つからないけど、自分で配線を頑張れば車両の電源と連動したUSBコネクタを作れるかも。

*1:レースECUなのでこのコネクタも設定が変わっている可能性はある

2016-04-14

エビス東 自己ベスト更新 58秒85

気温が10度前後で風が強い中、スポーツ走行枠を走る。フロントフォークの突き出し量をしつこく調整した甲斐があり、エビスの自己ベストを少し更新(結局突き出し量はゼロに落ち着いた)

D

※最後のカットでピーピー言ってるのは、一つ前の記事で書いた開発中のシステム……という程大袈裟な物では無いけど、ベストラップ更新を音で教えてくれるマシン。

このバイクは電気のサスペンションが前後水平に保とうと頑張るせいか、剛性の高いフロントタイヤには対しては必要な加重が出来ずに相性が悪い*1けれど、グニャグニャしがちなピレリのタイヤに対しては、過加重を防ぐ方向で上手く機能するのかも。


走行モードDDCの動作モードCompressionReboundコメント
RainRoad145%60%使用せず
SportRoad245%60%自己ベスト更新
RaceDynamic45%60%使用せず
SlickTrack45%60%ダンパーさん頑張り過ぎ

※フォークの突き出し量ゼロ

このようなDDCの設定で走行して、ベストラップはSportモードの時の58秒85。去年ダンロップを使っていた時のどうにか59秒台状態と同程度の労力で58秒台に入るので良いバランスだと思う。

あまり多くは試せなかったけれど、Sportsの設定は自然で普通のサスペンションっぽい。Slickの設定は、相変わらずストロークの最後の方で急に頑張りだす感じ。

とはいえ、まずサスがフルボトムした状態での車体の姿勢、フォークの突き出し量やリアの車高に対してある程度は納得行く状態でないと、ダンパーの設定に拘ってみても気休めにしかならず、逆に前後の車高やバランスが妥当であれば、躊躇無くフルボトムさせられるので、その過程で少々ダンパーの動きが気に入らなくてもそれほど困らない。という何度目かの教訓を得た。


最近のピレリは寒さに強い?

昔のSC1のピレリ(V2になる前)をこの日のような寒さの中で使ったら、コンパウンドが千切れるような現象で新品タイヤが20分弱でゴミに変化した悲しい記憶があるのだけど、今年は気温一桁か、ギリギリ二桁位の中でSC1で数回走行していて、タイヤ本来のパフォーマンスは発揮していないにせよ、酷いアブレーションでゴミ化する事は無かった。今のピレリは寒さに対してそこまで神経質にならなくても良いのかも。

ただ、それでもこのコースリアタイヤに厳しいので、新品のSC1で2本走行すると、右サイドほぼ終了で左サイドがバリ山の、中古として売るには使用感あり過ぎ、逆履きして使うにもやや手遅れ間のある微妙なタイヤが出来上がるのだった。トラクションコントロールを多めに効かせればタイヤを節約できるのではないかと試してみた(-3に設定)けれどあまり意味は無い様子。その代わりに、このモデル(のレースキャリブレーションキット3の初期値の)トラコンは意外と使えるかも。少なくともあからさまに邪魔とは感じない事を発見。



メガネ再び

以前にも少し試してみて、その時は効果がイマイチ実感できずに、すぐに止めてしまった。

日常生活には困らないものの、健康診断での視力検査の結果にショックを受けたり、月が三つに見えたり、他にも薦めてくれるライダーの方もいたので、今度は近所の眼鏡市場でちゃんとスポーツ用のメガネを購入して使ってみた。

http://www.meganeichiba.jp/brand/i_athlete/lineup/index.html#ia408

上側にだけフレームがあるタイプを購入。

以前に試した、乱視を調整するだけの物ではなくて、今度は遠くが良く見えるタイプなのでさすがに違いが分る。コーナーの縁石が二重に見える事も無くなった。

ただ、眼鏡を付けて走って一旦ピットインした後に、眼鏡を忘れて再度走っても、あまり違いが感じられないのが不可解。この日にベストラップを更新したのも眼鏡を忘れた時だった。

しかし長時間走って疲労した状態では確実に眼鏡がある方が楽に思える。あと、こんな事は眼鏡歴の長いライダーの人には当たり前なのだろうけど、サーキット走行で使う場合は、普通に真っすぐ眼鏡を掛けると、走行中は上目遣いで見る事が多いから、レンズの位置が低すぎて使えず、おでこに眼鏡を掛けるつもりで位置を決めると丁度良い感じ。

フレームを選ぶに当たって、なるべく視界の邪魔にならないタイプ、しかしフレーム無しで左右で支える2ポイントのは、すぐに壊れそうなので除外。という理由で上側のみフレームがあるタイプを選んだけれど、やはり時々は視界に入って邪魔に感じる事もある。

フィクションでは頻繁に見掛けるものの、現実世界で使っている人は見た事が無い、フレームが下側だけの眼鏡がバイクには向いているのかも。


ラップタイマーが調子悪い

発信機の前を通過しても反応しない事が多く、2周に1回位しか計測できずに不便。原因が赤外線の発信機なのか、受信機なのかバッテリーなのか判断が難しい。

GPSで検知する、このラップトリガーにしてしまおうか考え中。

http://2d-datarecording.com/Downloads/Manuals/GPS-Laptrigger_manual_BMW.pdf

現在使っている標準オプション赤外線受信機の代わりにコネクタに刺すと、同じようにS1000RRのメーターパネルにラップタイムを表示してくれる。メジャーなサーキットはスタート/フィニッシュラインの位置情報が登録済みで何もしなくても使える。

登録サーキットは、その場所でボタンを押して位置を記録する仕様。

登録済みの日本のサーキットとして茂木や鈴鹿や筑波辺りは予想通りとして、間瀬や本庄、日光サーキットまで登録済み。エビスは何故か南コース登録してある。バイクはまず走らないと思うけど、ドリフトで有名だからか。

*1:去年はこれに対応しようとしてフロントの車高が極端な事になってた

2016-04-12

ビープ音でベストラップ更新お知らせメカ(仮)を開発中


経緯はこう。

http://shop.alpharacing.com/shop/index.php?main_page=product_cvs_info&cPath=533_541_597&products_id=9599&sort=20a&language=en

http://shop.alpharacing.com/shop/index.php?main_page=product_cvs_info&cPath=533_541_597&products_id=9601&cPath=533_541_597&sort=20a&

S1000RRには、上記の赤外線発信機とレシーバーを使う事でダッシュボードの液晶部分にラップタイムを表示する機能が最初から備わっている。大変便利であるものの、R1やパニガーレのようなフルカラーではなく、20世紀の腕時計みたいな液晶の視認性はイマイチで、走行中にある程度頑張って覗き込まないと読み取れない。自分が頻繁に行くようなストレートが短いコースでは、タイムアタック中に正確なラップタイムを確認するのが困難な時もあり若干不便に思っていた。

http://rs-primo.com/movie.html

それで最近SNSの広告で流れてきたレーシングシミュレータのお店(使用ソフトはnFactor)の、この動画中のフィニッシュラインを通過する際にラップタイムを音声で通知してくれる機能、これがバイクに付いていたら便利そうと思い付く。

ちなみにこのお店には、先日実際に行ってみた。

nFactorは言ってしまえば普通のPC用のゲームソフトなので、動かすだけなら自宅でも遊べるのだけど、本格的なハンドルコントローラやペダルに3画面のモニタ、業務用?のシミュレータっぽく動く椅子。等々、ハードウェアについては一般家庭ではまず再現不可能なレベルでコストが掛かっている。

コースはエビスを含む日本のローカルなコース(nFactorのModと思われる)も多数あって、コースModの出来次第と思われるが、自分達が試したエビス東については、中々の再現度であった。基本的に4輪のドライバーが対象だし、殆どの人にとってはマリオカートの方が楽しいだろうけど、4輪も2輪も同じロジックで運転するタイプの人はバイクで速く走る参考にもなるかも。個人的には第一ヘアピンに進入する際に斜めに滑り降りる感覚がバイクそっくりだった。

とにかくこのnFactorのように、ラップタイムを音声通知してくれる機能を作れないかというアイデアがあったところ、良いタイミングでTakadamaさんにarduinoRaspberry Piの事を教えてもらう。

Arduinoをはじめようキット

Arduinoをはじめようキット

Raspberry Pi 3 Model B (Element14)

Raspberry Pi 3 Model B (Element14)

電子工作は自分に縁のないものという認識でいたけれど、確かにこれらを用いれば実現できそうに思えたので、最近発売されたばかりのRaspberry Pi3を購入。大きさはタバコの箱位なのに想像以上に普通のLinuxのPCだった。

同時に購入したブレッドボードジャンパーワイヤを使って、各種サイトを参照しつつお約束のLチカ等を試し、GPIOを使って赤外線レシーバーの信号を取得すれば目当ての機能が作れそうな事を理解した。

前述のAlphaRacingが販売している赤外線レシーバーの仕様は公開されていないものの、恐らく2Dのこの製品と同じと想像する。SD-LR02C-000の方と受信機の見た目は同じで、接続コネクタの形状だけが違う。

http://www.2d-datarecording.com/Downloads/Datasheets/Sensors-digital/Pdf/SD-LR02x-000-DINA4.pdf

実際にレシーバーRaspberry Piの5Vの出力、あるいは12Vのバッテリーに繋いだ状態で、信号線と思われるコネクタのピンにテスターを当てると、通常時は電流が流れていて赤外線の発信機に向けると一瞬だけゼロVに近くなる。上記のPDFの2ページ目にある

Output level active............... 0 V

not active..... 5 V

この挙動と思われる。

ただ、赤外線を受信していない時の電圧がPDFにあるように5Vで一定ではなく、結構な範囲で上下する。

PDFの製品と同じ物では無いから、この製品独自の仕様なのか、それとも自分の測り方が正しくないのか、もしくは電源がバッテリー直結ではダメで安定化電源のような物が必要なのか、自分のスキルと知識では判断が付かないのだった。

もしくは、車両側の専用コネクタから電源を取っている、つまり通常の使用状況であれば、電圧は安定しているのかもしれないけれど、それを確認する方法がちょっと思いつかない。

発信機の赤外線を当てた際に、一瞬電圧がゼロになる事だけは間違い無さそうだけれど、Raspberry PiのGPIOは、デジタル入力にのみに対応していて、電圧が激しく上下するような場合は、検知できないか最悪故障すると思われる。

対応方法を調べると、こういう時は電圧が変化するアナログ信号をデジタルに変換するチップを使うとの事なので、その為のチップを秋月電子で入手して、ゼロVと3.3Vで二値化する回路に挑戦したものの……この辺りが自分の工作スキルや知識の限界のようで、なんかダメっぽい。でも何がダメなのかサッパリわかりません。というYahoo知恵袋めいたフレーズしか出て来ないのだった。

このまま配線やテスターを弄り回していても解決せずに破壊するイメージしか浮かばないので、路線変更してCPUパワーで解決してみる事にした。Raspberry Piを使う意味があまり無い気もするけど、遊びなのでまずは手っ取り早く成果物と達成感が欲しい。

具体的にはバイクのメータパーネルに表示されるラップタイムをRaspberry Piのカメラユニット、もしくはUSB接続のカメラで撮影。パターンマッチングで数字を識別して読み上げる仕様を考えて途中まで実装。

しかし下記の問題により断念


  • メーターパネルの表面に色々な物が反射するので、ノイズが多過ぎて液晶の表示内容だけを抽出するのが困難。出来たとしても条件が限定され過ぎて、少しでも光の強さや角度が変わると破綻する。
  • ラップタイムとして表示される6桁の数字について、予め用意した0から9までのテンプレート画像とマッチングさせる単純な実装とした場合、映像の1フレーム毎に60回のパターンマッチングが必要。そこまでのリアルタイム性は求めないとしても、少なくともRaspberry Piのパワーではまともに動かない。単純な実装方法だと1フレーム毎に10秒程度の処理時間が掛かってしまう。
  • パターンマッチングのテンプレートとして用いる、0から9までの数字の画像を用意するのが大変過ぎる。7セグメントのデジタル数字のフォントは多数公開されているので、これらを使って作成した数字の画像をテンプレートとしてみたものの、実車のメータに表示される数字とは縦横比が異なる為(実車のはかなり横長である)か全くマッチせず。実車のメーターを直接撮影した画像から切り出した数字であれば認識するものの、角度の変化に対してシビア過ぎて、カメラの設置位置が変わると役に立たなくなる。
  • バイクのダッシュボード周辺が狭すぎ問題。一つ前の項目にも関連するけれど、USB接続の小さなWEBカメラであっても、ラップタイムの表示欄を真正面から撮影できる位置に設置するのが困難。以外とスペースが無い。ハンドルを切ると何かに干渉したり、ブレーキのリザーバータンクに遮られたり。設置位置を妥協して斜めから撮影する場合は、テンプレートとして使用する画像も同じく斜めのアングルから映す必要があり、尚且つ、近くの桁と遠くに表示される桁の数字とで見え方が変わるので、桁毎にテンプレート画像を別々に、つまり60枚用意する必要がありそう。しかもカメラの位置が変わると全て作り直し。
  • UI周りを作るのも、それを現地で操作するのも面倒過ぎる。まずカメラで撮影する映像のどの範囲がラップタイムの表示欄なのか、そしてどの部分が何桁目なのかを指定する必要がある。矩形で選択した範囲を単純に6分割して、それぞれの枠に数字が収まるようにドラッグして位置を調整するUIを作ってみたものの、前述の通りカメラを真正面に設置する事は出来ず、斜めから映す形になる為、遠くにある桁の数字ほど小さく映り、単純に6等分して収めるのは難しい。桁毎に個別にサイズ変更できるようなUIを作ったとして、そんなチマチマした操作を現地でやりたくない。

もう一度考えを整理。

走行中の関心毎は、ラップタイムの数字そのものよりも、自己ベストに対して速いのか遅いのかの方が優先度が高い。

それを知る為の便利な機能がS1000RRのメーターパネルには既に存在していて、既存のベストラップよりも速く走れている(とタイヤの回転数等から推測される)間は、メーターパネル左側の緑のランプが点灯する。このランプを撮影して、点灯状態を音で通知するだけの仕様ならば実現可能性が高そう。

このランプについては、ラップタイム表示よりはずっと見易い位置にあって、全力で走っている時でも横目で確認できるのだけど、さすがにずっと眺め続けている事は出来ないから、音でリアルタイム通知するメリットはあるはず。

  1. カメラで撮影する映像に対して、緑ランプが存在する座標範囲を予め指定しておく(矩形で選択)
  2. 指定範囲を切り取り、RGBHSV変換後に二値化して緑色部分だけを抽出
  3. 緑色の面積が一定値以上であればビープ音を鳴らす

という比較的シンプルなロジックで実現出来た。

RaspberryPiのパワーでも十分にリアルタイム処理可能で、画像の一部切り出しや二値化、面積の算出等の実装についてはOpenCVとそのチュートリアル的な内容そのままに関数を使うだけで完成。

しかもこの方法ならば開発中は実車が近くになくても、映像の入力をカメラから既存の車載映像に切り替えるだけで動作確認できる。RaspberryPiの実機を使う必要も無く、とりあえずMacbookと先日の車載映像で検証した様子を、次の記事に貼った映像の最後のカットに入れた。

f:id:kitaring:20160420232053p:image

緑の矩形で選択した範囲から緑ランプを検出する

f:id:kitaring:20160420232051p:image

ランプの点灯を検出するとビープ音を鳴らす(走行中はBluetoothイヤホンで確認)運用時はモニタに接続しないけれど、動作確認用に黄色の円を描画する。左上の数字は緑色として検出したピクセル

f:id:kitaring:20160420232052p:image

テストモード、二値化して緑色部分だけを抽出して(白色として)出力した状態。誤検出が多い時はパラメータを調整してこの画面で確認する


カメラを使ったテストもカメラ付きのノートPCや、WEBカメラの接続したPCでプログラムを起動して、何か緑色の物を映してみる事で確認可能。実車とRaspberryPiとカメラユニットの組み合わせでも正しくランプを認識できる事もテスト済み。設置場所を決めるのにとても苦労した話はまた今度書くかも。

実車のメータについては、対象とする緑色のランプの周辺に似たような色の物体は存在しないので、映像の範囲指定も二値化の際のパラメータも大雑把で大丈夫な様子。これなら疲れていたり暑かったり寒かったり風が強かったりする現地の環境でも、それほど消耗せずに作業できるはず

初めて使った Python3とOpenCV3については特筆すべき事はあまり無くて(基本的な事しかしていないので)、それよりも、Bluetoothイヤホンの接続*1とか、時間経過で突然音が出なくなり、RaspberryPi3の本体を再起動するまで復旧しない問題等に数日間悩まされた*2

*1:検索で見つかるRaspberryPi2の情報が使えない事も多い

*2Bluetoothサスペンドしているのだろうと考え、試行錯誤するものの、全く関係無かったようで、開発中にWindowsからリモートデスクトップ接続している場合のみ発生する事を確認。直接の原因は判然としないけれど、HTDMIでモニタに直接接続する場合には再現しない事が確認できたので解決とする

1993 | 01 |
2001 | 09 |
2002 | 07 | 10 |
2003 | 05 | 07 | 08 | 09 | 10 | 11 | 12 |
2004 | 04 | 05 | 07 | 08 | 09 | 10 | 12 |
2005 | 02 | 03 | 05 | 07 | 09 | 11 |
2006 | 03 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 10 | 11 | 12 |
2011 | 01 | 03 | 06 | 09 | 10 | 12 |
2012 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 |
2013 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2014 | 04 | 05 | 06 | 07 | 09 | 10 | 11 |
2015 | 01 | 02 | 03 | 04 | 05 | 06 | 09 | 10 |
2016 | 02 | 03 | 04 | 05 |