自作電子小物/開発情報/HA7車両情報データロガー/iPhone版0.4
自作電子小物/開発情報/HA7車両情報データロガー/iPhone版0.4
HA7 logger mini V0.4
2013年5月7日火曜日
スマートフォンとOBDを利用した車両運転情報記録システム。
目 次
1 大まかな設計
1.1 目標とするもの
1.2 全体構成
2 詳しい設計
2.1 スマートフォン部
2.2 接続アダプタ部
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
1 大まかな設計
大体の小物のイメージを固めて行きます。
1.1 目標とするもの
節約運転を行う為の情報を表示し、後で詳細な解析を行えるよう常に情報を記録し続ける、3000円以下の安価な小物を目指します。これは、前回小物V0.3と方向性は同じですが、画面の視認性の改善と、より安楽に無理のない行動が出来る様なものを目指します。
(1)節約運転とは
燃費:走行効率を追求し、相対的な使用量を減らす
燃費を上げる為の運転テクニックを自ら発見する
アイドリング停止は効果が大きいのか? → アイドリング率
短にエンジン回転数を低めにすれば良いのか軽く回す方が良い結果が得られるのか? → 瞬間燃費、平均RPM
スピードを上げて短時間で目的地に着くのが良いのか、経済的な速度はあるのか? → 区間燃費、平均速度
車重によって、どの位違うのか → 区間燃費、車重
通ったルートによって、どの位違うのか → 区間燃費、位置情報(GPS)
荷台カバーの有無など、その他の条件でどの程度違う物か → 区間燃費
絶対量:使用量を常時認知する事で、有意義な車の使用を考え直し、絶対的な使用量を減らす
これまでは、給油間隔や、車両のメータパネルについている燃料残量計の減り具合を見たりして、
使う量を把握していました。これでは見直しサイクルは長すぎるし、荒すぎます。
一番多くガソリンを使う行動は?→まず絶対量が大きいものから目を付けるのが常套手段
1回の乗車単位での使用燃料量→100円安い買い物をするのに、それ以上の燃料を使っているのか?
必要な情報を整理すると下記の通り
・瞬間燃費
・区間燃費
・総平均燃費
・車速
・エンジン回転数
・区間使用燃料量
・日別使用燃料量
・区間走行距離
・走行率
・車重
・広域絶対位置
最適化すると
記憶単位:一定時間間隔(n秒単位)
データ項目:
・日時
・燃料使用量(流量)
・移動距離もしくは車速
・エンジン回転数
・車重 →後に断念
・ 広域絶対位置
上記が必要最低限の情報と言う事で、このデータを処理する事により、必要な情報を導きだせる。
なお、区間の定義は利便性から考えて「日単位」で良いと思われます。
(2)小物の使用感について
基本的には、PCに頼らず小物単体で機能が完結する方が良いと思います。ただ、詳細な事を知りたくなった時の、外部へのデータ出力が可能な手段を残していければ、なお良いと考えます。
実際、以前のバージョン「V0.3」を長期的に使用してみて、通常は瞬間燃費と目標燃費との差が判るだけでも十分楽しいと思いましたし、詳細なデータは蓄積しているので後で何でも出来るという安心感があるだけで、PCで集計するのは面倒なので結局何もしないのが現実でした。本当は、日別推移ぐらいは見てみたいなあと思っていました。
そこで、基本的には前回バージョンの画面拡大をメインに、若干のデータ集計画面を用意するという「小物」にしたいと思います。
1.2 全体構成
(1)センサ
燃費を得る為の情報源は、大部分をOBD2コネクタから取得。不足する情報があれば、別途センサを用意します。
以前のバージョンでOBDからは十分な情報が得られるので、追加のセンサは不要と解っています。ただし、HA7はISO9141-2でのインタフェースとなるため、転送速度10.4kbpsと大変緩やかですので、変化率の大きい項目では、精度は期待出来ませんが、所詮目安程度のものなので、良しと考えます。
ただし、「車重」については、安価な解決策を見つけられておりませんので、とりあえず棚上げと致します。
位置情報に付いては、GPSを利用する事を仮に想定します。
(2)表示
運転中も確認する事になるため、運転の妨げになりにくい方法で情報伝達する必要が有ります。
・ヘッドアップディスプレイ 理想的、先行車位の距離に焦点を合わせる、光学系が大掛かりになる
・メータパネル付近 無難な方法
・ルームミラー付近 メータパネル同様だが意外と確認しづらい
・音声通知 何らかのアクションをしたら音声で読み上げる、情報量が少ない
・ヘッドマウントディスプレイ 運転の度に装着するのは現実的か?
HUDについては、継続して色々試行錯誤している最中ですが、満足行けるものにならないので、今回はパスと言う事にします。
そうすると、やはり無難にメータパネルと並べて表示パネルを設置する方法となります。前回にバージョンで使用した小型表示装置は2インチ弱と、老眼の始まった私の目には視認性が悪いものとなりました。今回は、3〜4インチ程度のディスプレイ装置を選択する必要があります。
5項目程度を、このサイズで表示するには、入手しやすい部品から、
・7セグメントLEDクラスタ
・LCDモジュール
となると思われます。7セグメントでは、手持ちの引き出しでは4桁×2行(500円)×3個で1500円程度、LCDモジュールは値段差、入手性のバラツキがありますが、3000円程度は掛かりそうです。ただ、LCDモジュールは、グラフ表示等、表現の自由度が高いので、多少高くても使いたいと思います。
(3)記録と転送
一時蓄積して、後でまとめてデータ転送する形態で考えます。常時転送では、この小物本来の目的から外れます。
まずは転送から方式を考えてみました。
・無線転送
理想的には、帰宅したら自動的に無線でデータをネットワーク上のストレージに送り込む方法が良いですが、コスト見合いです。無線は電波強度の測定等、開発機材を用意しなければならないので、かなり敷居が高いです。やはり無線モジュールを使う方法になりますし、最終的には認定試験の費用も発生するので、まだコスト的に選択出来ない状況に有ります。しかし、この所、USBドングル形のWiFi、Bluetoothアダプタがモジュールと同じ位の価格で、それも入手性が良く、電波法の面倒さも回避できるので、自作を行う者にとっては注目すべきデバイスです。
・USB接続
小物を持ち出ししてPCに接続するか、PCを車内に持ち込みUSBケーブルを接続して、データを吸い出す方法です。あまりハンドリングが良いとは思えないです。
・赤外線接続
結局、USB接続と同じ問題があります。また、転送速度を上げると一気にコストが上昇するので、なお不利です。
・記録メディア渡し
データを転送するのではなく、メモリカード等のメディアに蓄積しておき、それを取り外してPCに持って行く方法です。コストも問題有りません。特にSDカードはコストパフォーマンスに優れています。また、メディアを交換すれば、無限にデータ収集を続ける事も出来ます。消さない限りデータのバックアップともなります。
予想されるデータ容量は、1日2時間乗るとして1年間では
2時間×60×60×80バイト/2秒間隔×365日=101MB
ですので、現在市販されているSDカードでは、10年以上のデータを取れる事になります。
所で、転送先をPC前提で考えていましたが、PCと携帯電話の中間的な位置づけにあるスマートフォンを利用する事考えた場合、幾つかのメリットがあります。もちろん、スマートフォンを所持しているという前提です。
・丸ごと、スマートフォンのリソースを利用できる(画面、入力、恒久メモリ、センサ、通信、CPUパワー...)
・スマートフォンは、開発環境が充実しており、高度なソフトウエアを構築できる
・接近した時に何かするというアプリケーションに対応できる
この、恩恵を受けるには、小物にはスマートフォンとの通信インタフェースが必要です。おおむね、以下の様なインタフェースが用意されています。
・USB
・Bluetooth
・WiFi
・赤外線
究極の利便性を求めるのであれば、無線接続なのでしょうが、今まで電波法の壁に阻まれ諦めていました。ここで、思い切ってUSB無線ドングルが利用できる様になれば、これから製作するであろう「小物」も考え易くなるだろうと思い、無線USBドングルを使う検討を行います。現在、入手容易なのはWiFiかBluetoothですが、WiFiはアクセスポイントを別途用意する必要があり(無くても不可能ではないのですが設定が面倒)、使いにくい面があります。そこで、Bluetoothでの接続で考えます。
これで、画面、データ蓄積、位置情報(GPS)取得、PC連携などについて、ハードウエア面の事は考えなくともよくなります。
(4)構成図
簡単に言うと、スマートフォンを持って運転すれば、自動的にデータが蓄積されているという感じになります。
アクティトラックにOBD-Bluetooth接続アダプタを取り付けておきます。エンジンが始動して、OBDからデータが取得できる様になったら、Bluetoothで通信できる相手を探し、そのデータを送りつけます。
スマートフォン側は、予めアプリケーションを起動しておき(バックグラウンド)、 常時Bluetoothの通信相手を探すようにしておきます。これで運転席でエンジンをかければ、Bluetoothの通信リンクが確立するはずですので、送られてくるデータを処理して燃費計算、データ蓄積を行います。
車両との接続部分のみハードウエアを作り込み、ほとんどの部分をスマートフォン、手持ちの関係でiPhone5上でデータ処理します。接続アダプタは、あくまでも中継装置として考え、記録や計算処理を一切行わないようにし、低コストの部品で済む様にします。この方式だと、走行時には常にスマートフォンを携行する必要がありますが、本来携帯電話ですから、特に不自然な事ではないと思います。ただ、携行していなかった場合、その分の走行記録が抜けてしまうのがデメリットです。
2 詳しい設計
実際作成出来る所まで設計を進めます。
2.1 スマートフォン部
(1)Bluetooth通信インタフェース
Bluetooth規格はOBDに負けない位、色々なプロトコルの固まりで、非常に理解しづらいものがあります。また、iPhoneのiOSでの実装方法も少し判りにくいように感じます。解説は長くなるので省略させて頂き、BluetoothをiOSユーザアプリケーションで使うには、
・External AccessoryやGameKitフレームワークを使用
・Bluetooth4.0LE(LowEnergy, BLE)のみに対応するCoreBluetoothフレームワークを使用
の2つの方法があります。
External Accessoryを使用するにはAppleと個別契約(MFi)を結ぶ必要があり、公開できない情報が出来てしまう事から、私の活動としては使えないと判断しました。これを納得するのに結構時間がかかりました。インターネット上を探すと、解析されている方の情報も見つけられましたが、Appleの意思にそぐわないと思い、利用しない事にしました。
CoreBluetoothは、Bluetooth4.0規格から登場したAttribute protocolを使う通信をサポートするフレームワークです。SSP(RFCOMM)などの従来のBluetoothの機能は利用出来ません。MFiは不要です。アプリケーションプログラムからの見え方は至極簡単で、キー(UUID)に対して値を得る、もしくは値を書込むというもので、通信と言う感じではありません。今回は、OBDのデータ項目毎にキーを割当て、データが発生するたびに値を変更、つまり送信し、値が変更されたら受信されたという形になりますので、簡単な処理で車両データを取得可能だと思われます。
なぜ従来のBluetooth(クラッシクBT)はiOSで使えないか?使えない訳ではないのですが、前述の通り従来のBluetoothのAPIはMFi契約を交わさないと情報開示してくれないため、個人的な開発では資金的に無理がある為です。第三者への情報制限も当然あるでしょうから、電子工作ファン間での人柱で済む話でもありません。iOSはOSXと同じ部分が多いので何とか出来そうな気もしますが、不毛な世界と思えるのでパスです。
(2)時刻情報
スマートフォンを使う条件では、携帯電話網やインターネット上の時刻同期に仕組みをそのまま利用できます。全く、意識する必要がありません。
(3)広域絶対位置情報(GPS)
iOSではCoreLocationで簡単にGPS情報を取得可能。バッテリ消耗が大きいと言う懸念があるが、ドライブナビゲーションアプリケーションが実用されている事実がある事から問題にならないレベルであると思われる。実際の使用で確認するしかない。
(4)UI
車載画面としては小さいですが、必要最低限の表示は可能。特に問題なし。
(5)データ保存
iOS管理のストレージをそのまま利用します。スマートフォンとしては、大したデータ量ではありません。
1レコード100バイトとして、1日平均2時間の運転とした場合、1年間では
100バイト×3600秒×2時間×365日×分割損1割=290MB
10年では約3GBなので、購入するiPhoneのモデルと、自分の利用方法を良く考える必要があるかも知れませんが、納得できるレベルだと思います。
何とiOSでは、データの自動バックアップという恩恵にもあずかれます。
(6)データ外部出力
iTune - iPhone間の標準データ連携の仕組み「App共有ファイル」を利用する事で、新たにアプリケーションプログラムを用意しなくとも、データファイルの入出力が可能。また、削除などのデータ整理も、この画面上で出来る。
(7)電源
バッテリ駆動を基本とします。想定しているのは、長時間運行の運転ではないので、1日程度であれば外部電源の供給は不要と考えます。家に帰って充電すればOKですし、別途車両用の電源ケーブルを用意しても良いでしょう。
2. 2 接続アダプタ部
(1)車両情報 - OBD2 ...V0.3と同じ
HA7はハードウエアインタフェースとしてはK-Lineとなります。L-Lineは使われていません。0V〜バッテリ電圧の振幅、シングルエンド10.4kbps調歩同期シリアル信号ですので、ロジック回路の信号レベルに変換してしまえば、通信は出来ます。
はバッテリ電圧の振幅をロジックレベルに変換する必要があります。まずは分圧抵抗で単純に減圧する方法を考えてみます。ロジック部の電源を3.3Vと仮定し、中間の1.6Vをしきい値と考え、K-Line上のしきい値12V/2=6Vとの倍率は1.6V:6V=0.27倍となりますので、だいたい1/3になる様な定数の抵抗で分圧すれば良い事になります。
実際はもう少し複雑で、しきい値には上限下限がありますし、バッテリ電圧も変動しますので、最悪パターンでは機能しないかもしれません。
HIGHレベル:ロジックが2.0V以上、K-Lineがバッテリ電圧下限11V×70%=7.7Vと設定 2.0V:7.7V = 0.26倍以上
LOWレベル:ロジックが1.0V以下、K-Lineがバッテリ電圧上限15V×30%=4.5Vと設定 1.0V:4.5V = 0.22倍以下
(K-Lineのしきい値割合はISO9141-2規格値)
やっぱり、最悪ケースではダメでした。とは言え、悪いケースが2つ重なると言うのはあまりないですし、全くかけ離れた数字でもないので、この分圧方式でほぼ問題はないと思われます。実際、以前のバージョンで既に3.3Vへの変換回路は実証出来てはいます。
抵抗値は、この倍率前後になるように、手持ちの中から組み合わせただけです。ただし、全体の抵抗値自体が小さいと、常時流れる電流が増えますので、大きめの抵抗値にしなければなりません。また、大きすぎるとロジック回路側の影響を受け易くなりますので極端に大きくは出来ません。マイコンで受ける場合はせいぜい100kΩ位が限度かなと思っています。(本当は良く確認しなければなりませんが省略しました)
送信側
は、ISO9141-2規格で510Ω(±5%)プルアップする事になっており、アイドル状態でロジックHIGH=1になり、ロジックLOW=0時には、スイッチで接地する事によって電圧を下げるモデルが示されています。これも、単純にスイッチの代わりトランジスタでオン/オフする方法で考えてみます。プルアップ抵抗が有りますので、LOW時には大体12V/510Ω=23mA程ですので、少なくともその2倍程度の電流を流せる様にしておく必要が有ります。この程度なら、汎用の小信号用トランジスタが使えますので単純に済みます。しかしながら、ISO9141-2では最大2Aと指定されております。よって、本当ならば大きいIcのトランジスタを要しますが、逆に単なるシリアル通信部分に2Aも流れるのは不条理と考え、壊れて本望、入手容易な2SC1815を選択する事にしました。ベース抵抗の計算は、
コレクタ電流を100mA、hFE=300と設定し、ベース電流を0.33mA以上流せば良いと考えました。実際の計算は(3.3V-0.6V)/0.33mA=9.1kΩとなります。(0.6Vはデータシート上のVBEですが、大体こんなもんです)
マイクロコントローラから出力される、Tx信号は正論理なので、ベースにそのまま与えると反転してしまいます。信号を反転するには、
・マイクロコントローラ側に反転機能があればそれを利用する → 使えれば最善の策
・もう一段トランジスタをかませて反転させる → 必要なトランジスタ数が倍になる
・PNP型トランジスタを使う回路で考える → この構成の場合無理?
今回は、大したコストアップではないためもう一段トランジスタをかませる方法にします。
送受信手順
は、初期化フェーズで5bpsでの送信と、10.4kbpsという中途半端な速度での通信となりますので、マイコンの選定には注意を要します。とは言え、大部分のマイコンでは転送速度は自由に設定出来ますし、5bpsというもの凄く遅い送信も、ソフトウエアで生成してしまう方法を使えます。
(2)バッテリ電圧計測 ...V0.3と同じ
マイコン内蔵のA/Dコンバータを使いますが、基準電圧(電源電圧)より高い電圧を計測するには、電圧変換が必要となります。通常は、分圧抵抗式を使用しますが、今回はK-Lineの受信用のレベル変換回路が分圧抵抗構成になっていますので、これを流用します。アイドル時のK-Lineはバッテリ電圧となりますので、このタイミングで受信ポートのアナログ電圧値を計測し、分圧抵抗比で割れば、バッテリ電圧を取得出来る算段です。
しかし、測定可能な最大電圧に縛りが出て来ます。目的が異なりますので、仕方のない事だとは思いますが、同じ様な回路を2セット作るのは、かなり抵抗が有ります。
そこで、電圧測定の仕様を少し我慢して、最大15V位とする事にしました。
実際は、手持ちの抵抗の関係で、180kΩ+47kΩの組み合わせで0.207倍とし、A/Dコンバータの基準電圧3.3V÷0.207=15.9Vとなっています。
倍率が、LOW側に振った設定値となっていますが、これで問題ないのでしょうか?近くにプルアップ抵抗が配置されていますので、HIGH側に引込まれ易いと考えると、あまり良い方法ではないです。この辺は、要改善点として残ります。
(3)Bluetooth通信インタフェース
スマートフォン側の制約で、Bluetooth-LE(BLE)対応にしなければなりません。
Bluetooth部品選択
入手可能部品
・Bluetooth-LEモジュール(UART接続)
インターネットで丹念に探すと、1000〜5000円程度で幾つか入手できるモジュールがある
モジュールなので最終的には電波法での認可が必要なので多くの費用を要する
・Bluetooth-LE USBドングル(USBデバイス)
PC用のBLE対応USBドングルも1500円程度の安価で入手可能
USBホスト機能を持ったマイクロコントローラが必要
・Bluetooth-LE機能を内蔵したマイクロコントローラ
本来なら、この形態がベストであるが、現状個人開発ではコスト大
最終的には電波法での認可が必要なので多くの費用を要する
選択肢はUSBドングルしかないと考えました。
サポートソフトウエアライブラリ
USBをサポートするソフトウエアライブラリは、通常メーカからUSBホスト機能が提供されているので問題ありません。しかしながら、Bluetooth-LE対応で、自由に使えるライブラリは残念ながら見つけられませんでした。
そこで、Bluetooth-LEのソフトウエアスタックを自力開発する事にしました。結果的には何とか完成しましたが、とても原価(時間)のかかった作業になり、この時この判断は失敗だったかもしれません。詳細は「自作電子小物/TIPS/Bluetooth-LEスタック/ペリフェラル向け/STM32版」にまとめてあります。
(4)電源部
OBDコネクタに出ている、車両バッテリ電源(直流12V)を利用し、評価基板に与える5Vにするための電源回路が必要です。
電源が常時供給されているので、機能していない時の使用電力を出来るだけ少なくなるように考慮しなければなりません。
・K-Lineの受信ポートへの電圧レベル変換は、回路の単純化から分圧抵抗にしたため、常時電流が流れてしまう。
分圧抵抗全体を出来るだけ大きな値にする事で、電流を少なくする
12V/200kΩ=60μA この程度なら何とか許容範囲と考える
・マイクロコントローラ自体は、スタンバイ等を駆使すればμAレベルまで減らせるが、評価基板を流用しているので、プロセッサ以外のコンポーネントの電源をコントロールする回路が別途必要となる。
解決策として、出力コントロール端子のついたDC-DCコンバータもしくはボルテージレギュレータを使い、電源オンはイグニッション検出を電気回路で行い、電源オフはマイクロコントローラ自身で指示させる方法としました。
電源オン:バッテリ電源ラインに乗ってくるイグニッション時の大きな電圧変動を拾い、わずかな時間だけでも、ボルテージレギュレータの出力コントロール端子をオンにします。マイクロコントローラは起動したら何はさておき切れる前に、この出力コントロール端子を強制的にオンにする事で、オンが持続されるという作戦です。
電源オフ:OBD上の通信が途切れた事を検出したら、ボルテージレギュレータの出力コントロール端子をオフ状態にする事で、自分自身で電源を切ります。電源が入り易いのは、バッテリ上がりの危険が高くなるので、出力コントロール端子がフリー状態ではオフという回路にしておきます。
発熱量について
ボルテージレギュレータは落差分のエネルギーは熱として放出する事で減圧する素子ですので、電流が大きかったり、電圧差が大きい場合は発熱量に注意する必要があります。
試算: (12V-5V)×0.2A=1.4W
本当ならば、エネルギー効率・低発熱の面からDC-DCコンバータにするべき所だと思いますが、手持ち部品の関係でシャープのPQ20RX11となりました。やはり、この熱容量だとヒートシンク無しではダメです。
(5)制御部
Bluetooth-USBドングルを使用する為に、USBホスト機能を有するマイクロコントローラを要します。
・PIC24FJxxGBシリーズ
・PIC32MXシリーズ
・LPC1700シリーズ
・STM32F4シリーズ
など等、ありますが今回はハードウエア開発に時間をかけたくなかったので、開発評価ボードを流用する事にしました。STM32F4-Discovery は、機能てんこもりなのに安価で、別途プログラム書込み器を用意する必要がなく、個人開発者にはありがたい製品です。今回は、使用するプログラムメモリ量が全く予測できなかったので、出来るだけ容量の大きなものを探した結果の選択です。オーディオ入出力や、加速度センサも搭載されていますが、今回は未使用です。結果的にはオーバスペックだったと思われます。
Simple fuel efficiency meter and
vehicle data logger for HONDA's light weight truck GBD-HA7.