Skip to content

feat: simulator-cli にibisバイナリプロトコルを移植#2

Open
HansRobo wants to merge 8 commits intomasterfrom
ibis
Open

feat: simulator-cli にibisバイナリプロトコルを移植#2
HansRobo wants to merge 8 commits intomasterfrom
ibis

Conversation

@HansRobo
Copy link
Copy Markdown
Member

@HansRobo HansRobo commented Apr 7, 2026

No description provided.

HansRobo added 8 commits April 7, 2026 21:25
grSimフォーク(ibis-ssl/grSim)で実装されていた独自機能をER-Force
simulator-cliに移植し、ibisブランチではデフォルトで有効化する。

## 追加した機能

### IbisCommandAdaptor
- UDP:12345で715バイトのibisバイナリパケットを受信
- SSLビジョンデータをキャッシュしてロボット位置からチームを自動判別
- P-gainによる角度制御、加速度制限、極座標→ロボットローカル速度変換を実装
- sslsim::RobotControl (MoveLocalVelocity) に変換してシミュレータへ送信

### IbisFeedbackAdaptor
- SSLビジョンデータ(位置・向き)とRadioResponse(速度・ボール検出)を統合
- 128バイトのibisバイナリフィードバックパケットを構築
- UDP:50100+robotIdで制御系に非同期送信

### RefereeTeamDetector
- Game Controller(UDP:10003)のマルチキャストを受信
- チーム名照合でblue/yellowを自動判別し、解決後は受信を停止

### PacketSenderThread
- QThread+QMutex/QWaitConditionによるUDPバッチ送信スレッド
- 送信レイテンシを物理ループから切り離す

### ibis_protocol.h
- ibisバイナリプロトコルの定数・構造体・デシリアライズ関数・パケットビルダーを集約

## CLIオプション(デフォルト値付き)
- --ibis-port (12345)
- --ibis-feedback-addr (127.0.0.1)
- --ibis-feedback-port-base (50100)
- --ibis-feedback-team-name (ibis)
- --ibis-use-referee
- --ibis-acc-speedup/brake (4.0/6.0 m/s^2)
grSimのdocker-publish.yamlを参考に、ibis-ssl/framework-simulatorcliイメージを
ghcr.io (GitHub Container Registry) へpublishするワークフローを追加。

- イメージ名: ghcr.io/ibis-ssl/framework-simulatorcli
- Dockerfile: data/docker/Dockerfile.simulatorcli
- プラットフォーム: linux/amd64, linux/arm64
- トリガー: masterへのpush / v*.*.*タグ / PR(ビルドのみ) / workflow_dispatch
- GitHub Actions cache、SBOM、attestation対応
masterではなくibisブランチを中心に運用するため、
ワークフローのトリガーブランチをibisに更新。
arm64クロスコンパイル(QEMUエミュレーション)を廃止し、
amd64のみのビルドに変更することでCI実行時間を削減する。
QEMUによるarm64ビルドは実ビルドの5〜10倍以上の時間を要していた。

Dockerfile.simulatorcliも合わせて最適化:
- ビルドステージ: 不要なQt5パッケージを削除(simulator-cliはQt6のみ使用)
- ランタイムステージ: devパッケージをランタイムライブラリのみに置換
  - qt6-base-dev, libqt6opengl6-dev → libqt6core6t64, libqt6gui6t64等
  - libprotobuf-dev → libprotobuf32t64
ロボットレスポンス受信とフィードバック送信の結合を分離し、
QTimerを使った定期送信に変更。これにより送信タイミングが
コマンドレスポンスの受信タイミングに依存しなくなる。

変更内容:
- IbisFeedbackAdaptorにfeedbackHzパラメータを追加(デフォルト125Hz)
- QTimer(PreciseTimer)を使って指定レートでフィードバックを定期送信
- RobotCacheを追加し、ロボットレスポンス受信時に速度・ボール検知をキャッシュ
- タイマー発火時にキャッシュデータを参照して送信する方式に変更
- --ibis-feedback-hz CLIオプションを追加(最小値1Hz)
- ログ出力にフィードバック送信レートのHz表示を追加
## 変更内容

### sendGroundTruth シグナルの追加(Simulator → SimProxy)
- `Simulator::sendGroundTruth(QByteArray)` シグナルを新設
- `Simulator::process()`(200Hz)内で `stepSimulation` 直後にノイズなし位置データを emit
- `world::SimulatorState` 形式でシリアライズして伝送
- `SimProxy` でフォワードするシグナルと接続を追加

### IbisFeedbackAdaptor の位置更新ソース変更
- `handleVisionData`(SSL Visionパース、66.67Hz)を廃止
- `handleGroundTruth`(world::SimulatorState パース、200Hz)に置き換え
- Bullet座標系 → SSL座標系の変換: x_mm = p_y×1000, y_mm = -p_x×1000
- クォータニオン回転行列第1列から yaw 角を算出

### ibis-referee-port CLIオプションの追加
- `RefereeTeamDetector` コンストラクタにポート引数を追加
- `--ibis-referee-port` オプションで Game Controller ポートを変更可能に

## 背景
フィードバック送信レート(125Hz)はVisionパケット更新レート(66.67Hz)を上回っており、
位置キャッシュが古いデータのまま複数回送信される問題があった。
シミュレータの物理ステップ(200Hz)から直接取得することで完全に解消する。
ランタイムイメージにbuildディレクトリ全体をコピーしていた問題を解消。
cmake installを使ってバイナリとconfigファイルのみを抽出し、
必要最小限のファイルのみランタイムステージへコピーするよう変更。

- RELATIVE_DATA_DIRS=ONでビルドし、実行時のconfig参照を./config/に固定
- cmake --install でbin/とconfig/のみをインストールプレフィックスへ配置
- ランタイムステージはinstall済みのbin/simulator-cliとconfig/のみをコピー
- 不要になったsimulator-cli_entrypoint.bashを削除
- ENTRYPOINTをtiniに、CMDをsimulator-cliに整理
- CMakeLists.txtにinstallターゲットを追加(バイナリ・configファイル)
ibisフィードバック送信レート(125Hz = 8ms)の整数倍(×2)に揃えることで、
毎回のfeedback送信時に必ず2ステップ分の新鮮な位置データが得られる状態にする。

## 変更内容
- SUB_TIMESTEP: 1/200.f(5ms)→ 1/250.f(4ms)
- process() トリガー間隔: 5ms → 4ms(scaling=1.0 時)

## 周期の関係
- sendGroundTruth: 250Hz(4ms)
- feedbackTimer: 125Hz(8ms)= 2ステップに1回
- 位置データの最大鮮度: 4ms以内

## 副作用
- Vision パケット送信レートが 66.67Hz → 62.5Hz に変化
  (閾値 12.5ms に対して4msステップが当たるのが4ステップ目=16ms)
  ibis用途では影響なし
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant