Topicを音で感じろ！ ros2 sonify

Transcript

1. ros2 sonify ROS 2 のトピックをリアルタイムに音へ変換して、 耳で監視・異常検知する CLI ROSCon JP ライトニングトーク / 3 min github.com/OTL/ros2-sonify · Apache-2.0 ros2 sonify 0:00 – 0:20
2. グラフは一度に 1 枚。 耳は 同時に 何本でも。 なぜ音なのか rqt_plot を睨む 複数トピックを鳴らす 視線は 1 箇所しか置けない。 人間は複数の音を並列に聞き分けられる。 他のトピックで何が起きているかは、 画面から目を離してロボットを見ながら、 画面を切り替えるまで分からない。 異常だけ耳で捕まえる。 $ ros2 sonify /cmd_vel /scan /battery_state ros2 sonify 0:20 – 0:45
3. 何が、どう聞こえるか マッピング 値の大小 → 音程（ペンタトニックに量子化） 値の変化 → 音量 メッセージレート → トレモロの速さ トピックごとの区別 → 左右の定位 → 音色の濁り ＋ 音量増 → 無音 NaN・レンジ外の値 受信の停止 トピック名しか渡していない。鳴らすフィールドは起動後 2 秒の観測で自動選択。 値域が桁違い（rad/s と mm と %）でも、減衰付き running min/max で正規化するので事前設定が要らない。 ros2 sonify 0:45 – 1:20
4. 「濁る」と「黙る」は別の音 ここが要点 音色が濁る その声だけ消える センサが壊れた LiDAR に NaN が混入。値の範囲は正常のままなの ≠ ノードが落ちた 受信が途絶えた声だけが無音になる。 他の声は鳴り で グラフでは気づきにくいが、音は明らかに汚れる。 続けるので、どのトピックが 死んだのかがそのまま分 悪化するほど音量も上がる。 かる。 現場での対処がまったく違う。 ros2 sonify 音でも区別できないと意味がない。 1:20 – 2:00
5. 効いている判断 聴き続けられる音にする ペンタトニックに量子化する。値をそのまま周波数にすると、複数トピックを同時に鳴らした瞬間に不協和で耳 が死ぬ。音階に丸めれば何本でも和音になる。 正常な変化は音程、異常は音色と音量。両方を音程で表すと「速く走っている」のか「壊れた」のか区別できな い。 異常判定に不感帯を置く。適応レンジは常に少しずつ縮むので、健全なサイン波でも毎周期わずかに端を押し 広げる。そのまま積算すると正常なロボットが延々とノイズを出す。 ros2 sonify 2:00 – 2:30
6. ROS を 2 ファイルに閉じ込める 設計 / 検証 純 Python 層 — rclpy を import しない extractor / selector / mapping / voices / engine / trace / replay ROS 層 monitor / command.sonify ROS 非搭載の環境でも音を検証でき、収録トレースを ROS なしで 再生できる。 test_no_rclpy_import.py が構造として固定。 音そのものを自動テストする 「無音でないこと」では止めない。生成した WAV を FFT にかけて 検証する。 音程も上がる（相関 > 0.8） NaN 混入で高域エネルギー増 停止で音量が落ちる ブロック境界のクリックノイズ回帰 値が上がれば Docker の ros:humble-ros-base で統合検証。 /scan は BEST_EFFORT なので既定の RELIABLE で購読すると 1 通も 届かず、エラーも出ずに「なぜか無音」になる。publisher の QoS を読んで追従。 ros2 sonify 2:30 – 2:50
7. 耳で見る、ロボットのデバッグ まとめ # そのまま鳴らす（フィールドは自動選択） $ ros2 sonify /cmd_vel /scan # 音声デバイスが無い環境（CI・コンテナ・SSH 先） $ ros2 sonify /scan --output wav --wav-path out.wav # 収録 → ROS なしで再生（当日のバックアップ） $ ros2 sonify /scan --record trace.jsonl $ sonify-replay trace.jsonl --output audio github.com/OTL/ros2-sonify · Apache-2.0 ros2 sonify 2:50 – 3:00