zweisteinjpのブログ一覧

登り坂が割と多くてアクセルペダルの踏み込み量を増やさないと失速していく場面が多く発生した。
なお、踏み増しすれば充分対処可能なエンジンパワーの余裕はあるがDレンジのままだと右足が少し疲れる感じになる。
そういう場合はSレンジにシフトレバーを切り替えることでエンジン回転数が少し高めになり、グイグイ登り坂でも走ってくれた。燃費に対しての影響までは確認してないが、疲労感は低下したので良かった。

仮に、ハイブリッドだとモーターアシストになるのかもしれないが、バッテリーの持ち出しが終わるとそれ以上は錘にしかならないので、電池容量によって挙動は影響出そうな感じ。

大阪から鳥取の往復運転を週末にしましたが、追い越し加速性能は良かったです。上り坂になるとかなり回転数は上がってしまうのはやむなしですが、2人乗車くらいならそんなに失速する感じもなく頑張ってくれてました。
高速走行時の安定性についても1.3Lのノーマル車と比べるとはるかに安定しており、不安を感じるレベルではありませんでした。
車体が小型で軽いのと1.5Lエンジンのバランスが軽快な走行を可能にしているのでしょう。

ディスプレイオーディオ自体は全く問題なし。起動時間は純正ナビより少し遅いけど、起動後の動きはスムーズです。
ナビ機能に関してはGoogleナビかYahooナビで多少漢字が変わるもののディスプレイオーディオとは直接関係ないアプリケーション側の問題。
視認性も良く、気になるのは耐久性のみでしょうか。
純正ナビはバックカメラ、オーディオ、ラジオとしては使えますし、地域によっては地図も使えています。
とは言えナビの地図は最新でないと変な案内をされてしまうので、スマホがナビの代わりというのは世の流れなんでしょう。

生活必需品としての実用的な自動車の役目はもとより、走る・曲がる・止まるの基本が高い次元でバランスされており、運転する楽しみを失ってません。

職場の後輩がインチアップタイヤにしたら車速がずれますか？なんて聞いてくるから、ずれるに決まってるじゃんと返事。じゃぁ正しい車速はどうしたら分かりますか？と聞いてきたので、タイヤ径の比率から頭で計算して補正、もしくはレーダーとかで表示される車速と比べてみたらと言ってみたものの可愛そうなので、市販品も調べてみることにしたら、

永井電子機器（ウルトラ）
http://www.nagaidenshi.co.jp/MONITOR/4015.shtml

があることが分かりましたが、これは車速パルスとか使うタイプなので、自分の中の検討からは排除。でももし車速パルスを使って補正するくらいだったら、ECUに車速パルスを入力する前段にタイヤ径の比率を考慮した周波数変換すればいいのかな？少なくともエンジン制御は正しい車速で制御するようにはなるけど、メーター表示がどのパルスなり信号で車速表示するかにもよるので良く分からない。

とりあえず、直接車を改造することなく、計算上正しい車速を表示させる方法としては、OBDコネクタから診断機通信を使って車速を取得して、タイヤ径が変わった分の比率計算して修正した車速を何らかのディスプレイで表示するか、生の制御用のCANデータから処理するかのどちらかってことになる。

PICマイコンでもArduinoでもCANは使えるので、OBD通信を実装して車速を取得するのは過去の実績から至って簡単ですので、あとは計算して修正した値をどう表示するかを考える。
液晶とかは家の中で照明があれば読めるけど、そうでない場合は運転中に見るのは困難なので、７セグLEDとかも検討する。
通信・演算系の開発をまずやっつけて、表示系は別にした方がやりやすいので、二段階方式でインチアップした車両でばっちり合った車速が表示される表示器を作ってみることにする。
PICは手持ちのPIC18F2480を使うことにしたものの、最近の秋月電子だとPIC18F26K80とか少し違う型番のを使うことになりそう。ソースコードは殆どそのまま流用出来るのでポートとか仕様違いだけ付ければ大丈夫。



ハーネスはとりあえずコルゲートでグルグルにする。







OBDのService$01のデータストリームで得られる車速はLSBが0-255の1LSB 1km/hなので個人的にはちょっと粗いイメージがあるので制御用の車速を採用検討をスタート。

CANIDはFIT GE6のCAN関係の解析をされているblogから情報を使わせて貰って試行錯誤をしましたが、割とすんなり車速データが取得出来た。
https://web.archive.org/web/20161115152618/http://www.bsddiary.net/soft/fitmon/DBA-GE6.html


7seg ledはダイナミック点灯方式なのでカメラで撮影すると消えているところとか出ているのは、人間の目の残像効果で実際は普通に表示されている。

とりあえずCANの生データをそのまま単位変換して表示させており、タイヤ径補正は未だだが、単位変換の時点で浮動小数を使っており、この時点で補正は楽勝。

自分のFIT GE8では上手くいったものの、後輩のクルマは割と時期の近いアコードなので同じCANIDとか似た仕様のデータベースなら簡単に終わるけど、データベース構成が違うと解析をやり直す必要があるので、完全に完成させるには当分かかりそう。

もしOBDの診断機通信を使ってデータ表示をさせたい場合に、もっとも参考になりそうなサイトは下記のところです。

https://pullup.net/?p=14

ホンダの診断機通信で出だしでハマるところは、トヨタをはじめ殆どの他社は11bit CANIDを使っているところが、ホンダの場合は29bit CANIDになっているところが問題となる。マイコンでソフトを書く時でも標準CANIDか拡張CANIDかで設定を変える必要があるとか、何のことか分かってないと確実にドツボとなる。
29bit CANIDなんてどうして採用したやら。

最近の自動車ですとサイバーセキュリティと合わせてCANFDが導入されていたりなんかして、更に訳が分からない方向に発展しており、自作であれこれしたい人には大変な方向になってきている。