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