はじめに
株式会社EfficiNet Xの林 佑恭です！
前回記事の
本記事では「シミュレーションで学習したモデルを，そのまま実環境に適用したらどうなるのか？」について検証していこうと思います！
結論から言うと，シミュレーション環境上で驚異的な強さを誇ったAIは，実機へのデプロイによってその性能を大きく落とす結果となりました．
一方で，シミュレーション環境では性能が劣っていたものの，マレットの慣性を考慮した現実的な挙動を学習していたモデルを実機にデプロイしたところ，「最強のAI」よりも高い性能を見せました．
実機でのエアホッケー台
シミュレーション上でのエアホッケー台
目次
1.実機AIのパフォーマンス検証
- 速度モデルのパフォーマンス（Sim vs Real）
- 加速度モデルのパフォーマンス（Sim vs Real）
2.システム全体図
3.Simulation-to-Realのギャップ要因分析
- モデル固有のギャップ
- 速度モデル特有の問題点
- 加速度モデル特有の問題点
- システム共通のギャップ
- 計測・制御系の課題(レイテンシー，OpenCVノイズ，速度推定の誤差)
- 機械的・物理的な課題(モーター性能差，機械的クリアランス，オクルージョン)
4.Sim-to-Realギャップを解消するためのアプローチ
- 改善策と今後の課題
- Sim-to-Realを乗り越えた事例の紹介
5.使用した機材
1.実機AIのパフォーマンス検証
速度モデルのパフォーマンス（Sim vs Real）
シミュレーション上の速度モデルの挙動
速度モデルは，ボールを撃ち漏らさない高速ラリーを継続し，五月祭で95%以上の勝率を誇る驚異的な性能である一方，パックの慣性を無視しているため，実機では非現実的な挙動をしてしまうという課題を持つモデルです．実機にデプロイしても，そのラリー力は維持されるのでしょうか？？
実機上の速度モデルの挙動
なんと，遅い速度のパックですらほとんど打てない結果となってしまいました．．．パックが通り過ぎた後にマレットを動かしてしまっていますね．これでは，最強のエアホッケーAIとは程遠いです．
遅いパックを打てないパターンとして
- 見逃し:パックが完全に通り過ぎた後に動き出す
- 完全な空振り:パックの動きとマレットの動きが交差する見込みなく空振りする
- 直前での逸れ:パックの動きとマレットの動きが交差する見込みはあるが，ぶつかる直前で軌道が左に逸れる
の3パターンが見られました．
加速度モデルのパフォーマンス（Sim vs Real）
シミュレーション上の加速度モデルの挙動
加速度モデルは，慣性を考慮して学習したことで，マレットの動きが現実的で滑らかになり，不自然な挙動は大幅に改善されましたが，その結果，パックの撃ち漏らしが頻発し，速度モデルよりも性能が低いという課題を持つモデルです．モデルの強さを減らした分，実機へのデプロイを意識した設計になっている加速度モデルは，実機ではどのような動きをするのでしょうか？？
実機上の加速度モデルの挙動
遅いパックに対しては，悪くない精度で打てています！しっかりと助走をつけてからパックを打とうとする挙動が見られます．速度モデルと同様に，最強のエアホッケーAIとは程遠いですが，速度モデルよりは性能が高いです．
遅いパックを打てないパターンとして
-
急な軌道変更の失敗：
マレットが急に速度方向を大きく変える必要がある場合に．方向転換が間に合わずに空振りする．特に，横方向の動きから縦方向への切り替え時に顕著 -
壁際パックへの接近失敗：
壁ギリギリを通過するパックに対し，正確な位置まで十分に接近できずに撃ち漏らす
の2パターンが見られました．
システム全体図
概要図
エアホッケー台
システムは，計測，判断，実行の3つの主要なフェーズで構成されており，このサイクルを繰り返すことでマレットを制御していると考えると情報の流れがわかりやすいです．
1.計測
- 入力:iPhone16とCamoStudio(カメラアプリ)でエアホッケー台を撮影
- 処理:OpenCVを用いて，撮影した画像からニューラルネットワークの入力値となる情報（パックやマレットの位置や速度情報）を計算します．
2.判断
- 処理:前章で作成したNeural Network（速度モデルまたは加速度モデル）に，OpenCVで計算されたパックとマレットの状態を入力します，
- 出力:AIが計算したマレットの動作指令値（速度モデルなら速度，加速度モデルなら加速度）が出力されます．
3.実行
- 通信：CAN通信を通して，モータードライバ（EPOS4 70/15）にモーターへの指令値（回転速度など）を伝えます．
- 駆動：指令値を元に，Maxon DCXモーターを駆動させ，マレットを動かします．
(モーター1に500rpm,モーター2に500rpmで動くように指令した時の様子)
1から3のサイクルが繰り返され，Neural Networkがマレットをリアルタイムで制御します．このサイクルは，一秒間で60回(60FPS)繰り返されます．
このシステムは，非常に高速な処理が求められます．各ステップで発生するわずかな遅延や計測誤差が，次章で分析するSim-to-Realギャップの原因にもなります．
Simulation-to-Realのギャップ要因分析
シミュレーションで最強だったAIの性能を実機で大きく低下させ，加速度モデルとの性能を逆転させたSim-to-Realギャップの要因を詳細に分析します．ここでは，モデルの設計に起因するモデル固有のギャップと，制御システムや物理環境に起因するシステム共通のギャップに分けて解説します．
モデル固有のギャップ
速度モデル特有の問題点
速度モデル特有の問題点としては，過大な速度指令値による速度追従遅延，壁にぶつからないための速度司令値の抑制が考えられます．
-
過大な速度指令値による速度追従遅延
速度モデルは，モーターの物理的な性能限界を考慮していません．Neural Networkの出力の最大値をモーターの最大回転数時のマレットの速度に合わせて，250cmとしたところ，
$$
1フレーム間の速度指令変化≤v_{max} − v_{min} = 250 - (-250) = 500cm/s
$$という式が成り立ってしまいます．右に全速力で進んでいる状態で，Neural Networkが「左に全速力で進め」と指令する場合に等号が成立します．この式は，速度モデルは1フレームで最大500cm/sの急激な速度変化を指令することを示しています．
これは，実機のモーターの加速度の限界を大幅に超えるため，指令速度と実際の速度の間に極めて大きな差が生じてしまいます．これにより，空振りや壁への衝突が起こりました． -
壁にぶつからないための速度司令値の抑制
速度モデルの出力をそのまま速度司令値に使用すると壁に衝突したため，その回避策として，壁付近ではモーターへの速度司令値を，壁との距離に応じて小さくする処理を追加しました．その結果，衝突事故はなくなりましたが，現実の挙動とSimulationとの間に大きなギャップが生じてしまいました．
加速度モデル特有の問題点
加速度モデルは,実機のモーターの性能限界を考慮し,マレットの加速度の最大値を制限することで,速度追従遅延を抑制する設計を採用しました.
| 記号 | 意味 |
|---|---|
| $v_{\text{new}}$ | $\text{次フレームでのマレットの速度指令値}$ |
| $v_{\text{current}}$ | $\text{今フレームでのマレットの速度}$ |
| $a_{\text{NN}}$ | $\text{Neural Networkが出力した加速度}$ |
| $a_{\text{NN},max}$ | $\text{Neural Networkが出力する最大値}$ |
| $\Delta t$ | $\text{制御周期} = \frac{1}{60} \text{秒}$ |
のように定義すると，今回のシステムでの次のモーターの回転速度指令値は
$$
v_{\text{new}} = v_{\text{current}} + a_{\text{NN}} \cdot \Delta t
$$
のようになります．この時，
$$
1フレーム間の速度変化 = v_{\text{new}} - v_{\text{current}} \leq a_{\text{NN},max} \cdot \Delta t
$$が成立します．この式から分かる通り，Neural Networkが出力する最大値を小さくすることで，一フレーム間の速度変化の最大値を小さくできるため，速度追従遅延が軽減されます．今回のシステムでは，一フレーム間の速度変化の最大値は，16cm/sになるように設計しました．これが，加速度モデルの性能が実機で逆転した最大の要因だと推察されます．
しかし，その制限により以下のような問題は残りました．
-
急な軌道変更の失敗:
加速度に制限があるため，マレットが急に方向転換を必要とする場合に空振りしてしまうケースがありました．実は，モーターは一時的には加速度の限界を超えて動けるらしいのですが，加速度の上限を事前に決めているので，モーターの性能を十分に引き出せなくなってしまいました． -
レイテンシー:
速度追従遅延は軽減されたものの，後述する計算遅延や通信遅延といった，他のレイテンシー要因は依然として存在し，パックが速い場合は撃ち漏らしが頻発しました．
システム共通のギャップ
モデルの種類によらず，実機環境の計測・制御系，および機械的な構造全体が引き起こす問題点を紹介します．
計測・制御系の課題（レイテンシー，OpenCVノイズ，速度推定の誤差）
-
レイテンシー
- 計算遅延：OpenCVによる画像処理とNeural Networkによる推論計算にかかる時間
- 通信遅延：CAN通信など，指令値をモータードライバに伝える時間
- 速度追従遅延：指令速度に対して，モーターが実際にその速度に到達するまでの時間．パックが高速で移動する際の空振りの主要因となります．
-
推定値と実値でのギャップ
- OpenCVの推定値に乗るノイズ:画像処理を用いた位置推定には限界があり，パックやマレットの推定位置には数cm程度のノイズが乗ります．このノイズは，位置の変化から計算される速度推定にさらに大きな影響を与えてしまいます．
- 速度の推定値と実値でのギャップ:一フレームの間の位置の変化から速度を計算しているため，パックが反射する時に誤った速度推定を行してしまいます．例えば，1フレームの間に，壁に反射しながら地点Aから地点Bに移動した場合を考えましょう．この時，パックの速度は$(L1 + L2) \cdot 60(FPS)$で計算されるべきですが，今回のシステムでは $L3 \cdot 60(FPS)$ で計算されてしまいます．以上の例から分かるように，パックが反射する時，OpenCVによる速度推定値は実際の速度よりも小さい値になってしまいます．
機械的・物理的な課題（モーター性能差，動作機構の遊び，オクルージョン）
-
左右のモーターの性能差
左右のモーター間で最高回転数(または最高回転加速度)に差異がある可能性が高いです．例えば，Neural Networkが最高速（250cm/s）を指令した場合，左右のモーター性能の違いにより，マレットが想定された直線軌道から逸れてしまう現象が生じます．これは，指令値が同じでも，片側のモーターの追従速度が他方より速くなるためです． - 動作機構の遊び:
今回のロボットアーム（マレットを保持する機構）は，モーターを固定してもマレットがわずかにガタつき．上下左右に動いてしまう設計になっていました．これは正確な位置制御の妨げとなります．
-
カメラによるパックのオクルージョン:
ロボットアーム（マレットを保持する機構）がカメラの視野を遮ることで，パックが死角に入り，OpenCVによる画像処理ではその位置を特定できません．これにより，パックの追跡が途切れてしまいます．
Sim-to-Realギャップを解消するためのアプローチ
改善策
| ギャップ要因 | 対策アプローチ |
|---|---|
| 壁司令値の抑制 (速度モデル) | 速度モデルの使用を止め，加速度モデルを使用する |
| 左右モーターの性能差 | 高性能で個体差の少ないモーターに買い替える．または，モーターの特性を実機で計測し，指令値をモーターに合わせて補正する． |
| 動作機構の遊び | 動作機構を再設計し，駆動系の遊びを排除する． |
| カメラによるオクルージョン | 複数カメラを導入して死角をなくす． |
| 速度の推定値と実値のギャップ | OpenCVでの処理方法を変える．具体的には，壁にぶつかる際は別の速度計算方法にする． |
| レイテンシーの対策 | 過去数フレームの状態を渡したり，未来の予測をしてその状態をNeural Networkに入れたりする |
| 計測値に乗るノイズの対策 | カルマンフィルタなどを用いてノイズ除去を行なったり，Simulation上での学習時に実機で観測されるのと同程度のランダムノイズを載せたりする |
今回のシステムでは，過去数フレームの状態を渡すことはしましたが，レイテンシーの完全な対策とはなりませんでした．
Sim-to-Realを乗り越えた事例の紹介
Deepmind社の
今回の経験から，先人たちがSim-to-Realの壁を打ち破る具体的な手法に興味が湧いてきました．今後は，このレイテンシー問題やノイズ問題を始めとするSim-to-Realのギャップ問題を華麗に乗り越えた強化学習の実装事例を元に，Sim-to-Realの壁を打ち破る解決策を詳しく紹介していく記事を投稿する予定です．どうぞご期待ください！
(いいねをいただけますと，励みになります！）
使用した機材
-
エアホッケーテーブルは，
を使用しました．
-
モータードライバーは，モータードライバ EPOS4 70/15を使用しました．
-
モーターは，モータ Maxon motor DCXモーター B7740CE943AC DCX35L GB KL 24Vを使用しました．
-
CAN通信をする際には，
を使用しました．
-
パソコンには，RTX4070のゲーミングPCを使用しました．
-
カメラには，iPhone16を使用しました．カメラアプリとして，CamoStudioを使用しました．