STA25 チャンピオンデータがとれたので、１００点つけたいところですが、まだまだ、計測システムの品質は５０点です。
●STA25計測システムの課題
課題：TeensyのSDログプログラムでオーバーヘッドでデータ落ちが発生している
TeensyForumでHardwareSerialの扱い方とサンプルコードをいただいたので、受信は安定したのですが
受信したデータ配列をSDカード書き込み部分が時間食いすぎて、全７センサのデータ配列をSDカードに書き込むと計測周期10msecをはみ出してしまいます。
対策案１：CPUを２個にして、センサを分担する
対策案２：SDカードログをやめて、UDPとかUSBの高速通信でWindowsデバイスでログする
●計測の場合マイコンでがんばっても時間の無駄
目的が計測データを正確で、落ちが無いようにログするコトですので、製品ではないので、
小型化、使い勝手などは、二の次で、正確性、データ落ちがないことが最優先です。
対策案１で、マイコンを２個にするには、基板と配線と防水ケースのつくり直しになるので３か月くらいかかってしまうので、５月のスキー場の最終営業に間に合いませんし、将来的に、高速化するためには
更にマイコン数を増やすというイタチごっこになります。
対策案２では、WINタブレットを背負って計測しないといけません。しかし、RTKシステムは、電力消費量がIOTとしては、2000mWHと大きいので、大きなモバイルバッテリを足のくくりつけて計測する運命にあります。つまり、システムへ電力を供給するための太いUSBケーブルが必須なのです。
折角、USBケーブルをつなぐなら、電力だけでなくデータ通信をすればいいのが自然です。
そこで、SDログを止めて、タブレットのUSBでマイコンから受信ログする方法にしました。
●効果 「数μsecでログ通信が終わる マイコン内ログは数msecですので、千倍速いです。」
USBベースで走るTeensy4の為せる技ですが、１２Mbpsとか４８Mbpsで通信できますので
SDカードをSDIOで記録する以上の速度でログできます。更にUSBなので、データの信頼性が
確保されてますので、SDとかシリアルIFのように通信中に欠落する心配がありません。
SD書き込みで数msecかかっていたので、数μsecでログできるようになりました。
F9P３個のデータを１０μsec、IMUとひずみゲージセンサの100Hzデータ870byteも数μsecでした。
●プロジェクトの将来性に良い
２０２５年から２０２６年にかけて ublox F9PからX20PへRTKチップを変更します。
速度が今の８Hzから２５Hzで３倍速くなるので、今までのマイコンシステムSDログでは
対応できないので、USBログでシステムを組んでおけば、今より何倍も高速なセンサになっても
対応可能です。
●開発効率
遅いマイコンでいろいろな処理するより、PCで処理したほうが時間効率が良いです。
ラズパイとかマイコンでのプログラムは最小限にして、PCで処理プログラムを作ったほうが
効率が良いです。特に、私のような素人プログラマーだと効率が悪いコードを書くので
余計CPU性能が余裕がないといけませんので、PCでC#とPythonメインでプログラムを作って
いくことが将来的に開発効率が良いという理屈になります。
●WINDOWSの小型ガジェットがない
しかし、問題もあって、背負って計測するWINDOWS端末が小さいのがないのです。
タブレットは、１０インチ以上がほとんどで、８インチとなると滅多にありません。
アンドロイドタブレットとかスマホならあるのですが、WINDOWSでは、なかなか小さい端末ないです。 今回は、昔のFMV arrowsTabの８インチの遅いタブレットでログします。
ラズパイはUSBメインなので、ラズパイでログしてもよいかもしれませんが、
しかし、最後はPCへデータをわたさいといけないので、そこが問題になります。
●いずれはサーバーでログする
５G時代なので、HTTP経由でも相当速度が速いのでサーバーにアップロードする手もあります。
STAシステム、センサ数が多くて１CPUでできるか不安のままずるずると実測まで来てしまったのですが、フタをあけると後ろのGPSのデータ落ちが酷くて使えないことが判明しました。
Teensyのプログラムで相当無理してきたので、ギブアップなので、FORUMに泣きつきました。
類似の課題を検索して、回答数が多い方に質問を投げました。
TeensyForumのルールが、自分のコードを見せて相談しないといけないことになっているので、恥ずかしなら、稚拙なコードをだしてアドバイスをもらいます。しかし、プロがコードをみて、その人のレベルにあわせた内容で会話してくれるので、普通のFORUMに比べて、非常に濃密な内容で、学習効果が抜群によいです。
TeensyのFORUMは、米国のMAKERさん達の集まりですが、皆さんソフトのプロが趣味でTeensyをいじっているので、レベル抜群に高いです。英語自信がないので全てchatGPTで翻訳してもらって投稿しました。投稿したら、即回答がきて、F9Pからのデータ受信についての基本的な考え方を教えていただけました。その間、chatGPTに翻訳させていたら、回答事項を翻訳がてらに、サンプルプログラムも提示してきました。ところがそのアルゴリズムは、回答をそのままパクッテいて、いかにも知ったかぶりしています。ですので、サンプルプログラムも穴があるものがでてきました。しかし、本物の回答者のサンプルプログラムは、完璧で、コピペ一発で完全動作しました。この方相当のプログラマーだと思うのですが、GPSから入ってくるであろうデータで発生しそうなトラブルを全部想定して、対応できるアルゴリズムを１時間もしないで、回答してきてくれたので、その分野のプロだろうなと思います。chatGPTにその方のコードは見せないようにします。知ったかぶりのchatGPTに教えても、軽薄な理解しかしないだろうから、無駄です。
chatGPTは、技術屋の世界では、軽い人に似ている行動をするなと感じました。
つまり本物にはなれないので、技術開発など、創造性が必要な仕事は、AIは未だ未だできないと実感した次第です。
それにしても、米国のプログラマ優秀なので驚きました。片手間で、凄いサンプルコードを送ってきてくれるのですから、驚きました。
３月末でスキー場クローズしてしまうので、小賀坂スキーの横田様お忙しい中、よませスキー場まで
おいでいただいて、STA25システムのテストライドしていただきました。
当日は、前日からの積雪で重い雪が２０ｃｍほど硬い下地の上にずっしりと乗っていて、
一般スキーヤーが普通には滑れる状態ではありませんでしたが、
さすがに、テストライダーとして日本の頂点に立たれているお方だけあって、悪雪などなかったように
キレイなターンをしていただけました。
これだけきれいなターンをしていただいたので、データをみると、雪がたまってない下部の緩斜面では
完璧に近い模範的な滑りのデータとれました。
しかし、上部の重い雪が載っている斜面では、振動と雪がアンテナにかぶるために、RTKもIMUも不調で部分的にしか良いデータはとれませんでした。STAは、天気の良い整地を滑ることを想定して設計してありますので、本日の上部のスキーコースは、STAには、不適だったという判断です。
判った点１：ターン運動の方向角のグラフが三角形に見えるほど、良いターンでした。
三角形ということは、斜辺が直線になるということです。縦軸角度 横軸時間ですので、
傾きが角速度となります。傾きが一定だと直線になるので、角速度が等しい状態でターンをしている
ということが判りました。私などは、三角形ではなく、いびつなサインカーブになっているので
ターン弧の描くときの角速度が一定になるように滑れるのが上手いスキーヤーという法則をみつけました。
判った点２：ターン運動方向角と板の方向角差が横滑り角ですが、これは、ターンの上手い下手の基準になります。私などは、ターン中ずっと２５度から３５度くらいズレて滑ってますが、上手い人のターンでは、横滑り角は５度から０度でほぼゼロベースにあるようになります。その状態を作るために、どれだけの制御をしておられるのかは、板のたわみ前後比率をみれば、納得がいきました。
判った点３：たわみセンサが板の前後２か所に設置してあって、前後のタワミの比率で、スキーヤーの板のタワマセ方が手に取るようにわかります。模範的なターンでは、切り替え時点では、前たわみ状態です。その時は、板の迎え角を選んでいるの波形が僅かに上下振動します。そこから、ターンを決めにはいると前たわみからじわじわと後ろタワミに移動していきます。最後のターン終了までなだらかに後ろタワミを増加させていくのが良いタワマセ方だと判りました。ちょっとでも早めに後ろをたわませると途端に板は横滑りします。前後の荷重の仕方を微妙に調整することでターンを作るということがデータ見える化できたのは画期だと思います。
●以後
４月末から５月にかけて、システムを改善して、再度横田様にテストライドしていただいて、
高速、急斜面でのターンの模範データをとろうと思います。
https://tinyurl.com/293hxncv
今年に入って、ブログのアクセス数が昨年の６０％程度まで減少してます。
特に プログラミング関連記事が激減してます。私自身もそうですが、プログラムでわからない点があると
WEB検索しないで、chatGPTに聞いたほうが気の利いた回答を得られるので、WEB検索よりヒット率が高いです。そういう使い方をする人が増えたので、プログラムを教えるWEB記事は、皆減少していると思います。プログラム学習通信教育講座などは、激減していると思います。AIに食われる現象が身近にせまりつつあることを実感しました。AIで回答がでてくるブログ記事はダメだということです。
これからは、AIに学習を教えてもらえる時代なので、学習塾、専門学校、資格通信講座などは、影響をうけて、消滅するビジネスもあるかもしれないので、皆さんも注意して関わったほうがよいです。
しかし、chatGPTで、判らないことを聞くと、適当な回答が多いので、確実に解決できた例は
１０％程度ですが、検索時間が短くてすむ点がよいです。
●これからのブログ
８年目を迎える電子工作DIYのブログですが、他でやらない記事は元気に生きてます。
① ３Dプリンタで作る防水ケースは、難易度が高いため、WEBでもほとんどないので、AIも良い回答をだしませんので、私のブログの勝です。
②ひずみゲージアンプの選択
これもニッチなのですが、必ず力の測定をしたニーズがあるので、８年間コンスタントにアクセスがあるテーマです。chatGPTに聞くとHX711とアナログアンプしか紹介してくれませんので、本ブログで紹介しているADS122U04の圧勝です。ユーザーもわかっていて、HX７１１でハマったユーザーさんがADS122U04に乗り換えている例が沢山あります。要するにWEBで記事がすくない分野だとAIは回答できないのです。
③RTK
これは、元々ユーザーが少ないので、WEBの情報が少ないので、chatGPTに聞いてもろくな回答がありません。
●AIの及ばないテーマに集中する
AIは、WEB上にない情報は学習できなません。ですので、WEB上にあまり出ないテーマをネタにしていれば、AIに駆逐することなくブログは続けられます。逆に、ブログのアクセス数を狙うテーマだとWEB参照が増えて、AIに検知されるので、いずれは、AIに負けてしまいますので、永遠にニッチでアクセスすうが少ないテーマを数多く掲載するブログが生き残ると思います。ニッチトップということです。
テーマ数を増やす方向性で、２０２５年からは、スキーのRTKだけでなく。強みであるひずみゲージ測定とRTK測定のバリエーションを増やしていこうと思います。
３月１８日に今シーズン初回のスキー場計測しました。
予想外のアクシデントありましたが、毎年のことなので、予想外があることを予想していたので、
生きているデータだけで結構有意意義なデータが得られて、昨年からの１０か月間の開発の成果がでました。スキー場計測はじめたのが２０２０年の１月からですので、５年経過して、随分いろいろ経験して、
技術も向上しました。物事は、石の上にも３年といいますが、やはり３年目からの技術の進歩が著しかったです。誰もやったことがない技術開発でも３年は粘ってやってみるということだと思います。３年間は今から見るとバカみたいな無駄な開発をしていたと思いますが、それらを経て現在があるので、あきらめずに３年間は前向きにつき進めることが重要だと思います。この間、世間様からは、ほとんど本開発の価値を認めてもらってませんが、人の評価など気にせずに自分の価値感でいけばよいと思います。世間が欲しいものなら、どこかで企業が開発してますので、誰も振り向かないのは、未だ世間が潜在ニーズであるのか、全く役にたたない開発かのどちらかです。しかし、DIYの場合は、自分だけのニーズは確実にありますので、完成すれば自己満足にはなるので、それで良いです。
STA25の目玉は、スキー板のたわみセンサを板の前後に装着してあります。これによって、板の踏み方が
ターン中どのように変化してその変化がターンの軌跡と横滑りに及ぼす影響がデータで見られますので、
自分のターンで踏み方とターンの仕上がりが数値で評価できるので、AIのスキーレッスンの基礎データとなるシステムです。未だ、システムが重くて、滑りにくいとか課題がありますが、本質的に使えるとなれば小型軽量化をお金をかければ可能なので、クラウドファンディングにだして、投資を呼べば実現可能です。そうはいっても、応援してくれる人も、小賀坂スキーの横田様という方がテストライドしてご評価していただけます。こういう方は、業界には必ず数人はいらっしゃって、業界の未来を夢みて、世の中のDX化、IOT化とスキー業界という視点で、新しいコト作りに挑戦されてます。業界が進歩するのは、数少ないそのような方々が頑張っているからと思います。
https://tinyurl.com/29vjfok6
