Hapbeat 活動報告 2026年6月
Hapbeat の山崎です。6月は Duo WL v4 のハードウェア開発を進めつつ、JavaScript/Python/Arduino SDK の公開準備、Web サイトインフラの移行などに取り組みました。
各種取組は以下のように分類します(該当なしの場合は打ち消し線)。
プロダクト関連:販売するプロダクトの開発や進捗など
イベント関連:イベントや展示会への出展報告・準備など
検証・広報・その他:今後の方針に関する検討や広報活動など
プロダクト関連
Duo Wireless の新基板開発(v4)

背景:これまで活用してきた無線版 Hapbeat、Duo Wireless(以後、Duo WL)は、v3 系を2024年9月頃に開発しました。その後、マイナーアップデートを繰り返したものの、基本的な設計は変わらず、さまざまな場面で使用してきました。
その後の検証で、動作面でいくつか気になる点が見えてきました。特に大きな課題は、電池残量が少ない状態で瞬間的に大電流が必要な信号を再生したときに、電源系が不安定になり、振動再生に異常が生じることでした。
当時は根本的な解決方法が分かっておらず、基本的に自分で使う想定だったため、コンテンツ設計に注意すれば問題になりませんでした。リソースの都合もあり、対応を先送りにしていました。
ただ、これから Duo WL を自分以外の方に使っていただくことを前提にすると、特に商用利用では、原因が明確でないまま不具合が起きる問題を放置できません。このタイミングで基板の改修に踏み切りました。
また、生成AIのおかげで Wi-Fi/ESP-NOW を用いた音声ストリーミングも十分現実的に実装できることが判明したため、無線ブロードキャストでヘッドホンの音楽と振動を組み合わせるサイレントフェス的な用途にも展開できるように改良しました。
Duo WL v3 → v4:機能に関わる部品の変化
電源(3.3 V)/今回の最大の目的:LD56100(LDO)→ TPS63802(昇降圧 buck-boost)。v3 では激しい振動を再生した際に瞬間的に約 4 A が流れ、電圧が低下することがありました。その際、LDO から給電される DAC IC の電源が一時的に 3.3 V を下回ると、電源が戻った後も DAC が復旧しない問題がありました。
特に電池残量が減るとこの挙動が起こりやすく、残量の何%で起こるかが不明確なのが厄介でした。見た目には問題がなく、電池残量が多いように表示されていても DAC だけが正常でないことがあり、運用上の課題でした。
buck-boost への変更により、入力電圧が低下したときも所定の動作範囲内で 3.3 V を維持できる設計にしています。残量低下時の安定性を高められることが、今回の大きな改善点です。
ヘッドホン出力/新規追加:なし → TLV320AIC3204(2基目)の追加+TPA6130A2(capless ヘッドホンアンプ)。v3 にも有線ジャックは実装していましたが、こちらは入力専用で、確認用に手軽に振動を再生するためのものでした。v4 では出力への切り替えに対応し、音楽をヘッドホンで聴きながら振動を再生する、有線版 Hapbeat に近い体験を無線ブロードキャストでも提供できる構成にしました。サイレントフェスのような用途への展開も想定しています。
MCU:ESP32-S3-MINI-1-N8(flash 8 MB)→ ESP32-S3-WROOM-1-N16R8(flash 16 MB)。CPU は同じ ESP32-S3 のため演算性能は変わりませんが、Opus デコーダと2コーデック分の音声処理を載せた結果、ファームウェアが 1.875 MB の OTA スロットの約 95%まで膨らみました。flash を倍にして OTA スロットを 4 MB に拡張し、あわせて本体に保存できる音声データも約 4 MB から約 7.4 MB に増えています。
本来は 5 GHz Wi-Fi 対応の ESP32-C5-WROOM を選択したかったのですが、供給面を考慮し、今回は現状で調達しやすい S3 を選択しました。将来的な差し替えの際に基板レイアウトの変更を極力少なくできるよう、今回 MINI から WROOM に変更したという経緯もあります。
触覚 DAC/コーデック: PCM5100A → TLV320AIC3204。1つのコーデックが持つ DAC は2 ch のため、触覚 L/R と音声 L/R の4 ch には最初から2基必要でした。さらにヘッドホン側にはライン入力用の ADC も必要になるため、DAC 専用の PCM5100 では役目を果たせません。2基とも同じ品番にそろえることで、部品表も1品番で済むようにしています。PCM5100A は音質面で優位な側面がありますが、触覚用途は 500 Hz 以下を中心とするため、今回の用途では影響が小さいと判断しました。
また、将来的に ESP32-C5 への変更を視野に入れると、ESP32-C5 は I2S ペリフェラルが1基のため、I2S TDM に対応したコーデックを選択する必要があります。PCM5100A は TDM 非対応のため、この点も選定理由の一つです。
OLED:N091-2832(SPI 接続)→ X091-2832(I2C 接続)。主な理由は N091-2832 が生産終了となったためで、供給の安定性を考慮して変更しました。I2C 化は必須ではありませんでしたが、MCU ピンを節約できる点でもメリットがあります。
MQTT版の Studio 対応化
背景:東京工科大学様の方でご利用いただいている、カラーセンサーを用いた生体情報モニターのアラートを LAN 内の Hapbeat で伝える MQTT 版について、既存のソフトウェアとハードウェアに不具合が生じていました。点検とあわせて、Hapbeat SDK 向けに整備してきた Studio などのツールを活用し、MQTT 版も Studio で扱えるようにする作業に取り組みました。
旧モデルでは、パラメータ調整やファームウェアの書き込みに VS Code+PlatformIO が必要でした。慣れれば難しくはないものの、ファームウェアのバージョン管理に伴うコミュニケーションコストがかかり、久しぶりに使用する際には環境を思い出す負担も大きいと感じていました。開発者である私自身も、半年以上離れると再び書き込める環境を確認することが億劫になるため、改善が必要でした。
旧モデル手順書:https://app.notion.com/p/yus988/Hapbeat-56204c96e17c4438849a1a8368b729a9?source=copy_link
動画:用途例(初出:2024年夏)
Studio 上(下図)では、ファームウェアの書き込み、MQTT 通信フローの可視化、各種設定、カラーセンサーの値設定などをブラウザ上でまとめて扱えるようにしました。以前より格段に使いやすくなったと感じています。
こうした機能の多くは Hapbeat 固有ではないため、将来的には汎用的に使える部分を切り出して公開することも検討しています。

JavaScript/Python/Arduino SDK の公開

先月の Unity に引き続き、今月は対応プラットフォームを3つ追加しました。3つとはいえ、いずれもコードベースでほぼほぼ生成 AI に任せられたこともあり、Unity SDK の実装工数に比べると体感では3分の1以下でした。
3つとも、Unity SDK と同じ「発火(Trigger)と調整(EventMap)を分離し、event ID だけで紐づける」設計を踏襲しています。触覚波形はアプリに埋め込まず、Studio で作成した Kit としてデバイス側に置く方式です。
以下、それぞれの対応理由を簡潔に記します。
Python:研究(PsychoPy・Jupyter・ROS)やメディアアート、プロトタイピングで最も広く使われる言語であり、少ないコードで検証しやすいことから対応しました。汎用 OSC ブリッジを同梱しており、VRChat や TouchDesigner など他ツールとの統合の土台にもなります。
https://pypi.org/project/hapbeat-python-sdk/
JS/TS:Web・WebXR(three.js など)・Electron からブラウザベースの実験ツールまでをカバーする、幅広いプラットフォームです。ブラウザ・Node(PC アプリ/サーバー)・React Native(スマートフォン)のいずれでも同じコードを使える設計とし、環境ごとの通信経路の違いは SDK 側で吸収します。ブラウザでは UDP を直接送信できないため補助ツール `hapbeat-helper` が中継し、Node とスマートフォンではデバイスへ直接 UDP を送信します。Web の心理実験から展示デモ、スマートフォンアプリまで、幅広い入口になると考えています。
https://www.npmjs.com/package/@hapbeat/sdk
Arduino SDK(ESP32/M5Stack 対応):上記2つとは異なる「組込み・メイカー層」への入口として対応しました。依存ライブラリを追加せず、WAV ファイルを持たなくても「ボタンを押すと Hapbeat が鳴る」体験がマイコン単体で完結します。Kit イベントの発火に加え、マイコン側でのサイン波合成ストリーミングにも対応しており、ハードウェア試作や電子工作に触覚フィードバックを最短距離で組み込めます。
SDK 対応の無線版 Hapbeat の無償貸出プログラムはこちらから申し込めます!
イベント関連
LODGE XR Talk Vol.40(6/24)デモ展示

先月に続き、今月も LODGE XR Talk Vol.40 にて、Hapbeat SDK のデモを行いました。今回展示した内容は以下のとおりです。
Unity SDK Showcase デモ
Hand Interaction Demo(SDK):Unity+Quest 3S でのハンドトラッキング触覚体験
Duo 2+タブレット:従来の音楽+ゲームのデモ
今月もデモの合間にほかの展示を体験させていただきました。なかでも、ベントさんの Immersive Video デモは、これまで Vision Pro で体験した映像の中でも特に高画質で、非常に印象的でした。物理ボタンによる映像切り替えも展示との相性がよく、体験全体としてとても完成度が高かったです。ぜひ、こうした素晴らしい映像と Hapbeat を組み合わせていただけたらと思います。
Immersive Videoがこんな感じでサクサク切り替わる
— ベント|Immersive Video ᯅ (@FinalventNet) June 24, 2026
ボリュームもセンター位置もコントロール出来る
ペアリング無しで別系統のコントローラーと干渉しない
それぞれのコントローラーから複数台制御可能 https://t.co/vGIlXE7K03 pic.twitter.com/kkNcpkD4EI
検証・広報・その他
Web サイトのインフラを Xserver から Cloudflare Workers へ移行
もともとGitHubでコードを管理しているのに公開はFTPという構成で、GitHub Actionsのデプロイもたびたびタイムアウトで失敗していました。この気持ち悪さを解消するため、配信基盤を Xserver から Cloudflare Workersへ移行しました。主な効果は次のとおりです。
デプロイの改善: FTPを廃止し、GitHubにpushすれば自動反映。タイムアウトによる失敗もなくなり、過去バージョンへのロールバックも可能に
表示の高速化: 世界300拠点以上のエッジ配信とHTTP/3対応
セキュリティ・運用: DDoS防御やTLS証明書の自動化が標準で、サーバの保守が不要に
なおメールについては、Cloudflare だと転送のみで不安があったので、コスパと実績を考慮し「さくらインターネット」に移行しました。メールが届かなくなると業務に大きな影響があるため慎重に作業していましたが、実際にはスムーズに移行できました。最も安いプランを利用していますが、Hapbeat の現在の運用規模では特に支障なく使えています。
これでコスト面についても、Cloudflare側は無料枠で収まるため、固定費はメール(さくら)の月額 110円(1年契約)だけと、以前の Xserver 月額 980円よりも負担が軽くなりました。
7月の予定
ESP-NOW 音声ストリーミングの本格実装
アルゼンチンタンゴでの活用(本番)
Hapbeat SDK の Unreal Engine 対応
ホームページ更新準備
ここまでお読みいただきありがとうございます。少しでもご興味をお持ちいただけましたら Hapbeat X アカウントをフォローいただいたり、この記事を SNS 等でシェアしていただけると嬉しいです!
まだ Hapbeat を未体験の方は、ぜひレンタルをお試しください!
無線版 Hapbeat は下記フォームより無償で、個人・法人問わずどなたでもお試し可能です。ご自身のコンテンツ・作品・研究などに触覚要素を加えてみたい方は、ぜひお試しください!
法人のお客様も大歓迎です!Hapbeat の試用・ご購入、イベント活用、その他 Hapbeat に限らず触覚技術の活用にご興味がある場合はぜひ下記フォームよりご相談ください!
