パワーメーター２０１９もロードバイク実走行は、信州松本では、あと10日程度で終わってしまいます。冬シーズンは、QUOBO DIGITAl B+でのトレーニングとなりますが、できるだけ実走行データを収集しようとしてます。7月からスタートしたパワーメーター２０１９ですが、クランクトルクデータの実走行波形と角度を精度よく測定することで3カ月も要してしまいました。10月20日にようやく信州SKYPARKで左右クランクとSeatTUbeのひずみと角度のデータを精度よくログできるようになりました。
２０２０年で、ロードバイク関連のテーマはすべて終了いたしました。読者があまりにも少ないので止めました。
※2020年12月11日追記
4年にわたって、ロードバイクパワーメーターを開発してきましたが、2020年前半で、左右クランクのパワー解析が完了して、次にやるべきことが見えてきました。本記事は2019年の結果ですが
201６年から2019年までの3年間は、計測技術力が未熟で、まともなパワーメーター計測ができてなかったということだと思います。2020年になって、一挙に3年間の技術課題をクリアできて全体が見えるようになりましたので、基礎技術力がないといろいろなことをやろうとしても空転するだけだということを思い知りました。そこで、2020年夏からは基礎技術力強化としてロードバイクパワーメーターというアプリケーションを離れて、リアルタイムシステムを作るためのプログラミングと6分力センサを短時間に干渉補正できるシステム（SCP）を開発することに注力してます。
基礎技術力さえあれば、ロードバイク分野もいとも簡単に全容みえてくると思います。
2021年以降で、ロードバイク全体にかかる力のベクトルをリアルタイムに見えるシステムを開発していきます。クランクだけの力でなく、ハンドル、サドルにかかる力、重心の動き、走行抵抗などすべての力をセンシングするトータルしたシステムとしてパワーメーター開発をしていきます。
ブログ運営上、ロードバイク関連の読者が全体の２％程度しかいませんので、投稿は、ほとんどしません。投稿しても見る人がほとんどいないということですので、自分で整理ができたところで投稿することにしました。世の中で、ロードバイクの科学に興味のある人は稀にしかいないということだと理解してます。
●この3カ月での得られた知見
| 感想 | ほとんどがXbeeからのデータ落ちなく受信ログするための対策で時間をつぶしてしまいました。本来はSEATTUBE型とクランクのトルク波形の精度よい比較を目的にしていたので、クランクのデータをSDカードにログすれば無線は不必要だったのですが、XBEEを使うことに執着して3カ月無駄にしてしまいました。 ①電池寿命とデータ測定精度と信頼性は反比例しますので、電池寿命を犠牲にしないと精度のよい測定はできません。 ➁CPUもクロック60MHz以上でFLASHが64KB以上でないとまともなデータ処理（移動平均等）できません ③計測用途で非力なマイコンを使うこと自体が問題であると思うようになってます。ラズパイとかPCをできるだけ使って高速なクロックのCPUと潤沢なメモリを使えるハードで計測すべきです。 ④無線も汎用システムを使うのは限界があります。計測のプロの世界では、汎用の無線規格ではなくテレメトリー技術は独自のものを使って短距距離の無線通信方式を使ってます。ですので、ロードバイクも専用の無線通信方式があってしかるべきだと思います。 日立のタービン翼の論文ではFM電波でデータ通信してます。 https://www.hitachihyoron.com/jp/pdf/1972/09/1972_09_11.pdf東陽テクニカの販売しているシステム https://www.toyo.co.jp/files/user/img/download/mecha/pdf/J2D_J2DT_J1D_J4T_J1_catalog.pdf |
| ０： | パワーメーターって何だ？という本質的な問いかけが必要だと感じてます。 シートチューブのひずみを測定しているとトルク波形以外に無駄となった踏力成分もシートチューブのたわみエネルギとして計測データにでてきてます。人間のだしているパワーはクランクのトルク以外にもいろいろあるのに、現在パワーメーターは、推進に使われるエネルギしか計測してません。この点で、自分の運動量を表すには、シートチューブのたわみのほうが無駄なエネルギーもデータとして取得できるので面白いなと感じてます。人間の運動のパワーを測定するという広い視野にたつと、現在のロードバイクのパワーメーターの範疇では、将来性がないかなと感じてます。信州MAKERSでは、より広い視野にたってパワーメーターの開発をしていこうと感じました。これが2019年の最大の知見です。 |
| １： | Xbee通信速度が38400bps以上の場合、データ落ちが増加して通信の信頼性がなくなることを体験したZIGBEE規格の無線通信は、信頼性が軟弱でした。WIFIのほうが良いかも。 第一：フロー制御をいれること 第二：Xbee電源のノイズを減らす 第三：距離は短く障害物は無しとする 結論：2019年10月20日の実走行試験結果で、ベストのデータがとれました。5～10分間のデータ測定でデータ落ちが１－２個程度までの信頼性になってきてます。 条件は、Xbee 57600bps Hardwareフロー制御、マイコンデータ通信周期10msecと長くとって Xbeeの通信エラーに対処してようやくデータ落ちがなくなってきました。 ※使用マイコンは、STM32F103T8C6 CortexM3 72MHzです。Arduino系ATMEGA328Pなど低速のCPUを使うと57600bps以上で信頼性のある測定はできませんでした。 |
| ２： | 無線通信で、データを測定した場合そのデータのタイムスタンプを必ずつけて送信すること 高速CPUを使わないとタイムスタンプの精度もでませんでした。 |
| ３： | マイコン割り込みを使って複数CHのデータをログする場合、１Chの処理時間の和以上の周期時間をとらないとバッファエラーになってしまう。例えば、Xbee通信だと115200bpsで２５バイト送信するには計算値で2.17msecかかりますので2chで4.34msecですので、Xbee受信するだけで4msec以上の周期になってしまいますので、ペダリング波形の高速サンプリングでは、1つのマイコンで割り込み受信は、無理なことが分かります。１CH毎に受信ログしないと数msecのデータ測定はできないということになります。 |
| ４： | ひずみアンプはアナログのLT1167のほうが応答が早くてよいです。高精度ADCは、プログラムがうるさく周期も制限をうけて数msecの遅延がでるので、動的に精度がうるさいデータ測定は、アナログの計装アンプがよいです。 |
| ５： | IMUもI2Cの9軸LSM9DS１を使ってますが、フルデータを取得するのに5msec以上かかってしまうので他のセンサと共有してデータログするわけにはいきませんでした。やはりアナログのIMUのほうが高速応答できますが、ノイズが大きいので高級なアナログIMUを使うしかありません |
| ６： | ローラ台でOKでも実走行ではいろいろトラブルがあります。振動と環境の影響で電波の飛びがかわったり電池の接触、コネクタの接触不良がおきやすいので、実走行で計測するには、相当の試行錯誤が必要です。 |
●方向性
●以後
10月末までに、できるだけ実走行データを取得して11月以降にデータ処理したいのですが、3ポートのUSBシリアルを3個のTeraTermでログしていると後の処理時間が数時間かかってしまうので、一挙に3ポート同時受信して処理しながログできるプログラムを作ってから実走行データをとったほうが早いので、Processingのプログラム急いで作ってます。
