公開日：2023/02/25

24th Season

#24-7　万歩計をスマートに作ろう

　Arduino DUEで作った万歩計が有りました。

　　「#21-8　万歩計を作ろう」

　　「#22-3　万歩計を完成させる」

　Arduino DUEに、加速度センサ(MPU9250)、OLEDディスプレイ、モバイルバッテリを組み合わせて作りました(下図)。



　写真には写っていませんが、USBケーブルの先にはモバイルバッテリが接続されていて、かなり大きな装置です。こんな物をぶら下げて外を歩きたくなかったので、家の中で歩き回って動作確認しました。実験中の様子はこちらです。

　この様な万歩計を、今回はM5StickC Plus(下図)を使って作ろうと思います。



　DUEの外部に必要だったモジュールや装置が全てオールインワンとなっている機体なので、スマートに実装できると思います。

MPU6886の制御

　万歩計を作成するに当たって、一番のキーモジュールである加速度センサから検討を始めます。

　M5StickC Plus内蔵の加速度センサはMPU6886と言って、DUEで万歩計を作った時に使ったMPU9250と同じ、InvenSense社製です。計測できるデータも、使い勝手も、ほぼ同じであると期待できます。

　　MPU6886のデータシートを検索する(別ウインドウが開きます)

　DUEの時に歩行時のデータを取得し、歩行検知のモデリングと検出アルゴリズムを完成させているので(下図)、プログラムの主たる部分は、そのまま使えると思います。と、言うより、そうできるようにプログラムするべきでしょう。新たにM5StickC Plusでデータを取りなおして、歩行検出アルゴリズムの調整を繰り返すのはシンドイですから。




　MPU6886の制御に関しても楽ができるように、M5StickC Plusライブラリに備わったM5．Imuクラスを、そのまま使おうと思いました。初期化は、M5．Imu．Init()メソッドが用意されているのですが、これを使って初期化すると、色々意に沿わない設定値が書き込まれてしまって、宜しくありません……。
　MPU6886の初期設定は、自分でやらないとダメみたいです。MPU6886はI2C(Wire1)でESP32と接続されているので、Wire1クラスを使ってI2Cで制御できます。

　最初に、MPU6886モジュールのPWR_MGMT_1レジスタに対して、DEVICE_RESETビットに1を設定し、MPU6886のI/Oレジスタを初期設定に戻します。そこから、加速度センサの読み出しにデジタルLPFを適用しない設定値を書き込みます(ACCEL_CONFIG2レジスタ)。それ以外は初期値のまま使います。

　　// MPU6886 setting
　　// PWR_MGMT_1.DEVICE_RESET=1
　　i2c1_write (i2c_MPU6886,0x6b,0x80);
　　while (i2c1_read (i2c_MPU6886,0x6b)&0x80)
　　　　;
　　// PWR_MGMT_1.GYRO_STANDBY=0, CLKSEL=0b001
　　i2c1_write (i2c_MPU6886,0x6b,0x01);
　　// ACCEL_CONFIG2=bypass LPF
　　i2c1_write (i2c_MPU6886,0x1d,0x08);

　DUEで作った歩行検出アルゴリズムでは、10ms(＝ped_msec_ITVL)毎にサンプリングした加速度の移動平均(ped_MAX_MVA＝16区間)を取っています。移動平均もLPFに相当するため、MPU6886のLPF機能が活きていると、二重にLPFが適用されてしまって、歩行検出の閾値などの変更が必要になってしまいます。
　MPU9250は初期値がLPF無効だったのだけど、MPU6886は初期値がLPF有効なので、無効化設定(ACCEL_CONFIG2レジスタ)が必要となりました。
　これにて、MPU6886の動作設定と、MPU9250の動作設定が合いました。

　ここまで自分でI2C経由で直接MPU6886を制御したら、加速度データの読み出しも直接I2C読み出しでも良いのだけど、一応、M5．Imu．getAccelAdc()メソッドが使えます。

※折角のM5StickC Plusライブラリなのだけど、TFTディスプレイの制御関係以外、何だかんだで、思いのままに使えない気がするのは気のせいかしら？もう少し楽ができると期待して使い始めたのだけど……。汎用のライブラリなんて、所詮この程度なのかな？

共有リソースの管理

10ms毎のサンプリングと、歩行検出

　これをloop()関数内の実時間(millis()関数値)、10ms(＝ped_msec_ITVL)間隔で実行しています。このサンプリング周期が乱れると、歩行検出のアルゴリズムが乱れ、うまく歩行が検出できなくなってしまいます。
　ところが、普通にTFTディスプレイ全体を描画させたところ、100ms近く必要(@240MHz)なことが判りました。loop()関数内でTFTディスプレイの表示を更新してしまうと、10ms毎のサンプリングが破綻してしまいます。

　解決策は色々あって、例えば、表示を複数回に分けて描画する様にして、1回当たりの描画時間がサンプリング周期(ped_msec_ITVL)未満に収まるように調整することもできます。ただし、この場合、CPUの動作周波数を変更すると10ms未満で描画可能な処理量も変化するため、一々調整が必要になります。

　今回は、FreeRTOSのスレッドを使った並列処理(下図ｃ)でTFTディスプレイを更新することにしました。



　サンプリングして歩行検出する処理(task1)と、TFTディスプレイの表示を更新する処理(task2)を並列処理することで、表示を複数回に分けて描画する様な「調整」作業が不要になる反面、共有リソースの管理が必要となります。

　各処理に於いて、どのようなリソースが必要となるのか？確認して行きましょう。

メインプロセス(歩行検出)

　メインプロセス(loop()関数)では、10ms(＝ped_msec_ITVL)毎に加速度センサ(MPU6886)を読み出して、歩行検出を実行します。
　メインプロセスは以下のリソースを使います。

• 加速度センサ(MPU6886)
• 歩行検出のため、加速度データを読み出す。
• I2C(Wire1クラス)
• MPU6886はI2Cで通信するモジュール。
• Wire1クラスを使う。

サブスレッド(表示の更新)

　TFTディスプレイの表示を司るサブスレッドを起動しておきます。
　このスレッドは500ms毎に変数thrd_upd_screenを監視して、thrd_upd_screen＝trueを確認したら表示を更新します。更新が終わったらthrd_upd_screen＝falseに戻します。

　サブスレッドは以下のリソースを使います。

• TFTディスプレイ
• TFTディスプレイを更新するので自明。
• SPI通信
• TFTディスプレイのドライバチップST7789はSPIで通信するモジュール。
• 電源管理IC(AXP192)
• TFTディスプレイに、現在のバッテリ残量を表示するため、AXP192からバッテリ電圧を読み出す。
• I2C(Wire1クラス)
• AXP192はI2Cで通信するモジュール。
• Wire1クラスを使う。

　以上をまとめてみると、以下表の様になります。

　I2C(Wire1クラス)だけは、メインプロセスとサブスレッドの両方が使うため、共有リソースであると判りました。I2C(Wire1クラス)は、メインプロセスとサブスレッドのどちらかが排他的に使用しなければなりません。同時にI2C(Wire1クラス)を使用してしまうと、どこかで予期せぬ動作となって誤動作することになるからです。
　見かけ上、「MPU6886とAXP192を使う」とだけ考えてしまうと、I2Cが共有リソースであることを見落としてしまいそうですが、見落とさないように。

　なお、TFTディスプレイの表示は全てサブスレッドが担当する分業制にしたのですが、もし、メインプロセスでもTFTディスプレイを更新するようなプログラムにするなら、TFTディスプレイ(SPI)も、共有リソースとなってしまいます。
　並列処理を実装する場合、共有リソースは何と何なのか？十分吟味して、基本設計をしっかり実施しなくてはなりません。

セマフォ

　共有リソースの排他的使用を制御するのに、セマフォ🏁を使います。

　M5StickC Plusに搭載されているFreeRTOSには、セマフォAPI(関数)が整備されています。

• xSemaphoreCreateMutex()関数：
• セマフォを使うため、まず、この関数でセマフォハンドルを作成します。
• 作成したセマフォは、Giveの状態で生成されるようです。
• 今回使いたいセマフォはMutexタイプですが、他にBinaryタイプ、CountタイプのAPIも使えます。
• 用途に応じて、必要なタイプのセマフォを選んで使ってください。
• xSemaphoreTake()関数：
• 自分が共有リソースの使用権を獲得するため、セマフォを取得します。
• セマフォを取得できた時はtrue、できなかった場合、または既に取得していた場合にはfalseが返ります。
• xSemaphoreGive()関数：
• 自分が共有リソースの使用権を放棄するため、セマフォを解放します。
• セマフォを解放できた時はtrue、できなかった場合、または既に解放していた場合にはfalseが返ります。
• xSemaphoreGetMutexHolder()関数：
• 現在、誰がセマフォを取得しているか？調べる関数です。
• 返り値は、セマフォを取得中のタスクハンドルです。
• 誰もセマフォを取得していなかった場合には、NULLが返ります。
• xTaskGetCurrentTaskHandle()関数：
• 実行中タスクのタスクハンドルが返ります。
• xSemaphoreGetMutexHolder()関数で返ったタスクハンドルが、自分の物かどうか？を知るために使います。

　詳細な使い方については、FreeRTOS公式HPまたはESP-IDFリファレンスページを参照してください。次回完成させるプログラム(m5cp_pedometer.ino)を参照すると、具体的な使用例をご確認いただけます。sem_wire1()関数辺りで集中して使っています。

　基本的な処理の流れは以下の通りです。

　セマフォが複数のスレッドに対して同時に許可されることはありませんので、上の様にセマフォを取得(take)してから、解放(give)するまでの間に共有リソース(I2C)を使用すれば、その共有リソースは必ず、唯一のスレッドだけが使用することになります。
　共有リソースを他のスレッドが使っていて、セマフォを保持している場合、セマフォを取得できない場合があります。必ず、xSemaphoreTake()関数でセマフォを取得できた事を確認してから、共有リソースを使用してください。

※セマフォを取得できなかった場合は、１）取得できるまでずっと待つ、か、２）一旦共有リソースの処理を保留して別な処理を実行後、改めてセマフォを取得する等の対応が必要です。

低消費電力化

　万歩計のプログラムでは歩行を検知するため、常に加速度センサを参照しながらCPUが処理する必要があり、動作中は電源を遮断できません。身に着けて使う物なのでバッテリ動作が基本となりますが、万一、動作中にバッテリ残量が無くなって電源が遮断されてしまうと、歩数などのデータは消えてしまいます。
　消費電力の削減は重要な課題なのです。

　と、言っても、出来る事と言えば以下くらいしか思い当たりませんでした。

• １）ESP32の動作クロック周波数を下げる。
• Arduino IDEでコンパイルする時にESP32のクロック周波数を指定できる(下図)。
• 
  
  
  
• 単純計算では、F_CPUを半分の周波数にすれば、単位時間当たりの消費電力も半分になる。
• バッテリ動作可能時間は2倍に伸長する。
• あくまで単純計算。ESP32以外で電力を消費している回路もあるので、単純計算通りには行かないはず。
• どこまでバッテリ動作可能時間を延ばせるか、次回実験で試してみる。
• ２）TFTディスプレイのバックライトをOFFする。
• M5StickC Plus公式HPの回路図や電源グリッド図等によると、TFTディスプレイ関係の電源は以下の2系統。
• LDO2：　バックライト
• LDO3：　ドライバチップST7789と、TFTパネル本体
• ST7789＋TFTパネルの電源(LDO3)も遮断可能だけど、これは遮断しない。
• ST7789の電源LDO3を遮断する場合、電源LDO3を投入する度にST7789の初期設定が、やり直し。
• 電源を遮断したチップ(ST7789)に接続された信号線は、HIGH-ZまたはLOW出力にする必要があるので、回路図を見ながら、接続されている信号線を全て処理しなくてはならない。
• 極めて面倒なので、バックライトだけON／OFFする。
• バックライトは、M5StickC PlusライブラリのM5．Axp．SetLDO2()メソッドで制御(ON／OFF)できる。
• バックライトOFFの間は、TFTディスプレイ表示を更新しないようにしておくと、SPI通信やサブスレッド側CPUの動作で消費される電力も削減できる。
• バックライトを完全にOFFしないまでも、M5．Axp．ScreenBreath()メソッドを使って、明るさ(従って消費電流)を制御することは可能。
• 万歩計は、現在の歩数を確認したいとき以外は表示を見る必要が無いので、歩数計測中はバックライトOFFを基本として、明るさの制御は未実施とする。
• ３）5V電源のレギュレータを停止する。
• M5StickC Plusボード上で5V電源を生成する、昇圧レギュレータSGM6603がある。
• 5Vへの昇圧なので、5V電源を使っていないとしても、チャージポンプが動き続けて電流を消費している。
• M5StickC Plusボード上では5V電源は未使用なので、5V出力端子を使用しないのであれば、レギュレータSGM6603を停止することができる。
• レギュレータ(SGM6603)を停止すると、多少の電力は削減できるかもしれないけど、未実施とする。
• 停止はAXP192のI/Oレジスタを設定すると可能だが、M5．Axpクラスには実装されていない。
• 自分でI2Cを叩いて設定しなければならない。
• I2Cは共有リソースなので、セマフォを使って排他制御する必要がある。
• 手間がかかる割に、効果の程が明確ではない。

　３）の5V電源以外の対策は実施しておこうと思います。しかし、バッテリ動作可能時間には、少し課題が残るかもしれませんね。

ログを残す

　バッテリ動作可能時間を評価するため、時間経過とバッテリレベルの推移をログに残し、シリアルモニタから読み出せるようにしておこうと思います。
　どうせログを残すなら、歩数の時間推移も一緒に残しておくと、後でExcel等のソフトウェアに読み込んで、時間帯毎に、歩行速さや歩行距離などのデータを計算できます。所望のグラフ作成なども実施できて良いだろうと考えました。

　万歩計の計測データから消費カロリまで算出するためには、歩数と歩行時間の2つの情報が必要です。

　　ログ記録仕様：

• 毎時、ped_MINU_LOG分毎にログを残す。
• デフォルトではped_MINU_LOG＝1分に設定してある。
• RTCから読み出した実時間で、<分>%ped_MINU_LOG＝0となったタイミングで記録する。
• 例）ped_MINU_LOG＝25なら、毎時0分、25分、50分、の繰り返し。
• 「ped_MINU_LOG分毎(0分、25分、50分、75分、100分、125分、……)」ではないので注意。
• 等間隔でログを取りたいのなら、ped_MINU_LOGを、60(＝2×2×3×5)の約数に設定する必要がある。
• また、実時間を取得する必要があり、RTC(BM8563)からデータを読み出すことになる。
• RTC(BM8563)の制御もI2C(Wire1関数)なので、セマフォを使って排他的に制御しなくてはならない事に留意。
• ログに残す情報は以下の3点。
• 記録時の日時とバッテリレベル
• mmddHHMMBLとした、10進数10桁の数値で記録する。
• mm月、dd日、HH時、MM分のログ。
• BLは、記録時点のバッテリレベル0〜99[%]。
• バッテリレベルBLは100%になることが有り得るが、桁数が足りないので99として記録する。
• 最大値は12月31日23時59分99%の場合で、1,231,235,999なので、32ビット整数で充足。
• 記録時の歩数
• 起動時点からの累積歩数。
• 32ビット符号無整数値で記録しておけば十分。
• 記録時の歩行時間
• 起動時点からの累積歩行時間。歩行を検出していた時間をミリ秒単位で記録する。
• 32ビット符号無整数値で記録すれば、約1,193時間(≒50日)まで記録できるので、十分であろう。
• 従ってログは、3(＝ped_ELM_LOG)ロングワード×記録数のデータ領域を要する。
• ログ用の記憶領域は、ped_MAX_LOG＝ped_ELM_LOG×24時間×60分≒17Kバイトとしてある。
• そもそも、M5StickC Plusのバッテリは1日なんて持たないし、これだけ確保してあれば十分なはず。
• 万が一、全ログ領域を使い切った場合には、先頭に戻って一番古いデータから上書きする仕様とする。
• ESP32のRAM(MAX 320Kバイト)には、まだ余裕があるので、大きくすることは可能。

　身長・体重などの情報はExcel等のソフトウェアで計算する時に設定できるので、上仕様のログデータは身体的特徴に依存しません。METsの変換テーブルなども用意しておけば、ログデータから消費カロリなどを算出可能となります。計算方法については「#22-3　万歩計を完成させる」を参照してください。

　次回、残りの設計を終わらせて、万歩計を完成させたいと思います。