ぱららのブログ一覧

だいたいできちゃったけど、残りの部分をメモ代わりに書きながら、次の機能アップを
書いてみマッスル。

仕様としては、メニューボタンを押したら、画面下方にメニューを出します。
これはAndroidで標準的な方法があるので、登録するだけです。
６個のメニューを登録（６行でできるｗ）し、メニューの文字列は言語にあわせて変更
できるようにリソースとして登録します。英語版とか日本語版とか作れるんだぜ！

メニューからLoadFileを選び、ファイルを指定すると、全ラップのタイム、セクタタイム
を表示します。ベストタイムにはベストマークが付きます！

さらにみたいラップをクリックすると、そのラップデータをグラフ表示します。
縦軸をスピード、横軸を時間とします。

必要なデータは、各データと最大スピード、トータルの時間ですね。
ファイルをオープンしたらデータをメモリに書き出しながら、最大スピードを計算します。
最後にかかった時間を求めます。

これで、データの準備が出来ました。
次に、グラフのレイアウトを決めます。
システムの値から、縦と横のピクセル数を取得し、長手方向を時間軸として描画します。
場合によっては、９０度方向を変換する必要がありますので、独自の描画関数を作って、
条件にあわせて方向を変換するようにしました。

あとはグラフのグリッドとゲージの表示です。
どのくらいのピッチで表示すれば、いいかは最大値とピクセル数から計算して求めます。
だいたいターゲットの最大値のときはうまく出来るのですが、いろんな値をいれてテスト
すると、だいたい予想外の不具合が出ます。ピッチが狭くなって、数字が重なったり、
ピッチが大きすぎて閑散になったりｗ

ちょっとデバッグした結果、袖ヶ浦のデータでもちゃんと表示されたので、よさげです。

次の機能アップ候補としては、サーキット名表示や、ボトム、トップスピードの表示、
それに複数のデータ表示もサポート予定です。
できればエイトリアンカップまでには作ってみたいなぁ。

写真は出来上がったグラフ表示の画面です。

ゲ～ロゲロ、今日から仕事始めのぱららです。

明けまして、お酒、お酒、お酒の日々ですなぁ。今も日本酒を煽りながら書いてますｗ

起動したら、メニューボタンを押してファイルをロードしたりするためのメニューを追加するとかいう
日記の予定でしたが、正月の夜中に、コーディング頑張ったらそこそこ動いて、この２日ほどは
ベタなコードをオブジェクト指向的にデータをカプセル化＆ファイル分割もしてすっきり整理しました。
50%くらいの確率で、プログラムがハングアップするパターンを見つけてしまったけど、そこそこ
動くので、現状の動画を撮りました。
１）ランチャーからプログラムPararaVisionを起動
２）メニューからSDカード内のDBNファイルを開く
３）各ラップとセクタタイムのリストを一覧表示
４）ベストラップを指定
５）グラフ表示
６）メニューから、予め保存しておいたラップを指定
７）先のグラフに重ねて表示
という手順で撮影しています。
実際のハードウェア上ではなくエミュレータ上ですけどね。。。

これからしばらくバグ取りと測定精度の確認を行っていきます。
あと、プログラムアイコンをデザインしたりとか、、、今は仮のアイコンなので。

今度、筑波サーキットに行く時に持っていけるよう頑張るぞ！っとヽ(´ー｀)ノ

映像はこちら↓

ゲ～ロゲロ、新年明けましておめでとう！なぱららです。

昨年で本厄も終わり、ほっと一息。今年は（・∀・）ｲｲ!!年になるといいですねぇｗ

今回から、プログラムを実際に作り始めますですヽ(´ー｀)ノ

えっと、まずプログラムの名前決めないとね！
名前はTrackVisionをまねて、
　PararaVision
にしました～。もえ～(。_･☆＼ ベキバキ

まずは起動時に、バージョン表示とスプラッシュ画面を出すようにします。

起動時に一番最初に機動される画面(Activity)から、スプラッシュ画面用のActivityを呼び出し
３秒表示したらタイマーでその画面(Activity）を終了します。
Androidでは、基本的なアプリケーションのベースををActivityと呼んでいます。このプログラムの場合、Avtivity＝画面
くらいのつもりで読んでいただければOKです。

名前は決めたけど、スプラッシュ画面作るのは結構大変じゃん、、、

ひとまず、RX-8にタイトルを合成して作りました。
まぁまぁジャン！

そのうち、また変えるかも。
一人千円くれたら、ランダムにあなたの車をスプラッシュ画面に出します！
とか、商売出来ないかな(。_･☆＼ ベキバキ

次は、プログラム本体にメニュー画面を追加する予定です。

ゲ～ロゲロ、今年も紅白見る予定のぱららです。

案外順調にここまで順調でありますヽ(´ー｀)ノ

今回はDBOX.DSFファイルの中身を解析しました。
このファイルには、コントロールラインの位置情報。それに、ジムカーナのようにStartラインと
Finishラインが違うときのための、Finishラインの位置情報、それと各セクタタイムや分析の
ために使えるSplitライン（最大６つまで登録可能）があります。

それぞれスタートポイントとエンドポイントがあり、経度、緯度の順です。
ポイントを無効にするには、2147483647 を設定します。キリいい数字なんですが、プログラマ
じゃないとわからないですよねｗ
#16進数で７ｆｆｆｆｆｆｆです。

----------------------------------------------
[Start Finish]
839516550 216900923 839516505 216900764

[Finish]
2147483647 2147483647 2147483647 2147483647

[Split 1]
839525010 216899714 839524967 216899502

[Split 2]
839531317 216896883 839531405 216896975

[Split 3]
2147483647 2147483647 2147483647 2147483647

[Split 4]
2147483647 2147483647 2147483647 2147483647

[Split 5]
2147483647 2147483647 2147483647 2147483647

[Split 6]
2147483647 2147483647 2147483647 2147483647
----------------------------------------------

簡単だなぁと思ったんだけど、実はちょっと問題あったよ。
オレはてっきりStart Finishの２つのポイントのデータはコントロールラインの位置で
コースを横切る2点だと思ってました。
実際の位置を調べてみると、最初の点をAとすると、計測ポイント、次のポイントをB
とすると逆進行方向に数ｍはなれた位置となっていた。えっどういうこと？

●オレの予想：
　A　　　↑　　　B
　・----↑----・　←コントロールライン
　　　　　↑
　　　　　進行方向

●実際の位置
　A　　　↑　　　　　
　・----↑----　←コントロールライン
　　　　　↑
　　　　　進行方向
　・
　B

コントロールラインを横切る判定を、２つの計測ポイントを結ぶ直線とこの計測ライン
が交わった位置を検出するアルゴリズムを考えていたので予定が違ったぞ！

プログラム的にはデータを読み込んだ後に、点Aを原点にして進行方向に向かって、
90度に直交する直線を左右にある程度距離をとった位置を算出して、計測ライン
データを作ることにした。左右に広げるのは、このポイントがコースの右端にきたり
左側にきたりして、一定のルールがないためだ。
予定よりコード書く量が増えた瞬間（´･ω･`）

このらいんのゲート幅はPerformaceToolではデフォルト25mとなっていた。
２つのコースが近くて、ゲートがまたいでしまう場合はこの値を小さくする必要が
あり、手動で変更できるようになっている。

この連載の今年のノルマはこれで終わりヽ(´ー｀)ノ
新年からはコードを書いていく過程をレポートする予定であります。
では、よいお年をお迎え下さい！

ゲ～ロゲロ、もう今年も終わりかと物思いにふけるぱららです。

さて、いよいよLogデータを解析するのであります！
まぁこれが出来ないと話にならんのであります。

使ったツールは
　Binary Editor BZ
であります。
このバイナリエディタは、構造をファイルに定義しておくと、その構造にあわせた表示をしてくれるし、繰り返し表示するときも簡単に次のレコードに移動してくれるので重宝するんですヨ。

パフォーマンスボックスのログデータはDBOX_XXX.DBNというファイル名で記録されるのであります。
XXXは001から順番に番号がカウントされていく感じ～。

まずは秀丸でファイルを開いてみると、テキストとバイナリが混在してました。
PerformaceToolでVBOフォーマットで保存すると、テキストデータで保存されマッスル！
が、現地でPCを使わずにデータを見るのが目的なので、このバイナリデータが見れないと
目的が達成できません！
まぁでも親切に構造が書いてあったのでｗ簡単に分析完了しましたよヽ(´ー｀)ノ
---------------------------------
File created on 2008/12/23 at 14:37:02

[HEADER]
SATS(1)
TIME(3)
LATITUDE(4)
LONGITUDE(4)
VELOCITY(2)
HEADING(2)
HEIGHT(4)
YAW__(2)
YAW_(2)
YAW(2)
SLIP(2)
CHKSUM(2)

[COMMENTS]
Firmware Version 01.00 Build 0048
Serial Number -------

[DATA]
$・愠・
,6・m ・ 裕
$・惲ﾃ2
j6｣j ・ 4ﾜ
$・愑・
ｩ6ｸg ・ #
$・愷^2
・ｽZ ・ ﾁﾐ
$・愰)2
$6・T ・ 塚
$・愰・
b6ﾀY ・ D
---------------------------------

●解析結果
１つのデータレコード長は33Byte。バイトの並びはビックエンディアン。
ヘッダは”$”の文字(0x24)から始まる。
以後はHeaderに書いてある順番とカッコ内のバイト数で構成されている。
SATS(1)：捕捉した衛星の数。筑波だと５～10くらいの衛星数が入っていますね。
TIME(3)：グリニッジ標準時で、1970年1月1日0時0分0秒からの経過時間が10msec単位で記録されている。
　ただし、3バイトしかないので、下3バイトのみとなる。GPSの計測周期が10Hzなので100msec毎に
　カウントアップされる。ロガーとしては相対時間がわかればいいので、これでいいが、プログラムで
　計算するときはちょうど桁上がりが発生したときの処理を忘れないようにしないとネ。
LATITUDE(4)：緯度（北緯）。百分率表記で単位は分であわせている模様。変換してGoogleMAPで表示させた　ら、筑波サーキットのコントロールラインと思われるところが表示されたので問題ないだろう。
　今回はGoogleMapなとどの連携もないし、相対位置がわかればいいだけなので、さらに無問題。
LONGITUDE(4)：経度（東経だがマイナスなし）
VELOCITY(2)：速度。単位はkm/h。100倍された値が記録されているので、表示するときは100で割る。
HEADING(2)：進行方向を360度を100倍だったかかな。。。示している。今回は使わない。
HEIGHT(4)：高度。何倍かして記録されている。メモがどっかいったので何倍かわからん。もち使わない。
YAW__(2)：記録されてない。常に０．DriftBox用と思われ。
YAW_(2)：同上
YAW(2)：同上
SLIP(2)：同上
CHKSUM(2)：なんのチェックサム方式かは不明。使わない。

●Javaで実装上の注意
簡単なファイル読み込みプログラムを作ってバイナリデータを読み込んでみた。
C++と違ってJavaにはunsignedの整数型がないので注意。
また、Byteデータをビットシフトしてint型などに入れるときも注意。Javaでは必ずint方に
キャストして（符号拡張して）から代入される。
例えば
　short int a　に Byte b[2]を入れるとき
　a = b[0]<<8 + b[1];
だと、バグりました（´･ω･`）
正しくは
　a = (b[0]&0xff)<<8 + b[1]&0xff;
のように０ｘｆｆのANDをとる必要がありました。
JavaのByte型はCのchar型と同じでsignedです。
つまり
b[1]が0xff(-1)はintに符号拡張されて0xffffffffとなり、255を足したいのに-1引くことになるです。
b[1]が0xff(-1)はintに符号拡張されて0xffffffffとなり、0xffとANDをとると、下位８ビットのみ有効と
なって0x000000ffを足すので正しく255を加算できます。
ちゃんとJavaの言語仕様読まないとはまりそうだけど、今回は遊びだからね（汗
このまま進めマッスルｗ

明日は、Start/Finish/Splitラインのデータファイル（DBOX.DSF）の解析を行うのであります。