了解しました。 先ほどの SCOUT Model E（Moorebot Scout E） の調査内容を、日本語で整理してまとめ直します。 研究・ROS利用の視点も意識して書いています。

SCOUT Model E（Moorebot Scout E）

ハードウェア・センサー・ソフトウェア仕様まとめ（日本語）

1. 概要

SCOUT Model E（Scout E） は、Moorebot（Pilot Laboratories）が開発した 小型・屋外対応の自律移動ロボットです。
  • 室内／屋外の監視・点検用途
  • 教育・研究用途（Linux + ROS搭載）
  • オリジナルScoutの クローラ（履帯）版
という位置づけで、 **「安価・小型・ROSが動く実機」**として非常に貴重な存在です。

2. ハードウェア構成

2.1 CPU・メモリ・ストレージ

項目 内容
SoC ARM Cortex-A7 クアッドコア（約1.2GHz）
RAM 512MB LPDDR3
ストレージ 16GB eMMC
アーキテクチャ ARM64（aarch64）
※ 一部の解析記事では Rockchip系SoC が使われていることが確認されています。

2.2 カメラ・音声

項目 内容
カメラ 200万画素 CMOS
解像度 最大 1920×1080（1080p）
視野角 約120° 広角
夜間 IRカット切替 + IR LED（ナイトビジョン）
マイク 内蔵（アプリでON/OFF可）
スピーカー 1W

2.3 駆動系・機構

項目 内容
駆動方式 4輪駆動 + クローラ（履帯）
モーター DCモーター ×4
最高速度 約2 km/h
機構特徴 段差・屋外路面に強い
※ オリジナルScout（メカナムホイール）より 再現性・直進性が大幅に改善されています。

2.4 電源・筐体

項目 内容
バッテリー 18650 Li-ion（約2000mAh）
駆動時間 約2時間（IR使用時は短縮）
充電 USB 5V / 2A
防水性能 IPX4（屋外利用可）
サイズ 約 11.5 × 10 × 8 cm
重量 約 350g

3. センサー構成

3.1 センサー一覧

センサー 内容
IMU 6DoF（3軸加速度 + 3軸ジャイロ）
ToF 距離センサー（～約2m）
照度 光センサー（昼夜判定用）

3.2 センサー実装例（解析記事より）

  • IMU：STMicroelectronics LSM6DS3
  • ToF：STMicroelectronics VL53L0X
  • 照度：Lite-On LTR-303
👉 教育・研究用途として 非常に一般的で扱いやすい構成です。

4. ソフトウェア構成

4.1 OS / ミドルウェア

項目 内容
OS Linux（Debian系）
ミドルウェア ROS 1.x
アクセス SSHログイン可能（root権限あり） 
ssh linaro@linaro-alip
👉 **「完全に中が触れる市販ロボット」**という点が最大の価値です。

4.2 通信

項目 内容
Wi-Fi 2.4GHz / 5GHz（802.11 a/b/g/n）
Bluetooth 4.2（デフォルト無効）
映像配信 ローカル / P2P / クラウド（選択可）

4.3 制御・プログラミング

① スマホアプリ

  • Android / iOS
  • 手動操作
  • 自動パトロール
  • 検知イベント設定

② Scratch（Blockly）プログラミング

  • GUI操作 → Pythonコード生成
  • ROSノードとして実行

③ 低レベル開発

  • Python / C/C++
  • UARTポートあり
  • ROSトピック直接操作可能

5. AI・自律機能（内蔵）

機能 内容
物体検知 人・犬・猫
動体検知 動き検知
追従 人・ペット追跡
自動充電 ドック復帰
音声連携 Alexa / Siri
※ SLAMによる地図生成は非搭載 → Teach & Repeat / VPR 的な発展がしやすい構成

6. Scout（旧型）との違い

項目 Scout Scout E
移動方式 メカナムホイール クローラ（履帯）
屋外対応 × ○
走行再現性 低い 高い
研究用途 △ ◎
👉 Model Eは研究・自律走行用途向け

7. 研究・プロジェクト視点での評価

強み

  • Linux + ROSが最初から動く
  • カメラ・IMU・ToFが最低限揃っている
  • 小型・安価・安全
  • SSH可能でブラックボックスが少ない

弱み

  • LiDARなし
  • 高精度オドメトリ不可
  • 計算資源は非力（Jetson級ではない）

8. SCOUTプロジェクトとの相性（あなたの文脈）

これまでの VPR / Teach & Repeat / SLAMレス自律走行の議論と、 SCOUT Model E は 非常に相性が良いです。
  • 「地図を作らない」前提
  • カメラ主体
  • 軽量エッジAI
  • ROS1ベースで拡張しやすい
👉 教育・実証・論文ネタとして使いやすい実機
もし次に進むなら、例えば：
  • SCOUT Eで できること／できないこと
  • Jetsonを追加した拡張構成案
  • VPR / VT&R 実装例との対応表
  • 研究用途での限界と回避策
なども整理できます。 どこまで深掘りしますか？  

SCOUTの巡回パトロールの機能はどのようにルートを制御していますか？制御に関するプログラムを見ることもできるのですか

  SCOUT（特にScout/Scout E）の「巡回パトロール」は、いわゆる SLAMで地図を作って自己位置推定しながら巡回ではなく、基本は **「教えた動きの再生（teach & repeat 的）」**に近い方式です。

巡回パトロールはどうルート制御している？

マニュアル上の記述から読み取れる範囲だと、流れはこうです。
  • ユーザーがアプリでロボットを手動運転して「経路を教える」
  • そのときの経路をロボット側が記録（距離や回転の“つもり”のコマンド列）
  • パトロール実行時に、そのコマンド列を順に再生する
マニュアルにも、パトロールは日中に教えるのと夜間（ナイトビジョン）で差が出る、またユーザーがカメラ前に居ると特徴抽出に影響し得る、といった記述があり、何らかの**カメラ特徴を使った補助（見え方の整合）**を入れている可能性はありますが、少なくとも 「地図生成＋自己位置推定の堅牢なナビ」ではないです。 また、同じマニュアル内に「Scoutは“歩数を数える”みたいな方式（動きの再現性に依存）」という文脈に近い説明もあり、これも オドメトリ精度に強く依存する単純な再生型だと解釈するのが自然です。

制御プログラムは見られる？

ここは “どのレベルを見たいか”で答えが分かれます。

1) 見られる（触れる）もの：ロボット上で動くLinux/ROSとAPI

  • SCOUTは Linux上にROSが動いていることが明記されています。
  • マニュアルには、Scratch（Blockly）で作ったプログラムが Pythonコードに生成され、ScoutのROS上で実行されると書かれています。
  • さらにマニュアルには Custom Scratch API が載っていて、rollereye.set_translate(...) や rollereye.set_rotate(...) のような形で 移動コマンドをAPI経由で出せることが分かります。
つまり、
  • 自分で書くPython（Scratch生成含む）
  • そのAPIで出す移動制御
  • ROSトピック周り（あなたがやっている /cmd_vel 等）
このレイヤは 見える／制御できる可能性が高いです。

2) 見えない（見えにくい）もの：アプリの「パトロール」内部実装

一方で、
  • アプリが記録している「パトロール経路データの形式」
  • それを再生する内部ロジック（例：補正、失敗時処理、ドック復帰戦略）
  • クラウド連携や通知周り
は、アプリ側（Android/iOS）やロボット側のバイナリ実装に入っていることが多く、ソースが公開されていなければ「そのまま読む」のは難しいです。 ただしマニュアルには「ロボットの制御レイヤはオープンソース」との記述もあり、少なくとも一部は公開・提供される可能性があります（入手経路は “連絡して” といったニュアンス）。

“パトロールの中身”を現実的に覗く方法（おすすめ順）

あなたの今のROS連携の流れだと、次が一番確実です。
  1. パトロール実行中にROSトピックを記録する
    • /cmd_vel（または同等の移動指令）
    • 可能ならIMU/ToF/カメラも一緒に → 「どんな指令列で動かしてるか」が分かります
  2. ロボット内のプロセス確認（sshできるなら）
    • ps aux / systemctl / rosnode list などで、パトロール時に動くノードやバイナリを特定
  3. アプリの経路データを探す
    • ロボット側の保存ファイルやログ（/home, /opt, /var 等）に“route”“patrol”等がないか検索
必要なら、あなたの環境（Scout側ROS Melodic / PC側Noetic）に合わせて、 **「パトロール中のコマンド列をrosbagで抜く手順」**をそのままコピペで作ります。 いま確認したいのはどちらですか？
  • A) パトロールが出してる移動コマンド列（cmd_vel的なもの）を見たい
  • B) パトロール機能そのものの実装（コード）を読みたい

メーカーがROSに出している範囲はわかりますか

  結論から言うと、Moorebot（SCOUT / Scout E）が「ROSとして公式に外へ出している範囲」はかなり限定的で、 いわゆる 「研究用ロボットとして全部のROSインタフェースを公開している」状態ではありません。 ただし、 👉 実機の中ではROSが“中核制御層”として確実に使われている 👉 ユーザーが触れる範囲と、メーカー内部で閉じている範囲が分かれている というのが実態です。 以下、分解して説明します。

1. メーカーが「ROSで使っている」と明言している範囲

公式仕様・マニュアル・技術記事から確実に言えるのは：
  • OS：Linux
  • 制御基盤：ROS（ROS 1系）
  • Scratch（Blockly）で作ったプログラムは 👉 Pythonコードに変換され、ROS上で実行
つまり、
ROSは “内部制御OS” として使われている
これは明確です。

2. ユーザーが公式に触れることができるROS相当レイヤ

(1) Custom Scratch API（最重要）

マニュアルに API名・関数名が明示されています。 例（実際に載っているもの）：
  • 移動系
    • set_translate(degree)
    • set_rotate(direction)
    • set_wheel(front_left, front_right, rear_left, rear_right)
  • 速度制御
    • set_translationSpeed()
    • set_rotationSpeed()
  • センサー・AI
    • 人・ペット検知
    • 動体検知
  • メディア
    • カメラ撮影
    • 録画開始・停止
    • サウンド再生
重要なのは：
これらはROSノード or ROSラッパの上に作られたAPI
という点です。 つまりメーカーは、
  • ROSノード
  • ROSトピック
  • ROSサービス
を そのまま公開せず、 Scratch / Python APIとしてラップして提供しています。

(2) SSHログイン（非公式だが事実上可能）

技術ブログ等で確認されている事実：
  • ScoutはSSHログイン可能
  • 通常ユーザー：linaro
  • 中で普通のLinux + ROSが動いている
これにより：
  • rosnode list
  • rostopic list
  • ps aux
  • systemctl
などが 理論上は可能です。 ⚠️ ただし：
  • これはメーカーが「研究者向けに正式サポートしているAPI」ではない
  • ファーム更新で壊れる可能性あり

3. メーカーが「ROSとして出していない」範囲（＝ブラックボックス）

(1) 巡回パトロール（route / patrol）

  • アプリで作る「巡回ルート」
  • その保存形式
  • その再生アルゴリズム
  • 失敗時の復帰ロジック
👉 ROSパッケージとしては公開されていない つまり：
/patrol_route のような公式トピックや StartPatrol.srv のようなサービスは 公開されていない
可能性が高いです。

(2) ナビゲーションロジック本体

  • SLAM
  • 地図生成
  • 自己位置推定
これらは そもそも搭載されていない or 非公開。 Scoutのパトロールは NavStack（move_base）型ではないです。

(3) AI検知（人・ペット検知）

  • 推論モデル
  • 推論結果のROSトピック
→ アプリ経由のイベントとしてのみ公開

4. まとめ：メーカーがROSに「出している範囲」

整理するとこうです👇

✅ 出している（公式・半公式）

  • Linux + ROS を使っている事実
  • Scratch / Python API
    • 移動
    • 速度
    • カメラ
    • AIイベント
  • UARTなどの拡張インタフェース

⚠️ 出していない（ブラックボックス）

  • 巡回パトロールの内部実装
  • 経路データ構造
  • ナビゲーション戦略
  • アプリ内部ロジック
  • ROSトピック一覧の公式ドキュメント

5. あなたのSCOUT研究文脈での重要な示唆

ここが一番大事です。

SCOUTは：

「ROSナビの完成品」ではなく 「ROSが動く素体」
です。 だからこそ：
  • 公式パトロールを「使う」のではなく
  • 自分でROS側にNav / VPR / Teach&Repeatを実装する
  • 公式パトロールは「比較対象・ベースライン」
という立ち位置が 研究的にめちゃくちゃ美味しい。

次にできる具体アクション（おすすめ）

もしよければ次は：
  1. 公式パトロール実行中に
    • rostopic list
    • rostopic echo /cmd_vel
  2. 自作ノードから同じ指令を出す
  3. 「公式 vs 自作」の比較
をやると、 👉 論文1本分の構造がそのまま出ます
次に知りたいのはどれですか？
  • SCOUT内部で実際に生えてそうなROSノード予想
  • 公式パトロールを“観測だけ”する具体手順
  • SCOUTを「ROS Teach & Repeat 実験台」として再定義する設計図
どれも、かなり深く書けます。