第192章 Action–Device Mapping

行为与设备映射

第191章建立了：

Action
 ↓
Device Object
 ↓
Physical Device

第192章进一步解决一个核心工程问题：

ICAI 产生的 Action，如何根据设备能力转换成具体设备能够理解的 Command？

因此建立：

Action
 ↓
Device Capability
 ↓
Device Mapping
 ↓
Device Command
 ↓
Physical Device

1. Action 不等于 Device Command

必须严格区分：

Action

和：

Device Command

例如 ICAI 的认知结果：

Action = Grasp

这表示：

机器需要完成“抓取”这个行为。

但具体设备可能需要执行：

Gripper
 ↓
Open
 ↓
Move
 ↓
Close
 ↓
Force Control

因此：

Action
≠
Command

而是：

Action
 ↓
Command Generation

2. Device Capability 决定映射方式

建立：

Action
+
Device Capability
 ↓
Device Command

例如：

Action = Grasp

设备：

Gripper

能力：

Open
Close
Force Control

于是可以生成：

Open
 ↓
Move
 ↓
Close
 ↓
Apply Force

但是如果设备只有：

Move
Stop

那么：

Grasp

就无法直接映射。

因此：

Action 能否执行，不仅取决于 Action 本身，还取决于 Device Capability。

3. Action–Device Mapping

建立独立的映射层：

Action
      +
Device
      ↓
Action–Device Mapping
      ↓
Device Command

可以抽象为：

class ActionDeviceMapper
{
    public function map(Action $action, Device $device)
    {
        // 根据 Action 与 Device Capability
        // 生成设备命令

        return $command;
    }
}

使用：

$command = $mapper->map(
    $action,
    $gripper
);

形成：

Action Object
 ↓
ActionDeviceMapper
 ↓
Device Command

4. Grasp 映射实例

例如：

Action
{
    type: grasp
    target: egg_001
    force: 0.25
}

设备：

Gripper

能力：

open
close
force_control

映射：

Grasp
 ↓
Gripper Capability
 ↓
Command Sequence

得到：

Open
 ↓
Move To Target
 ↓
Close
 ↓
Force = 0.25

于是：

ICAI Action

被转换成：

Physical Device Command

5. 一个 Action 可以产生多个 Command

这是本章非常重要的地方。

例如：

Action = Grasp

并不一定对应：

Command = Grasp

而可能是：

Grasp
 ↓
Command 1: Open
Command 2: Move
Command 3: Close
Command 4: Force Control

因此：

One Action
 ↓
Multiple Commands

形成：

High-Level Action → Low-Level Command Sequence

6. Move 的映射

例如：

Action
{
    type: move
    target: egg_001
    position: [100,80,30]
    velocity: 0.08
}

设备：

RobotArm

设备能力：

Move
Position Control
Velocity Control

映射为：

Move
 ↓
Set Target Position
 ↓
Set Velocity
 ↓
Execute Motion

最终形成：

Device Command

7. Release 的映射

例如：

Action = Release

如果设备是：

Gripper

则：

Release
 ↓
Open

但如果设备是其他类型：

Robot Hand

可能是：

Finger Release

因此：

Same Action
+
Different Device
 ↓
Different Command

这正是 Device Abstraction 的意义。

8. 同一个 Action 可以映射不同设备

建立：

Action = Move

可能进入：

RobotArm

得到：

Joint Motion

进入：

AGV

得到：

Wheel Motion

进入：

Linear Motor

得到：

Linear Displacement

所以：

Move

不是具体硬件命令。

它是：

ICAI 的行为语义。

而：

Device Command

才是：

设备执行语义。

9. Action Mapping 不改变 Cognition

映射层必须保持独立。

完整结构：

Scene
 ↓
Cognition
 ↓
Method
 ↓
Action
 ↓
Action–Device Mapping
 ↓
Device Command

其中：

Cognition

负责：

为什么这样行动？

Action

负责：

要完成什么行为？

Mapping

负责：

这个设备如何完成这个行为？

Command

负责：

设备具体执行什么？

这四个层次不能混在一起。

10. Device Capability Matching

在 Mapping 前可以先进行：

Action
+
Device Capability
 ↓
Capability Matching

例如：

Action = Grasp

设备：

AGV

Capabilities：

Move
Stop
Navigation

匹配：

Grasp
 ↓
No Capability

因此：

Mapping

不能继续。

系统返回：

{
    "status": "failed",
    "reason": "unsupported_action"
}

然后：

Feedback
 ↓
Cognition

重新进行：

Method Matching

11. Capability 不只是 Action 名称

设备能力还可以进一步结构化：

Capability
{
    type
    parameters
    limits
    state
}

例如：

Gripper

可以具有：

force_control
max_force
min_force
opening_range
precision

那么：

Action
Force = 0.25

还需要判断：

0.25

是否在：

Device Capability Limit

以内。

形成：

Action
+
Capability
+
Constraint
 ↓
Executable Command

12. Mapping 是一个计算过程

因此：

Action–Device Mapping

不是简单：

Grasp → Gripper

而是：

Action
+
Device
+
Capability
+
Parameters
+
Constraints
 ↓
Mapping Algorithm
 ↓
Device Command

这与第188章：

Method Calculation

形成对应。

区别是：

Method Calculation

解决：

认知上如何行动。

而：

Action–Device Mapping

解决：

设备上如何实现这个行动。

13. Device Command Object

为了继续保持 OOP 结构，Command 本身也可以成为对象：

class DeviceCommand
{
    protected $device;
    protected $type;
    protected $parameters;
    protected $timestamp;
}

于是：

Action
 ↓
Mapping
 ↓
DeviceCommand Object

例如：

DeviceCommand
{
    device: gripper_001
    type: close
    parameters:
    {
        force: 0.25
    }
}

这样整个执行链保持对象化：

Scene Object
 ↓
Cognition Object
 ↓
Method Object
 ↓
Action Object
 ↓
Device Object
 ↓
Command Object

14. Action Sequence

一个复杂行为可以形成：

Action
 ↓
Action Sequence
 ↓
Command Sequence

例如：

Grasp
 ↓
Open
 ↓
Move
 ↓
Align
 ↓
Close
 ↓
Force Control

可以建立：

class CommandSequence
{
    protected $commands = [];

    public function add(DeviceCommand $command)
    {
        $this->commands[] = $command;
    }
}

于是：

Action
 ↓
Mapping
 ↓
CommandSequence
 ↓
Device

15. API 通讯结构

由于 ICAI 与设备系统保持独立：

ICAI Cognitive System
        ↓
Action Data
        ↓
Device Mapping API
        ↓
Device Command
        ↓
Device System

例如：

{
    "action": "grasp",
    "target": "egg_001",
    "force": 0.25
}

设备系统内部：

Action Parser
 ↓
Capability Matching
 ↓
Action–Device Mapping
 ↓
Command Generation
 ↓
Device Controller

最终：

Physical Device

16. Mapping 结果必须可追踪

为了支持后面的 Feedback 和 Learning：

Action ID
Scene ID
Device ID
Command ID
Timestamp

应该保持关联。

例如：

{
    "scene_id": "scene_001",
    "action_id": "action_017",
    "device_id": "gripper_001",
    "command_id": "command_031",
    "type": "close",
    "force": 0.25
}

于是可以追踪：

Scene
 ↓
Cognition
 ↓
Action
 ↓
Command
 ↓
Device
 ↓
Result

17. Mapping 与反馈

最终：

Action
 ↓
Device Capability
 ↓
Device Command
 ↓
Device
 ↓
Physical Action
 ↓
Result

如果成功：

Result
=
Success

如果失败：

Result
=
Failure

如果发生异常：

Unexpected Result

都进入：

Feedback

然后：

Feedback
 ↓
Scene Update
 ↓
Cognition

因此：

Action–Device Mapping

仍然属于完整认知闭环的一部分。

18. 本章最终工程链

现在可以把第171–192章压缩成：

Real-Time Data
        ↓
Element Instance
        ↓
Object Instance
        ↓
Relation
        ↓
Scene Instance
        ↓
Current Scene
        ↓
Cognition
        ↓
Method
        ↓
Method Calculation
        ↓
Action Object
        ↓
Action Data
        ↓
Device Object
        ↓
Capability Matching
        ↓
Action–Device Mapping
        ↓
Device Command
        ↓
Physical Device
        ↓
World Change
        ↓
New Perception
        ↓
Scene Update
        ↓
New Cognition

这里已经出现一个非常清晰的两阶段转换：

                 ICAI
                  │
                  ↓
       Cognition → Action
                  │
                  ↓
             Action Data
                  │
                  ↓
          Device Abstraction
                  │
                  ↓
       Action–Device Mapping
                  │
                  ↓
          Device Command
                  │
                  ↓
           Physical World

因此第192章的核心原则可以定义为：

Action–Device Mapping Principle

ICAI 的 Action 表示认知系统决定执行的行为，而 Device Command 表示具体设备执行该行为所需要的控制指令。二者之间通过 Device Capability 和 Action–Device Mapping 建立转换关系，使同一个认知行为能够根据不同设备的能力、参数和约束生成不同的设备命令，同时保持认知系统与具体硬件控制系统的独立性。