【STA】RTKデータ解析用グラフィック機能開発ーその1ー<自動追尾機能便利>

STAスキーターンアナライザのプログラムは1月から3月にスキーデータを計測しながら、パッチをあてて改良してきたのですが根本的な課題があって、スキーシーズンが終わってから、新たな構成で作り直しました。3週間にわたる試行錯誤があったので備忘録として残しておくことにしました。量が多いので課題ごとに複数記事でシリーズで備忘録します。
今回は、2次元までの表示ですが、3次元表示は、2022年のシステムで実現する予定です。

目次(詳細を忘れないうちに記事2,3,4を作ります6月末まで)
●その1:本記事は、最初の全体の解説と目次の記事となります。
紹介動画

 

その2:<ソースBITMAP表示基礎>  2021年6月28日作成

その3:<自動追尾機能の中身>  2021年6月30日作成


その4:<ターン解析核心部>

※2021年7月12日スキーの曲げセンサ開発開始しました。

【ロードセル】銅板でロードセル作ってみたその1<曲げ測定用>

 

●新たな機能 旧機能と比較

機能 旧プログラム (rev20以前) 新プログラム (rev21以降)
BITMAPの
使い方
BITMAPは、PictureBox1をbitmapに指定して,g.drawした瞬間に逐次更新させる構成、表示更新毎に毎回一から計算してプロットしていたので遅かった BITMAPを複数もって、最初に測定全データを大きなBITMAP(SourceBitmap)に展開しておいて、必要な範囲をきりとって表示用BITMAP(PictureBitmap)にコピーしてPictureBoxへ表示する。座標プロット計算がないので表示量に関係なく一瞬で表示できる高速処理※.NETのBITMAPクラスは整数で処理しているので、Width x Height x 3バイト が4バイト整数以上では使えないので2GB以下の画像しか使えない
スケールの

扱い方

×:
RTKデータをDataGridViewから読み込んでスケール変換計算させてPictureBoxへプロット 1cmスケールだと画面に大きな棒がでるだけで、それを次々と更新していくには時間が何秒もかかってしまうので拡大は実際は使えない
〇:
SourceBitmap作成時にスケール設定して全体を書き込む
巨大なデータだと数分かかる場合もある

BITMAPの上限2GBの制限があるため、全体を1cm分解能で作成する場合は750mx20m幅のコースデータしか入らない
データの
フォーカス機能
×:
プロットしたグラフのフォーカスしたい線をBOLDにして、その位置でのデータを表示、拡大するとページめくりしながらデータを検索するので、ページめくりが数秒かかるので、検索するのに時間がかかって、1つ1つのデータをしっかりと観察することができなかった。
◎:
スライダーで全体をスクロールしながらフォーカスしたい部分で止めることでその部分のデータが見れるので検索が瞬時にできる、最新のデータは、PictureBoxの中心部に固定表示されるので、目視しややすく、データの見落としが少ない。
座標変換機能 ×:
東西南北は、固定
◎:
ターンデータを始点と終点を結んだ直線基準に水平に回転させて、ターンをサインカーブ状に表示
インデックス

機能

▲:
描画後スクロールバーをスライドさせて参照する部分をBOLD表示することでその位置データの情報を文字表示
◎:
描画スクロール時に同時に位置データがみれる。座標回転した場合でも、座標位置のRTKデータを保持しているので、
ビューモード ×:
静的表示、1ページで表示するデータを描画するだけで、いじりようがない。
◎:自動追尾 (AutoTrace機能)
動的表示、指定範囲は、ソースBITMAPに登録した範囲内を自由にスクロールして表示 Y軸固定モードとY軸AutoTraceモードがあって、拡大してみる場合便利
画像
はみ出し防止
×:
全データを表示しないとはみ出してしまうので、小さい絵で視認性が悪かった
◎:自動追尾(AutoTrace)
動的トリミング機能で、常にターン先頭データはグラフの中心高さ表示するので、どんな倍率を拡大してもはみ出しは発生しない。
立ち止まり中の
データ処理
×:
RTKデータでプロット表示処理しているのでスキーの停止中でもずっとスクロールしていても、インデクスが先に進まないので操作が手間で非常に時間がかかる。
◎:
ソースBITMAPで、RTKデータから離れるので、スキー停止中のデータは1点だけになる、迅速に全体のスクロール検査ができる

 

●手間取った点
①BITMAPとGRAPHICSとIMAGEの単語の意味の区別がつかなかった。
今までは、WEB上のサンプルプログラムをコピペしてつぎはぎでグラフィックプログラムを作っていた。

「ビットマップも形式が何種類もあってIMAGEオブジェクトの1種と定義される。BMP,GIF,JPEG、PNGなどもBITMAPでIMAGEオブジェクトである。時系列データのグラフ描画では、BMP型を主に使う。」

 「GRAPHICSは GRAPHICSオブジェクトに描画するための描画メソッドが用意されていて、GRAPHICSオブジェクトは、描画する絵具TOOLであって、描画媒体は、IMAGEであるBMPキャンバスとなる。」

②BITMAPの倍率次第で破綻する場合もある
1stStep:範囲指定されたデータの最大最小平均値を計算と同時にINDEX用の2種類の配列も計算
2ndStep:ソースBITAMAPの倍率の選択(倍率手動指定、自動計算)
3rdStep:ソースBITMAPのサイズ表示で倍率修正(BITMAPクラスは整数の制限があって2GB以下でしか使えない)
4thStep:スクロールバー値変化で描画BITMAPの切り取りサイズを変更しながら動的トリミングを行う
 =>BITMAPの倍率を拡大して1cm/dotまで分解能をあげるとスキーコース全体をとりこめなくなる。
   例えば、750mx79mの滑走データがある場合、1cm/dotでBITMAPにすると1.7GBでエラーになる
  1.2cm/dotにすれば1.2GBまでなら使える。
  BITMAPが2GBしか使えない解説記事https://imagingsolution.net/program/csharp/bitmap_class_max_size/

 

③ソースBITMAPの座標点とRTKデータのリンク
当初、DrawImageを使ってBITMAPを回転しようとしたが、座標とデータのINDEXをもってないと回転後の座標からRTKデータを読み出すことができなくなるので、回転は、座標回転計算で座標を求めて、その座標でソースBITMAPを作成することにした。
INDEXとして、2種類の配列をもっている

●INDEX1:「X座標からRTKデータ番号を得るために直線回帰」

スキーターンデータを回転させて水平正規化することで、X値とY値が1:1関係になることを利用してRTKデータ番号とBITMAP X座標の直線回帰をおこなって、RTKデータとBITMAP座標を関連づけた。
座標計算過程でX軸に対するY軸の値配列を全ドットで保持する

 

 

●INDEX2:「自動追尾(AutoTrace)一定位置に最先端データを滑らかに表示するためにRTKデータ補間」
スライドバーを動かすことで、X座標が刻々変化するとY座標も上下してターン弧を描くが、固定トリミングだと、ターンがはみ出してしまう場合があった
そこで、ターン先頭データは、常にグラフ中心高さに制御しながら表示する動的トリミング機能を採用することにした。
動的トリミング機能を実現するためには、ソースBITMAP全データのFy(x)関係を配列でもつことにした。
●以後

次の記事から詳細なプログラムの解説を備忘録していきます。

 

 

6 thoughts on “【STA】RTKデータ解析用グラフィック機能開発ーその1ー<自動追尾機能便利>”

  1. タナカ様 コメント有難うございます。高須先生のブログの件、ご連絡感謝いたします。
    丁度、スキーターンアナライザ(STA)記事に日本からアクセスが急増したので、リンク先をみたら、GPSPPという専門的なサイトだったので、どなたかとおもっていたのですが、高須先生だったのでびっくりしました。私などは、専門業界の人からみれば、駆け出しの素人なので、当サイトにご来訪いただいても見るべきものは無いと思いますが、たくさんご来訪いただき感謝しております。ArduSimple社もアクセスの急増があったようで、翌日何かあったのかとメールが飛んできました。ArduSimple社のマネージャーさんとエンジニアさんが私のスキーターン解析テーマを気に入ってくれてます。タナカ様もTwitterを拝見するとバイクレースがご趣味ではないかとお察しいたします。バイクレースなら松本のBIZSTATION社の社長さんもなバイク趣味ではないかと思います。私は、BIZSTATION社の近所に住んでいるので、社長さんにお願いしてDGPRO用の基準局を使わせていただいてます。レースカー、バイクなどモータースポーツのIOTは、進んでいるなと感じてます。
     自転車、スキーなどはまだまだIOT化が遅れている分野で、やるべきことがたくさんあります。
    2021-2022はスキーターンアナライザを自分の満足のいくところまで開発しようと思ってます。
     何かお気づきの点がありましたが、ご指摘していただければ助かります。
     ご指導よろしくお願いいたします。

    1. ご丁寧なコメントを頂き恐縮です。

      ArduSimple社に掲載された記事も拝見しております。開発されているSTAのような、RTKの適用可能性を押し広げていく試みが広く知られるのは素晴らしいですね。

      BizSTATION様のDrogger製品群は元々バイク用途に作られていることもあって、常々気になっております。しっかり製品品質にまとめられており、すごいことだと思います。

      バイクはクルマに比べるとペイロードがかなり小さいのが悩みなのですが、自転車やスキーになるとさらに諸条件が厳しくなるのだと想像します。

      信州MAKERS様が問題を発見・解決されていく様子をブログで拝見して、私も大変刺激を受けております。
      次シーズンでのシステムのさらなる発展を願っております。

      1. タナカ様 コメント有難うございます。 
        バイクは、速度が速いので大変だと存じます。プロ用機材のTrimbleBD982なら50hzサンプリングなので高速でもターンのデータを測定できるかもしれませんね。スキーでもレース用となるとF9Pでは厳しいです。
         F9PのSTAは、アマチュア練習用途ですが、現在2次元ですが、来年は3次元にして、人間の入力とSTAの出力を同時に表示することで、ターンの全容が見えて、だれもが自分の滑りの学習練達に利用できることを目指してます。
         これからも、ご指導宜しくお願いいたします。

        1. 位置情報の解像度が上がればさらに見えてくるものはありそうです。スキーはダイレクトに人間の入力に反応しますものね。

          スキーと比べると、バイクはかなり重く慣性も大きいためか、M8T(10Hz)とF9P(20Hz)を比較した際は、走行軌跡という点ではそれほど差はありませんでしたが、これもさらに解像度を上げていくと何か見えてくるのかもしれません。教えて頂いたTimbleの受信機、この価格でその性能が出せるのは驚きです。自動運転用途ですと100Hzで出力するものもあるようで、すごい話です。

          移動が伴うスポーツは外部からの観測が難しく、そのため第三者によるコーチングも難しいのですよね。追走、並走という手もありますが、余程の実力差がないと観測行為に割ける余裕がありませんし、そういった技量の人間をひとり割り当てるのはそもそも贅沢なことです。この点、スキーとバイクは条件が似ている気がしますし、滑走してゆくスキーの方が一層難しいかもしれませんね(サーキット走行の場合はバイクはぐるぐる周回するので、定点カメラという手があります)。

          私も何かしらライディング技術の向上に使えるものができれば良いなと思ってちょこちょこと進めております。今回コメントさせて頂いて、こちらもやる気が出てきました笑

          今後ともどうぞよろしくお願い致します。

          1. タナカ様 コメント有難うございます。M8Tの時代から使われていたんですね、ご経験をお聞かせいただけると勉強になります。自分がユーザーでDIYをされているのは、非常に良いアプローチだと存じます。信州MakersのポリシーDIYでコト作りとモノ作りを目指すにピッタリです。これからも同好の士として宜しくお願いいたします。
             スキーデータ解析ソフト開発中ですが、ターンをどういう表現をすれば、自分の滑りを理解しやすいかあれこれ考えながら開発してます。構想している時間がうんとかかっているのですが、それが楽しみでもあるので、時間を気にせずに開発してます。
             テーマ以外でも、ブログの使い勝手など、お気づき、ご要望がございましたら、率直なご意見いただければ助かります。 ご指導宜しくお願いいたします。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です