optimal & fix file cmake

config/runtime/action_handlers_params.yaml

@@ -0,0 +1,77 @@
+# Action handler của move_base2 (D8: navigation runtime chạy trọn một mission — nav xong thì chạy
+# nốt action của chặng rồi mới báo kết quả).
+#
+# Handler là plugin của gói `action_core`, nạp qua Boost.DLL đúng như planner/recovery. Thêm một
+# loại action mới = viết một `.so` + thêm một dòng ở đây, không phải sửa dòng nào của navigation.
+#
+# Vì sao file này tồn tại: thiếu handler thì `ActionRunner::start` từ chối và chặng mang action đi
+# thẳng tới ABORTED — tức mọi order VDA5050 có node action fail ở chặng đầu tiên.
+
+actions:
+  handlers:
+    # Dò: lấy mẫu frame thô của LiDAR/camera, lọc, ghi ra `dock_target` cho chặng sau tra.
+    - {name: detect,   type: FrameSamplerActionHandler}
+
+    # Hai handler THẬT, chạy được cả trên robot: chúng không điều khiển thiết bị nào vì chính action
+    # đó không yêu cầu thiết bị nào.
+    - {name: waiter,   type: WaitActionHandler}
+    - {name: reporter, type: LogReportActionHandler}
+
+    # ⚠ STUB MÔ PHỎNG, CHỈ DÀNH CHO SIM/DEV. `NoopActionHandler` chỉ log rồi báo thành công sau
+    # `duration` giây — nó KHÔNG nói chuyện với thiết bị nào. Trên robot thật, một `PickUp` chạy qua
+    # đây nghĩa là robot báo "đã nâng kệ" trong khi càng nâng chưa hề nhúc nhích, và fleet master sẽ
+    # giao chặng tiếp theo với giả định hàng đã ở trên xe. Thay bằng handler thật (nói chuyện với
+    # PLC/băng tải/càng nâng) trước khi chạy ngoài hiện trường.
+    - {name: sim_noop, type: NoopActionHandler}
+
+  detect:
+    action_types: [DetectCharger, DetectPallet]
+    output_frame: dock_target     # chặng docking trỏ `move_to` vào đây
+    # STUB chỉ cho Gazebo/dev: thay perception bằng target cố định (-1.5, +0.2) trong `base_link`,
+    # theo đúng pose `trolley_goal` giả trước đây. Handler quy nó sang `map` MỘT LẦN rồi ghi
+    # `dock_target` tĩnh vào tf3, nên target không chạy theo robot khi chặng docking bắt đầu.
+    # PHẢI tắt trước khi chạy robot thật để handler lấy frame do perception publish.
+    use_simulated_goal: true
+    simulated_parent_frame: base_link
+    simulated_offset_x: 1.5      # [m]
+    simulated_offset_y: 0.2       # [m]
+    simulated_offset_yaw: 0.0     # [rad]
+    settle_delay: 1.0             # [s] chờ robot đứng hẳn — pose lúc vừa dừng còn dao động cơ khí
+    sample_window: 2.0            # [s] thu mẫu
+    min_samples: 20
+    max_spread_xy: 0.03           # [m]   tản hơn -> kFailed, KHÔNG lùi vào
+    max_spread_yaw: 0.05          # [rad]
+    timeout: 15.0                 # [s]   frame thô không tới -> kFailed
+
+  waiter:
+    action_types: [wait]
+    default_duration: 2.0    # [s] dùng khi action không kèm tham số `duration`
+    max_duration: 600.0      # [s] trần cứng; vượt trần thì action THẤT BẠI, không bị cắt ngắn
+
+  reporter:
+    action_types: [logReport]
+
+  sim_noop:
+    # ⚠ `PickUp` và `charge` KHÔNG có ở đây: chúng là compound action, adapter đã dịch chúng thành
+    # chuỗi chặng và GỠ khỏi danh sách action. Thứ tới được ActionRunner là các actionType do chuỗi
+    # đó sinh ra (`LiftFork`, `startCharging`) cộng với action thường của order.
+    #
+    # Đây đúng chỗ dễ trôi lệch nhất giữa hai bảng: khai `PickUp` ở đây thì handler không bao giờ
+    # được gọi, còn quên `LiftFork` thì chặng thiết bị ABORT giữa chừng với kệ đang trên càng.
+    action_types: [LiftFork, startCharging, DropDown, Drop, MutedOn, MutedOff, pick, drop]
+    duration: 2.0    # [s] thời gian giả lập thiết bị làm việc
+    timeout: 30.0    # [s] timeout TẦNG 1 — trách nhiệm của chính handler
+
+# Bảng symbol -> thư viện cho Boost.DLL. Thiếu `library_path` là nguyên nhân phổ biến nhất của lỗi
+# "plugin build xong nhưng runtime báo không tìm thấy".
+FrameSamplerActionHandler:
+  library_path: libaction_core_frame_sampler_action_handler
+
+WaitActionHandler:
+  library_path: libaction_core_wait_action_handler
+
+LogReportActionHandler:
+  library_path: libaction_core_log_report_action_handler
+
+NoopActionHandler:
+  library_path: libaction_core_noop_action_handler

config/runtime/compound_actions_params.yaml

@@ -0,0 +1,54 @@
+# Action "phải dò rồi mới biết đích" — bảng mở rộng của `VDA5050SourceAdapter`.
+#
+# File riêng thay vì sửa `mission_adapters_params.yaml`: file đó là symlink sang cây config của
+# `pnkx_nav_core` (submodule). `robot::NodeHandle` gộp mọi file YAML trong thư mục config vào một
+# cây, nên khoá `vda5050_src` ở đây hợp nhất với khoá cùng tên bên kia.
+#
+# ── Bảng này chỉ giữ CẤU TRÚC ────────────────────────────────────────────────────────────────────
+#
+# Fleet chỉ gửi `charge`; `DetectCharger` và `startCharging` là actionType NỘI BỘ do adapter sinh ra,
+# không bao giờ xuất hiện trong order JSON. Tên frame cụ thể đến từ `actionParameters` của chính
+# order, nên thêm một trạm sạc mới không phải sửa file này.
+#
+# Bốn từ khoá của một step, phải có ĐÚNG MỘT:
+#   action: <type>          chặng chỉ-action; mang nguyên actionParameters của action gốc
+#   move_to: <frame>        chặng nav, frame cố định
+#   move_to_param: <key>    chặng nav, frame lấy từ actionParameters[<key>] của action gốc
+#   move: <mét>             chặng nav tương đối; dương = tiến, âm = lùi
+# Tuỳ chọn cho step navigation: profile (position | docking | go_straight | rotate), marker.
+# `marker` chỉ hợp lệ với `profile: docking`: nó chọn override trong
+# maker_sources.yaml/docking_marker_profiles. Không khai = dùng cặp docking mặc định.
+# Tolerance thuộc YAML riêng của local planner đang được profile chọn, không khai ở đây.
+
+vda5050_src:
+  compound_actions:
+    charge:
+      steps:
+        # 1. Dò: đứng yên lấy mẫu frame thô, lọc nhiễu, ghi ra `dock_target`.
+        #    Robot không phát cmd_vel trong EXECUTING_ACTIONS nên đây đúng là lúc để lọc.
+        - {action: DetectCharger}
+
+        # 2. Tiến vào đích vừa dò được bằng profile docking. Sai số do local planner đọc từ YAML
+        #    của chính plugin đó.
+        - {move_to: dock_target, profile: docking, marker: charger}
+
+        # 3. Thao tác thiết bị. Chặng 1 hoặc 2 hỏng thì `clear_queue_on_failure` xoá chặng này —
+        #    robot không bao giờ đóng relay khi chưa vào được vị trí.
+        - {action: startCharging}
+
+    PickUp:
+      steps:
+        - {action: DetectPallet}
+        - {move_to: dock_target, profile: docking, marker: trolley}
+        - {action: LiftFork}
+        # Lùi ra khỏi khe kệ. Quãng đường tương đối được quy ra pose tuyệt đối tại `submit`, từ pose
+        # LÚC ĐÓ — lúc adapter sinh chặng thì robot còn chưa tới nơi.
+        - {move: -0.5, profile: go_straight}
+    
+    GoStraight:
+      steps:
+        - {move: 1.0, profile: go_straight}
+    
+    Rotate:
+      steps:
+        - {move: 0.0, profile: rotate}

config/runtime/maker_sources.yaml

@@ -1 +0,0 @@
-../../../../pnkx_nav_core/config/maker_sources.yaml

config/runtime/maker_sources.yaml

@@ -0,0 +1,23 @@
+# Compatibility allow-list for BaseNavigation::dockTo(marker, ...).
+#
+# move_base2 docking resolves `goal_frame` to an absolute pose and runs DockPlanner +
+# HybridLocalPlanner.  It does not consume the legacy per-marker PNKXDockingLocalPlanner
+# parameters (plugins, maker_goal_frame, delay, timeout, velocity, tolerance, or lookahead).
+# Keep only the marker names that the host may submit until `dockTo` is migrated to
+# declarative dock_sequences.
+maker_sources: trolley charger dock_station undock_station dock_station_2 undock_station_2
+
+# Marker có entry ở đây dùng cặp planner riêng. Marker rỗng hoặc chỉ có trong `maker_sources` mà
+# không nằm trong bảng này sẽ dùng cặp `docking` mặc định của move_base_common_params.yaml.
+docking_marker_profiles:
+  trolley:
+    global_planner: DockPlanner
+    local_planner: HybridLocalPlanner
+
+  charger:
+    global_planner: DockPlanner
+    local_planner: HybridLocalPlanner
+
+  dock_station:
+    global_planner: DockPlanner
+    local_planner: HybridLocalPlanner

config/runtime/move_base_common_params.yaml

@@ -1,60 +1,74 @@
-position_planner_name: PriestLocalPlanner #HybridLocalPlanner MPPILocalPlanner PriestLocalPlanner PNKXLocalPlanner
-docking_planner_name: PNKXDockingLocalPlanner #StanleyDockingLocalPlanner PNKXDockingLocalPlanner
-go_straight_planner_name: PNKXGoStraightLocalPlanner
-rotate_planner_name: PNKXRotateLocalPlanner
-base_local_planner: LocalPlannerAdapter
-base_global_planner: SBPLLatticePlanner
+# Cặp global/local planner của từng kiểu chuyển động. move_base2 nạp trực tiếp
+# `robot_nav_core2::LocalPlanner`; không dùng LocalPlannerAdapter (bridge chỉ dành cho move_base cũ).
+position:
+  global_planner: CustomPlanner
+  local_planner: HybridLocalPlanner
 
-PriestLocalPlanner:
-  base_local_planner: LocalPlannerAdapter
-  base_global_planner: SBPLLatticePlanner #CustomPlanner SBPLLatticePlanner
+docking:
+  # goal_frame đã được ControlLoop quy thành pose tuyệt đối. DockPlanner dùng đúng contract
+  # makePlan(start, goal, plan), còn CustomPlanner chỉ xử lý makePlan(Order, start, goal, plan).
+  global_planner: DockPlanner
+  local_planner: HybridLocalPlanner
 
-PNKXDockingLocalPlanner:
-  base_local_planner: LocalPlannerAdapter
-  base_global_planner: TwoPointsPlanner
+go_straight:
+  global_planner: TwoPointsPlanner
+  local_planner: PNKXGoStraightLocalPlanner
 
-PNKXGoStraightLocalPlanner:
-  base_local_planner: LocalPlannerAdapter
-  base_global_planner: TwoPointsPlanner
+rotate:
+  global_planner: TwoPointsPlanner
+  local_planner: PNKXRotateLocalPlanner
 
-PNKXRotateLocalPlanner:
-  base_local_planner: LocalPlannerAdapter
-  base_global_planner: TwoPointsPlanner
+# Đường lùi chung cho mọi profile: planner chính trả false hoặc plan rỗng thì move_base2 đổi sang
+# planner này đúng MỘT lần cho request hiện tại. Backup cũng fail thì mới chạy recovery; request mới
+# luôn bắt đầu lại từ planner chính. Backup gọi makePlan(start, goal, plan), không mang VDA5050
+# Order, để SBPLLatticePlanner (chỉ có overload ba tham số) dùng được.
+backup_global_planner: SBPLLatticePlanner
+
+# Compound docking quy `goal_frame` thành pose tuyệt đối; HybridLocalPlanner không đọc maker_name.
+# `true` chỉ dành cho PNKXDockingLocalPlanner legacy, vốn phải chọn marker trước initialize().
+docking_requires_marker: false
+
+# Bảng `library_path` và tham số riêng của CustomPlanner, DockPlanner, TwoPointsPlanner cùng các
+# local planner nằm trong các YAML runtime đồng hành (symlink từ pnkx_nav_core/config/). Không lặp
+# lại chúng ở đây để tránh hai nguồn cấu hình cho cùng một plugin.
 
 ### replanning
 controller_frequency: 30.0   # run controller at 30.0 Hz
-controller_patience: 0.0    # if the controller failed, clear obstacles and retry; after 15.0 s, abort and replan
+controller_patience: 0.033333333  # [s] giữ hành vi cũ: fail controller -> recovery sau một cycle 30 Hz
 planner_frequency: 0.0       # don't continually replan (only when controller failed)
 planner_patience: 2.0        # if the first planning attempt failed, abort planning retries after 5.0 s...
 max_planning_retries: 0     # ... or after 10 attempts (whichever happens first)
 oscillation_timeout: -1    # abort controller and trigger recovery behaviors after 30.0 s
 oscillation_distance: 0.5
-## recovery behaviors
+
+### telemetry
 #
-# Recovery của move_base cũ đã dừng: bộ behavior gen-2 (tick-based) khai ở
-# `recovery_behaviors_params.yaml` và do `recovery_core::RecoveryRegistry` nạp, không phải khoá
-# `recovery_behaviors` ở đây.
+# [s] Chu kỳ in bảng thông số runtime ra terminal: CPU của từng thread đã đăng ký (control loop,
+# thread lập plan, hai vòng cập nhật costmap), chi phí từng đoạn công việc (local planner, global
+# planner, cachePlans), RSS và tốc độ tăng RSS. 0 = tắt hẳn, không đo gì.
 #
-# Danh sách gen-1 đã được gỡ hẳn thay vì để lại: các entry cũ trỏ tên alias `RotateRecovery` /
-# `ClearCostmapRecovery` vào file .so gen-2, trong khi loader ở đây import theo chữ ký gen-1
-# (`robot_nav_core::RecoveryBehavior`). Boost.DLL không kiểm kiểu qua ranh giới .so, nên hai bên
-# không bao giờ gặp nhau ở compile time và lỗi chỉ hiện ra lúc chạy. Giữ lại khoá cũng làm hai file
-# config tranh nhau cùng một tên alias.
-recovery_behavior_enabled: false 
-recovery_behaviors: [       
-                      {name: aggressive_reset, type: ClearCostmapRecovery},
-                      {name: conservative_reset, type: ClearCostmapRecovery},                      
-                    ]
+# Dòng "(không đăng ký)" trong bảng là phần CPU KHÔNG thuộc navigation stack — nó thuộc host ROS
+# (callback cảm biến, OPC-UA, VDA5050, TF bridge). Đọc con số đó trước khi kết luận move_base2 nặng.
+#
+# Đây là công cụ chẩn đoán: tắt lại khi đã đo xong, đừng để chạy thường trực trên robot thật.
+runtime_stats_period: 0.0
+# Recovery gen-2 nằm ở `recovery_behaviors_params.yaml`, namespace `recovery`.
+recovery_behavior_enabled: true
 
-conservative_reset:
-  reset_distance: 3.0        # clear obstacles farther away than 3.0 m
-  invert_area_to_clear: true
-
-aggressive_reset:
-  reset_distance: 3.0
-
-ClearCostmapRecovery:
-  library_path: librobot_clear_costmap_recovery
+## mission layer
+#
+# true (mặc định của move_base2): VDA5050 Order đi qua `mission_adapters` — order được cắt thành
+# từng chặng tại mỗi node có action, chỉ phần `released` được chạy, `orderUpdateId` nối tiếp thay vì
+# chạy lại từ đầu, và có `mission_timeout` làm lưới cuối. Nguồn mission và tham số của layer khai ở
+# `mission_adapters_params.yaml`.
+#
+# false: order đi thẳng xuống navigation như MỘT goal duy nhất — hành vi của move_base gen-1, và
+# cũng là hành vi đã chạy được trên sim trước 2026-07-31. Đây là đường lùi khi mission layer gây vấn
+# đề trên hiện trường: đổi một khoá, không phải build lại.
+#
+# Bật mà không nạp được nguồn nào thì runtime TỰ quay về đường trực tiếp kèm log cảnh báo — thiếu
+# plugin không được phép biến thành robot đứng im không rõ lý do.
+mission_layer_enabled: true
 
 MoveBase:
   library_path: libmove_base2