> For the complete documentation index, see [llms.txt](https://taiphoon-com.gitbook.io/taiphoon.com-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://taiphoon-com.gitbook.io/taiphoon.com-docs/ja/support/knowledge-base/can-bus.md).
# CAN Bus
### CAN Bus とは
CAN（Controller Area Network）はノイズの多い環境向けに設計された有線通信バスで、当初は自動車の電子システムで使用されていましたが、現在ではフライトコントローラー、センサー、GPS、ESC、その他の周辺機器間の通信にも広く使用されています。
機体上では、モーター、ESC、電源モジュール、無線機器がいずれも顕著な電磁干渉を発生させる可能性があります。CAN がよく使用される最大の理由は、このような環境で通常のシングルエンドのシリアル通信よりも安定していることにあります。
### CAN の主な特性
CAN の最も重要な特性は、**差動信号**と**共有バス**のアーキテクチャを使用していることです。
これは、複数の機器が同じ CAN\_H と CAN\_L の線を共用でき、受信側は 2 本の線間の電位差を読み取るため、両方に同様に影響するノイズに対して強い耐性を持つことを意味します。
### 差動信号とは
CAN は **CAN\_H** と **CAN\_L** の 2 本のデータ線を使用します。伝送時、この 2 本の線上の信号は逆方向に変化し、受信側は片方の線の絶対電圧だけを見るのではなく、両者の差分を見ます。
この方式の利点は、外部ノイズが 2 本の線に同時に結合した場合、2 本の線の同相ノイズはほぼ同じになるため、受信側が差分を計算する際にこのような干渉を大幅に打ち消せることです。そのため CAN は、モーター、ESC、大電流システムの近くでも良好な信頼性を維持できます。
### CAN と UART / I2C の違い
CAN、UART、I2C はいずれもフライトコントローラーの周辺機器の接続に使用できますが、用途と設計思想が異なります。
| インターフェース | 典型的な構造 | 利点 | 一般的な用途 |
| -------- | ------------- | -------------------------------- | ---------------------------------- |
| UART | ポイントツーポイント。 | シンプルで一般的、設定が容易。 | GPS、テレメトリー、受信機、デバッグコンソール。 |
| I2C | 複数機器で 2 線を共有。 | 短距離の基板内または近距離のセンサーに適している。 | コンパス、気圧計、シンプルなセンサー。 |
| CAN | 複数ノードでバスを共有。 | ノイズ耐性が高く、長距離や多数の周辺機器の統合により適している。 | CAN GPS、CAN ESC、CAN センサー、ノードモジュール。 |
### バストポロジー
CAN は真の**マルチドロップバス**です。すべてのノードが同じ幹線に接続され、どのノードもデータを送信でき、すべてのノードがバス上のフレームを受信できます。
フライトコントローラーの用途では、UART のように各機器ごとに独立した TX/RX を 1 組ずつ引くのではなく、フライトコントローラー、GPS、センサー、ESC、その他のノードを同じ CAN 幹線にデイジーチェーンで順に接続するのが一般的です。
### 調停の仕組み
複数のノードが同じバスを共用するため、CAN プロトコル自体にメッセージ調停の仕組みが組み込まれており、複数の機器が同時にデータを送信しようとした場合に、フレームの優先度によってどれが先に送信するかを決定します。
これも CAN がリアルタイム制御の場面に適している理由の一つです。単純な「早い者勝ち」の方式で運に任せるのではなく、プロトコル層がどのメッセージをバス上で優先的に保持すべきかを決定します。
### 終端抵抗
正常な CAN バスでは、**物理的な両端**にそれぞれ **120 Ω の終端抵抗**を 1 個ずつ配置する必要があります。
終端抵抗の役割は信号の反射を吸収することです。正しく終端されていないと、信号がケーブルの末端で反射して戻ってきて、データの歪み、ノードの出現と消失の繰り返し、通信の不安定の原因になることがあります。
### 終端が正しいかどうかの判断方法
バスの両端にそれぞれ 120 Ω の終端抵抗がある場合、システム全体の電源を切った状態で CAN\_H と CAN\_L の間の抵抗を測定すると、通常は **60 Ω** に近い値になります。2 個の 120 Ω 抵抗が並列になっているためです。
これは現場でのトラブルシューティングで非常に実用的な簡易チェック方法です。60 Ω から大きくずれている場合は、通常、終端の数が正しくない、配線に誤りがある、または一部のノードの内蔵終端設定が正しく構成されていないことを示しています。
### よくある終端の誤り
CAN で最もよくある問題は、終端抵抗の構成ミスです。
典型的なケースは次のとおりです。
* 終端がまったくなく、反射が深刻になる。
* すべてのノードで終端が有効になっており、合成インピーダンスが低すぎる。
* 終端が物理的な末端ではなく、途中のノードにある。
正しい原則はシンプルです。**終端が必要なのはバスの両端のみ**で、途中のノードには通常、終端を追加すべきではありません。
### ビットレート
一般的なフライトコントローラーのエコシステムでは、CAN の一般的なビットレートは通常 **1 Mbps** で、これは多くのフライトコントローラーファームウェアや DroneCAN 周辺機器の一般的なデフォルト値でもあります。
UART とは異なり、CAN のビットレートは通常、頻繁に変更する必要はありません。ただし、すべてのノードが同じビットレートを使用する必要があり、そうでないと、設定を誤った機器は通常バス上でまったく見えなくなります。
### コネクターとケーブル
多くのフライトコントローラーシステムでは、CAN に **4-pin JST-GH** コネクターがよく採用され、典型的なピン配置は 5V、CAN\_H、CAN\_L、GND です。
ただし、コネクター形式は一般的であっても、すべての機器が完全に同じである保証はありません。実際に配線する前に、その機器のピン定義、電源電圧、バス給電に対応しているかどうかを確認してください。
### 給電は自動的に成立するわけではない
CAN ケーブルには 5V と GND が同時に含まれていることが多く、低消費電力の周辺機器への給電に便利ですが、すべての機器がバスから直接電源を取るのに適しているわけではありません。
バス上のノード数が多い、線が長い、または一部の機器の消費電力が高い場合、電圧降下により周辺機器の起動が不安定になったり、再起動を繰り返したり、断続的にオフラインになったりすることがあります。そのため、実装時にはまず電流予算と線路損失の評価を行う必要があります。
### CAN がフライトコントローラーの周辺機器に適している理由
フライトコントローラーの周辺機器にとって、CAN の利点はノイズ耐性だけではありません。
一般的な利点は次のとおりです。
* 複数の機器が同じバスを共用するため、拡張が容易。
* 単方向のデータ入力だけでなく、機器の状態報告も提供できる。
* 比較的長い配線距離やノイズの多い環境に適している。
* バスを介してノード管理、パラメータ設定、一部のファームウェア更新を行える。
### DroneCAN とは
フライトコントローラーの用途において、CAN は下位の物理層とデータリンク層の通信方式にすぎません。「データの内容をどう表現するか、ノードをどう管理するか、パラメータをどう構成するか」を実際に定義するのは、通常 **DroneCAN** のような上位プロトコルです。
DroneCAN は CAN 上で動作するアプリケーション層プロトコルと考えることができます。標準化されたメッセージ形式、ノード管理方式、動的ノード番号割り当て、パラメータアクセス、機器のファームウェア更新手順を定義しており、異なるメーカーの互換機器が同じバス上で連携しやすくなります。
### Node ID
DroneCAN のアーキテクチャでは、各ノードに一意の **Node ID** が必要で、一般的な有効範囲は 1 から 127 です。
多くのフライトコントローラーファームウェアでは、ノード番号をシステムが自動的に割り当てることができます。これにより初回の統合の難易度を下げられますが、ユーザーが手動で番号を指定する場合は、異なる機器で Node ID が重複しないようにする必要があります。そうしないと、ノード同士が互いに干渉します。
### 動的ノード割り当て
動的ノード割り当ての利点は、新しい機器をバスに接続した後、必ずしも事前に番号を手動で固定しなくても、フライトコントローラーに認識され、システムに組み込まれることです。
これは実際の組み立て、特に複数のセンサーやモジュールを同時に統合する場合に役立ちます。ただし、システム構成が固定している場合は、動作が正常であることを確認した後に重要なノードの番号を固定し、後でネットワークを再構成する際の変動リスクを下げることが一般的に推奨されます。
### 冗長 CAN
一部のフライトコントローラーや周辺機器は 2 組目の CAN インターフェースに対応しており、冗長チャネルを構築して全体の接続信頼性を高めることができます。
これはすべてのシステムで必須の機能ではありませんが、大型の機体、重要ミッション用の機体、または配線が長いシステムでは、デュアル CAN 構成によりより高いフォールトトレランスを実現できます。
### よくある問題
CAN バスの典型的な問題は、通常次のような点に集中しています。
* **終端抵抗がない**：ノードが時々現れたり消えたりします。
* **終端が多すぎる**：インピーダンスが低すぎ、通信品質が低下します。
* **ビットレートの不一致**：一部のノードがまったく見えません。
* **Node ID の競合**：2 つのノードが同じ番号を使用すると互いに干渉します。
* **電源供給の不足**：機器が不安定になったり、再起動したり、ランダムにオフラインになったりすることがあります。
* **ケーブルが長すぎる、または配線が悪い**：CAN はノイズ耐性が比較的高いとはいえ、物理的な限界があります。
### 推奨される確認手順
CAN 機器が正常に動作しない場合は、次の順序で確認することをお勧めします。
1. CAN\_H、CAN\_L、5V、GND の配線方向が正しいことを確認します。
2. バスの両端にそれぞれ 120 Ω の終端抵抗が 1 個ずつあることを確認します。
3. システムの電源を切った状態で、CAN\_H と CAN\_L 間の抵抗値が約 60 Ω かどうかを測定します。
4. すべてのノードのビットレートが一致していることを確認します。
5. Node ID が重複していないことを確認します。
6. 特に多ノードシステムでは、バスの給電が十分であることを確認します。
7. 必要に応じて、CAN/DroneCAN 対応のモニターツールを使用して、ノードがオンラインになっているか、フレームトラフィックがあるかを確認します。
### 注意事項
**注意：** CAN の接続方式はバスであり、スター型配線ではありません。中心点から複数のノードを大きく分岐させると、バスの特性が損なわれやすく、反射のリスクが増大します。
**注意：** 終端抵抗は物理的な両端にのみ配置してください。すべての機器に終端が内蔵されているからといって、すべて有効にしないでください。
**注意：** CAN は UART よりノイズに強いですが、配線の影響をまったく受けないわけではありません。線の長さ、コネクターの品質、電源の品質、バストポロジーは、依然として信頼性に直接影響します。