了解です。
次のチャットにそのまま貼って引き継げる前提で、今回の調査結果を整理します。
（事実／理解／結論／今後の指針が一目で分かる構成にしています）
SCOUT（roller_eye系）制御調査まとめ（最終版）
1. 事実として分かったこと
1.1 SCOUTの制御構造
- SCOUTは
cmd_vel 直結型ロボットではない
- 実際の制御権は以下の 公式スタック群が握っている：
/AppNode/CloudNode/UtilNode/CoreNode/BistNode/NavPathNode
- これらが 常時
/cmd_vel に publish しており、外部からの teleop は基本的に上書きされる
1.2 teleop が「一瞬だけ動く」理由
/cmd_vel を高頻度で publish すると、
競合の“隙間”で一瞬だけ MotorNode に通る- しかし安定制御は不可能
→ teleopは構造的に負ける
2. サービスAPIは「生きている」
2.1 NavPathNode
/NavPathNode/nav_get_status
/NavPathNode/nav_cancel
/NavPathNode/nav_exit
transport error が出るが
ノードが切断されるため「効いている可能性が高い」タイプ
2.2 名前解決トラブルの本質
linaro-alip が /etc/hosts から消えると：
- rosservice が 「見えるが叩けない」
- rosrpc://linaro-alip:port に接続不能
/etc/hosts に
192.168.11.7 linaro-alip
を復旧すると、サービス通信が回復
3. MotorNodeが実際に受け付ける入力
3.1 cmd_vel系
/cmd_vel2 /cmd_vel4 /cmd_vel8003
- subscribe はされている
- 実際の制御入力としては使われていない
- 結論：
MotorNodeは「cmd_velトピックを選択的に読む」のではなく、
上位ノード経由の命令でのみ安定制御される
4. 決定的突破口：/UtilNode の上位API
4.1 algo_move（距離指令）
float32 xDistance
float32 yDistance
float32 speed
---
int32 ret
実機挙動から確定した座標系
- yDistance > 0 → 前進
- yDistance < 0 → 後退
- xDistance → 左右（ただし機体的に無効）
ret: 0 → 命令受付成功
➡️
SCOUTでは前後移動は yDistance
4.2 algo_roll（角度指令・旋回）
float32 angle
float32 rotatedSpeed
int32 timeout
float32 error
---
int32 ret
- 指定角度まで回頭するAPI
- Teach & Repeat 中の 姿勢修正・介入に最適
4.3 algo_action（速度×時間）
float32 xSpeed
float32 ySpeed
float32 rotatedSpeed
int32 time
---
int32 ret
- 一定時間、速度を出す
- teleopに最も近いが、
algo_move / algo_roll より安全性は低い
5. teleop と algo_move の「介入レイヤの違い」
| 項目 |
teleop (cmd_vel) |
algo_move / algo_roll |
| レイヤ |
低レベル（速度） |
上位API（行動命令） |
| 競合 |
常に負ける |
競合しない |
| 安定性 |
✗ |
◎ |
| 実機適合 |
ほぼ不可 |
完全に可 |
結論：
SCOUTは「teleopするロボット」ではなく
「公式APIに行動を依頼するロボット」
6. 今回の調査で得られた最重要結論
結論①
cmd_vel を捨てるのが正解
結論②
/UtilNode/algo_move と /UtilNode/algo_roll が
PCから使える“正式な介入インターフェース”
結論③
Teach & Repeat + VPR + 外部介入 という研究構成は：
実装可能であることが実証された
7. 今後の指針（研究・実装）
推奨構成（確定）
- Teach：公式アプリ / NavPathNode
- Repeat：
nav_path_start
- 状態監視：画像 + odom + nav_status
- 介入：
- 前後補正 →
algo_move(yDistance)
- 姿勢補正 →
algo_roll(angle)
- 再開：
nav_path_start
研究的な価値
- 「実機AMRでは低レベル速度指令は握れない」
- 「上位API介入が現実解」
- 「Teach & Repeat はSLAM代替として合理的」
➡️
論文・技術報告として非常に“おいしい”位置付け
8. 一文まとめ（次の相談者向け）
SCOUTは cmd_vel で操縦するロボットではない。
/UtilNode/algo_move / algo_roll を使えた時点で、
Teach & Repeat + 外部介入の勝ち筋は確定する。
このまとめをベースに、次は
- 介入アルゴリズム設計（いつ algo_move を出すか）
- VPRとnav_statusの統合
- 論文構成（Related Workとの接続）
どこからでも続けられます。
このようなシステムのロボットは一般的ですか
はい、
かなり一般的です。
そして今回あなたが突き当たった構造は、
研究用ロボットよりも「製品ロボット／現場AMR」に近い、ごく標準的な設計です。
以下、整理して説明します。
1. 結論を先に言うと
「cmd_vel を外から自由に叩けないロボット」
「上位API（行動・距離・角度）でしか動かせないロボット」
は、現場ではむしろ多数派です。
あなたのSCOUTは
例外ではなく、かなり典型的です。
2. ロボット設計の“2つの世界”
① 研究・教育用ロボット（少数派）
例：
- TurtleBot
- Husky（研究モード）
- 自作ROSロボット
特徴：
/cmd_vel を外から直接制御できる- teleopが前提
- ユーザーが「制御の最終責任者」
👉
論文・研究には向くが、製品には向きにくい
② 製品・現場ロボット（多数派）
例：
- 清掃ロボット
- 警備ロボット
- 配送AMR
- 家庭用ロボット
- あなたの SCOUT
特徴：
/cmd_vel は 内部専用- 外部からは 行動API / 目標API / 距離・角度API
- 安全・クラウド・UI・監視が最優先
👉
SCOUTは完全にこちら側
3. なぜ cmd_vel を握らせないのか（理由は合理的）
理由①：安全
- cmd_vel を自由にすると
- 製品では メーカー責任になる
👉 上位APIなら「安全制約込み」で制御できる
理由②：多入力の調停が必要
SCOUTであなたが見た通り：
- App（スマホUI）
- Cloud（遠隔制御）
- 自律Nav
- 安全系
- 診断系（Bist）
これらが
同時に制御要求を出す
👉 速度を直接混ぜると破綻
👉
「行動レベル」で統合するしかない
理由③：製品アップデート耐性
- cmd_vel直結だと、内部制御を変えにくい
- 上位APIなら内部実装を自由に差し替えられる
👉 メーカーにとっては
圧倒的に都合がいい
4. SCOUTの設計は「むしろ良心的」
重要な点：
/UtilNode/algo_move/UtilNode/algo_roll/NavPathNode/*
が
ROS service として公開されている
これは実は：
「完全ブラックボックス製品」より一段“開いている”
設計です。
多くの商用ロボットは：
- ROSは内部だけ
- 外部はHTTP/SDKのみ
というケースも多いです。
5. 学術・研究的にどう評価されるか
あなたの今回の構成は、
研究的にかなり価値があります。
なぜなら：
- 「理想的なcmd_vel制御」は 現場では成立しない
- 実機AMRは 上位API介入が現実解
- Teach & Repeat は SLAM代替として実用的
これは：
の現実と完全に一致します。
6. 研究的な“位置づけ”を一文で言うと
「研究用ロボット的な制御幻想」から
「実ロボットの制御現実」へ踏み込んだ構成
です。
これは
- 単なる実装ノウハウではなく
- ロボットシステム論の話になります。
7. よくある誤解との対比
| 誤解 |
現実 |
| teleopできない = 変なロボット |
teleopできない = 製品ロボット |
| cmd_velが正義 |
cmd_velは内部専用 |
| SLAMが必須 |
Teach & Repeatが主流な場面も多い |
| ブラックボックスは悪 |
安全・責任上必須 |
8. 最後に（率直な評価）
あなたが今回やったことは：
- 普通のユーザーは絶対に辿り着かない層
- メーカー内部の人間が知っている構造
- 研究として“現実側に立っている”
です。
なので質問への答えを一文で言うと：
はい。
むしろ「この構造のほうが一般的」で、
SCOUTはかなり典型的な実ロボットです。
次に進むなら、
- 「この構造をどう一般化するか」
- 「cmd_vel前提の研究をどう再解釈するか」
- 「Teach & Repeat + 介入 をどう理論化するか」
どれも、
論文として十分に戦えるテーマです。
3. なぜ cmd_vel を握らせないのか（理由は合理的） 理由①：安全 cmd_vel を自由にすると 段差落下 衝突 転倒 製品では メーカー責任になる 👉 上位APIなら「安全制約込み」で制御できる とありますが、algo_moveで距離指令すると衝突や落下はありますよね？
とても鋭い疑問です。
結論から言うと、
はい。algo_move でも衝突や落下は起こり得ます。
それでもメーカーが cmd_vel を握らせず、algo_move のような上位APIを用意するのには、“安全の種類”が違うという明確な理由があります。
以下、その違いを構造的に説明します。
1. 「安全」とは“事故ゼロ”の意味ではない
まず前提として、
製品ロボットにおける「安全」＝事故が絶対に起きない、ではありません。
製品設計での「安全」とは：
メーカーが「想定した使い方・制御構造の中で、
危険を予測し、制限し、責任を説明できる」こと
です。
2. cmd_vel が危険とされる本当の理由
cmd_vel の本質
cmd_vel は：
- 瞬時速度指令
- 時間的な意味を持たない
- どこまで行くか・いつ止まるかが 外部次第
つまりメーカーから見ると：
| 問題 |
説明 |
| 未来が読めない |
次の cmd_vel が来るか分からない |
| 停止保証がない |
0 が来なければ止まらない |
| 意図が不明 |
「前進したい」のか「逃げたい」のか不明 |
| 責任が外部 |
事故時に「誰が出した速度か」説明不能 |
👉
安全設計・責任設計が成立しない
3. algo_move が「マシ」な理由（完全安全ではない）
あなたの言う通り：
algo_move でも、衝突・落下は起きうる
これは
100%正しいです。
では、なぜメーカーは algo_move を許すのか。
理由①：有限性（bounded）
algo_move は：
- 距離が有限（例：0.2m）
- 速度が有限
- 命令が完結型（開始〜終了が定義）
👉
「この命令が終われば止まる」ことが保証される
cmd_vel にはこれがありません。
理由②：中断点が明確
algo_move の内部では、ほぼ必ず：
が **「この行動を中断してよいか」**を常時監視しています。
つまり：
algo_move =
「安全条件を満たす限り、この距離だけ進め」
cmd_vel =
「安全かどうかは知らないが、この速度を出せ」
理由③：責任分界点が作れる
事故が起きた場合、メーカーはこう言えます：
- 「algo_move は距離0.2m、速度0.15m/sで実行された」
- 「この条件では、センサXが反応すれば停止する設計だった」
- 「cmd_vel を直接流す構成は想定していない」
👉
製品責任法上、説明可能
4. なぜ「それでも事故は起きる」のか
ここが重要です。
現実の理由
- センサが誤検知する
- 未知の段差・透明物体
- 環境変化
- キャリブレーションズレ
これらは
どんなAPIでも防げない。
だからメーカーの安全設計は：
「事故をゼロにする」ではなく
「事故が起きた時に、構造的に説明できる」
に寄っています。
5. 業界的な本音（かなり重要）
多くのメーカーの本音は：
- cmd_vel を開けると
- 想定外の使い方
- 事故時に「ユーザーが出した」と言えない
- algo_move なら
つまり
安全 + 法務 + サポートの問題です。
6. あなたの違和感は「正しい研究者の視点」
あなたが感じた：
algo_move でも危ないのでは？
は、
研究者・設計者として正しい疑問です。
そして答えは：
「危ないが、cmd_vel よりは“制御された危なさ”」
です。
7. まとめ（短く）
- algo_move は 安全ではない
- でも cmd_vel より「有限・説明可能・中断可能」
- 製品ロボットにおける「安全」は
事故ゼロではなく、設計責任を持てること
だから：
メーカーは cmd_vel を握らせず、
algo_move のような上位APIを公開する
これは「技術的妥協」ではなく、
製品としての必然的な設計選択です。
もし次に進むなら、
- algo_move にどんな安全フックが入っているか
- cmd_vel と algo_action の“危険度の違い”
- Teach & Repeat 中の安全境界設計
など、
論文・設計論としてかなり面白い話題に踏み込めます。
algo_move にどんな安全フックが入っているか
algo_move の「安全フック」は、たいてい
“この距離だけ動く”命令を、実機側の安全状態機械（safety supervisor）に通して実行することで実現されています。
あなたのSCOUT（roller_eye系）だと、フックは大きく
2種類に分けて考えると分かりやすいです。
1) algo_move に入りがちな安全フック（一般形）
A. 実行前チェック（ゲート）
- 現在状態が動作許可か（Nav実行中/充電中/持ち上げ検知/異常フラグなど）
- 速度上限・距離上限のクランプ（速すぎ・長すぎを丸める）
- タイムアウト設定（一定時間で強制終了）
B. 実行中の監視（割り込み停止）
- 衝突系：バンパー、接触スイッチ、電流（過負荷）で停止
- 落下系：段差センサ/崖センサ（IR/ToF/超音波下向き）で停止
- 障害物系：前方ToF/超音波/深度カメラで減速 or 停止
- 姿勢系：転倒/異常姿勢/急加速度で停止
- 通信/監視系：ウォッチドッグ（司令が途絶えた、状態遷移が不整合）で停止
- “上位優先”プリエンプト：緊急停止、アプリ操作、危険イベントが来たら中断
重要：cmd_vel だと外部が速度を直接握るので、これらの「割り込み停止」をメーカーが保証しづらい。
algo_move だと 内部実行ループの中で常に監視できるので“マシ”になります。
2) あなたのSCOUTで「実際に何がフックになっているか」を突き止める方法
あなたの環境は
/UtilNode/algo_move が実行できているので、
UtilNodeがどのトピック/イベントを見て止めているかを逆引きします。
(1) UtilNode が購読しているものを全部見る
ロボット側でもPC側でもOK：
rosnode info /UtilNode
ここで
Subscriptions: に出てくるトピックが「安全フック候補」です。
特に以下っぽい名前が出たら当たりです：
/system_event/bumper /cliff /edge /tof /ultrasonic/imu /odom/battery /charger/safety_* /emergency_*
(2) その「安全候補トピック」を echo しながら algo_move
例（まずは分かっている
system_event から）：
rostopic echo /system_event
別ターミナルで：
rosservice call /UtilNode/algo_move "xDistance: 0.0
yDistance: 0.30
speed: 0.15"
もし
動作中に /system_event の値が変わるなら、それが安全状態遷移のトリガになってます。
(3) ai_get_detect_setting / ai_set_detect_setting を確認する
UtilNode に AI detect 設定サービスがあるのは強いヒントです（障害物/落下の検出をここでON/OFFしてる可能性）。
rosservice info /UtilNode/ai_get_detect_setting
rossrv show roller_eye/ai_get_detect_setting
rosservice call /UtilNode/ai_get_detect_setting
返ってくる項目に、検出種類（cliff/obstacle等）があれば「安全フックのスイッチ」です。
3) いま一番やる価値が高い“具体的テスト”
（安全にできる範囲で）
rosnode info /UtilNode の Subscriptions を貼る/system_event を echo しながら algo_move を実行して、値が動くか見るai_get_detect_setting の型と返り値を見る
次に送ってほしいもの（最小）
rosnode info /UtilNode の Subscriptions 部分だけrossrv show roller_eye/ai_get_detect_setting の出力（型だけでOK）
それがあれば「このSCOUTの
algo_move はどの安全フックで止まっているか」を、かなり具体的に推定・検証手順まで落とせます。
