Robotic navigation as an end-to-end communication system

From Signal to System

這個頁面把倉庫裡的三個模型搬到瀏覽器上直接執行：有限頻寬下的多機器人探索、 通訊延遲造成的航位偏差、以及 LiDAR 串流的鏈路預算。所有數字都來自同一組固定種子， 可用倉庫內的 Python 腳本逐位元重現。

ROS 2 套件骨架 Python 模型（無 ROS 環境亦可執行） JS ↔ Python 對照：檢查中… 無硬體、無實測資料

總覽 Overview

一條從實體訊號到系統決策的資訊流，以及沿路上每個環節的取捨。

資訊流資訊鏈

01 SIGNAL
感測擷取
LiDAR / IMU / 相機，100 Hz–20 Hz 不同速率與時戳
02 PERCEPTION
感知與建圖
佔據網格、SLAM、感測融合，誤差隨時間累積
03 PLANNING
規劃與控制
DWA / MPC 取樣、PID 跟隨，受限於機上算力與功耗
04 LINK
無線鏈路
頻寬、往返延遲、丟包，直接改變導航品質
05 EDGE
邊緣卸載
算力–通訊權衡，決定要送多少資訊出去

這個倉庫裡有什麼

ROS 2 套件
src/：perception / mapping / planning / control / comms 五個節點群，含 cpp 控制器與 urdf 底盤描述
可執行模型
tools/coverage_model.py（探索）、analysis/（延遲、鏈路預算、更新率）
技術報告
report/report.tex，本頁「報告」分頁為其可讀版本
設計文件
docs/design_overview.md、sensing_pipeline.md、comms_architecture.md
本頁
離線可安裝的 PWA，內含與 Python 相同的模型實作

這個倉庫裡沒有的東西

  • 沒有實機、沒有測試台、沒有場域資料。
  • 沒有在 ROS 2 環境中啟動過節點，因此沒有任何 ros2 launch 的執行紀錄。
  • 沒有任何量測得到的實驗數據：報告中的案例研究是假設情境，數字來自解析式與資料表等級的假設。
  • 沒有模型權重、沒有訓練資料集。
誠實標註：本頁所有圖表都標明「模型輸出」或「假設情境」，與實測數據嚴格區分。

三個可以馬上動手的模型

有限頻寬探索

兩台機器人在 40×40 網格上探索，比較「整張地圖上傳」與「只傳變化格」的覆蓋率差距。可互動、可重跑。

延遲死區

命令往返延遲 τ 與速度 v 造成 v·τ 的航位偏差；找出 0.1 m 容許值下的延遲上限。

鏈路預算

原始 / 降採樣 / 差異更新三種資料流的頻寬需求，以及在給定頻寬下可達到的更新率。

有限頻寬下的多機器人探索

假設情境：兩台地面機器人、一台邊緣伺服器、共享一條上傳鏈路。地圖為 40×40 佔據網格，兩台機器人分別從自由空間的固定比例位置出發。

未探索 伺服器已收到 僅存於機器人（未傳出） 障礙物 機器人
Simulation step
0 / 200
Simulated wall-clock
0.0 s
Server map coverage
0.0 %
On-board coverage
0.0 %
Gap (local − server)
0.0 pp
Transmitted cells
0
Cells left in backlog
0
Uplink load @5 Hz
0 kbps

已提交的參考結果

由 tools/coverage_model.py 在同一組種子下產生，瀏覽器版本必須逐位元一致。

設定每步預算最終覆蓋率傳輸格數總計

每步預算掃描（差異更新）

預算低於「機器人學到新格的速度」時，伺服器地圖會落後且無法追上。

這是模擬。網格世界、感測半徑與移動規則都是簡化模型：沒有感測雜訊、沒有封包遺失、沒有 SLAM 誤差，通訊成本以「格數」計而非以位元計。 它的用途是讓「資料表示法與傳輸策略會改變導航表現」這件事可以被重複檢驗，而不是預測某個真實場域的覆蓋率。

延遲造成的航位偏差

若命令在往返延遲 τ 之後才生效，機器人已偏離當初計算命令時的位置約 v·τ。

Dead-band error v·τ
0.100 m
τ at 0.1 m tolerance
200 ms
Jitter σ (modelled)
20 ms
速度 vv·τ @ ττ 上限 (0.1 m)
這是一階解析模型，不是量測結果：假設環境在 τ 內不變、控制器無補償、且誤差只來自死區位移。 真實系統還會受到封包抖動、時戳錯位與控制器頻寬的影響，因此實際退化通常比這條直線更陡。

技術報告

《From Signal to System: The Intersection of Communications, Sensing, and Robotic Navigation》——把八個環節串成一條資訊流，並以一個假設情境收尾。

章節

  • 1 導論：為何機器人導航可以當成通訊系統來看
  • 2 感測與訊號擷取：雜訊模型、時戳同步、SNR
  • 3 感知與建圖：SLAM、佔據網格、EKF 感測融合
  • 4 區域規劃與機上運算：DWA / MPC、功耗與算力共同設計
  • 5 導航系統中的通訊：頻寬 B、延遲 τ、丟包率 pℓ
  • 6 邊緣與雲端卸載：C = C_local(λ) + C_comm(λ) + C_edge(λ)
  • 7 案例研究：2 Mbps 共享鏈路下的兩機探索（假設情境）
  • 8 結論與未來方向：語意通訊、學習式壓縮、多機非同步協調

閱讀完整報告（HTML 版）→

報告是設計研究：案例研究為假設情境，出現的數字為解析結果或資料表等級的數量級假設，全文不引用外部文獻、也不宣稱任何量測結果。

重現與驗證

三個模型都可以只用 Python 重跑；本頁的 JavaScript 實作與 Python 在同一組種子下必須輸出相同數字。

1. 產生參考資料集（純 Python，不需要 ROS 2）

git clone https://github.com/TeWei02/From-Signal-to-System
cd From-Signal-to-System
python3 -m pip install numpy            # 只有 coverage_model 需要

python3 tools/coverage_model.py         # 印出探索模型結果與檢查碼
python3 tools/build_web_data.py        # 重新產生 docs/data/reference.json
jsc tools/verify_engine.js             # macOS 內建 JavaScriptCore，逐位元比對瀏覽器引擎

2. 本頁在瀏覽器內的即時驗證

下方表格由本頁的 engine.js 當場重算，再與 docs/data/reference.json 的已提交數值比較，容差 1e-9。

檢查項目結果樣本數
檢查中…

3. ROS 2 部分與環境限制

src/ 下的節點、套件描述與 URDF 是 ROS 2 工作區的骨架：介面、話題與節點職責已定義，但沒有在本機或任何 CI 環境中啟動過。 因此倉庫不提供 colcon build 的成功紀錄、不提供 Gazebo 世界檔、也不宣稱節點可在特定 ROS 2 版本上執行。 要在真實環境重現，需要自備 ROS 2 發行版、Gazebo 與對應的感測器外掛。

不可重現的部分已明確列出：沒有硬體、沒有場域資料、沒有訓練好的模型、沒有 ROS 2 執行紀錄；只有模型與文件是可重現的。