Arduinoは1.8.19をインストールしましょう。追加のボードマネージャのところに
https://dl.espressif.com/dl/package_esp32_index.json,http://arduino.esp8266.com/stable/package_esp8266com_index.json,https://files.seeedstudio.com/arduino/package_seeeduino_boards_index.json
と書きます。そうすると，

ボードマネージャに，ESP32がでるので，とりあえず3.3.0をインストールしてください。

ボードマネージャからXIAOESP32C3を選びます。で，接続されているComを確かめて指定します。で，

センサーを動かすには二箇所のジャンパー(I2Cと6A。添付右画像の通り)を埋める必要がある。あとは配線。
オレンジがi3-i9。
青がh2-h10。
黄色がb2-c15。
紫①b3-b16。
紫②b4-h15。
マイコンの位置と，センサーの向きに注意。白いコネクタが下側にくるように。

下記ダウンロードボタンから必要ファイルをダウンロードする。
I2C_Scanを書き込み，0x6Aが出てくればセンサーは見えている。
LSM6DSVを送って，ジャイロの波形が出れば動作OKです。今日はここまでにしましょう。カレーおいしかった。

難消化性デキストリン，イヌリン，なにもなしで，おにぎり一個食べたあとの血糖値を比較した動画，実測なのが良い。カーブは難デキのほうがジワジワ効くという先行研究どおり。GPR41とGPR43て有名なんですね。確かに，難消化性デキストリン漬けになってから冬の寒さを感じにくくなった。エネルギーを消費しやすく，脂肪をためにくく，免疫強化され，感染症やがんが遠のく・・・。これって，アンチエイジングよね。

自作フルトラッキングは、XIAOESP32C3+LSM6DSVでトラッカーを作成し、SlimeVRに認識させることができたので、手順をまとめておこう。
開発環境の準備
VisualStudioCodeでPlatformIO使う。インストールしたら、SmileVRのファームウェアをGitでローカルフォルダにクローンする。これらの手順はこのページにまとめられている。
ファームウェアの準備
プロジェクトのplatformio.iniファイルから、ファームウェアの設定（使うマイコンやセンサーの種類）を行う。ここに手順が記載されている。ここには、SlimeVRで使用される主要なマイコン用の設定が、あらかじめ何種類も記載されている。ESP8266、ESP32系が多いが、ここではXIAOESP32C3を想定する。冒頭default_envsで指定した設定でプログラムのビルドが行われる。ここではseeed_XIAO_ESP32C3という設定を新たに追加して使用している。「WifiのSSIDとパスワードをハードコードするばあいはここに書け」とあるが、ここのSSIDとPWは機能しない。これに長時間悩まされることとなる。

[platformio]
build_cache_dir = cache
;default_envs = seeed_xiao_esp32s3
default_envs = seeed_XIAO_ESP32C3

（中略）

;If you want to set hardcoded WiFi SSID and password, uncomment and edit the lines below
;To uncomment, only remove ";" and leave the two spaces in front of the tags
; '" - quotes are necessary!'
  -DWIFI_CREDS_SSID='"HELL"'
  -DWIFI_CREDS_PASSWD='"koda・・・・"'

（中略）

[env:seeed_XIAO_ESP32C3]
platform = espressif32 @ 6.7.0
platform_packages =
  framework-arduinoespressif32 @ https://github.com/espressif/arduino-esp32.git#3.0.1
  framework-arduinoespressif32-libs @ https://github.com/espressif/arduino-esp32/releases/download/3.0.1/esp32-arduino-libs-3.0.1.zip

board = seeed_xiao_esp32c3

build_flags =
  ${env.build_flags}
  -DESP32C3
  -DARDUINO_USB_MODE=1
  -DARDUINO_USB_CDC_ON_BOOT=1

monitor_filters = colorize, esp32_exception_decoder
board_build.filesystem = littlefs

センサーの準備
センサーの設定はdefines.hから行う。解説ページで作ることもできるが、XIAOESP32C3の作成事例を参考に手動で作るのが良い。
①IMUをLSM6DSVに指定
②IMUの回転角度を指定（サンプルは解説ページにあるがよくわからない）
③セカンドIMUのあるなしを指定。
④LSM6DSVとのI2C接続（SCLとSDA）に使う端子を指定。SeeedのXIAOESP32C3マニュアルを見ながら指定する。ここでは作成事例に倣いD1とD2に指定。
⑤LSM6DSVの割り込み端子を指定する。IMUが測定完了をマイコンに知らせる端子(INT1)があり、これをつなぐと処理がスムースになるので必ずつなぐ。INT2はなくても良いらしいのでダミーとなっている。
⑥PIN_BATTERY_LEVELは電池電圧を調べる端子を指定する。ここではD0。Battry関連の設定を適切に行うと、適度な電圧低下でマイコンをスリープさせて電池を破損から守ってくれる機能があるらしい。
　上記設定にしたがって組み上がったトラッカーが、以下のブレッドボードとなる。どうにか動いているがD0未接続ですね。電池駆動にした際、電池の出力を分圧した値をD0に入れると思われる。センサーの設定は重要で、接続に失敗するとトラッカーが起動しなくなり、シリアル・ポートにログが出なくなるので注意。

#define IMU IMU_LSM6DSV
#define SECOND_IMU IMU
#define BOARD BOARD_CUSTOM
#define IMU_ROTATION DEG_180
#define SECOND_IMU_ROTATION DEG_180
 
#define PRIMARY_IMU_OPTIONAL false
#define SECONDARY_IMU_OPTIONAL true
 
#define MAX_IMU_COUNT 1
 
#ifndef IMU_DESC_LIST
#define IMU_DESC_LIST \
    IMU_DESC_ENTRY(IMU,        PRIMARY_IMU_ADDRESS_ONE,   IMU_ROTATION,        PIN_IMU_SCL, PIN_IMU_SDA, PRIMARY_IMU_OPTIONAL,   PIN_IMU_INT) 
 
#endif
 
#define PIN_IMU_SCL D1 //D1
#define PIN_IMU_SDA D2 //D2
#define PIN_IMU_INT D3 //D3
#define PIN_IMU_INT_2 D4 //D4
#define LED_PIN LED_OFF //OFF
 
#define PIN_BATTERY_LEVEL D0 //D0/A0
#define BATTERY_MONITOR BAT_EXTERNAL
#define BATTERY_SHIELD_RESISTANCE 0 
#define BATTERY_SHIELD_R1 100
#define BATTERY_SHIELD_R2 100

ビルドして送信し動作チェック
platformio.iniとdefines.hの準備ができたら、ビルド（✓ボタン）して送信（→ボタン）する。キャッシュが悪さをすることもあるようなので、Clean（左の虫アイコン→ボード→Generalからアクセス）もたまにする。送信が終わったら、シリアル・ポートを開く（コンセントのボタン）。適切にできていると、トラッカーからシリアル・ポートに起動メッセージが出力される。センサー認識メッセージに感涙の涙・・・。
Wifiログインできない問題
しかし、ハードコードしたSSIDとパスでアクセスポイントが見つけられない問題に直面する。ルータ側もチェックするが問題はなさそうであり、結局ソースコード（wifihandler.cpp）に手をいれるはめに。具体的には、ESP8266じゃないとき（つまりESP32である今回のようなとき）if (phyModeG) {return false;}となり、問答無用で何もしない設定になっていた。ここに接続用のコードを追記することでサーバーへの接続が可能となり、スマホのSlimeVRアプリにトラッカーを出すことに成功した。同じソースコードでS3も試したが、こちらはどうも様子がおかしく信号が安定しない。今回はC3で行くか。

bool WiFiNetwork::tryConnecting(bool phyModeG, const char* SSID, const char* pass) {
#if ESP8266
	if (phyModeG) {
		WiFi.setPhyMode(WIFI_PHY_MODE_11G);
		if constexpr (USE_ATTENUATION) {
			WiFi.setOutputPower(20.0 - ATTENUATION_G);
		}
	} else {
		WiFi.setPhyMode(WIFI_PHY_MODE_11N);
		if constexpr (USE_ATTENUATION) {
			WiFi.setOutputPower(20.0 - ATTENUATION_N);
		}
	}
#else
	/*
	if (phyModeG) {
		return false;
	}
	*/
	///////////////////////////////
	wifiHandlerLogger.info("ESP32: resetting WiFi state before begin()");
	WiFi.disconnect(true);
	delay(200);
	WiFi.mode(WIFI_STA);
	delay(50);	
	////////////////////////////////


	if (phyModeG) {
		// ESP32: PHY mode cannot be changed like ESP8266.
		// Treat "G retry" as a normal retry.
		wifiHandlerLogger.warn(
			"ESP32: PHY Mode G requested but not supported. Falling back to normal connect. SSID='%s' passLen=%d",
			(SSID ? SSID : "<saved>"),
			(pass ? (int)strlen(pass) : -1)
		);
		Serial.println("###DBG### ESP32 phyModeG requested -> fallback to normal connect");
		phyModeG = false; // 以降は通常接続として進める
	}

#endif

	/////////////////////////////////////////////
	wifiHandlerLogger.info(
		"###DBG### WiFi.begin about to run: SSIDptr=%p SSID='%s' passLen=%d phyModeG=%d",
		SSID,
		(SSID ? SSID : "<saved>"),
		(pass ? (int)strlen(pass) : -1),
		(int)phyModeG
	);
	Serial.println("###DBG### tryConnecting entered");
	/////////////////////////////////////////////

	setStaticIPIfDefined();
	if (SSID == nullptr) {
		WiFi.begin();
	} else {
		WiFi.begin(SSID, pass);
	}
	wifiConnectionTimeout = millis();
	return true;
}

SlimeVR導入ガイドによれば、オンラインフラッシャーはユーザーフレンドリだが、PlatformIO版の方が小回りが効くらしい。オンラインフラッシャーにS3ボードがなく、いきなりPlatformIO一択になる。ArduinoはQualcomに買われて廃れる運命にあるようだし、PlatformIOに移行するか。
VSCodeインストール、SlimeVRのgitをクローン、など進め・・・接続するIMUにあわせてdefines.hを作成する必要があるらしい。具体的になってきたね。ふむ・・・このセッティングだと、センサーはYが下を向いているようだね。直感的にDEG0か180に思えるが、素直に考えれば180か？

defines.hは下記のように。公式ページで作ってもらったファイルをもとに、ESP32C3の接続事例も参考にしながら書き進む。SDA/SCLなどのピン番号はXIAOS3のマニュアルに従い、GPIOの番号で指定するようだ。INTはLSM6DSV側に端子があり、ここから「測定が完了した」という信号を受け取り、サンプルすることで効率がよくなるので、つなぐのが一般的なようだ。platformio.iniのdefault_envsは「BOARD_ESP32S3_SUPERMINI」にしてある。とりあえずビルドはできるし、書き込むこともできる。が・・・

#define IMU IMU_LSM6DSV
#define SECOND_IMU IMU
#define BOARD BOARD_CUSTOM
#define IMU_ROTATION DEG_180
#define SECOND_IMU_ROTATION DEG_180

#define PRIMARY_IMU_OPTIONAL false
#define SECONDARY_IMU_OPTIONAL true

#define MAX_IMU_COUNT 1

#ifndef IMU_DESC_LIST
#define IMU_DESC_LIST \
    IMU_DESC_ENTRY(IMU,        PRIMARY_IMU_ADDRESS_ONE,   IMU_ROTATION,        PIN_IMU_SCL, PIN_IMU_SDA, PRIMARY_IMU_OPTIONAL,   PIN_IMU_INT) 

#endif

// Battery monitoring options (comment to disable):
// BAT_EXTERNAL for ADC pin, BAT_INTERNAL for internal - can detect only low battery, BAT_MCP3021 for external ADC
#define BATTERY_MONITOR BAT_EXTERNAL
#define BATTERY_SHIELD_RESISTANCE 0 //130k BatteryShield, 180k SlimeVR or fill in external resistor value in kOhm

#define PIN_IMU_SDA 5  //D4-GPIO5
#define PIN_IMU_SCL 6  //D5-GPIO6
#define PIN_IMU_INT 7  //D8-GPIO7
#define PIN_IMU_INT_2 8 //D9-GPIO8
#define PIN_BATTERY_LEVEL 4 //D3/A3-GPIO4

書き込めるが、ESP32でファームウェアが動いてるのか動いてないのかわからん状態で小一時間ほど。。いや、20時間ほど・・・。以下はXIAOC3用。

#define IMU IMU_LSM6DSV
#define SECOND_IMU IMU
#define BOARD BOARD_CUSTOM
#define IMU_ROTATION DEG_180
#define SECOND_IMU_ROTATION DEG_180

#define PRIMARY_IMU_OPTIONAL false
#define SECONDARY_IMU_OPTIONAL true

#define MAX_IMU_COUNT 1

#ifndef IMU_DESC_LIST
#define IMU_DESC_LIST \
    IMU_DESC_ENTRY(IMU,        PRIMARY_IMU_ADDRESS_ONE,   IMU_ROTATION,        PIN_IMU_SCL, PIN_IMU_SDA, PRIMARY_IMU_OPTIONAL,   PIN_IMU_INT) 

#endif

#define PIN_IMU_SCL D1 //D1
#define PIN_IMU_SDA D2 //D2
#define PIN_IMU_INT D3 //D3
#define PIN_IMU_INT_2 D4 //D4

#define LED_PIN LED_OFF //OFF

#define PIN_BATTERY_LEVEL D0 //D0/A0
#define BATTERY_MONITOR BAT_EXTERNAL
#define BATTERY_SHIELD_RESISTANCE 0


#define BATTERY_SHIELD_R1 100
#define BATTERY_SHIELD_R2 100

LSM6DSVのチェック用Arduinoプログラムはここに保存しておこうか。

Snapmaker U1は ，家庭や小規模工房向けの「本格的マルチカラー・マルチ素材対応FDM 3Dプリンター」 である．2025年後半にクラウドファンディングで大きな注目を集め，既存機の枠を超えた機能を備えている．このタイプでは驚くほど安い．

レビュー動画
　多色・多素材プリントはロマン．動画によれば，プリント開始の時間の遅さとソフトウェアの接続不具合が問題として挙げられている．追々改善されそう．

前回，Fitbitから得られる歩数データをPHPで365日分取得しcsv形式でダウンロードするプログラムの開発と，24時間データ（Intraday）を取得するために，Googleに申請フォームを送った．審査に数週間～数か月かかるということで，その間に各種指標の1日1個データを取得するプログラムを歩数データ取得用プログラムをベースに改造する．

過去3年分の安静時心拍数の推移
・365日分取得できるため，3回に分けて取得した．ChatGPTもグラフを読めているため，AIに健康管理してもらうアプリもできそうだ．
・ストレスイベントを越えてから，RHR70~80が，54~66bpmまで落ちた！

1. 歩数・消費カロリー取得用
・login（リンク），STEP（リンク），CALLO（リンク）はこちら．
・ユーザー側も自身の歩数データをcsv形式でDLできるようにした．
・各種指標で混ざらないように，csvの保存場所を階層ごとに分けた．
・Fitbitアプリと一致．これも1時間ごとにデータを取得できたんだ．

Fitbitアプリ更新した瞬間にPHPの波形も更新されてて凄いな．Pythonの時は，Too Many Requestで怒られてたから，リアルタイムの反映は難しかったんだよなぁ．

2. RHR・RMSSD取得用
・RHR（リンク），daily RMSSD（リンク）はこちら．
・RMSSDは30日ずつしか取得できないようだ．なので内部処理で13回（365日分）呼んで表示した．この方法だと，複数回読んでいるため取得漏れの可能性がある．
・Fitbitで取得するRMSSDは，daily（1日分）とdeep（深睡眠）が取得可能．そのため，csvでダウンロードした時には，下記画像のように両方表示するようにした．

3. 睡眠データの取得
・Sleep（リンク）はこちら．
・こちらもグラフ上ではMainLenのみだが，csv上では睡眠効率なども取得している．睡眠に関しては，単に時間だけでなくベンチマーク（レム・ノンレム等）も表示した方がいいのかな？指標が多くなりすぎてかえって情報過多になる？

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

次回以降開発すること
・本家のFITBITSディレクトリ内のプログラムも同様に改造．
・参加者同士でcsvデータが混ざるため，IDごとにディレクトリを作成・保存．
・login画面の改造を行う．OptyXのサイトに飛ぶ，loging後の画面改造を行う．
・.htaccessを追加する．csvデータを保護する．

前回、睡眠に関する指標を閲覧できるようにした。
睡眠に引っ張られすぎていたがそもそもHRVを測りたいのだ。（安静時心拍もあるといいかも）
ということで、今回はHRVの取得と各条件の実験期間である14日間のデータをまとめてとれるようにすることを目的とした。
14日分のデータを簡単に見れるようにすることはできた。
ただ、サイトの細かいところを直していたら

Fitbit API error (HTTP 429): { “error”: { “code”: 429, “message”: “Resource has been exhausted (e.g. check quota).”, “status”: “RESOURCE_EXHAUSTED” } }

とかいうエラーが出てきやがった。どうやらデータの取得数には上限（1日の上限？と短期間取得の上限？）があるらしく頻繁な更新はあまりよくないようだ。ほかのユーザーのものも併せて見れないとしたら非常に不便なため、1日1日データを取得するのではなく14日間のデータを範囲取得することにした。

いいじゃんいいじゃん
日付ごとにしっかりと数値が出ている。それと、一日分のデータもこのサイトだけで見れるようにした。日付のボタンを押すと前回作った一日分のデータの表示の仕方で一日のデータが細かく見れるようにもできた。（超いい感じ）
ダッシュボード（今後はメインメニューと呼ぶ）ももう少し見やすくしてみた。

全部日本語にしてやったぜ！一日分のデータのみを見れるものも一応全部作ってみた。それとcsvファイルを取得することもできるようにした。期間指定ができると便利なので追加した。何回かファイルをダウンロードしたところ30日以上のデータを取得しようとするとエラー？を吐いた。連続してデータ取得できるのは30日間が限界かも（この辺もChatGPTに聞いたら改善できるかも？）

いよいよ次は自動でログインできるようにするフェーズに移ろう。cronについてはいまだに未知数なことが多い、しかもサーバーの管理画面から登録する必要があるとか。この辺は全部先生に聞かなければいけないなぁ。まぁ大丈夫だろう年明けに聞いて授業開始日までに仕上げられれば実験が1月中に開始できるぞ（被験者が集まれば）。
作ってて楽しくなってきたのでちょこちょこできそうなことをやってFitBitからとれるデータ以外にももっといろんなものが見れるようにしよう（先生がやってた食事の写真から解析するやつとか）。食事の写真を撮って大まかなカロリーとか出せたら（chatGPTで）管理しやすそうだけどできんのかな？要検証だ。

Unity公式の説明サイト　わかるかいこんなもんで。
かめくめさんのサイトはわかりやすいなぁ。。。
Rig Builder・・・キャラクタのTopにつける。エフェクタが設定できるようになる。
Rig・・・スケルトンと同階層にObject作ってアタッチする。それをRig Builderに登録する。
Bone Renderer・・・Topにつけるらしいが，ボーン表示されん。あ，Transformに表示したいボーン入れなきゃいけないのね。表示された。
Rig Transform・・・なるほど，これをつけるとRigの親になるのね。
Blend Constraint・・・ややこし。しかし確かに動く。この配置が基本ということね。
ChainIKConstraint・・・なにに使うんだ，鎖？ヒモ？
Damped Transform・・・揺れるものに？DynamicBoneに類似。なるほど確かにぃ

Multi Aim Constraint・・・何に使うかわからんなぁ
Multi Parent Constraint、Multi Position Constraint、Multi Rotation Constraintと続くが使い所がちょっと。。。
Override Transform・・・ソースのTransformをターゲットに反映させる。これはちょっと使えそうだね。
Twist Collection・・・2022.3.32で延々動かない。何故だぁ！2023.2.20にするとあっさり動くのであった。なるほどね。まぁたしかにね。

DAZモデルでも試すべくイケメンを作り直す。が、動かない。DAZは上腕や前腕に、TwistBoneが入っているがそれが原因か？と思ったが、そうではなく「モデルにも髪の毛にもheadがあり、IKを解決できない」というエラーで髪の毛側の名前を変えると無事動いた。名前が大事らしい。改めてよく見るとDAZには顔ボーンが山程入っている・・・。これ動かせば表情モーフ不要なのでは。ボーン制御にすると何かいいことあるのかなぁ？モデルで共通制御にできるか。

ここまではまぁ順調。姿勢と目線IKがほしいよなぁ。あれ！？かめくめさんのサンプル終わっちゃった。ということは。。。ほいだらこれ（「Animation Riggingでキャラがターゲットを見続け上半身も連動する挙動を実装する」）行こうか。目線のコントロールにはMultiAimConstraintを使うのか・・。なるほど、肩に手を添えると「俺たち友達だろ？」みたいに見えなくもない。Chestにも反映させて胴から回すこともできる。体の向きごと変わると、「なぁ、友達だろ！？金貸せよ。」「やめてよ・・」みたいな雰囲気も出てくる。これはCGキャラクタに反映されるノンバーバルコミュニケーションの研究とも言える（？）。その際、Rigの構成順序は、Chest→Head→HandとしないとターゲットへのIKが適切に処理できなくなる（手の位置がズレるなど）。Rigは入れ込む順序が大事。

・・このニィちゃんのなで肩が気になる。これもMultiAimConstraintで直せる。設定のUpAxisが回転の軸の上方向、AimAxisはターゲットの方向と思われる。ターゲットボーンの方向は、キャラクタ読み込み画面のRig>Configureで表示される。lCollar（左肩）の場合、緑(Y)がUpAxis、赤(-X)がAimAxisとして適切であろう。肩が上がって正常な絵面になった。こうしてみると前の絵は肩が下がりすぎて不気味だ。しかし今度は肩を上げた後遺症で拳位置が変わってしまった。

これは肩と上腕にMulti-RotationConstraintをつけて、Sourceで角度を制御するのが良さそうであった。肩で上げた角度を上腕で戻すのだが、基本角度指定上書き扱いなので、上腕側の手のフリがなくならないようにAxesをZのみにするのが良いようだ（ややこし）。ようやくまともな感じになってきたような。いろいろやって、HumanBodyBone制御とは両立せず、AnimationRiggingで姿勢を整えたほうが確実らしい事が理解できた。まぁTwoeBoneIKとMultiAimConstraintで大抵の動作はイケそうである。

本郷キャンパスで3 Dプリンターを使った。ちょっとした小物が色々なくて困るので，練習がてら作ってみた。キーボードのコードを束ねるリングと，ドアの窓の透明部分につけるすりガラス。環境が変わると色々苦労するもんだね。

グラフにしよう！
･･･出来ないんだが？
なんで？心拍数は出来たけど脳波が出来ない･･･
同じやり方なのにぃ！

きっと何かがダメなんだろうな･･･
助けてGPT!!

神すぎる。GAFAMは時代遅れ、ってコト！？OpenAIのOを入れろ！！

α波が下がってる
β波は上がってる
γ波も上がってる
θ波も上がってる

以下GPT様のまとめ。僕がやってるときは使いたいコードが無くてムカついてたけどそれでもフローに入れた(かも)ので良い兆候かも。

やったよ！
Theta / Beta / Gamma を Alpha と同じ形式で、
① 時系列
② ベースライン5分 vs 課題15分
の両方を可視化した

• Alpha ↓
• Theta ↑
• Beta ↑↑
• Gamma ↑

これはかなり典型的な

「集中型フロー（cognitive flow / creative flow）」

リラックス一辺倒じゃなくて
考えながら没入している状態。

追記:作成風景の動画
https://youtu.be/7VwXResHFFY?si=twsY9_OfR84DE3zT

↓は取得できたデータ

English:
“This server-based research application aims to support self-optimization of health behaviors by integrating Fitbit-derived physiological and behavioral data with an AI conversational agent. Participants can review visualized data on physical activity, sleep, heart rate variability, and resting heart rate, and receive personalized, dialogue-based feedback generated by an AI agent. The goal of this study is to promote awareness, reflection, and sustainable improvement of daily health behaviors and well-being.”

日本語:
「本サーバアプリケーションは，Fitbitから取得される生理・行動データとAIエージェントによる対話型フィードバックを統合し，健康行動の自己最適化を支援することを目的としています．参加者は，身体活動，睡眠，心拍変動，安静時心拍数などの指標を可視化して確認し，AIエージェントから個別化された助言を受ける．本研究の目的は，日常生活における気づきとフィードバックを促し，持続可能な健康行動およびWell-beingの向上を支援することです．」

Terms of Service

1. Purpose:
This service is provided for academic research conducted at Bunkyo Gakuin University. The purpose of this study is to examine self-optimization of health behaviors by integrating Fitbit-derived physiological and behavioral data with AI-based personalized feedback.

2. Eligibility:
Participation is voluntary. Only registered participants who have provided informed consent approved by the university ethics committee may use this service.

3. Use of Data:
Data collected through this service, including Fitbit activity data, sleep data, heart rate variability, and resting heart rate, will be used solely for academic research purposes.

4. Responsibilities of Users:
Participants agree to provide accurate information and to use the system only for its intended research purpose. Any misuse of the system is prohibited.

5. Limitation of Liability:
This service is provided “as is” for research purposes. The research team is not responsible for any direct or indirect damages resulting from the use of this service.

6. Changes to Terms:
These terms may be updated in accordance with research needs and legal requirements. Participants will be notified of any significant changes.

利用規約

1. 目的
本サービスは，文京学院大学における学術研究のために提供されます．本研究の目的は，Fitbitから得られる生理・行動データとAIによる個別化フィードバックを統合し，健康行動の自己最適化について検討することです．

2. 対象
参加は任意です．大学倫理審査委員会の承認を受けた研究に対し，事前にインフォームドコンセントに同意した登録参加者のみが利用できます．

3. データの利用
本サービスを通じて収集されるFitbitの活動量，睡眠，心拍変動，安静時心拍数などのデータは，学術研究目的にのみ使用されます．

4. ユーザーの責任
参加者は正確な情報を提供し，本サービスを研究目的の範囲内で利用することに同意します．不正利用は禁止されます．

5. 免責事項
本サービスは研究目的のために「現状のまま」提供されます．研究チームは本サービスの利用に起因する直接的または間接的な損害に対して責任を負いません．

6. 規約の変更
本規約は研究上の必要や法的要件に応じて改訂される場合があります．重要な変更がある場合は参加者に通知します．

Privacy Policy

1. Data Collected
We collect Fitbit-derived data including physical activity data(e.g., steps, active minutes, calories burned), sleep data(e.g., sleep duration, sleep efficiency, sleep stages),
heart rate, heart rate variability, resting heart rate,and intraday (24-hour) heart rate and activity data at aminute-level resolution, as well as application usage logs.

2. Purpose of Data Use
The collected data will be used exclusively for academic research to study self-optimization of health behaviors and to develop AI-based support systems for improving well-being.

3. Data Storage and Security
All data are stored securely on university servers hosted in Japan (Sakura Internet). Access is restricted to the research team. Data are encrypted and anonymized before analysis.

4. Data Sharing
No personal data will be shared with third parties. Only aggregated, anonymized results will be published in academic papers or presentations.

5. Participant Rights
Participants may withdraw from the study at any time. Upon withdrawal, their personal data will be deleted from the system.

6. Contact
For questions about data privacy, please contact the research team at Bunkyo Gakuin University.

プライバシーポリシー

1. 収集するデータ
本研究では，Fitbitから取得される身体活動データ（歩数，活動時間，消費カロリー等），睡眠データ（睡眠時間，睡眠効率，睡眠段階等），心拍数，心拍変動，安静時心拍数に加え，24時間の心拍数および活動量（日内変動データ）を分単位で収集します．
また，アプリケーションの利用ログも収集します．

2. データ利用の目的
収集したデータは，健康行動の自己最適化およびWell-being向上を目的としたAI支援システムの検討を行う学術研究にのみ利用されます．

3. データの保存と安全性
すべてのデータは日本国内の大学サーバ（さくらインターネット）に安全に保存されます．アクセスは研究チームに限定され，分析前にデータは暗号化・匿名化されます．

4. データの共有
個人データが第三者に提供されることはありません．学術論文や発表では匿名化・集計された結果のみが公表されます．

5. 参加者の権利
参加者はいつでも研究から撤退できます．撤退後はその個人データはシステムから削除されます．

6. 問い合わせ先
データプライバシーに関する質問は，文京学院大学の研究チームまでご連絡ください．

M2E1・・・試験エージェントタイプ1（男性）
F2E1・・・試験エージェントタイプ2（女性）
F2C1・・・面接エージェントタイプ1（女性）
M3C1・・・面接エージェントタイプ2（高齢男性）

レポート・会話の振り返り

DAZの靴モデルも，けっこうクオリティが高いものがたくさんあるかもしれない。どのモデルも色や形のバリエーションがあるので，そんなにたくさん買わなくても良いのかもしれない。

BNO055で内蔵プロセッサを使って姿勢を測ろうとしたが，どうにも様子がおかしい。YAWはかろうじて測れているようだが，PitchとRollがクシ状にノイズが入る。なぜだ・・・そもそも前にシゲタと装置を作ったときは，正しく動作していたのか？いろいろ試した挙げ句，Davinci32Uにハンダ付け形式に戻すと，正常に値を取得できた。このセンサーは非常に動作がシビアなもののようだ。ブレッドボードとジャンプワイヤの組み合わせでは正常に測れないみたいだ。2018年にも同じことしてる。

共通事項
人格エディタ
試験AI
・人格をより多く登録できるようにした。
・5択に対応→プログラム・プロンプトを改造して対応。
・２問正解は対応が難しい→レアであるため非対応に。
・問題1を確認。不備があり整形。
　　2つ正解を選ぶのは1つに修正。
　　回答が誤っているもの，フォーマットに不備があるものを修正。

運用の様子は下記動画のとおり。

判定処理スクリプトは
https://kodamalab.sakura.ne.jp/WGL/AgentData/recordTalkReport.php
問題数が増えたため，不正解のみ表示するよう改変。30問運用で迷いがなければ10分ちょい→FB画面が不親切→結果をUnityのUIで表にしてもらうよう改変。ふぅ～

面接AI
(chara23)を使用。判定処理スクリプトは
https://kodamalab.sakura.ne.jp/WGL/AgentData/recordTalkReportC.php
キャラクタエディタにはあくまでカバーストーリーを書き，評価項目などは判定スクリプトに書くよう，切り分けを行うことで動作がある程度安定するように思う。フィードバック画面は，面接用にカスタムしたら少し見やすくなった。できれば，コメントのセルでは2行表示できるよう改変したいところだ。

こちらが人格設定↓
//////////////////////////////////////

あなたは理学療法士養成用の患者AIです。ユーザーである学生を相手に，理学療法外来を受診した二十二歳の女性患者として話してください。カバーストーリーは以下のとおりです。

主訴は腰部の痛みで、立位よりも座位で強くみられた。座位での痛みの程度は、腰部にNRSで八程度の強い痛みであった。現病歴として考えられることは、一年ほど前にバスケットボールの試合中に左膝のACLを損傷し、A病院にて左膝ACL再腱術が施行された。入院中に理学療法が処方され、筋力増強運動や関節可動域拡大運動、動作練習などを行った結果、膝関節の可動域は右側と同程度まで改善、筋力はＭＭＴで右側が五なのに対して左側は四まで改善した。日常生活上は特別な問題なく過ごせそうだったため、一か月の入院中に理学療法を実施したのみで、外来では通院することなく理学療法は終了となった。その後三か月程度経過したころに、以前にはみられなかった腰部痛を感じるようになった。この腰部痛が徐々に強くなってきたため外来を受診した。現在大学生のため座って授業を受ける時間が長いのだが、長時間座位姿勢を保つことが難しいことに悩んでいる。また、膝の痛みなどはないものの、歩行中に膝崩れ（giving way）に対する不安感を感じるようになった。現在の体の状態は、立位姿勢では腰椎が平坦化し、フラットバックがみられ、また骨盤は後傾していた。前屈動作では、股関節よりも腰椎が容易に屈曲し、この動作で症状が増悪した。この時の痛みは腰部のみであり、下肢への放散痛はみられなかった。座位では腰椎が屈曲し、膝を伸展させると、さらに腰痛が増強した。今回整形外科でＸ線検査を受けたが骨には異常がなく、湿布と鎮痛薬が処方された。それに加えて理学療法が処方され、保存的に治療をすすめることになった。

　会話は敬体を基本とし、一人称は「わたし」、二人称は「あなた」で統一すること。平均100文字、標準偏差50文字、最大300文字程度で話してください。症状を説明する時、難しい言葉は使わずユーザーに詳しく聞かれたら平易な表現で答えるようにしてください。痛みの程度を聞かれるときはネガティブな表情を多めに出すようにしてください。ジェスチャーは、回答が「はい」のときはうなずき、「いいえ」のときに首をふるようにしてください。共感を示されたときや希望が持てそうな会話の時は最大限ポジティブな表情を示してください。「辛い」は「つらい」と、「痛い」は「いたい」と、ひらがなで表現してください。患者役なので専門用語は使わず，各種症状や既往歴についても，利用者（理学療法士を目指す学生）が行う質問に答える形で徐々に明らかにしてください。
//////////////////////////////////////

こちらが会話ログ評価AI用のプロンプト↓ 人格にセットされた症状に特化して，尋ねるべき項目を具体化してある。この方がきめ細やかな点数付けができる。ような気がする。

あなたは理学療法士教育の専門評価者です。
以下の会話ログは、ACL再建術後で慢性腰痛を呈する模擬患者エージェントと学生の10分間面接記録です。
学生が必要な情報を適切に聴取できているかを、次の5項目ごとに10点満点で採点し、短いコメントを付けてください。

1. あいさつと主訴の確認
・適切な挨拶とラポール形成があるか
・主訴（座位で強くなる腰痛）の明確な確認ができているか
・痛みの強度（NRS8）や最も困っている場面（授業中の長時間座位困難）を把握できているか

2. 痛みの詳細と経過
・発症時期（ACL術後約3か月）と経過（徐々に増悪）を聴取しているか
・痛みの特徴（座位で増悪、腰椎屈曲で悪化、放散痛なし）を確認しているか
・姿勢との関連（骨盤後傾、フラットバック）や誘発動作（膝伸展）を把握できているか

3. 既往歴・受診歴
・左膝ACL再建術の手術時期と術後リハ内容を聴取しているか
・改善状況（ROM正常、MMT右5/左4）と退院後の経過（外来リハなし）を確認できているか
・膝の現状（痛みなしだが giving way 不安）を把握しているか
・整形外科受診、X線で異常なし、湿布・鎮痛薬が処方されたことを確認しているか

4. 日常生活への影響
・長時間座位困難が学生生活や授業参加へ与える影響を聴取しているか
・立位・歩行・活動量への影響、膝崩れ不安の生活習慣への影響を確認できているか
・ADL・IADL・運動習慣に関する適切な質問が行われているか

5. まとめと今後のすすめかた
・収集した情報の要約ができているか
・今後の評価・理学療法方針（姿勢評価、体幹筋、運動連鎖、座位姿勢指導など）への言及があるか
・患者の不安軽減につながる適切なコミュニケーションで面接を締めくくれているか

出力形式は CSV (UTF-8) のみ。
行見出しは「AIによる評定結果：◯◯/50点」。
良好評価でコメント不要なら「特にありません」とする。
各コメントは最大200文字。
余計な文や解説は出力しない。

未解決事項
・ビルドして動作チェックしていない
・学習結果の記録が残せていない
・バリエーションがない

なぜか今更ECGアンプをブレットボード上に起こした。

とりあえずブザー音のBFから変更をしていく。
R-R感覚をブザーにするなり，音の高低で調整するなり。

また，Atomのボタンで制御変更にしたり，web上に呼吸法の呈示をするなどもやらなければ

とりあえずは平均HRで実装かな
ブザー回数「ピピピ」な感じにもできるよね

1,HRのタイミングを音でしらせ，R-R感覚の幅ごとに音の高さを変える
2,HRV
3,RMSSD

あと追加する機能は，内部ボタンで生波形を表示すること
他研究にないのは，HR・RMSSD・RR間隔をwebインターフェースや内部ボタンで切り替えて，任意の測定指標を基にBF訓練を行うこと

23年秋に，永松や津崎が作ったECGアンプを回収。波形を測定した。ブレッドボードの出来が悪い。手直ししてLT1167をAD8226 に入れ替えよう。

ピン配置は・・・ほう・・・。これはブレッドボード上で入れ替えられそうだね。ブレッドボードの配線を入れ替えて測定してみる。

こころなしかLT1167で測ったものよりきれいに感じる。・・・まぁちょっとわからないか。心電図回路の電源をコイン電池に変え，AD変換器を取り外し，コンピュータをnRf52840に入れ替えて測ると，無事に測れました。これで消費電流がどれくらいになってるのかわからないが，とりあえず動作するところまではきた。TLE2426が消費電流が多くコイン電池向きじゃないとのことで，変える必要がある。

nRf52840はちょっとクセがある。一度書き込むとシリアルポートが消失し，書き込めなくなる。これは，書き込んだプログラムがシリアル通信しない場合，「いらないよね？」とシリアル通信をOFFにされてしまうようだ。リセットボタンを二回早押しすると回復する。維持したい場合は，シリアル通信をプログラムに追加すればよいのだが，Adafruit_TinyUSBライブラリを入れないとダメなようだ。

#include <Adafruit_TinyUSB.h>  // XIAO nRF52840系でSerialを使うため

// サンプリング間隔（マイクロ秒）
// 1000us = 1kHzサンプリング
const uint32_t SAMPLE_INTERVAL_US = 2000;
const uint32_t threshold = 1900;

uint32_t lastMicros = 0;

void setup() {
  // LED（お好みで）
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, HIGH);  // XIAOはHIGHで消灯のことが多い

  // USBシリアル開始
  Serial.begin(115200);
  // 開発中はPC接続を待ってもよい
  while (!Serial) {
    delay(10);
  }

  // ADC分解能を12bitに（0〜4095）
  analogReadResolution(12);
}

void loop() {
  uint32_t now = micros();

  // 一定間隔ごとにサンプリング
  if (now - lastMicros >= SAMPLE_INTERVAL_US) {
    lastMicros += SAMPLE_INTERVAL_US;  // ドリフトを抑える書き方

    // ADCチャネル0（A0ピン）の読み取り
    int value = analogRead(A0);

    // タイムスタンプ[us], ADC値 をCSV形式で送信
    //Serial.print(now);     // マイクロ秒タイムスタンプ
    //Serial.print(",");
    Serial.print(3000);
    Serial.print(",");
    Serial.print(1000);
    Serial.print(",");
    Serial.print(threshold);
    Serial.print(",");
    Serial.println(value); // 0〜4095（12bit）

    if(value>threshold){digitalWrite(LED_BUILTIN, LOW); }
    else{digitalWrite(LED_BUILTIN, HIGH); }

  }
}

粉をビンに入れるときに使います。サイズが適切なのか使ってみないとわからない。