📚 课程目录第3章仿真平台选型与架构设计

3. 仿真平台选型与架构设计

无人机集群仿真不是“跑一个模型”那么简单。一个可用的集群仿真系统，通常要同时承载飞控动力学、通信链路、传感器感知、任务规划、编队控制以及环境干扰等多类模型，还要支持多机并发、分布式部署和实时或近实时交互。因此，平台选型与架构设计直接决定了后续场景构建的上限。本节从常用平台对比入手，再讨论分布式架构、实时性约束，最后落到模块划分与接口设计。

一、常用仿真平台对比与选型依据

集群仿真平台大致可分为三类：通用机器人仿真器、飞控专用仿真器、以及自研/轻量级分布式仿真框架。它们并非互相替代，而是常组合使用。

平台	定位	优势	局限	适用场景
Gazebo / Ignition	通用机器人仿真	物理引擎成熟、传感器模型丰富、ROS 生态好	大规模集群时计算开销大、实时性受渲染影响	中小规模集群、感知与避障验证
AirSim	视觉与飞控仿真	虚幻引擎渲染逼真、支持 PX4 接口	资源消耗高、分布式扩展需二次开发	视觉导航、单机或小规模集群
PX4 SITL + jMAVSim/Gazebo	飞控软件在环	与真实飞控代码一致、MAVLink 接口标准	偏单机、集群需多实例管理	飞控逻辑、编队控制算法验证
NS-3 / OMNeT++	网络仿真	通信协议精确、可大规模节点	不含飞控动力学	集群通信、组网、时延分析
自研分布式框架	定制化集群仿真	可裁剪、易扩展、可控实时性	开发成本高、模型需自行积累	大规模集群、特定任务验证

选型时建议按四个维度打分：规模（需要同时仿真的无人机数量）、保真度（动力学/传感器/通信的精度要求）、实时性（是否要求硬实时或软实时）、生态与复用（能否复用现有飞控代码和模型）。例如，验证 50 架无人机的编队保持，若只关心控制律，可选用 PX4 SITL 多实例 + 轻量通信模型；若还要验证视觉避障，则需引入 Gazebo 或 AirSim，但规模要相应压缩。

二、分布式仿真架构

当集群规模超过单机算力上限时，必须把仿真任务拆分到多台计算机或计算节点上。典型的分布式集群仿真架构采用“管理节点 + 仿真节点 + 通信中间件”三层结构。

这种架构的关键在于时间推进策略。常见有两种：一是保守同步，所有节点在每个仿真步长结束后等待最慢节点，保证全局一致，但实时性受最慢节点拖累；二是乐观同步，节点先本地推进，遇到跨节点事件时回滚，适合事件稀疏的场景。集群仿真中，若机间通信频繁，保守同步更稳妥；若各机耦合弱，可放宽同步周期。

三、实时性要求与约束

实时性分为硬实时和软实时。无人机集群仿真中，飞控内环（姿态控制）通常要求 1 kHz 以上的更新率，外环（位置/编队）约 50–200 Hz，通信链路仿真可能只需 10–100 Hz。若仿真步长 Δt 取 1 ms，则单步内必须完成所有模型计算和状态交换，否则会出现“仿真时间落后于真实时间”的累积漂移。

实际工程中常用实时因子（Real-Time Factor, RTF）衡量：RTF = 仿真时间 / 墙钟时间。RTF ≥ 1 表示满足实时，RTF < 1 表示仿真慢于真实。例如，仿真 60 秒场景耗时 90 秒，RTF ≈ 0.67，说明需要降低模型精度或增加计算节点。建议在架构设计阶段就预留降级策略：当 RTF 低于阈值时，自动降低传感器渲染频率或简化气动模型，而不是直接崩溃。

实时性设计原则：先保证控制回路的时间确定性，再优化感知与渲染；把非实时任务（如日志、可视化）放到独立线程或独立节点，避免阻塞主仿真循环。

四、模块划分与接口设计

模块划分的目标是“高内聚、低耦合”，让每个模块可以独立替换和测试。推荐按功能划分为六个核心模块：

飞控模块：运行 PX4/ArduPilot 的 SITL 实例，输出电机指令和状态估计。
动力学模块：根据电机指令和风扰计算六自由度位姿，可用简化模型或高保真模型。
通信模块：模拟 MAVLink/自组网链路的时延、丢包和带宽限制。
感知模块：生成 GPS、IMU、视觉等传感器数据，可注入噪声和故障。
任务/编队模块：执行航点规划、编队保持、避障决策等上层逻辑。
环境模块：提供地形、障碍物、风场和电磁干扰等场景要素。

接口设计上，建议统一采用发布/订阅模式，消息格式尽量对齐真实系统的 MAVLink 或 ROS2 消息。例如，飞控模块以 250 Hz 发布 vehicle_state（位置、速度、姿态），通信模块订阅后按链路模型转发给其他节点；感知模块以 100 Hz 发布 imu_data 和 gps_fix。所有消息带时间戳和序列号，便于回放和故障定位。

# 示例：模块间消息定义（伪代码）
topic: /uav/{id}/state
  rate: 250 Hz
  fields:
    timestamp: uint64   # 仿真时间，单位 ns
    position: float32[3]  # NED 坐标系，单位 m
    velocity: float32[3]  # m/s
    attitude: float32[4]  # 四元数 w,x,y,z
    armed: bool

topic: /uav/{id}/cmd
  rate: 50 Hz
  fields:
    timestamp: uint64
    target_pos: float32[3]
    target_yaw: float32

接口一旦确定，各模块可以并行开发：飞控组用 SITL 验证控制律，通信组用 NS-3 验证链路模型，最后通过中间件联调。这种“接口先行”的做法能显著降低集成风险。需要注意的是，坐标系约定必须全文统一：本文默认采用 NED（北-东-地）坐标系，姿态用四元数表示，角度单位为弧度。若某模块使用 ENU 或欧拉角，必须在接口文档中显式标注转换关系。

常见陷阱：多个仿真节点各自维护全局时钟，导致状态交换时时间戳不一致。务必由管理节点统一分发仿真时间，各节点只做本地插值，不自行推进全局时钟。

综上，平台选型要匹配规模与保真度需求，分布式架构要解决时间同步与通信瓶颈，实时性要靠 RTF 监控和降级策略兜底，模块与接口设计则决定了系统能否持续演进。这四者相互制约，需要在设计初期就通盘权衡，而不是等到仿真跑不动时再回头修改。