#ros2

位置/速度 loop・FF・friction は FW、homing HSM・校正 orchestrator は Host。判断基準は「制御周期」「位相要求」「反復サイクル」の 3 点

監視は決定的コード (token ゼロ)、LLM エージェントはイベント駆動で起きる。人間が rosbag を渡してフィードバックする工程を消す構成と token 消費の抑え方

Gazebo (旧 Ignition) の構成・機能一覧と、実務でハマる問題点をまとめた一般知識ノート。

導入コストと学習コストで比較。制御・ROS ネイティブ機能重視なら Gazebo、レンダリング品質やアセット重視なら Unity。

640x480 の raw 画像 1 本が何 MB/s か、同一 PC 内 publish は何が重いか、foxglove/rosbridge 経由の閲覧と rosbag 記録がなぜ効くか、compressed を使う判断基準

仕様が固まっていないコードの watchdog は「正しさ」を検証できない。普遍的不変条件・宣言済み contract・sim 真値 diff・golden run 回帰の 4 層に分解する

ros2 run/launch の子は親の terminate で死なず残留・混信する。setsid+killpg の手書きは手続き依存で失敗する。systemd-run --user --scope + RuntimeMaxSec なら掃除を忘れても cgroup ごと必ず死ぬ

joint origin は機構の事実で TF/IK が読む。visual origin はメッシュの描画位置だけ

URDF の `<limit>` は定数のみで他関節の値に依存できない。mimic は固定線形結合まで。状態依存の可動域はコード側（IK / planner / controller）で埋める

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

yaml で param が他 param を参照する数式を書けるようにする実装 pattern。muParser の SetVarFactory + ClearVar + post_set_parameters_callback + pending snapshot の 4 点セット

git rev + dirty diff + param snapshot + ros env を録画時に自動で残す。sidecar dir か MCAP 内蔵。実装は rc26 流儀の XML 1 ファイル + shell script (Option B) を採用

URDF 情報を複数 node で共有する時の pattern。/robot_description を transient_local で subscribe して urdf::Model に parse、query API を提供する Buffer + Listener を作る

外部依存のソースを自リポに取り込むこと。build 再現性を上げるが drift と二重管理の対価がある

bringup は最上位 launch と URDF だけ。機能 launch・param は機能パッケージ側 (rc26 と同じ層分け)。2026-09-04 整理後の配置

config-driven の debug UI パターン。settings ページで widget と launch/topic/service を bind、debug ページで実行、Foxglove layout も動的生成

汎用 debug WebUI に追加すると効く機能を、安全・観測性・操作・記録・チーム・UX で分類。投資対効果と避けたいものも

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

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