notes
Robotics

CAN の実効帯域とフレーム rate

bit rate と frame rate を区別。8B payload の Classical CAN で ~9000 fps、CAN-FD 500k/4M で ~11000 fps。実用は 60-70%

要点: CAN の「帯域」= bit rate (物理層)、「サンプリングレート」= frame rate (実用) は別物。8 バイト payload の Classical CAN 1 Mbps で ~9000 fps 理論、~6000 fps 実用。CAN-FD 500k arb / 4M data で ~11000 fps 理論、~8000 fps 実用。

数字#

bit rate と bus 長 (物理限界)#

プロトコルbit rate最大 bus 長
Classical CAN1 Mbps40 m
Classical CAN500 kbps100 m
CAN-FD arb 相~1 Mbps上と同じ
CAN-FD data 相 (BRS)8 Mbps max、実用 2-5 Mbps数 m 級
CAN-XL10-20 Mbps数 m

1 フレームの bit 数 (概算)#

Classical CAN (11-bit ID、8 byte payload):

  • SOF + ID + control + data + CRC + ACK + EOF + IFS ≈ 111 bit
  • Stuff bit で最大 +25% → 実測 111-140 bit

CAN-FD (arb 相と data 相で異なる速度):

  • Arb 相 header: ~30 bit at nominal rate
  • Data 相: 8-byte で ~80 bit、64-byte で ~530 bit at data rate
  • BRS ↑↓ の切り替え overhead: 数 bit

実効 frame rate#

理論 = bit rate ÷ 1 フレーム bit 数、実用は 60-70% (IFS + arbitration + retransmit)。

プロトコル + payload1 フレーム時間最大 fps実用 fps
Classical CAN 1 Mbps, 8B111 μs~9000~6000
CAN-FD 500k/4M, 8B~90 μs~11000~8000
CAN-FD 500k/4M, 64B~200 μs~5000~3500
CAN-FD 500k/8M, 8B~70 μs~14000~10000

帯域 vs 制御ループ rate#

区別すべき 3 段:

場所典型 rate決めるもの
FW 内 current loop10-50 kHzESC 内蔵
FW 内 speed/position loop1 kHzTimer 設定
Feedback publish (FW → CAN)100-1000 Hzframe rate 割り当て
Host 側 subscribe (DDS)30-200 HzDDS QoS + CPU
上位制御 (host → CAN command)100-1000 HzROS 2 timer

制御性能は FW の 1 kHz が支配、CAN 帯域はそれを N motor で分け合えるか。

使用率計算 (n motor)#

Command + feedback を各 motor で 100 Hz なら:

RC27 の例 (8 motor × command 3 frame + feedback 1 frame × 100 Hz):

  • fps = 8 × (3 + 1) × 100 = 3200 fps
  • CAN-FD 500k/4M 実用 8000 fps の 40% → 余裕あり
  • 制御 rate を 1 kHz に上げると 32000 fps → bus 容量超過

Sampling point (bit 内) は別物#

「CAN のサンプリング」= 1 bit のどの瞬間に 0/1 判定するか (信号品質のため):

  • 1 bit を Time Quantum (TQ) に分割、8-25 TQ が典型
  • Sample point: bit time の 75-87.5% (Classical)、70-75% (CAN-FD data 相)
  • 制御系のサンプリング周期とは無関係

詳細は CAN のビットタイミング 参照。

Bus 使用率の目安#

使用率状態
< 30%余裕、追加 device OK
30-50%実用推奨上限 (real-time 保証しやすい)
50-70%動くが arbitration 待ちが目立つ、優先度低いフレームは遅延
> 70%エラー/ retransmit で崩壊しやすい

実測方法#

canbusload -b -r -t -c 3 can0@1000000  # can-utils
  • -b: byte 単位
  • -r: real-time refresh
  • -t: transport-layer overhead 含む

or candump can0 | wc -l を 1 秒間実行 → fps 概算。

フレーム遅延の目安#

  • Classical CAN 1 Mbps, 8B: 送信開始 → 完了 111 μs
  • 平均 arbitration 待ち: 1-2 フレーム時間 = ~200 μs
  • 合計 host → wire → 相手 ≈ 300-500 μs
  • CAN-FD (500k/4M): 100-200 μs

bus 上遅延は数百 μs 級。1 ms の phase lag の内訳では 無視できるレベル。

phase lag の主犯は:

  1. gs_usb + USB scheduling (~1-5 ms)
  2. FW 制御 loop の period wait (0-1 ms)
  3. 機構応答 (可変)
  4. Feedback publish 頻度 (~10-30 ms/回)

CAN 自体は数百 μs で確定的。

関連#

最終更新:

On this page