前回の回転数推定について、再確認してみます。
まず結論
結論から言って、前回の回転数推定がGPSデータと合っていなかったのは、私の勘違いでした…
／(^o^)＼ﾅﾝﾃｺｯﾀｲ
maxの使い方を勘違いしていました。
正しくは、以下のようにピーク周波数を出します。
>> y = [1:512]/512/gData(1,1); >> [maxAmp iMax] = max(abs(gFFT(3:200,:))); >> maxFreqRpm = y(iMax)*60;
ここでは、[rpm]の単位でピーク周波数列を出しました。
これを使って、前回と同様のグラフを作ってみると、
>> gear1 = maxFreqRpm * 5.01*10^-3;
>> gear2 = maxFreqRpm * 7.85*10^-3;
>> gear3 = maxFreqRpm * 1.05*10^-2;
>> gear4 = maxFreqRpm * 1.32*10^-2;
>> gear5 = maxFreqRpm * 1.61*10^-2;
>> plot(x, gear1, x, gear2, x, gear3, x, gear4, x, gear5, vel(:,1), vel(:,2), "*-");
>> axis([0 400 0 100]);
>> xlabel("t[s]");
>> ylabel("velocity[km/h]");
>> xticks([0:10:400]);
点マーカ付きの線がGPSデータからの速度データです。 まだ合っているようには見えませんが、時間軸位置を調整すれば合いそうに見えます。 260[s]あたりでのGPSデータ落ち込みと320[s]あたりの加速度データ落ち込みが重なるようにしてみます。
GPSデータの260[s]近辺で極小値を取る時刻を探します。
>> find((vel(:,1) > 250) & (vel(:,1) < 270)) ans = 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 >> [minVal minIdx] = min(vel(ans,2)) minVal = 21.600 minIdx = 11 >> ta_vel = vel(ans(minIdx),1) ta_vel = 261
同様に、FFTデータからの推定速度の、320[s]付近の極小値時刻は、
>> find((x > 315) & (x < 325))
ans =
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
>> [minVal minIdx] = min(gear1(ans))
minVal = 1.8788
minIdx = 11
>> ta_gear1 = x(ans(minIdx),1)
ta_gear1 = 318.40
GPSデータのほうの時刻を基準にして横軸を合わせてみたいと思います。
>> plot(x2, gear1, x2, gear2, x2, gear3, x2, gear4, x2, gear5, vel(:,1), vel(:,2), "*-");
>> axis([0 400 0 100]);
>> xticks([0:10:400]);
>> xlabel("t[s]");
>> ylabel("velocity[km/h]");
合わせた部分(t = 260[s]付近)とその前の部分が合うようになってきました。
ただ、加速し始めの部分が少しずれているように見えます。 これは加速度センサの測定周波数誤差によるものではと考えられます。これを補正してみます。
Ւ>> find((vel(:,1) > 160) & (vel(:,1) < 165))
ans =
122
123
>> [minVal minIdx] = min(vel(ans,2))
minVal = 7.9000
minIdx = 1
>> tb_vel = vel(ans(minIdx),1)
tb_vel = 163
>> tb_gear1 = 170
tb_gear1 = 170
>> tRatio = (tb_vel - ta_vel) / (tb_gear1 - ta_vel)
tRatio = 1.0769
>> x3 = (x2 - ta_vel) * tRatio + ta_vel;
>> plot(x3, gear1/tRatio, x3, gear2/tRatio, x3, gear3/tRatio, x3, gear4/tRatio, x3, gear5/tRatio, vel(:,1), vel(:,2), "*-");
>> axis([0 400 0 100]);
>> xticks([0:10:400]);
>> xlabel("t[s]");
>> ylabel("velocity[km/h]");
FFTデータでは、加速し始め部分は170[s]に見えるので、特に極小値時刻探しせずに値を入れています。
また、加速度の測定周波数に誤差がありそうということなので、FFT結果の周波数も修正が必要になります。 ここでは、tRatio(実際の測定周期/当初想定した測定周期)で割っています。
まあまあ合ってきましたが、まだ微妙なところが多いです。
- t = 210[s]～250[s]では、4速ギアでの推定速度がよく合っています。
- t = 170[s]～210[s]は4速ギアと5速ギアの推定のどちらが正しいのか、微妙です。
- t = 90[s]～130[s]はどのギアも実際の速度より低い推定値になっています。
- t = 80[s]～90[s]あたりの落ち込みではGPSデータとFFTデータが合っていません。もしかしたら周波数誤差も時間ごとに変動があるのかもしれません。
課題
やっぱり加速度センサの測定周波数誤差を補正できるようにする必要がありそう。
加速度ログに、CPUクロックで測定した測定周波数を入れておけば後で分析できるかと思っています。
一度マイコンプログラムを変更して、再度データ取りをしてみたいと思います。
以下、この間違いに気づく前に調べたことを掲載します。
今回の速度推定方法が間違っていなさそうということが確認できました。
バイク駆動系の仕組み
前回、回転数→速度の変換を計算サイトに頼りましたが、一度自分で仕組みを調べてみます。
以下がいい参考になりました。
エンジンの回転からリアタイヤまでの伝達経路は以下の通りです。
- エンジンのピストンが往復運動する
- クランクシャフトが回転
- この回転数(1分あたりに何回転するか)が"回転数"となると考えられます。
- プライマリードライブギアが回転
- クラッチが回転
- このギア比が"1次減速比"
- ミッションで変速される
- ギアごとに変速比が決まっています。
- ドライブスプロケットが回転
- ドリブンスプロケットが回転
- このギア比が"2次減速比"
- リアタイヤが回転する
前回の回転数→速度の変換サイトを見ると、これらの要素が考慮に入っているようです。
ドラッグスター250の関連スペックは以下の通り。
| 項目 | 値 |
|---|---|
| 1次減速比 | 3.130 |
| 2次減速比 | 2.800 |
| 変速比(1速) | 2.642 |
| 変速比(2速) | 1.684 |
| 変速比(3速) | 1.260 |
| 変速比(4速) | 1.000 |
| 変速比(5速) | 0.821 |
| リアタイヤ断面積 | 130mm |
| リアタイヤ扁平率 | 90% |
| リアタイヤリム径 | 15インチ |
確認してみると、
- リアタイヤの外周長は、(15[inch] x 25.4 + 130[mm] x 0.9 x 2) x π = 1932[mm]
- 1速の場合、速度[km/h]と回転数[rpm]の比は、
60(/min→/h) / 3.13 / 2.642 / 2.800 x 1932 / 10^-6(mm→km) = 5.01 x 10^-3
となり、変換サイトに記載されていたものと一致します。
ということで、この変換比については問題なさそうです。
加速度波形の再確認
加速度の時間波形を確認してみたいと思います。
まず、対応が分かりやすくなるように、加速度データをFFTデータと同じ形に直します。
>> gFFTLen = size(gFFT)(2); >> gData2 = reshape(gData(1:512*gFFTLen, 2), 512, gFFTLen);
これで、gFFT(:,i)とgData2(:,i)が対応するデータ(gFFT(:,i)の元になったのはgData2(:,i))となります。
もう一度FFTグラフを掲載します。
このグラフでは、t = 250[s] あたりのFFT波形が素直な形に見えます。
加速時のぎざぎざも過ぎた後なので、5速で安定して走っている状態ではないかと思われます。
ここの加速度波形を見てみます。
>> find((x > 250) & (x < 251)) ans = 782 783 784
まず、t = 250[s]にあたるのは783番目あたりのデータになるようです。
>> figure(2);
>> plot(gData(1:512,1),gData2(:,783), "*-");
>> xlabel("t[s]");
>> ylabel("Accel[g]");
前のグラフを残しておくために、figure(2)でもう一つ別のグラフウィンドウを用意しました。
横軸目盛り表示のため、gDataの1列目を使用しています。
グラフは以下の通り。
きれいな繰り返し波形が得られました。
この波形を見ると、およそ0.3秒の間に20個の山が見られます。すると、
周波数はおよそ60Hz
→ 回転数3600[rpm]
→ 5速ギアとすると速度は 3600 x 1.61 x 10^-2 = 58.0[km/h]
と速度推定ができます。
GPSデータで、この時刻周辺の速度を確認してみます。
(ここでも前回と同じデータを使います。時刻基準が19秒ほどずれていたので、これも考慮します。)
>> find((vel(:,1) > 240-19) & (vel(:,1) < 260-19)) ans = 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 >> vel(ans,:) ans = 222.000 52.900 223.000 54.000 224.000 51.800 225.000 51.500 226.000 51.500 227.000 51.100 228.000 50.000 229.000 51.500 230.000 51.800 231.000 53.600 232.000 53.600 233.000 54.000 234.000 54.000 235.000 52.900 236.000 52.200 237.000 51.100 238.000 49.000 239.000 50.400 240.000 50.000
これを見てみると、速度推定はそこそこ合っていそうです。
FFT波形確認
時刻t = 250[s]あたりのFFT結果を確認してみます。
>> y = [1:512]/512/gData(1,1);
>> plot(y(1:200), abs(gFFT(1:200,783)), "*-");
>> xlabel("Freq[Hz]");
ここで登場したyは、以前にFFTグラフ表示を行ったときに使ったものと同じで、周波数軸方向のインデックスに対応する周波数値を示します。
グラフは以下の通り。
1点目、2点目で大きな値が出ているのはDCバイアス(重力による定常的な測定値)および窓関数によるものと考えられます。
これを除くと、やはり60[Hz]あたりでピークが出ているようです。
確認してみます。
>> [m i] = max(abs(gFFT(3:end,783))) m = 174.60 i = 20 >> y(20) ans = 62.500
ピーク周波数62.5[Hz]と出ました。
問題なさそうです。
以上
今回の記事は以上です。
次回はマイコンプログラム変更と、できれば再データ取りになります。
