#can

Controller Area Network の物理層・フレーム構造・アービトレーション・エラー処理の基本

CAN の bit rate とバス長のトレードオフの物理的理由、Bit Time セグメント構造

CAN FD の速度切替の仕組み、BRS ビット、Classical との差分

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

CAN バスタップ・UART タップ・リセット線制御を ESP32 に載せ、zenoh-pico で無線公開する。対象基板の FW を変更せずにバス健全性・hardfault ログ・遠隔再起動が手に入る

gs_usb 経由の CAN feedback は FW と host のクロックが同期しておらず、ROS msg の header.stamp は host 受信時刻を反映するため実測から 2-10 ms 遅れている

CAN バスの異常を PC 側から切り分ける手順。リンク統計のエラーカウンタ、candump のフィルタ・ログ、cansniffer、canplayer による再生

candump inter-arrival、round-trip probe、ROS jitter、正弦波位相遅れ、host loop dt の 5 段階で通信レイテンシの主因を切り分ける手順

スキーマ YAML から両側 (PC ROS 2 / MCU C99) の通信コードを機械的に得るフレームワーク。マスターはスキーマ依存のビルド成果物を持たず、スレーブから受け取った blob で ROS Topic/Service/Param を実行時構築する

uplink CAN 1 本と downlink CAN N 本を束ねる同梱ランタイム。bridge は単一バス前提のまま動く。std_id → busmask で分配、node → bus で単一バス転送

スキーマ YAML の最小構造、vcan でサンプルを動かす手順、bridge の主な ROS API と再プロビジョン方法

Standard ID = Topic (動的割当)、Extended ID = 設定 + Service。boot_id で再起動検知、HEARTBEAT 受信で ID 衝突検出