本页聚焦 roboto_imu 的两大核心架构决策：一是通过抽象基类统一所有 IMU 硬件的数据访问契约，二是通过静态工厂方法将具体驱动类型的实例化逻辑与使用者解耦。这种分层设计使得上层应用（无论是 C++ 原生代码还是 Python SDK）始终面向同一套接口编程，而底层协议差异（HiPNUC 私有串口协议、J1939 CAN 协议等）被封装在各自的派生类与传输层中，实现「接口不变、实现可插拔」的扩展路径。

Sources: imu_driver.hpp, imu_driver.cpp

核心设计动机

在机器人系统中，IMU 可能通过串口或 CAN 总线接入，不同厂商的协议帧格式亦不相同。若将协议解析、线程管理、数据缓冲直接耦合在应用代码中，将导致三个问题：其一，更换硬件型号时需侵入式修改业务逻辑；其二，同一物理总线（如 can0）上挂载多颗 IMU 时，接收线程与回调管理难以复用；其三，跨语言绑定（pybind11）需要为每种型号编写重复胶水代码。为此，项目引入三层抽象：最上层是 IMUDriver 通用接口，中间层是按厂商分化的具体驱动（当前为 HipnucIMUDriver），最下层是总线传输抽象（IMUSocketCAN、IMUSerialPort）。三层之间通过组合与继承协作，确保新增传感器型号时，只需新增一个 IMUDriver 派生类并在工厂方法中注册分支即可。

Sources: imu_driver.hpp, hipnuc_imu_driver.hpp

下图为三层抽象的概念关系：

graph TD
    A[应用层 / Python SDK] -->|pybind11| B[抽象接口层 IMUDriver]
    B -->|工厂方法| C[具体驱动层 HipnucIMUDriver]
    C -->|组合| D[传输抽象层<br/>IMUSocketCAN / IMUSerialPort]
    C -->|调用| E[协议解析层<br/>hipnuc_j1939 / hipnuc_dec]
    D -->|系统调用| F[Linux Kernel<br/>SocketCAN / TTY]

抽象基类与工厂方法

IMUDriver 作为抽象基类，定义了所有 IMU 必须暴露的最小数据面：设备 ID、角速度、四元数、线加速度与温度。其中最关键的成员是静态工厂方法 create_imu，它根据字符串参数 imu_type 执行分支创建。当前实现仅支持 "HIPNUC" 类型，但其签名已预留扩展空间。工厂返回 std::shared_ptr<IMUDriver>，这使得调用方在编译期无需包含任何派生类头文件——imu_driver.cpp 中虽包含 hipnuc_imu_driver.hpp，但使用者只需链接 imu 库并包含 imu_driver.hpp 即可。这种「依赖倒置」消除了应用层对 drivers/ 子目录的编译期依赖。

Sources: imu_driver.hpp, imu_driver.cpp

工厂方法的调用时序如下：

sequenceDiagram
    participant Client
    participant IMUDriver
    participant HipnucIMUDriver
    participant Transport

    Client->>IMUDriver: create_imu(id, "can", "can0", "HIPNUC", 0)
    IMUDriver->>HipnucIMUDriver: std::make_shared<...>()
    HipnucIMUDriver->>Transport: get_instance("can0") / open(...)
    Transport-->>HipnucIMUDriver: shared_ptr
    HipnucIMUDriver-->>IMUDriver: shared_ptr
    IMUDriver-->>Client: shared_ptr&lt;IMUDriver&gt;

具体驱动实现：HipnucIMUDriver

HipnucIMUDriver 继承 IMUDriver 后，主要承担两项职责：一是根据 interface_type（"serial" 或 "can"）选择并初始化对应的传输对象；二是在接收回调中完成协议解析与数据更新。构造函数内使用 std::bind 将成员函数 can_rx_cbk / serial_rx_cbk 注册为传输层的回调函数。当底层线程收到原始帧或字节流后，回调内部调用 C 语言编写的协议解析器（hipnuc_j1939_parse_frame、hipnuc_input），并将结果写入受 std::shared_mutex 保护的 sensor_data_ 结构。公开 getter 方法则通过共享锁（std::shared_lock）实现无阻塞并发读。值得强调的是，HipnucIMUDriver 本身不直接管理接收线程生命周期，线程由传输层对象内部持有，这进一步隔离了「协议语义」与「IO 线程语义」。

Sources: hipnuc_imu_driver.hpp, hipnuc_imu_driver.cpp

类结构示意如下：

classDiagram
    class IMUDriver {
        +create_imu(...)$ shared_ptr~IMUDriver~
        +get_imu_id() uint16_t
        +get_ang_vel() vector~float~
        +get_quat() vector~float~
        +get_lin_acc() vector~float~
        +get_temperature() float
    }
    class HipnucIMUDriver {
        +can_rx_cbk(rx_frame)
        +serial_rx_cbk(data, length)
        -sensor_data_ : can_sensor_data_t
        -raw_ : hipnuc_raw_t
    }
    class IMUSocketCAN
    class IMUSerialPort

    IMUDriver <|-- HipnucIMUDriver
    HipnucIMUDriver --> IMUSocketCAN : uses (CAN)
    HipnucIMUDriver --> IMUSerialPort : uses (Serial)

传输层抽象：总线无关设计

为了屏蔽 CAN 与串口的差异，HipnucIMUDriver 并不直接调用 Linux 系统 API，而是依赖两个传输抽象类。IMUSocketCAN 采用单例模式（每个接口名如 can0 仅维护一个实例），内部持有独立的接收线程与回调注册表；IMUSerialPort 则通过静态工厂方法 open() 创建实例，同样内部持有接收线程。两者均向上层暴露回调注册接口：IMUSocketCAN 使用 add_can_callback 并结合 set_key_extractor 实现基于 CAN ID 的多设备路由；IMUSerialPort 使用 set_serial_callback 将字节流整包投递。这种「策略化」的总线选择意味着：若未来新增 Ethernet-UDP 或 SPI 接口，只需在 HipnucIMUDriver 构造函数中增加一个分支并引入新的传输类，而无需改动 IMUDriver 接口或 Python 绑定层。

Sources: socket_can.hpp, serial_port.hpp

构建系统的层次映射

CMake 构建规则严格反映了上述运行时架构的依赖方向。imu_protocol 静态库封装 IMUSocketCAN 与 IMUSerialPort，不依赖任何驱动；hipnuc_imu 库依赖 imu_protocol 与 C 协议解析器；最顶层的 imu 库则聚合 imu_driver.cpp（工厂实现）并链接 hipnuc_imu。这种由底向上的链接顺序确保：协议层 → 驱动层 → 抽象层/工厂层。若后续新增另一家厂商驱动（例如 xsens_imu），只需新建 src/drivers/xsens/ 目录、产出独立静态库，并在根 CMakeLists.txt 中将该库加入 imu 的链接列表即可，现有模块完全隔离。

Sources: CMakeLists.txt, src/drivers/hipnuc/CMakeLists.txt, src/protocol/CMakeLists.txt

跨语言一致性

pybind11 绑定层仅暴露 IMUDriver 基类及其静态工厂方法 create_imu，而不直接暴露 HipnucIMUDriver。Python 用户通过 IMUDriver.create_imu(...) 获取对象后，即可调用 get_quat() 等虚函数。由于 pybind11 的 class_<IMUDriver, std::shared_ptr<IMUDriver>> 声明与 C++ 侧共享智能指针语义一致，Python 垃圾回收与 C++ shared_ptr 引用计数天然协同。这种「基类绑定」策略意味着：即便底层新增十种具体驱动，Python API 也无需任何改动——所有扩展都在 C++ 工厂方法内部消化。

Sources: pybind_module.cpp

设计优势与权衡

下表从扩展性、耦合度与运行时成本三个维度总结当前架构的利弊。

延伸阅读

理解工厂模式与抽象驱动的位置后，建议按以下路径深入：若需了解数据在回调与 getter 之间的并发控制细节，请参阅 传感器数据访问与线程安全；若对 IMUSocketCAN 的单例实现与实时接收线程感兴趣，可阅读 SocketCAN 单例与实时接收线程；若关注串口侧的 UART 线程模型，则查看 串口通信与 UART 接收线程。对于 CMake 构建细节的完整解读，请移步 CMake 构建系统与依赖管理。