Chương B · đường phải bay được, không chỉ vẽ được — cửa sổ receding horizon

Khung 6 câu hỏi

🖼️ Hình nhanh: cửa sổ MPC trượt theo thời gian
thời gian ──► t₀ t₁ t₂ |████ horizon ██|···· giải opt, chỉ dùng bước đầu u₀ |████ horizon ██|···· dịch cửa sổ, giải lại từ x đo mới |████ horizon ██| ★ = trạng thái hiện tại (feedback) ██ = kế hoạch dự định

🇻🇳 Chuyện thật (sân D · cũng B): Sau bão miền Trung: map cũ lệch, gió còn giật — plan cả chuyến trên giấy đẹp nhưng ba mươi giây sau đã sai như chỉ đường trước khi đường sập.
Góc nhà đô thị cũng thế: gió hẻm đổi hướng, bám traj dài là “tin lời hứa cũ”.
MPC nhìn lại \(x\) đo được, tối ưu cửa sổ ngắn, chỉ thực thi bước đầu rồi giải lại — replan có kỷ luật.
Chốt: kinodynamic + receding horizon = đường bay được theo \(f\), và sửa khi gió/map đổi, không bám plan chết. ../00C.

Hình minh họa (seminar-ready)

Hình gốc hoặc minh họa cho ebook — không cắt từ slide Princeton. Dùng Present: bật Slide · F toàn màn.

0. Mục tiêu học

1. Phân biệt planning hình học và kinodynamic.
2. Nêu ba chiến lược chính + trade-off.
3. Giải thích MPC như re-plan vòng kín (receding horizon).
4. Chứng minh số: đường vẽ được ≠ đường bay được (cua 90°).

1. Trực giác

Xe tải không đi được đường thiết kế cho xe đạp.
Mọi “đường” đều ngầm chứa thời gian; khả thi hay không nằm ở đạo hàm
(vận tốc/gia tốc), không nằm ở hình vẽ trên bản đồ.

Ba chiến lược khi đường hình học không bay nổi:

1. Decouple — plan hình học trước, làm mượt + timing sau (RRT → min-snap, Lec 9).
2. Kinodynamic RRT — mọc cây trong state \((p,v,\ldots)\); mỗi cạnh = forward sim \(f(x,u)\).
3. Trajectory optimization / MPC — tối ưu có ràng buộc dynamics + limits (+ obstacle).

2. Cốt lõi + sơ đồ

2.1. Ba chiến lược

  Decoupled:       [RRT hình học] → [smooth+time] → [tracking ctrl]
  Kinodynamic:     [RRT trong state-space; cạnh = ∫ f(x,u) dt]
  Trajectory opt:  min Σ c(x,u)  s.t. dynamics + limits + obstacle
  MPC:             traj opt chân trời ngắn, lặp mỗi 10–50 ms

2.2. Kinodynamic RRT (ý)

  x = (p, v, …) ∈ state-space
  mỗi cạnh: chọn u ∈ U_allowed ──► tích phân ẋ=f(x,u) ──► x_new
            (không còn đoạn thẳng Euclidean trong workspace)

2.3. MPC = feedback planning

Mỗi chu kỳ điều khiển:

1. Đo / ước lượng \(x_t\) (sang Chương C: \(z\) nhiễu!).
2. Giải \(\min \sum_{k=0}^{H-1} c(x_k,u_k)\) trên horizon \(H\) (0.5–2 s).
3. Chỉ áp dụng \(u_0\); bỏ phần còn lại.
4. Lặp — cửa sổ trượt.

         quá khứ          hiện tại ★        tương lai (kế hoạch)
  ──────────────●─────────●═══════════════●········
                          │←── horizon H ──→│
                          chỉ gửi u₀ xuống plant

Vì sao thường robust hơn opt “một phát”: mỗi bước hấp thụ nhiễu gió / model error bằng cách replan từ state thật.

3. Demo — đường hình học ≠ đường bay được

"""
Cua vuông góc 90° với v=3 m/s trong 0.2 s.
So với a_max=5 m/s² → kết luận khả thi / cách vá.
"""
import numpy as np

v = 3.0          # m/s
t_turn = 0.2     # giây đổi hướng π/2
a_max = 5.0      # giới hạn gia tốc ngang giả định

a_need = v * (np.pi / 2) / t_turn
print(f"Gia tốc cần ≈ {a_need:.1f} m/s²")
print(f"Giới hạn     = {a_max:.1f} m/s²")
if a_need > a_max:
    v_ok = a_max * t_turn / (np.pi / 2)
    R_ok = v * v / a_max
    print("→ KHÔNG khả thi với tốc độ/thời gian này.")
    print(f"  Vá: chậm còn ≈ {v_ok:.2f} m/s, hoặc bán kính cua ≥ {R_ok:.2f} m")

🧪 Kỳ vọng demo: in a_need ≈ 23.6 m/s² > 5 → không khả thi; gợi ý chậm ≈ 0.64 m/s hoặc bán kính ≥ 1.80 m. Bài học: timing và \(a\) quyết định feasibility.

Hình minh họa trade-off:

  v cao + cua hẹp:     ●──┐          cần a lớn (❌)
                          └──●

  v thấp hoặc R lớn:   ●········●    a = v²/R nhỏ (✅)
                      (cung rộng)

4. Gắn RL–UAV / đa mục tiêu

• Policy RL điều khiển trực tiếp ≈ amortize planning vào mạng — so paper: RL vs MPC (chất lượng, latency, bền khi model sai / gió).
• Action bound trong env phải khớp thrust-to-weight, \(\omega_{\max}\) thật — env cho action bất khả thi → khó sim-to-real.
• Hybrid: MPC/shield tầng dưới, RL chọn reference / trọng số đa mục tiêu (energy vs coverage) tầng trên.
• Gió đô thị: MPC horizon ngắn hấp thụ gust; cost trong MPC có thể phạt vùng gió mạnh (cùng cost map Lec 7).
• Năng lượng: \(c\) trong MPC/traj opt = proxy pin; đừng chỉ tối thiểu độ dài đường.

5. Ưu / nhược

Nghĩa với năng lượng / gió / độ phủ: kinodynamic ép “bay nổi”; MPC cho phép cost đa mục tiêu trên horizon ngắn; phủ dài hạn thường vẫn ở tầng waypoint.

6. Lỗi thường gặp

⚠️ Lỗi hay gặp: Đánh giá planner chỉ bằng độ dài mà quên gia tốc / giới hạn motor.
⚠️ So RL với MPC nhưng cho MPC thời gian tính không thực tế.
⚠️ Nhầm “đã min-snap” với “đã kinodynamic đầy đủ” — min-snap vẫn dựa model flat/giả định.
⚠️ Horizon MPC quá ngắn → myopic (không thấy vật cản xa); quá dài → không kịp giải.

7. Checklist

1. Ba chiến lược kinodynamic — trade-off chính từng cách?
2. MPC khác trajectory optimization “chạy một phát” ở điểm nào?
3. Trong env RL của bạn, action bound lấy từ đâu — đã khớp giới hạn thật chưa?
4. Cost MPC/path đã có năng lượng hoặc gió chưa, hay chỉ độ dài?

⚡ Nhớ một câu: Đường đẹp trên map vẫn có thể bất khả thi — feasibility nằm ở \(f(x,u)\) và cửa sổ MPC trượt theo feedback.

🔗 Sang bài sau mang theo: Mọi planning/control từ Ch.A–B hay giả định biết \(x\). Chương C bắt đầu: máy thật chỉ cho \(z\) nhiễu — phải giữ belief.

  ★ Hình nhớ mãi (hết Chương B):
  vẽ được ──?──► bay được ──(MPC)──► bay được *dưới nhiễu*

Trước: Lec09 · Sau: Lec11 · hết Chương B