Robotics
gs_usb のタイムスタンプ・レイテンシ
gs_usb 経由の CAN feedback は FW と host のクロックが同期しておらず、ROS msg の header.stamp は host 受信時刻を反映するため実測から 2-10 ms 遅れている
要点: gs_usb 経由の CAN feedback は FW と host のクロックが同期していない。ROS msg の header.stamp は host が受信した時刻を反映し、motor で測定された時刻ではない。典型 2-5 ms、jitter によっては 10 ms 以上古い値になる。
遅延の内訳
| 段階 | 時間 |
|---|---|
| エンコーダ → FW サンプル | 0-1 ms |
| FW send buffer → CAN 送信開始 | ~100 µs |
| CAN 伝送 (500k+FD BRS, 6-8B) | ~60-200 µs |
| USB (gs_usb) | 1-5 ms、jitter で 10 ms+ |
| driver → subscriber | ~100 µs |
| 合計 (motor 事象 → host 到着) | 典型 2-5 ms、悪い時 10 ms+ |
タイムスタンプの流れ
motor 物理 → FW サンプル → FW send → CAN → USB → driver
| |
FW clock header.stamp = now()
(host と別) ここで初めて時刻が付くFW からのフィードバック frame に FW 時刻は含まれていない。
制御への影響
- 内側 PID (velocity/position on FW): 影響なし。FW clock で完結する
- Host からの FF 送信: 後追いになる。t0 の軌道サンプルを送ると FW 到着は t0+δ (δ = 2-5 ms)。v_ff=10 rad/s なら 50 mrad の追従誤差
対策
| 対策 | 実装コスト | 効果 |
|---|---|---|
δ を実測して Host 側で先出し (sendTrajectoryPoint(pos(t0+δ), vel(t0+δ), acc(t0+δ))) | 小 | 中: 平均遅延は消せる、jitter は残る |
| feedback frame に FW μs counter を載せる (protocol 拡張) | 中 | 大: bag で真の遅れが見える |
| PTP 相当のクロック同期 (ping-pong で offset+skew 推定) | 中〜大 | 大: jitter も追える |
ros2_control で解決するか
解決しない。ros2_control は host loop jitter を数十 µs 級に落とすが、FW↔host クロック非同期と gs_usb 遅延には効かない。これは hardware_interface 実装側の責務 (EtherCAT なら DC (Distributed Clocks) で解決するが CAN には対応する仕組みがない)。
ros2_control 化で得られるもの:
- Host loop jitter: 数 ms → 数十 µs
- 軌道 FF が標準機能 (JointTrajectoryController)
- MoveIt との互換性
ros2_control 化のコスト:
- RT Linux 運用が必要
- hardware_interface プラグイン実装
- timestamp 問題自体は残る
関連
最終更新: