前回の記事でラズパイZeroを使って車両のOBDカプラ経由で車両のCANを読み出せるようにしました。Raspberry Pi Zero Wで車両のCAN情報を読み出す
今回は取得したCAN情報から車速情報を取り出していきます。
下記リンク先を見るとGP5のFitだとID 158が車速、17Cがエンジン回転数、324が水温とのことです。GE8の方が古いため若干違う可能性がありますが、この情報を元に今回はID158のデータを見ていきたいと思います。
OBDカプラに装置を接続するという行為は通信を妨害してしまい、故障が入ってしまう可能性もあります。(例えばCANのH-Lを短絡させて通信できなくしてしまったり、余計なCAN情報を流してしまったりなど)
作業する際は細心の注意を払ったうえで、自己責任でお願いします。
CANデータをロギングするコード
前回実行したCAN Hatのサンプルコードは1つしかメッセージを受信しないものでした。
それだと調子が悪いのでメッセージが無くなるまでロギングを継続するコードに変更します。
(2022/07/02 追記)
私がこのコードを書いたときのpython-canの最新バージョンは3.3.4だったのですが、4.#にメジャーアップデートされたことで記述が少し変わりました。具体的に言うと8行目のcan0 = の所でbustype =の所を変更する必要があります。詳細はコードの中にコメントを追記したので確認お願いします。
import os
import can
import pandas as pd
os.system('sudo ip link set can0 type can bitrate 500000')
os.system('sudo ifconfig can0 up')
can0 = can.interface.Bus(channel = 'can0', bustype = 'socketcan_ctypes')# socketcan_native
#can0 = can.interface.Bus(channel = 'can0', bustype = 'socketcan')# python-canのバージョンが4以上はこちら
msg = 0#初期化処理
list = []
#msg = can.Message(arbitration_id=0x123, data=[0, 1, 2, 3, 4, 5, 6, 7], extended_id=False)
print("Start")
df = pd.DataFrame()
while msg != None:
msg = can0.recv(10.0)
list.append(msg)
if msg is None:
print("Logging end. File output in progress.")
df=pd.DataFrame(list)
df.to_csv("test.csv")
print("Finish")
os.system('sudo ifconfig can0 down')こちらのコードをざっくり解説するとCANメッセージが来なくなるまでCANを読み込んでリストに保存しCSV出力するというだけのコードです。(本当はフィルタリングとか色々やりたかったのですが、自分が持ってるラズパイZeroだとキツそうだったのでロギングのみとしています。。。)
ロギングしたデータの確認
ロギングしたデータのフォーマット
ロギングしたデータをエクセルで見てみます。(列名は別途追加しています。)
C列：タイムスタンプ、
E列：ID
F列：フォーマット
→恐らく標準フォーマットのIDなのでSとなっていると思ってます。拡張フォーマットの場合はEになると思ってますが、拡張フォーマットのIDが無かったため真偽不明です。。。
H：DLC(データ長)
→DLCが3ならデータ部が3バイトとなってます・
末尾：チャンネル(今回はチャンネルが1つしかないため、あまり意味は無いです)
ちなみにデータを見ていた思ったのですが、最終バイトのデータ(DLC:8だったら7バイト目のデータ)は受信するたびに動いているため、カウンタのようなものかもしれません。
ただ不規則に動いているように見受けられるため、カウンタ＋αの役割を持っていると思われます。
(2022/07/02 追記)
python-canのバージョンが 4.#にメジャーアップデートされたことでデータのフォーマットが少し変わりました。
大きな変更点としては送信/受信の情報が追加されてます。(細かなところでいうとDLCという表記がDLという表記になってます。)
(2021/11/14 追記)
7 Byte目のデータを見てみると37→0a→19→28→37…と繰り返しているため4回受信ごとに値が変わるように見受けられます。(ただし、8 Byte目以外にデータが入るとこの法則が崩れるため、ちょっとややこしい法則かもしれません。。。)
(補足)参考文献の記載が0始まりで表記されていたため、本ブログでも0始まりでバイトを数えていきます。
車速データを取り出してみる
こちらの参考記事によるとID158の0 Byte目と1 Byte目が車速情報で0.01を掛けたものと記載があります。
それでは具体的に見ていきます。今回はGE8も同様か見るためにエクセルでデータを見ていきます。
例えば下記のように0 Byte目が0f、1 Byte目がb8となっている場合は0fb8となります。
これを十進法に変換すると4024となり、0.01を掛けて40.24 km/hとなります。
この変換を各データに実施しグラフに描画したものが下記になります。
制限速度が60 km/hの道路を走っていたので、おおよそ合ってそうです
(本当はもっと長くロギングしていたのですが、ラズパイZeroの限界かもしれません。。。)
 |
| 図1:ID158の0,1 Byte目を描画したグラフ |
(2021/11/14追記)その他のバイトのデータも見てみる(4,5バイト目)
参考文献ではID158の4,5 Byte目も車速で、6 Byte目が？？となっていたので、自分でも見てみました。
下記図のオレンジがID158の4,5 Byte目で、青が0,1 Byte目です。
 |
| 図2：ID158の0,1 Byte目のデータと4,5 Byte目のデータ比較 |
2つを比較するとおおよそ同じ値を示していることがわかります。
ID158の６Byte目を取り出したものが次の図です。
時間経過とともに上昇して2分程度すると上昇が止まり、再度上昇しているという図です。
図5を見ると車速が0となっているところで6 Byte目のデータの上昇が止まっていることが分かります。なので、ID158の6 Byte目は距離に関する情報だと推察されます。
一応10km程度走った際のデータを確認したところ、やはり2550 m(2.55km)毎にリセットされてますね。何かの解析に走行距離を使うなら車速情報から算出した方が良いかもしれないですね。
図2の一部を拡大したのが次の図なのですが、何となく4,5byte目の値に対して0,1byte目は丸められているように見受けられます。
 |
| 図3：図2の一部分を拡大した図 |
(2021/11/14追記)その他のバイトのデータも見てみる(6バイト目)
 |
| 図4：ID 158の6 Byte目 |
最初何かの温度だと思っていたのですが、
①0からスタートしている。
②途中で上昇が止まって再度上昇が再開している。
という2点から別のものだと考えました。
②の途中で止まっているという点に着目して、速度のグラフと重ね合わせると面白いことが分かりました。
 |
| 図5：車速情報と6 Byte目を重ね合わせたグラフ |
図5を見ると車速が0となっているところで6 Byte目のデータの上昇が止まっていることが分かります。なので、ID158の6 Byte目は距離に関する情報だと推察されます。
そこで、速度のデータと時間から走行距離を概算し、6byte目と比較してみました。
(下記図のオレンジが速度と時間から求めら走行距離(m)、青が6byte目のデータとなります。)
 |
| 図6：車速情報から概算した距離と6 Byte目情報 |
図6のオレンジ線が一番最初にお見せした6byte目のグラフと似たような形をしているため
走行距離で間違いなさそうです。
また、速度から概算した走行距離に0.1を掛け合わせると6 Byte目のデータと一致します。
 |
| 図7：車速情報から概算した距離に0.1掛けたものとの比較 |
よって6Byte目に出てくるデータに10を掛けるとm単位の距離になります。
今回は6Byte目のデータが120近くまで上昇しているため、1200 m走ったことになります。
ちょっと気になったのは1Byteのデータなので、2550mまでしか格納できません。
2550m超えて走ったらどうなるかが気になりますね。。。
ちなみにID158の6byte目のデータを使うより、車速から概算した方が精度よく距離を出すことが出来そうです。(図8参照)
 |
| 図８：図7の一部を拡大したもの |
(2021/11/20追記)
 |
| 図9：10km程度走った場合の6Byte目の情報 |
まとめ
今回は車両のOBDカプラからCANの情報を読み出し、ID158の情報を解析しました。
解析した結果下記の情報が格納されていることが分かりました。
次回は他のCAN IDを解析しようと思います。
↓次回記事
.png)
0 件のコメント:
コメントを投稿