Physical AI実装における「フィールドバス」の重要性を解説 ロボットアーム「OpenArm」のCAN FD活用例から紐解く産業用ネットワーク
要点
-
Physical AI（実世界で動作するAIシステム）の開発では、機器同士を繋ぐ産業用ネットワーク「フィールドバス」の知識が実機の安定動作に影響する。
-
フィールドバスはWeb系通信と異なり、リアルタイム性や同期精度、優先度制御、異常時のフェイルセーフなどが重視される。
-
オープンソースのロボットアーム「OpenArm」では、制御周期の高速化とデータ量増加に対応するため、従来のCANより高速・大容量な「CAN FD」規格が採用されている。
-
OpenArmのモータ制御には、5つのパラメータで制御する「MIT mode」という独自のサイクリック（周期的）通信プロトコルが使用されている。
-
実機開発では通信規格の仕様理解に加え、配線や終端抵抗などの物理的な要因から順にトラブルシューティングを行う姿勢が重要となる。
-
株式会社ABEJAの共通基盤グループに所属する内田氏は、2026年7月15日、同社のテックブログにおいて、Physical AI（人工知能をロボットなどの物理的な実体に搭載し、現実世界で動作させる技術）の実装で重要となる産業用ネットワーク「フィールドバス」の考え方を解説する記事を公開した。記事では、オープンソースのヒューマノイドロボットアーム「OpenArm」における「CAN FD」を用いたモータ制御の実例を交え、Web系エンジニア向けに実機制御通信のポイントを紐解いている。
リアルタイムな分散制御を支えるフィールドバスの特徴
AIやWebシステムの開発では、HTTPやgRPCなどの信頼性の高いネットワーク層の上に構築された通信プロトコルが一般的である。しかし、ロボットや産業機械の制御で用いられる「フィールドバス」（工場やロボットなどの現場で制御装置と周辺機器を繋ぐデジタル通信ネットワーク）は、リアルタイムな分散制御を行うために異なる設計思想を持つ。
フィールドバスでは、データが「確実に届くこと」に加えて、「一定の周期内に届くこと」や「複数のモーターなどの機器が正確に同期して動くこと」が要求される。通信は主に、制御に不可欠なデータを一定の間隔で送り続ける「周期的な通信」（サイクリック通信）と、設定の変更や診断情報の読み出し時に発生する「非周期的な通信」に分けて設計される。
制御通信を選定・評価するための5つの指標
記事では、制御通信の仕様を見極める上で重要となる5つのポイントが提示された。
- 制御周期：データをやり取りする時間の間隔。ロボットアームの制御などではミリ秒（ms）以下の単位が求められる。
- 最悪遅延とジッタ：ジッタとは通信周期の揺らぎのことであり、最悪のケースでどれだけ遅延が発生するかを考慮する必要がある。
- 同期精度：複数のモーターなどを同時に同じ時間基準で協調動作させるための精度。
- バス負荷とプロセスデータ設計：通信回線（バス）の帯域幅に対する負荷。毎周期やり取りされる「プロセスデータ」（モータ指令値やセンサ値などの制御データ）のサイズを最適化することが求められる。
- 安全・診断・保守性：通信が途絶えた際などに、機器を安全に停止させるフェイルセーフ機能などが含まれる。
OpenArmが採用する「CAN FD」と「MIT mode」の実態
実際の適用例として紹介されているのが、オープンソースのロボットアーム「OpenArm」における「CAN FD」通信である。CAN FDは、従来の産業用通信規格であるClassic CANを拡張し、最大64バイトのデータ長とより高速な通信（最大5Mbps以上）に対応した規格だ。
OpenArmでは、アームに搭載されたDamiao（達妙）製モータと制御装置の間でサイクリック通信を行っている。ここでのプロトコルには、標準的な産業規格である「CANopen」ではなく、独自の「MIT mode」が採用されている。MIT modeでは、位置、速度、トルク、比例ゲイン（Kp）、微分ゲイン（Kd）という5つのパラメータを1つのデータフレームに詰め込んでモータを制御し、状態フィードバックを受け取る。
従来のClassic CANでは、データフレームの最大サイズが8バイトに制限されているため、5つの浮動小数点数を同時にやり取りする多軸のロボットアーム制御では、帯域幅が不足する。そのため、OpenArmのように高速な制御周期（500Hz〜1kHzなど）を維持しながら複数のモータを制御するシステムでは、大容量化されたCAN FDが不可欠になるという。
開発・デバッグにおける注意点とアプローチ
OpenArmを用いた開発では、Python用の制御ライブラリであるopenarm_canと、Linux標準のCANデバッグツール群であるcan-utilsが併用される。これにより、送信されている生の通信データを監視しながら動作確認が行われる。
実装や運用の過程では、各モータに割り当てる識別子（CAN ID）の重複や、モータのレジスタ設定ミスによるボーレート（通信速度）の不一致などで通信が途絶えるトラブルが発生しやすいという。内田氏は、通信が動かない場合のトラブルシューティングとして、ソフトウェアのコードを疑う前に、まずはオシロスコープなどを用いた物理レイヤーの配線不良や終端抵抗の有無、ネットワークの設定から順に遡って確認していくアプローチが有効であると説明している。