0. はじめに

こんにちは、共通基盤グループの内田です。

Physical AIの開発では、データセットやモデルに注目が集まりがちですが、現場で意外と効いてくるのが、フィールドバスを含む産業用ネットワークの知識です。

AIエンジニアやWeb系エンジニアにとって、HTTP/gRPC/MQTTのような通信は馴染みがあっても、CAN、EtherCAT、PROFINET、EtherNet/IP、Modbusといった産業用ネットワークは少し違った見方が必要になります。アプリケーションプロトコルだけでなく、通信周期、優先度、同期、配線、終端、ノイズ、フェイルセーフといった要素が、実機の振る舞いに直接影響するためです。

本記事では、フィールドバスの基本的な考え方と代表的な規格を概観しながら、Physical AI実装で必要になる制御通信の見方を整理します。後半では、Physical AI向けに開発されているオープンソースのヒューマノイドロボットアームであるOpenArmを題材に、CAN FDを使ったモータ制御の例を紹介します。

この記事では、AI/Web系エンジニアの方が実機制御に入るときに、通信のどこを見ればよいのかを理解するための入口を提供できればと思っています。

1. フィールドバスとは

フィールドバスは、産業用ネットワークの一種であり、PLCやモーションコントローラなどの上位制御装置と、サーボドライブ、I/O、センサ、アクチュエータなどの現場機器を接続するための通信基盤です。

Wikipedia では、フィールドバスを次のように説明しています。

“A fieldbus is a member of a family of industrial digital communication networks used for real-time distributed control.”

ここで重要なのは、フィールドバスが単に「データを送受信するためのネットワーク」ではなく、「リアルタイムな分散制御のための通信基盤」として設計されている点です。

工場の製造ライン、産業機械、ロボット、計装制御システムでは、多数の機器が協調して動作します。たとえば、ロボットでは複数のモータやセンサが制御装置と接続され、モータの状態やセンサ値の取得、制御演算、次の指令値の送信を一定周期で繰り返します。この閉ループ制御を安定して動かすには、データが「届くかどうか」だけでなく、「決められた周期で届くか」「遅延やジッタが許容範囲に収まるか」「複数の装置が必要な精度で同期できるか」が重要になります。

そのため、フィールドバスを含む産業用ネットワークでは、Web系の通信とは異なり、次のような点が設計上の関心になります。

リアルタイム性：決められた周期内に通信できるか、ジッタを評価できるか
同期機構：複数の機器を同じ時間基準で動かせるか
優先度制御：重要な制御データを優先して扱えるか
物理層の安定性：配線、終端、ノイズ、距離、トポロジが適切か
異常時の振る舞い：通信断や遅延を検出し、安全側に停止できるか

また、多くの産業用ネットワークでは、周期的な通信と非周期的な通信を分けて設計します。

周期的な通信は、モータへの指令値、センサ値、I/O状態など、制御ループで毎周期必要になるプロセスデータのやり取りに使われます。一方、非周期的な通信は、機器の設定、パラメータ変更、診断情報の読み出し、アラーム通知など、必要なタイミングで発生するデータのやり取りに使われます。

つまり、フィールドバスを理解するうえでは、単に「どの規格が速いか」を見るのではなく、制御に必要な周期通信と、設定・診断に使う非周期通信をどのように分けて扱うかを見ることが重要です。この視点は、CANopen、EtherCAT、PROFINET、EtherNet/IPなど、異なる産業用ネットワークを比較するときにも共通して役立ちます。

2. Web系通信と比べて理解するフィールドバスの特徴

フィールドバスを含む産業用ネットワークの特徴は、Web系通信と比較すると理解しやすくなります。ここでは、AI/Web系のエンジニアが馴染みやすい HTTP、gRPC、MQTT、WebSocket などの通信と比べながら、フィールドバスの見方を整理します。

Web系通信では、HTTP や gRPC、MQTT などのアプリケーション層プロトコルの下に、TCP、UDP、QUIC、IP がある構成を前提にすることが多いです。たとえば HTTP は stateless なアプリケーションレベルのプロトコルとして定義されており、TCP はアプリケーションに対して信頼性のある順序付き byte stream を提供します。

そのため、Web系のアプリケーション開発では、「どの API にリクエストを投げるか」「どの Topic に Publish するか」「タイムアウトやリトライをどう扱うか」といった L7〜L4/IP 付近が主な設計対象になりやすく、Ethernet や Wi-Fi などの L1/L2 は比較的抽象化されています。

一方、フィールドバスでは、L1/L2 の性質が制御品質に直接影響します。

たとえば CAN では、上位に CANopen のようなプロトコルや装置独自の制御プロトコルが載りますが、実際の設計では CAN ID、ビットレート、フレーム長、バス負荷、配線、終端抵抗、ノイズ耐性などを意識する必要があります。CAN では CAN ID がバス上の優先度にも使われ、数値が小さい ID ほど高い優先度を持ちます。

つまり、Web系通信では低いレイヤがある程度隠れているのに対し、フィールドバスでは低いレイヤの設計がアプリケーションの振る舞いに近い位置にあります。

この違いは、通信が担う役割にも表れます。

Web系通信では、多くの場合、通信はアプリケーション間でデータをやり取りするための手段です。もちろん低遅延性やスループットが重要なシステムもありますが、業務アプリケーションでは、多少の遅延やばらつきがあっても、最終的に正しいデータが届くことに価値があります。

一方、ロボットや産業機器では、フィールドバスがモータや I/O の閉ループ制御に組み込まれます。制御装置が指令値を送り、モータやセンサの状態量を受け取り、それをもとに次の指令値を計算する、という循環を一定周期で回すためです。

そのため、フィールドバスでは平均レイテンシだけでなく、周期、最悪遅延、ジッタ、同期精度が重要になります。たとえば PROFINET IRTの仕様では、デフォルトの最小更新周期として 250 µs とされており、対応ハードウェアや構成によっては 31.25 µs 周期、1 µs 程度のジッタも示されています。

また、通信異常時の扱いも異なります。Web系通信では、タイムアウト、リトライ、エラー応答として扱うことが多いですが、ロボットや産業機器では、通信断や大きな遅延が、脱力、保持、ブレーキ、Safe Torque Off などの安全側への遷移に関わります。そのため、PROFINET には PROFIsafe、EtherCAT には Safety over EtherCAT / FSoE のような安全通信の仕組みも用意されています。Safety over EtherCAT は IEC 61508 に基づいて開発され、IEC 61784-3 で標準化された技術です。

まとめると、Web系通信とフィールドバスを含む産業用ネットワークの違いは、次のように整理できます。

観点	Web系通信	フィールドバスを含む産業用ネットワーク
主な関心	API、Topic、メッセージ、再送、タイムアウト	周期、優先度、同期、配線、終端、ノイズ
時間の見方	平均レイテンシ、P95/P99、スループット	周期、最悪遅延、ジッタ、同期精度
通信の役割	アプリケーション間のデータ交換	モータ、センサ、I/O の閉ループ制御
失敗時の扱い	タイムアウト、リトライ、エラー応答	安全停止、脱力、保持、ブレーキなどに関わる

つまり、フィールドバスは Web系通信の単なる低レイヤ版ではありません。モータやセンサの状態量を一定周期で循環させ、閉ループ制御を成立させるための通信です。

そのため実務上は、AI/Web側の処理、ログ、監視、可視化、映像伝送などは通常のネットワーク通信に逃がし、制御周期に関わる指令値、状態量、I/O、同期信号はフィールドバス側に閉じ込める、という分け方が重要になります。

3. 代表的なフィールドバス・産業ネットワーク

規格名を検索すれば仕様や対応製品は見つかりますし、最近ではAIで複雑な仕様も簡単に要約して概要を知ることができます。一方で、初見だと「どの名前で調べればよいのか」「どれがモータ制御向けなのか」「既設設備では何に出会いやすいのか」が分かりにくいと思います。

この章では、Physical AI やロボット制御の文脈で出てきやすいフィールドバス・産業ネットワークを、検索の入口として整理します。厳密な優劣比較ではなく、最初に全体像を掴むための地図として読んでください。

個別の規格を詳しく調べる場合は、まず以下のような資料が参考になります。最初に読むなら、一覧性の高いキーエンスの資料と、体系的に整理された『産業用ネットワークの教科書』が使いやすいと思います。

資料	使いどころ
キーエンス「代表的なフィールドネットワークの紹介」	AS-i、CANopen、CC-Link、DeviceNet、EtherCAT、EtherNet/IP、Modbus など、主要なフィールドネットワークを広く眺める入口として使いやすいです。代表的なフィールドネットワークについて、概要、配線方法、通信プロトコル、特徴が整理されています。
キーエンス「産業用Ethernetの整理」	EtherCAT、PROFINET、EtherNet/IP、CC-Link IE など、産業用 Ethernet 系の違いを見たいときに参考になります。制御周期、同期精度、実装方式、既存設備との相性という観点で整理されています。
FAプロダクツ/JSS「フィールドバスとは？主な種類・規格の比較、イーサネットとの違い」	フィールドバスの基本概念、主要プロトコル、技術的な仕組み、産業用Ethernetとの違いを広く確認できます。
オリックス・レンテック「工場ネットワークにおけるフィールドバスの役割と種類」	工場ネットワークにおけるフィールドバスと産業用Ethernetの関係を掴むのに向いています。フィールドバスの安定性、接続性、安全性や、産業用Ethernetへの移行についても説明されています。
N-S-C「フィールドバスの実現技術」	RS-232C、RS-422、RS-485 などの低レイヤや、シリアル通信をベースにしたフィールドバスの考え方を確認したい場合に参考になります。
『産業用ネットワークの教科書』	フィールドバス、産業用Ethernet、デバイスバスを体系的に学びたい場合の書籍です。フィールドバス、CC-Link、DeviceNet、PROFIBUS DP、産業用Ethernetなどを扱う構成になっています。

産業用ネットワークでは、名前が似ていても世代・レイヤ・用途が異なる規格があります。たとえば、CC-Link と CC-Link IE TSN、PROFIBUS と PROFINET、CAN と CANopen、Modbus RTU と Modbus TCP は、Family 名だけで同じものとして扱うと誤解しやすいです。機器仕様を見るときは、対応している規格名、世代、プロファイルまで確認するのが重要です。

規格 / Family	出会いやすい場面	概要
EtherCAT	短周期・多軸同期が必要な装置でよく出てきます。	通常のTCP/IPのようにノード間で個別に通信するのではなく、1つのフレームが全ノードを通過しながらデータを読み書きする特殊な方式で高速化しています。Beckhoff は EtherCAT を “Ethernet fieldbus” と位置づけています。
PROFINET	欧州系設備、製造業全般、PLC連携、プロセス、モーション、ロボットなど	工場系で広く使われる Industrial Ethernet です。リアルタイム通信、トポロジ、設定、診断に加えて、PROFIsafe、PROFIdrive、PROFINET over TSN などの関連キーワードも一緒に調べると全体像を掴みやすいです。
EtherNet/IP	北米系設備、自動車、離散製造、Rockwell 系PLC環境など	標準 Ethernet / TCP/IP との親和性が高い規格です。ODVA は EtherNet/IP について、標準 TCP/IP を利用し、UDP によるリアルタイムな周期データ伝送も扱います。CIP、Implicit / Explicit messaging、CIP Motion、CIP Sync、CIP Safety あたりが検索キーワードになります。
CC-Link Family	日本・アジア圏、三菱電機系PLC、FA設備、I/O、モーション、安全、TSN文脈など	CC-Link、CC-Link IE Field、CC-Link IE TSN、CC-Link IE Field Basic など枝が分かれます。「CC-Link対応」と書かれている機器を見たときは、どの世代・どの規格に対応しているかを確認した方がよいです。CC-Link IE TSN は TSN 技術を使い、複数周期の運用や高精度な時刻同期を扱う規格。
MECHATROLINK	サーボ、モーション、半導体・液晶関連装置、搬送、包装、工作機械など	モーション制御向けの色が強い規格です。安川電機系・サーボ系の装置で見かけやすいです。MECHATROLINK-III は Ethernet ベースのモーション制御用ネットワークで、100Mbps、最小リンク周期31.25us、同期ジッタ1us以下などの仕様が示されています。
CAN / CANopen	組込み機器、装置内通信、移動体、低〜中速の分散制御、モータドライブなど	CAN は下位層寄りの通信技術、CANopen はその上に載る上位プロトコルとして見ると分かりやすいです。CANopen は CAN ベースの第7層プロトコルで、デバイス機能やプロファイルも定義します。モータ制御では CiA 402 も重要な検索キーワードになります。
Modbus RTU / TCP	計測、監視、PLC・機器連携、既設設備、シンプルなレジスタ読み書きなど	多軸モーション制御の主役というより、既設機器とつなぐ、値を読む、設定を書く、という場面でよく出てきます。Modbus RTU は主にシリアル回線、Modbus TCP は TCP/IP 上で使われます。公式仕様も Application Protocol、Serial Line、TCP/IP 実装ガイドとして分かれています。
PROFIBUS	既設設備、欧州系ライン、プロセスオートメーション、FA設備など	新規では PROFINET に移行している場面もありますが、既設設備ではまだ出会う可能性があります。PI は PROFIBUS を fieldbus-based automation standard とし、コントローラと分散フィールド機器を単一バスケーブルで接続する規格。
DeviceNet	既設設備、I/O、センサ、アクチュエータ、北米系・Rockwell 系の古い設備など	ODVA 系のレガシー寄りフィールドバスとして見ておくとよいです。DeviceNet は CAN をデータリンク層に使うデジタルな multi-drop fieldbus network。新規採用というより、既設設備との接続・保守で出会う規格として押さえるのがよいと思います。

Physical AI やロボット制御の新規開発では、まず EtherCAT、PROFINET、EtherNet/IP、CC-Link IE TSN / Field、CAN/CANopen あたりに当たりやすいと思います。一方で、既設設備、計測、監視、PLC連携まで含めると、Modbus RTU/TCP、PROFIBUS、legacy CC-Link、DeviceNet などにも出会います。

現在の Physical AI ではロボット単体が研究対象になることも多いですが、社会実装に進むほど、ロボットは PLC、I/O、センサ、既設装置、監視系と接続されます。そのときには、工場やプラントに混在する複数の産業用ネットワークを理解し、物理的にも通信的にも既存システムへ接続する設計が必要になると予想しています。

この章の表は、採用規格を決めるための比較表ではありません。まずは「どの名前で検索すればよいか」「同じ Family 名でも何が違うのか」「自分が扱う装置の文脈に近い規格はどれか」を掴むための参考情報として使っていただければと思います。

4. 制御通信の仕様を見るときのポイント

既製ロボットを使う場合は、通信方式や制御周期があらかじめ決まっていることも多いです。一方で、ロボットを自作したり、モータ、センサ、I/O、周辺機器まで含めて設計したりする場合は、どの産業用ネットワークが要件に合うのかを判断する必要があります。

ここでは、規格を選ぶための詳細比較ではなく、モータ制御やロボット実装で通信仕様を見るときの確認観点を整理します。

4.1 制御周期

まず確認するのは、閉ループ制御を何Hzで回したいかです。

たとえば、1 kHz で回したいのか、500 Hz で十分なのか、2 kHz 以上が必要なのかで、必要な通信性能は大きく変わります。ここが曖昧なままだと、通信規格、軸数、送受信データ量、コントローラ構成の比較がしにくくなります。

4.2 最悪遅延とジッタ

次に見るのは、平均レイテンシだけではなく、最悪遅延とジッタです。

制御ループでは、平均的に速いことよりも、決められた周期の中で安定して通信できることが重要になります。たまに大きく遅れる通信が混ざると、追従性や安定性に影響します。

Web系通信では P95 / P99などのパーセンタイルでの遅延を見ることが多いですが、モータ制御では「周期内に毎回収まるか」「ジッタが許容範囲か」を見る必要があります。

4.3 同期精度

多軸ロボット、力制御、センサ融合を扱う場合は、複数の機器が同じ時間基準で動けるかも重要になります。

モータごとの指令や状態取得のタイミングがずれると、各軸が個別には正しく動いていても、ロボット全体としては期待した動きにならないことがあります。そのため、分散クロックや IEEE 1588 / PTP 系のような同期機構が、規格や製品の中でどのように扱われているかを確認します。

4.4 バス負荷とプロセスデータ設計

周期通信では、位置、速度、トルク、制御モード、ステータス、エラー情報などのデータを毎周期やり取りします。

そのため、最終的には「何byteのデータを、何軸に対して、何Hzで送受信するのか」という見積もりになります。ここを見ると、現在の軸数では問題なくても、将来軸数を増やしたときに通信が詰まるかどうかを早めに判断できます。

特に CAN 系では、CAN Classic なのか CAN FD なのかで、1フレームあたりのペイロードやデータフェーズの速度が変わります。OpenArm の例では、この観点がそのまま CAN FD を使う理由につながるため、次章で具体的に見ていきます。

4.5 安全・診断・保守性

最後に、通信異常時の扱いを確認します。

通信断や周期遅れが起きたときに、モータを脱力するのか、位置を保持するのか、ブレーキをかけるのか、Safe Torque Off に落とすのか。PoCでは後回しにされがちですが、実機を安全に動かすうえでは重要な設計項目です。

また、現場で原因を追えるように、エラー状態、通信状態、遅延、再接続、ログ、復旧手順を確認できることも重要です。制御通信は、速く動かすためだけのものではなく、安全に止めて、原因を追い、再開できるようにするための基盤でもあります。

この章で挙げた観点は、特定の規格に閉じたものではありません。EtherCAT、PROFINET、EtherNet/IP、CAN/CANopen、Modbus など、どの規格を見る場合でも、制御周期、遅延・ジッタ、同期、バス負荷、安全・診断の観点で見ると、仕様の読み方がかなり整理しやすくなります。

次章では、OpenArm の CAN FD 通信を題材に、これらの観点が実際のロボット構成でどう現れるかを見ていきます。

5. 実際のフィールドバス使用例：OpenArmのCAN FD通信

ここまで、フィールドバスを含む産業用ネットワークの考え方、代表的な規格、制御通信の仕様を見るときの観点を整理してきました。この章では、実際に OpenArm を触ったときに見えた CAN FD 通信のポイントを紹介します。

ABEJA では、SO-ARM を用いた基礎実験やシミュレーションベースの Physical AI 検証に加えて、OpenArm 1.0 を使った実機検証も進めています。OpenArm の全体構成やエコシステムについては、公式ドキュメントや LeRobot の資料に詳しくまとまっているため、ここでは詳説しません。

なお、OpenArm 公式ドキュメント上では、現在 OpenArm 2.0 が最新版として公開されています。また、OpenArm 1.0 のドキュメントは active maintenance 対象外とされています。そのため、本記事の OpenArm 実例は ABEJA で検証している OpenArm 1.0 を前提にしつつ、コマンドや構成は利用する OpenArm のバージョンに応じて公式ドキュメントを確認してください。

また、本記事では説明を簡潔にするために、OpenArm で使われるモータを基本的に Damiao モータと表記します。OpenArm 1.0 では DAMIAO 43 series や DAMIAO 8009P などのモータが使われていますが、公式ドキュメントでは DAMIAO 4340 series は QDD motor ではないと説明されています。そのため、すべてのモータを一律に QDD モータとは呼ばないようにします。

5.1 OpenArmではCAN FDでモータとサイクリック通信する

OpenArm では、Damiao 製のモータが使われており、モータとの通信には CAN bus が使われます。LeRobot の Damiao Motors and CAN Bus のドキュメントでも、Damiao モータを LeRobot から CAN bus 経由で扱う手順が整理されています。

OpenArm 全体のソフトウェア構成を細かく説明し始めると長くなるので、ここでは次のように分けて見ます。

LeRobot / ROS 2 / テレオペレーション / データ収集 / 推論 / 可視化
        |
        | joint command / state abstraction
        v
openarm_can / LeRobot の Damiao Motors 実装
        |
        | SocketCAN
        v
CAN FD インターフェース
        |
        | CAN ID / Damiao motor protocol
        v
Damiao モータ

ここで重要なのは、ホスト側のソフトウェアタイマー（タスク制御）が主導して、CAN FD 上でサイクリック通信を成立させている点です。つまり、モータに対して指令値を送り、モータから位置・速度・トルク・温度・状態コードなどのフィードバックを受け取る通信が、一定周期で流れます。

5.2 プロトコルの位置づけ：CANopen規格との違い

OpenArm の CAN 通信で最初に整理しておきたいのは、OpenArm が CANopen ネットワークとして動いているわけではない という点です。

CAN、CAN FD、CANopen、Damiao モータプロトコルは、次のように分けて考えると分かりやすいです。

名前	見方
CAN	CAN ID による仲裁と短いフレームを基本にした通信方式。下位層寄りの技術。
CAN FD	CAN を拡張し、データフェーズの高速化や大きなペイロードを扱えるようにした方式。
CANopen	CAN 上に載る上位プロトコル。PDO、SDO、NMT、デバイスプロファイルなどを定義する。
Damiao モータプロトコル	Damiao モータを制御するための独自プロトコル。OpenArm ではこれを CAN / CAN FD 上で扱う。

Damiao の通信プロトコル資料では、CAN bus 上で制御コマンド、フィードバック、レジスタ操作を扱う独自プロトコルが説明されています。たとえば MIT mode のコマンドでは、位置、速度、kp、kd、トルク相当の値を送ります。フィードバックでは、モータ状態、位置、速度、トルク、温度などが返ります。

つまり、OpenArm の通信は次のように見るのがよいです。

レイヤ	見ること
CAN FD / SocketCAN	Linux 上の CAN インターフェースと通信路
Damiao モータプロトコル	モータに送る指令値、状態フィードバック、レジスタ操作の意味
OpenArm / LeRobot / ROS 2	複数のモータをロボットアームとして扱う上位実装

この整理をしておくと、「CAN を使っている = CANopen で動いている」と誤解しにくくなります。OpenArm で見るべきなのは、CANopen の PDO / SDO ではなく、Damiao モータが定義している CAN ID、制御モード、フィードバック、レジスタです。

5.3 5つのパラメータで操るMIT mode：Damiaoモータの制御と状態フィードバック

Damiaoモータは、単に目標角度を送れば動くデバイスではありません。OpenArmで利用するMIT modeでは、位置、速度、位置ゲイン、速度ゲイン、フィードフォワードトルクという5つのパラメータを組み合わせてモータを制御します。

MIT modeで扱う主な指令値は次のとおりです。

値	意味
q	目標位置
dq	目標速度
kp	位置偏差に対するゲイン
kd	速度偏差に対するゲイン。ダンピングの調整にも使う
tau	フィードフォワードトルク

概念的には、モータへ与えるトルク指令は次のように表せます。

τ_cmd = kp × (q_des - q) + kd × (dq_des - dq) + tau

ここで、q_desとdq_desは目標位置と目標速度、qとdqはモータから取得した現在位置と現在速度です。位置偏差にkpを掛けた成分、速度偏差にkdを掛けた成分、そしてtauとして与えるフィードフォワード成分を組み合わせて、モータの出力を決めます。

たとえば、目標位置だけを指定し、dqとtauを0にすれば、位置制御に近い使い方ができます。ただし、同じ目標位置でも、kpを大きくすると位置偏差に対して強く応答し、kdを大きくすると動きに対する減衰が強くなります。ゲインが適切でなければ、振動、オーバーシュート、応答の鈍化、過大なトルクなどにつながる可能性があります。

一方、kpとkdを小さくし、tauを主体にすると、トルク制御に近い使い方もできます。このようにMIT modeでは、同じ通信形式を使いながら、位置制御、インピーダンス制御、トルク指令に近い制御を構成できます。

ただし、5つの値を送るだけでは閉ループ制御は成立しません。モータから返される状態フィードバックも、指令と同じように重要です。

OpenArm CAN Libraryのドキュメントでは、Damiao Motor protocolのMIT control modeとして{kp, kd, q, dq, tau}を扱い、モータから位置、速度、トルク、温度などの状態を取得する構成が説明されています。

代表的な状態フィードバックは次のとおりです。

状態	確認する目的
現在位置	目標位置に追従しているかを確認する
現在速度	動作速度や振動、急激な変化を確認する
推定トルク	負荷や接触状態、過大な出力を確認する
モータ温度	過負荷や連続運転による発熱を監視する
状態コード	過電流、過熱、通信ロストなどの異常を検出する

上位の制御ソフトウェアは、これらの状態を周期的に受信し、次の指令値を計算します。OpenArmでは、この指令と状態の交換がCAN FD上でサイクリックに行われます。

上位コントローラ
    |
    | q, dq, kp, kd, tau
    v
Damiaoモータ
    |
    | position, velocity, torque, temperature, status
    v
上位コントローラ

ここで重要になるのが、ポリシーの出力をどの制御レイヤに接続するかです。

ポリシーが目標関節角qを出力し、kpやkdの設定を下位制御に任せる構成であれば、AI側とモータ制御側の責務を比較的分離しやすくなります。一方、ポリシーがtauやゲインまで直接出力する構成では、より柔軟な動作を実現できる可能性がある反面、出力制限、異常検出、安定性、接触時の挙動を含めた安全設計が重要になります。

したがって、DamiaoモータのCAN通信を見るときは、フレーム形式だけでなく、次の点まで確認する必要があります。

どの制御モードを使うか
5つの指令値をどのレイヤが決定するか
指令値とゲインの上限をどこで制限するか
状態フィードバックをどの周期で取得するか
通信断や異常状態を検出したときに、どのように停止するか

MIT modeは、5つのパラメータによってモータの振る舞いを柔軟に調整できる制御方式です。一方で、その自由度が高い分、ゲイン設定、状態監視、指令値制限、安全停止まで含めて設計する必要があります。AIやROS 2から見た関節指令が、最終的にどのような制御量としてモータへ渡されているかを理解することが、実機制御を安定させる第一歩になります。

5.4 CAN FDが必要になる理由を通信量から見る

OpenArm で CAN FD を使う理由は、設定上そうなっているから、というだけではありません。多軸ロボットでサイクリック通信を回すと、Classic CAN では通信量が厳しくなりやすいからです。

CAN FD は Classic CAN の制約を緩和するための方式です。CiA の説明では、CAN FD は arbitration phase と data phase で異なるビットレートを使え、Classic CAN の「最大 1 Mbit/s 程度」「最大 8 byte ペイロード」という制約に対して、より高速なデータ送信と最大 64 byte のデータフィールドを扱えると説明されています。

ここでは細かいフレーム構造までは追わず、オーダ感だけを見ます。前提として、11-bit ID の標準データフレーム、8 byte payload、ビットスタッフィングやエラーフレームを除いた概算として考えます。拡張 ID、ビットスタッフィング、USB-CAN アダプタ、OS スケジューリング、ライブラリ側の待ち時間を含めると、実効的な余裕はさらに変わります。

たとえば、1 本の CAN bus 上に 8 個のモータがあり、「各モータに指令 1 フレーム、各モータから状態 1 フレーム」を毎周期やり取りするとします。ここでの「8 個」は、関節モータに加えてエンドエフェクタ側のモータを含む、または 1 本の CAN bus 上に 8 個のモータが載る構成を想定した概算です。

8モータ × 2フレーム = 16フレーム / 周期

Classic CAN の 1 Mbps で 8 byte データフレームを扱う場合、データ本体以外にも ID、制御フィールド、CRC、ACK、EOF、インターフレームスペースなどのオーバーヘッドが乗ります。8 byte の標準データフレームは、ビットスタッフィングを除いても約 111 bit になります。

16フレーム × 約111 bit = 約1776 bit / 周期

1 Mbps では、約 1776 bit を送るだけで約 1.8 ms かかります。ビットスタッフィングや実装上の余裕まで見ると、もう少し重くなります。

つまり、1 kHz、すなわち 1 ms 周期で 8 モータ分の指令と状態を安定して回したい場合、Classic CAN 1 Mbps ではオーダーとしてすでに厳しいことが分かります。もちろん、実際の負荷はフレーム数、データ長、ビットスタッフィング、送受信タイミング、USB-CAN アダプタ、OS スケジューリング、ライブラリ側の待ち時間によって変わります。それでも、「1 kHz で多軸を回すなら、Classic CAN では余裕が小さい」という判断は、この時点でできます。

CAN FD を使うと、arbitration phase は nominal bitrate で行いつつ、data phase をより高い bitrate で送れるため、データ部分の送信時間を短くできます。また、最大 64 byte の payload を扱えるため、プロトコル設計によっては複数の値をより効率よく載せられます。

LeRobot の Damiao Motors and CAN Bus のドキュメントでも、OpenArm 系の構成では CAN FD が推奨され、次のように bitrate 1000000、dbitrate 5000000、fd on の設定例が示されています。

sudo ip link set can0 down
sudo ip link set can0 type can bitrate 1000000 dbitrate 5000000 fd on
sudo ip link set can0 up

ABEJA で検証していたときも、CAN インターフェースの初期化で fd on を付け忘れて通信がうまくいかないことがありました。can0 が UP になっていることと、OpenArm / Damiao モータが期待する CAN FD 設定で通信できることは別です。

確認するときは、次のように ip コマンドでインターフェースの詳細を見ます。

ip -d link show can0

UP しているかだけでなく、CAN FD が有効になっているか、nominal bitrate と data bitrate が期待どおりかを見ることが重要です。

5.5 openarm_canとcan-utilsを併用する

OpenArm の CAN 通信を扱うときは、openarm_can だけを見ればよいわけではありません。実機トラブルを切り分けるには、Linux の SocketCAN と can-utils も合わせて見る必要があります。

OpenArm CAN Library は、高レベルの OpenArm 制御アプリケーションと低レベルのモータプロトコルをつなぐブリッジとして実装されています。OpenArm CAN Library のドキュメントでは、Linux の SocketCAN を使って CAN bus 通信を抽象化し、モータ制御と状態監視の API を提供すると説明されています。

一方で、低レイヤの確認には can-utils が便利です。can-utils には、CAN フレームを表示・記録する candump、単一フレームを送る cansend、CAN traffic を生成する cangen、バス負荷を見る canbusload などのツールがあります。

実機でよく使う確認は、たとえば次のようなものです。

# CANインターフェースの状態確認
ip -d link show can0

# CANフレームが流れているか確認
candump can0

# LeRobot側の診断
lerobot-setup-can --mode=test --interfaces=can0,can1

OpenArm / LeRobot の上位ツールで動かない場合でも、candump でフレームが見えるか、ip -d link で CAN FD 設定が入っているかを確認すると、問題が上位実装にあるのか、CAN インターフェースにあるのか、物理層にあるのかを切り分けやすくなります。

OpenArm CAN Library 側にも、CAN インターフェース設定やモータ検出の CLI があります。

# CAN FD with 5 Mbps data rate
openarm-can-configure-socketcan can0 -fd

# Discover motors on the bus
openarm-can-cli -i can0 discover

# Monitor motor status
openarm-can-cli -i can0 monitor

このように、OpenArm 向けのツールと Linux 標準寄りの CAN ツールを併用すると、トラブル時の見通しがかなり良くなります。

5.6 CAN IDとレジスタ設定で詰まる

OpenArm を OEM で購入した場合、通常は CAN ID があらかじめ割り振られています。そのため、最初はあまり意識しなくても動くことがあります。

ただし、モータ交換や修理をすると話が変わります。交換したモータに正しい ID が設定されていなければ、コード側の設定が正しくても通信できません。つまり、CAN ID はソフトウェアの設定ファイルだけでなく、モータ内部のレジスタ設定とも対応しています。

Damiao の通信プロトコル資料では、複数モータが同じ CAN bus を共有でき、各モータに motor_id と feedback_id があることが説明されています。コマンドは motor_id 宛に送られ、フィードバックは feedback_id で返ってきます。

LeRobot の Damiao Motors and CAN Bus のドキュメントでも、各モータには送信用の id と受信用の recv_id が必要で、OpenArm 系のデフォルト ID は送信 ID 0x0N、受信 ID 0x1N のパターンに従うと説明されています。

実機では、次の 3 つを揃える必要があります。

確認対象	見ること
コード側の設定	関節名、モータタイプ、送信 ID、受信 ID が正しいか
モータ内部の設定	`ESC_ID`、`MST_ID` などが期待値になっているか
物理接続	対象モータが正しい CAN bus に接続されているか

このあたりで困ったのが、Damiao のレジスタ情報です。最初は、どの値がどのレジスタに対応し、どれを書き換えると永続化されるのかを把握するのに少し時間がかかりました。Damiao の資料では、レジスタ操作として read / write / store が定義されており、runtime RAM への書き込みと flash への保存が分かれています。

コード上の ID を直しても、モータ側の ID が違っていれば応答は返ってきません。逆に、モータ内部の ID を書き換えたあと、store していなければ再起動後に戻る可能性があります。このあたりは、実機を触らないと見えにくいポイントでした。

5.7 動かないときはネットワークから順に見る

OpenArm を触っていてロボットが動かないとき、最初は原因がすぐに分からないことがあります。上位の LeRobot や ROS 2、openarm_can、CAN FD 設定、USB-CAN アダプタ、配線、コネクタ、モータ ID、モータ状態のどこでも止まり得るためです。

このときは、いきなり上位アプリケーションを見るより、下から順に見る方が早いです。

電源
配線、コネクタ、終端、GND
CAN インターフェースの状態
CAN FD 設定
candump でフレームが見えるか
モータ ID / feedback ID
openarm_can / LeRobot の診断
ROS 2 / 上位アプリケーション

社内で OpenArm を使った実験でも、通信周りでいくつか躓きました。代表的なものを整理すると、次のようになります。

事象	見るポイント	対応・学び
`can0` が UP しているのに通信できない	CAN FD 設定、bitrate、dbitrate、`fd on`、USB-CAN アダプタの CAN FD 対応	UP しているだけでは不十分です。`ip -d link show can0` で CAN FD 設定まで確認します。
初期化時にうまく動かない	`fd on` を付け忘れていないか	OpenArm / Damiao 側が期待する設定と、Linux 側の SocketCAN 設定がずれていると通信できません。
Link Down / BUS-OFF になる	ケーブル、CAN-H / CAN-L / GND、コネクタ、終端、電源	断線や接触不良でエラーが溜まり、インターフェースが落ちることがあります。まず物理層を確認します。
Leader / Follower や左右の CAN デバイスが入れ替わる	USB-CAN アダプタの列挙順、`can0` / `can1` の対応	UDEV ルールで固定し、物理ラベルも貼ると運用しやすくなります。
一部のモータだけ通信できない	対象モータの送信 ID / 受信 ID、コネクタ、電源、モータ内部の ID	コネクタが一見刺さっていても接触が甘いことがあります。ID 設定と物理接続を両方見ます。
モータ交換後に応答しない	`ESC_ID`、`MST_ID`、レジスタの永続化	OEM 購入時は ID 設定済みでも、交換モータでは自分で ID を振る必要があります。
姿勢によって過補償気味になる	ゼロ点、キャリブレーション姿勢、重力補償パラメータ	どの姿勢をゼロとするかを揃えないと、後段の補償がずれます。
エラーの原因が追えない	フィードバックの状態コード、温度、電圧、過電流、通信タイムアウト	「動かない」だけでなく、「なぜ止まったか」を追えるログを早めに入れるべきです。

Linux の SocketCAN では、次のように ip コマンドで bus errors、error-warning、error-passive、bus-off などの状態を確認できます。

ip -details -statistics link show can0

エラーが多すぎると CAN デバイスが BUS-OFF 状態になり、送受信できなくなることがあります。

Damiao のプロトコル資料では、フィードバックの状態コードとして、過電圧、低電圧、過電流、MOS 過温、ロータ過温、通信ロスト、過負荷などが定義されています。つまり、単に「動かない」と見るのではなく、CAN インターフェースの状態と、モータ側の状態コードの両方を見る必要があります。

このような情報は、モデルやデータセットの設計だけを見ていると見落としがちです。実機を触ると、ソフトウェア、通信設定、物理配線、モータ内部状態の境界に問題が出ます。

5.8 この例から分かること

OpenArm の CAN FD 通信を見ると、フィールドバスは単なる「低レイヤの通信方式」ではないことが分かります。

OpenArm では、AI / ROS 2 / LeRobot の上位処理と、Damiao モータとのサイクリック通信が分かれています。そして、その境界には、CAN FD 設定、CAN ID、モータプロトコル、制御周期、バス負荷、レジスタ、ゼロ点、エラー状態、診断ログといった設計項目があります。

実機制御では、「CAN FD で通信できた」だけでは十分ではありません。モータが期待するプロトコルで、期待する周期で、期待する ID に対して指令を送り、状態を受け取り、異常時に止められるところまで含めて、制御通信の設計になります。

Physical AI の実機開発では、モデルやデータセットだけでなく、モータ、通信、配線、診断、復旧手順を安定させる必要があります。OpenArm のようなオープンなロボットを触る価値は、まさにこの境界を自分たちで見られることにあると感じています。

5.9 参考資料

OpenArm や Damiao モータを触る場合は、まず以下を見るのが良いと思います。

資料	使いどころ
OpenArm 公式ドキュメント	OpenArm 全体のコンセプト、OpenArm 2.0、ハードウェア・ソフトウェア・エコシステムの概要を確認する入口。
OpenArm 1.0 ドキュメント	本記事で扱っている OpenArm 1.0 の構成や前提を確認する入口。
OpenArm Motor Specifications	OpenArm 1.0 で使われている Damiao モータの種類、減速比、QDD かどうかの位置づけを確認する入口。
OpenArm CAN Library ドキュメント	`openarm_can` の構成、SocketCAN、Damiao Motor protocol、MIT control mode、CLI を確認する入口。
openarm_can GitHub	実装、インストール、CAN FD 設定、CLI、C++ / Python 利用例を確認する入口。
LeRobot: Damiao Motors and CAN Bus	LeRobot 側から Damiao モータを使うときの CAN FD 設定、can-utils、診断コマンド、ID 設定の確認に使えます。
Damiao Communication Protocol	Damiao 独自プロトコル、MIT mode、フィードバック、レジスタ操作、状態コードを確認する入口。
linux-can/can-utils	`candump`、`cansend`、`canbusload` など、SocketCAN 上でのデバッグに使うツール群。
Linux Kernel SocketCAN documentation	SocketCAN、CAN network device、bit timing、BUS-OFF、統計情報などを低レイヤから確認したいときに使えます。

CAN / CAN FD 自体の仕組みをもう少し詳しく知りたい場合は、以下の動画も参考になります。通信パケットのパーサや処理回路を作るわけでなければ本文の理解には必須ではありませんが、フレーム構造や CAN FD の考え方を直感的に掴むには非常に分かりやすいコンテンツです。

CSS Electronics: CAN FD Explained - A Simple Intro
- CSS Electronicsの解説記事の公式動画版です。アニメーションを交えて、CAN FDのフレーム構造や効率向上の仕組みが約13分で分かりやすくまとまっています。
Kvaser: CAN (Controller Area Network) Protocol Tutorial
- CANインターフェースの老舗Kvaser社による、CAN/CAN FDプロトコルの基礎チュートリアル動画です。物理層の電気信号の仕組みからデータリンク層の挙動までをステップバイステップで視覚的に理解できます。

6. まとめ

Physical AIが社会実装へ進むにつれて、AIモデルやデータセットだけでなく、それらを支える制御通信や実機システムの理解も、これまで以上に重要になっていくと考えられます。

本記事では、その入口として、フィールドバスを含む産業用ネットワークの基本的な考え方と、通信仕様を見る際の着眼点、そして OpenArm を例に実際の制御通信の構成を紹介しました。

AI/Web系のエンジニアにとって、フィールドバスや産業用ネットワークは最初は少し敷居が高く感じられるかもしれません。しかし、「どの周期で、どの通信路を通り、どのように実機を安全かつ安定して動かすのか」という視点を持つことで、実機システム全体の見え方は大きく変わってきます。

本記事が、Physical AIの実機開発に携わる方にとって、制御通信を理解する最初の一歩となれば幸いです。

We Are Hiring!

ABEJAは、テクノロジーの社会実装に取り組んでいます。技術はもちろん、技術をどのようにして社会やビジネスに組み込んでいくかを考えるのが好きな方は、下記採用ページからエントリーください！（新卒の方やインターンシップのエントリーもお待ちしております！）

careers.abejainc.com

ABEJA Tech Blog

中の人の興味のある情報を発信していきます

Physical AI実装で効く制御通信の考え方：OpenArmのCAN FD実例から学ぶフィールドバス