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

6月 19, 2021
dj1711572002

STAスキーターンアナライザのプログラムは1月から3月にスキーデータを計測しながら、パッチをあてて改良してきたのですが根本的な課題があって、スキーシーズンが終わってから、新たな構成で作り直しました。3週間にわたる試行錯誤があったので備忘録として残しておくことにしました。量が多いので課題ごとに複数記事でシリーズで備忘録します。
今回は、2次元までの表示ですが、3次元表示は、2022年のシステムで実現する予定です。
※2022年2月追記
８か月がかりで、スキーターンアナライザー　グラフィックアニメーションプログラム完成させました。本シリーズで学習したすべての集大成です。
http://shinshu-makers.net/shinshu_makers/2022/02/12/%e3%80%90sta22%e3%80%91rtk%e3%83%87%e3%83%bc%e3%82%bf%e8%a7%a3%e6%9e%90%e7%94%a8%e3%82%b0%e3%83%a9%e3%83%95%e3%82%a3%e3%83%83%e3%82%af%e6%a9%9f%e8%83%bd%e9%96%8b%e7%99%ba%e3%83%bc%e3%81%9d%e3%81%ae5/

 

 

※グラフィック備忘録
①PictureBoxとBitmapを定義してしまう場合
参考LINK PictureBox.Imageプロパティに設定している画像を描き変えた時、すぐに表示に反映する　
PictureBoxは、額縁に相当します。額縁に差し込む絵は、紙であるBitmapオブジェクトです。
　Bitmapに描画するには、それぞれのBitamap専用のグラフィック処理クラス graphicsを定義します。 
　Dim bmp as new Bitmap(PictureBox1.Width,PictureBox1.Height)’bmpオブジェクトを定義
　Dim g as Graphics =Graphics.FromImage(bmp)’bmpのグラフィクス処理を定義
　g.DrawLine(Pens Red,x0,y0,x1,y1)’ bmpビットマップへ線が描画されてPictureBoxに反映

②PictureBoxとは独立させてBitmapを処理するしてからPictureBoxに反映させる場合
（参考https://dobon.net/vb/dotnet/graphics/createimage.html　）
　Dim bmp as new Bitmap(1000,400)’1000×400にビットマップを定義
   Dim g as Graphics =Graphics.FromImage(bmp)’bmpのグラフィクス処理を定義
　g.DrawLine(Pens Red,x0,y0,x1,y1)’ bmpビットマップへ線が描画する
　PictureBox1.Image=bmp ‘bmpをPictureBox1へ差し込む
　この場合ビットマップに各種処理をした後で、PictureBox表示できるので、便利です。

 

目次（詳細を忘れないうちに記事２，３，４を作ります6月末まで）
●その１：本記事は、最初の全体の解説と目次の記事となります。
紹介動画

 

その２：＜ソースBITMAP表示基礎＞　　２０２１年６月２８日作成

その３：＜自動追尾機能の中身＞　　２０２１年６月３０日作成


その４：＜ターン解析核心部＞

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

【ロードセル】銅板でロードセル作ってみたその１＜曲げ測定用＞

 

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

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

扱い方

 ×：
RTKデータをDataGridViewから読み込んでスケール変換計算させてPictureBoxへプロット　1cmスケールだと画面に大きな棒がでるだけで、それを次々と更新していくには時間が何秒もかかってしまうので拡大は実際は使えない		 〇：
SourceBitmap作成時にスケール設定して全体を書き込む
巨大なデータだと数分かかる場合もある
BITMAPの上限２ＧＢの制限があるため、全体を１ｃｍ分解能で作成する場合は７５０ｍｘ２０ｍ幅のコースデータしか入らない
データの
フォーカス機能		 ×：
プロットしたグラフのフォーカスしたい線をＢＯＬＤにして、その位置でのデータを表示、拡大するとページめくりしながらデータを検索するので、ページめくりが数秒かかるので、検索するのに時間がかかって、1つ１つのデータをしっかりと観察することができなかった。		 ◎：
スライダーで全体をスクロールしながらフォーカスしたい部分で止めることでその部分のデータが見れるので検索が瞬時にできる、最新のデータは、PictureBoxの中心部に固定表示されるので、目視しややすく、データの見落としが少ない。
座標変換機能 ×：
東西南北は、固定		 ◎：
ターンデータを始点と終点を結んだ直線基準に水平に回転させて、ターンをサインカーブ状に表示
インデックス

機能

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

 

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

「ビットマップも形式が何種類もあってIMAGEオブジェクトの1種と定義される。ＢＭＰ，ＧＩＦ，ＪＰＥＧ、ＰＮＧなどもＢＩＴＭＡＰでＩＭＡＧＥオブジェクトである。時系列データのグラフ描画では、ＢＭＰ型を主に使う。」

　「GRAPHICSは　ＧＲＡＰＨＩＣＳオブジェクトに描画するための描画メソッドが用意されていて、ＧＲＡＰＨＩＣＳオブジェクトは、描画する絵具ＴＯＯＬであって、描画媒体は、ＩＭＡＧＥであるＢＭＰキャンバスとなる。」

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

 

③ソースＢＩＴＭＡＰの座標点とＲＴＫデータのリンク
当初、ＤｒａｗＩｍａｇｅを使ってＢＩＴＭＡＰを回転しようとしたが、座標とデータのＩＮＤＥＸをもってないと回転後の座標からＲＴＫデータを読み出すことができなくなるので、回転は、座標回転計算で座標を求めて、その座標でソースＢＩＴＭＡＰを作成することにした。
ＩＮＤＥＸとして、2種類の配列をもっている

●ＩＮＤＥＸ１：「Ｘ座標からＲＴＫデータ番号を得るために直線回帰」

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

 

 

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

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

 

 

More from my site

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

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

    返信

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

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

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

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

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

      返信

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

        返信

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

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

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

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

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

          返信

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

コメントを残す

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