# 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