2020年、世界はコロナ渦の真っ只中です。
家にいる時間が増えました。そして運動不足になりがちです。
というわけで、今回はtoioコアキューブを使った運動不足解消ネタです。
要約
toioコアキューブのシェイク検出機能でgoogleマップ（ストリートビュー）を移動します。
やりたいこと
toioコアキューブを2個使います。
一つずつ手に握って腕を振り、左右の振りの早さで進む速度や向きをコントロールしたいと思います。
腕の振りを鍛えて世界一周しましょう。
実現方法
具体的には、2個のキューブでシェイク検出を行い、
- 左右を振っていれば前進
- 片方だけなら、振っている腕のほうを向く
という動きにします。
ストリートビューは別途ブラウザで開いておいて、操作は上記のキューブの動きをキー入力に変換して伝えます。
キューブの動きをキー入力に変換するのは去年のアドベントカレンダーでもやったので、コードは使い回しです。
というわけで前回同様に実装言語はrust、動作環境はWindows10です。
今回のおはなしのながれ
というわけで、今回は成果物の新規性が低く若干（かなり？）ショボいので、実装の流れを書いていきたいと思います。
実装の記録
ここからは実装の記録です。
プログラムを実行する前準備として、toioコアキューブを二個Windowsのbluetoothデバイスとして登録しておいてください。
このプログラムはWindowsのbluetooth登録情報を参照して接続対象となるキューブを探します。
スタート
去年のパワポコントローラーを改造します。コードはこれです。
このパワポコントローラーは、発表後にbleのライブラリをマイクロソフト製のwinrt-rs(v0.7)に変更したのですが、そのへんの話は今回の記事の主旨ではないので軽く省略します。
コードを取得してきたらブランチを作って作業します。ブランチ名は安易にgoto_vtravelです。
そして、examplesディレクトリを作って丸コピーします。
ファイル名はgoto_vtravel.rsにします。
git clone https://github.com/kaz399/rs_toio_cube
cd rs_toio_cube
git switch -c goto_vtravel
mkdir exsamples
cp src/main.rs exsamples/goto_vtravel.rs
とりあえず二個認識させてみよう
まずは二個のキューブを認識させるところから始めます。
実は下回りの実装をあまり覚えていないので、何も考えずに接続処理を追加してみます。
コードはこれです。
うまくいけば、二個目のキューブのLEDが青色に点灯するはずです。
実行しましょう。
cargo run --example goto_vtravel
Finished dev [unoptimized + debuginfo] target(s) in 0.07s
Running `target\debug\examples\goto_vtravel.exe`
Page key mode
search registered cubes
success to connect
battery level 100%
search registered cubes
thread 'main' panicked at 'error: read: Error { code: 0x8000000B, message: "有効な範囲外のデータにアクセスしようとしました" }', core_cube\src\win10.rs:328:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\examples\goto_vtravel.exe` (exit code: 101)
ああ、だめですね。適当すぎたようです。
二つ目のキューブの接続チェックの際に、すでに接続済みの一つ目のキューブに接続してreadを試みて失敗しているようです。
下回りにも修正を入れます。
接続済みだった場合はOK(false)という成功なのか失敗なのかよくわからない値を返してread処理まで進まないようにします。
接続状態を検出するコードはこんな感じです。全体としてはこうなります。
let connection_status = ble_device.connection_status().unwrap();
debug!("Connection Status: {:?}", connection_status);
if connection_status == BluetoothConnectionStatus::Connected {
return Ok(false);
}
そしてふたたび実行してみます。
cargo run --example goto_vtravel
Finished dev [unoptimized + debuginfo] target(s) in 0.07s
Running `target\debug\examples\goto_vtravel.exe`
Page key mode
search registered cubes
success to connect
battery level 100%
search registered cubes
success to connect
battery level 100%
今度は両方のキューブに接続できました。
二つのキューブのLEDが無事に緑と青に点灯しました。
ちなみに右手用が青、左手用が緑になります。
二個のキューブのセンサーの値を取得してみよう
無事に二個接続できたので、次はセンサー値の取得です。
こんな感じで両方のキューブに同じNotifyハンドラを登録してみます。
デバッグ情報を有効にして実行すると。。
export RUST_LOG=debug
cargo run --example goto_vtravel
（中略）
[2020-12-14T13:10:54Z DEBUG goto_vtravel] sensor [SensorInfo { time: Instant { t: 9158.6269347s }, slope: Aslant, collision: NotDetect, double_tap: NotDetect, posture: Normal }, SensorInfo { time: Instant { t: 9158.6790044s }, slope: Aslant, collision: NotDetect, double_tap: NotDetect, posture: LeftSideUp }]
[2020-12-14T13:10:55Z DEBUG goto_vtravel] sensor information status changed [1, 1, 1, 0, 1, 0]
[2020-12-14T13:10:55Z DEBUG goto_vtravel] sensor [SensorInfo { time: Instant { t: 9159.7795435s }, slope: Horizontal, collision: Detect, double_tap: NotDetect, posture: Normal }]
うーん。これではどちらのキューブのセンサー情報なのか区別できません。
クロージャを使ってハンドラ関数を生成すればいい感じになるのかも？という気がしましたが、やり方がよくわからなかったのでハンドラ関数を二つ作るというダサい手法でしのぎます。
今回の目標はとにかく運動不足の解消です。知力不足の解消は別の機会になんとかします。
二つのキューブに別々のハンドラを登録するよう変更しました。シェイク検出の定義も追加してあります。
実行結果はこんな感じです。
[2020-12-16T01:54:09Z DEBUG goto_vtravel] sensor(cube1) information status changed [1, 0, 0, 0, 3, 1]
[2020-12-16T01:54:09Z DEBUG goto_vtravel] cube1:sensor [SensorInfo { time: Instant { t: 55169.0215776s }, slope: Aslant, collision: NotDetect, double_tap: NotDetect, posture: Downward, shaking: 1 }]
[2020-12-16T01:54:11Z DEBUG goto_vtravel] sensor(cube2) information status changed [1, 0, 0, 0, 1, 2]
[2020-12-16T01:54:11Z DEBUG goto_vtravel] cube2:sensor [SensorInfo { time: Instant { t: 55171.1816288s }, slope: Aslant, collision: NotDetect, double_tap: NotDetect, posture: Normal, shaking: 2 }]
無事に二個のセンサー情報を別々に取得できるようになりました。
キーイベントを発生させよう
ブラウザのgoogleマップ（ストリートビュー）は下記のキーボード操作が行えます。
| キー | 動き |
|---|---|
| ↑ または W | 前進 |
| ← または A | 左を向く |
| → または D | 右を向く |
| ↓ または S | バック |
二個のキューブのシェイク検出値をもとにキーイベントを生成します。
昨年の経験から、enigo 0.0.13ではNumLockを有効状態にしないとカーソルキーイベントが生成できないことがわかっているので今回は無難にWASD操作にします。
enigoには新しいバージョンの0.0.14がありますが、こちらは試していないのでカーソルキーが普通に生成できるのかどうかは不明です。
キューブのシェイク検出値とキーイベント発生の関係ですが、こういうのは実際に操作しながら調整してみないと、いわゆる「いい感じ」かどうかわからないので、まずは適当に実装して様子を見てみたいと思います。
腕の振りの早さに応じてマップの移動スピードを可変させたいです。
シェイク検出値を積算して一定値を超えたらキーイベントを発行させる方法を試してみます。
おためし実装はこれです。キーイベント処理を追加して、パワポコントローラー用の不要な部分はバッサリ削除しました。
googleマップを操作するための手順は
- コンソールでgoto_vtravelを実行させる（ログレベルはinfoにしておきます）
- ログを見てキューブが二個とも接続できたことを確認
- ブラウザを起動してgoogleマップにアクセスし、ストリートビューモードにする（人形を道路にドラッグ＆ドロップ）
- ウィンドウのフォーカスはブラウザで放置
- キューブを握ってひたすら腕を振る
です。
実行コマンドは下記です。
export RUST_LOG=info
cargo run --example goto_vtravel
試したところ、前進はまあまあ普通だけど左右移動が少なすぎて方向転換が超辛いということがわかりました。
これでは180度ターンするだけで酸欠で気絶しそうです。
操作感を調整しよう
ストリートビューは左右キーを押している間はずっと方向を変える作りなので、方向転換時のキーオフのタイミングを遅らせることにより変化量を増やします。
キーイベント発行処理は100ms周期でループしているので、方向転換時は3周期（300ms）の間キーをオンにするようにします。
あと試してみてわかったのですが、腕は左右交互に振るので左右「同時」ではなく「交互」にシェイク検出値が得られます。
両方の腕を交互に振り続けていることを判断するために、直近のシェイク検出イベントから600ms以内であれば有効値とみなしています。
そのうえで、(右のシェイク検出レベル)×(左のシェイク検出レベル)が0でない間は両腕が振られていると判断しています。
修正したものはこれです。
もし振っている腕のほうを向くという操作性に違和感があり、逆のほうがいいと思う場合には左右のキューブを持ち替えてください。
完成
プログラムができたので実際に使ってみたいと思います。
皇居一周にチャレンジ
手始めに皇居を一周してみたいと思います。
雰囲気を出すために腕だけではなく、その場駆け足もします。
大手町あたりから代官町まで走りましたが、かなり疲れます。
いまハアハア言いながら書いています。
運動不足の自分には皇居一周は結構厳しいです。
しかも、部屋でバタバタやっていたら愛犬に吠えられてしまいました。残念です。
おわりに
やっぱり外で運動するのが一番です。
早くコロナが収束し、また心置きなく外で遊び回れる日が来ますように。