ArduPilot SITL 下的 CAN/DroneCAN 外设仿真与调试指南quad-can 与 quadplane-can 完整解析【免费下载链接】ardupilotArduPlane, ArduCopter, ArduRover, ArduSub source项目地址: https://gitcode.com/GitHub_Trending/ar/ardupilot本篇技术指南围绕 ArduPilot 官方文档中“Testing under SITL”一节展开系统讲解如何通过sim_vehicle.py在软件在环SITL仿真环境中启动支持 DroneCAN 外设的模拟载具quad-can四旋翼、quadplane-can垂起固定翼并结合AP_CANManager库源码、默认参数文件与自动测试用例深入剖析 CAN 总线参数CAN_P1_*、CAN_D1_*、外设固件AP_Periph配置与调试手段。读完本文你将能够独立搭建一套可复现的 CAN 外设仿真环境并理解底层参数如何被解析与生效。1. 关联文档要点在 SITL 中启动 DroneCAN 仿真载具原文档libraries/AP_CANManager/README.md给出了最核心的两条启动命令这是本文的起点四轴垂直起降机quadplanesim_vehicle.py -f quadplane-can四旋翼quadcoptersim_vehicle.py -f quad-can其中sim_vehicle.py位于 Tools/autotest/sim_vehicle.py-f--frame选项用于选择仿真机型帧frame。文档还指出SITL 仿真系统支持种类广泛的 DroneCAN 外设——这意味着你可以在没有真实硬件的情况下验证 CAN 总线上的电调ESC、舵机、GPS、气压计、测距仪等外设的通信与飞控逻辑。需要说明的是上述启动方式依赖Tools/autotest/pysim/vehicleinfo.json中预定义的 frame 条目若想用真实硬件则需走 Tools/AP_Periph/README.md 描述的烧录流程其第 116、118 行给出了与本文档完全一致的两条命令说明这两条命令同时适用于 SITL 主固件与 AP_Periph 外设固件两个场景。2. 帧定义剖析vehicleinfo.json 如何串联主固件与外设固件sim_vehicle.py -f quad-can能一键启动关键在于 Tools/autotest/pysim/vehicleinfo.json 中约 L282-L292、L442 起对这两个 frame 的定义quad-can: { waf_target: bin/arducopter, default_params_filename: [ default_params/copter.parm, default_params/quad-can.parm ], periph_params_filename: [ default_params/periph.parm, default_params/quad-periph.parm ] }quadplane-can的定义结构相同只是default_params_filename换成quadplane-can.parm、periph_params_filename换成quadplane-periph.parm。从这份 JSON 可以确认三个关键事实主固件是 ArduCopterwaf_target均为bin/arducopter即 CAN 仿真场景复用四旋翼/垂起飞控固件作为“飞行大脑”。双进程架构SITL 会同时启动主飞控bin/arducopter与一个CAN 外设仿真进程参数来自periph_params_filename二者通过仿真 CAN 总线通信——这正好对应真实系统中“飞控 AP_Periph 外设固件”的部署形态。vehicleinfo_schema.mdTools/autotest/pysim/vehicleinfo_schema.md将该字段明确注释为 “Default parameter files for the CAN peripheral side of CAN-enabled simulations”。参数分两侧装载主固件读quad-can.parm/quadplane-can.parm外设侧读periph.parmquad-periph.parm/quadplane-periph.parm两侧通过CAN_P1_*/CAN_D1_*等参数协调。2.1 主固件侧默认参数quad-can.parm / quadplane-can.parmTools/autotest/default_params/quad-can.parm 内容CAN_P1_DRIVER 1 CAN_D1_UC_ESC_BM 0x0F SIM_CAN_SRV_MSK 0xFf SIM_VIB_MOT_MAX 270 GPS1_TYPE 9 RNGFND1_TYPE 24 RNGFND1_MAX 110.00 BATT_MONITOR 8Tools/autotest/default_params/quadplane-can.parm 内容CAN_P1_DRIVER 1 CAN_D1_UC_ESC_BM 0xF0 CAN_D1_UC_ESC_OF 4 CAN_D1_UC_SRV_BM 0x0F CAN_D1_UC_OPTION 16 SIM_CAN_SRV_MSK 0xfff SIM_VIB_MOT_MAX 270 GPS1_TYPE 9 ARSPD_TYPE 8 RNGFND1_TYPE 24 RNGFND1_MAX 110.00 RNGFND_LANDING 1 BATT_MONITOR 8其中CAN_P1_DRIVER 1把物理 CAN 接口 1P1绑定到第 1 个虚拟驱动CAN_D1_UC_*属于 DroneCAN 驱动UC_ 子组的参数。ESC_BMESC 位掩码与SRV_BM伺服位掩码将 CAN 外设上的通道映射到电调/舵机ESC_OF是电调起始偏移OPTION为 DroneCAN 驱动选项——从数值组合可以推断quadplane 场景把高 4 路通道映射为电调0xF0 偏移 4、低 4 路映射为舵面0x0F而 quad 场景则把低 4 路全部用作电调0x0FSIM_CAN_SRV_MSKSITL 仿真外设侧启用的伺服输出掩码quadplane 为0xfff覆盖 8 路输出以上GPS1_TYPE 9、RNGFND1_TYPE 24、ARSPD_TYPE 8、BATT_MONITOR 8等将 GPS/测距仪/空速计/电池监控器指向 DroneCANUAVCAN类型即这些传感器全部来自仿真 CAN 外设RNGFND_LANDING 1启用测距仪辅助着陆仅 quadplane。2.2 外设侧默认参数periph.parm 系列Tools/autotest/default_params/periph.parm 是所有 CAN 外设仿真的基础它把传感器指向仿真外设并默认关闭输出GPS1_TYPE 1 COMPASS_ENABLE 1 BARO_ENABLE 1 ARSPD_TYPE 100 RNGFND1_TYPE 100 RNGFND1_MAX 120.00 BATT_MONITOR 16 BATT_I2C_BUS 2 OUT1_FUNCTION -1 ... OUT8_FUNCTION -1 SIM_ADSB_COUNT 4 ADSB_PORT 2随后 quad-periph.parm 将 4 路输出OUT1_FUNCTION 33..36即电机 1-4映射为电调SIM_CAN_SRV_MSK 0x0fquadplane-periph.parm 则把前 4 路设为舵面OUT1_FUNCTION 51..54、后 4 路设为电调OUT5_FUNCTION 33..36带 1000/2000 的 PPM 限幅SIM_CAN_SRV_MSK 0xff。这正与主固件侧CAN_D1_UC_ESC_BM/CAN_D1_UC_SRV_BM的掩码设定一一对应——两侧配置必须匹配仿真才能正确驱动。3. 底层支撑AP_CANManager 的参数体系与初始化流程启动命令背后的核心库是 AP_CANManager。它作为 CAN 协议栈的“管理器”单例负责分配物理 CAN 接口HAL 层HAL_CANIface、按参数创建对应的协议驱动并完成注册。3.1 两级参数组结构从 AP_CANManager.cpp 的var_info可以看出参数采用两级分组接口级参数P1_、P2_、P3_取决于HAL_NUM_CAN_IFACES定义在 AP_CANIfaceParams.cpp每个物理接口包含CAN_Pn_DRIVER绑定到第几个虚拟驱动0 表示禁用1/2/3 对应第一/二/三个驱动修改需重启CAN_Pn_BITRATE经典 CAN 波特率范围 10000~1000000默认 1 MbpsCAN_Pn_FDBITRATECAN-FD 数据段波特率1M/2M/4M/5M/8M仅支持 CAN-FD 的板卡出现CAN_Pn_OPTIONS接口级位掩码选项bit0 为LogAllFrames记录全部 CAN 帧到日志。驱动级参数D1_、D2_、D3_取决于HAL_MAX_CAN_PROTOCOL_DRIVERS定义在 AP_CANManager_CANDriver_Params.cpp每个虚拟驱动包含CAN_Dn_PROTOCOL该驱动使用的协议。可选值来自 AP_CAN.h 的AP_CAN::Protocol枚举0:Disabled, 1:DroneCAN, 4:PiccoloCAN, 6:EFI_NWPMU, 7:USD1, 8:KDECAN, 10:Scripting, 11:Benewake, 12:Scripting2, 13:TOFSenseP, 14:RadarCAN默认 DroneCAN修改需重启CAN_Dn_PROTOCOL2辅助的 11 位地址协议7:USD1, 10:Scripting, 11:Benewake, 12:Scripting2, 13:TOFSenseP, 14:RadarCAN可与 29 位地址主协议同线复用CAN_Dn_UC_*当协议为 DroneCAN 时出现的子参数组在AP_DroneCAN.cpp中定义如CAN_D1_UC_ESC_BM、CAN_D1_UC_ESC_OF、CAN_D1_UC_SRV_BM、CAN_D1_UC_OPTIONCAN_Dn_PC_*当协议为 PiccoloCAN 时的子参数组。3.2 init() 的驱动创建链路AP_CANManager::init() 的执行逻辑与上文的参数一一对应遍历所有物理 CAN 接口读取其绑定的驱动编号_interfaces[i]._driver_number若 HAL 中该接口尚未分配则NEW_NOTHROW HAL_CANIface(i)创建底层接口并以_bitrate/_fdbitrate*1000000调用init()通过switch (drv_type[drv_num])按CAN_Dn_PROTOCOL创建驱动对象——DroneCAN 分支创建AP_DroneCANPiccoloCAN 分支创建AP_PiccoloCAN其余协议走default: continue将接口挂载到驱动add_interface并调用_drivers[drv_num]-init(drv_num)若CAN_Dn_PROTOCOL未在AP_CANManager中注册的驱动则CANSensor类传感器可通过register_11bit_driverAP_CANManager.cpp按PROTOCOL2注册到对应驱动。这也解释了为什么quad-can.parm中只需一行CAN_P1_DRIVER 1CAN_D1_PROTOCOL默认即为 DroneCAN接口 1 绑定到驱动 1 后DroneCAN 栈被自动实例化并完成初始化。4. 调试手段日志、SLCAN 桥接与自动测试4.1 CAN 日志LOGLEVEL 与 LogAllFramesAP_CANManager提供CAN_LOGLEVEL参数0~4不记录 / 仅错误 / 警告及以下 / 信息及以下 / 全部用于记录接口初始化与调试信息。若想抓取总线上的原始 CAN 帧可将某接口的CAN_Pn_OPTIONS置位LogAllFrames此时 check_logging_enable() 会在 IO 进程周期性地为对应接口注册帧回调由 can_logging_callback() 写入日志——CAN-FD 帧记录为CAFD消息经典 CAN 帧记录为CANF消息均含总线号、帧 ID、DLC 与完整数据载荷可用于离线分析总线流量。4.2 SLCAN 桥接无需硬件的总线观测AP_SLCANIface.cpp 定义了一组CAN_SLCAN_*参数把某个 CAN 接口“桥接”到串口用 SLCAN 文本协议在终端里收发 CAN 帧CAN_SLCAN_CPORT要路由到 SLCAN 的 CAN 接口编号0 禁用 / 1、2 对应第一、二接口需重启CAN_SLCAN_SERNUM使用的串口编号-1 表示不使用临时串口该参数会在重启或超时后自动复位CAN_SLCAN_TIMOUT无活动多少秒后切回原驱动0~127 秒CAN_SLCAN_SDELAY设置 SERNUM 后延迟多少秒再启动 SLCAN默认 1 秒。该桥接在init()中通过_slcan_interface.init_passthrough(i)判断并替换默认 ifaceAP_CANManager.cpp因此它同样适用于 SITL是排查仿真 CAN 帧收发问题的轻量手段。4.3 自动测试中的使用quad-can与quadplane-can不仅是手动仿真帧也直接用于仓库的回归测试在 Tools/autotest/arducopter.py 中quad-can被标记为 “needs CAN periph”在 Tools/autotest/arduplane.py 中quadplane-can同样作为需要 CAN 外设的测试帧出现并在 Tools/autotest/quadplane.py 中通过restart_SITL_frame(quadplane-can, ...)在用例中途热重启到该帧。这意味着运行Tools/autotest/autotest.py时这些帧对应的 CAN 外设仿真链路会被反复验证你手动复现的正是 CI 同款环境。5. 实战小结一条命令背后的完整链路将本文内容串起来sim_vehicle.py -f quadplane-can实际完成了以下工作sim_vehicle.py读取 vehicleinfo.json 的quadplane-can条目确定主固件为bin/arducopter为主飞控装载copter.parm与 quadplane-can.parmCAN_P1_DRIVER 1启用 CAN 接口并绑定 DroneCAN 驱动CAN_D1_UC_*完成电调/舵面通道映射传感器类型指向 DroneCAN为仿真外设装载 periph.parm 与 quadplane-periph.parm在 CAN 总线上模拟出 4 路舵面 4 路电调及 GPS/气压计/测距仪等外设飞控与 AP_Periph 两侧在仿真 CAN 总线上建立 DroneCAN 通信实现与真实无人机一致的外设发现、参数读取与输出控制逻辑。如需调整仿真场景例如改用其他传感器类型、改变电调映射或观察 CAN 原始帧可直接在上述.parm文件基础上追加CAN_Pn_*、CAN_Dn_*、CAN_SLCAN_*与CAN_LOGLEVEL参数或参考 AP_CANManager 的参数定义自行组合再通过sim_vehicle.py提供的--add-param-file等机制注入参数后重启验证。【免费下载链接】ardupilotArduPlane, ArduCopter, ArduRover, ArduSub source项目地址: https://gitcode.com/GitHub_Trending/ar/ardupilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ArduPilot SITL 下的 CAN/DroneCAN 外设仿真与调试指南quad-can 与 quadplane-can 完整解析【免费下载链接】ardupilotArduPlane, ArduCopter, ArduRover, ArduSub source项目地址: https://gitcode.com/GitHub_Trending/ar/ardupilot本篇技术指南围绕 ArduPilot 官方文档中“Testing under SITL”一节展开系统讲解如何通过sim_vehicle.py在软件在环SITL仿真环境中启动支持 DroneCAN 外设的模拟载具quad-can四旋翼、quadplane-can垂起固定翼并结合AP_CANManager库源码、默认参数文件与自动测试用例深入剖析 CAN 总线参数CAN_P1_*、CAN_D1_*、外设固件AP_Periph配置与调试手段。读完本文你将能够独立搭建一套可复现的 CAN 外设仿真环境并理解底层参数如何被解析与生效。1. 关联文档要点在 SITL 中启动 DroneCAN 仿真载具原文档libraries/AP_CANManager/README.md给出了最核心的两条启动命令这是本文的起点四轴垂直起降机quadplanesim_vehicle.py -f quadplane-can四旋翼quadcoptersim_vehicle.py -f quad-can其中sim_vehicle.py位于 Tools/autotest/sim_vehicle.py-f--frame选项用于选择仿真机型帧frame。文档还指出SITL 仿真系统支持种类广泛的 DroneCAN 外设——这意味着你可以在没有真实硬件的情况下验证 CAN 总线上的电调ESC、舵机、GPS、气压计、测距仪等外设的通信与飞控逻辑。需要说明的是上述启动方式依赖Tools/autotest/pysim/vehicleinfo.json中预定义的 frame 条目若想用真实硬件则需走 Tools/AP_Periph/README.md 描述的烧录流程其第 116、118 行给出了与本文档完全一致的两条命令说明这两条命令同时适用于 SITL 主固件与 AP_Periph 外设固件两个场景。2. 帧定义剖析vehicleinfo.json 如何串联主固件与外设固件sim_vehicle.py -f quad-can能一键启动关键在于 Tools/autotest/pysim/vehicleinfo.json 中约 L282-L292、L442 起对这两个 frame 的定义quad-can: { waf_target: bin/arducopter, default_params_filename: [ default_params/copter.parm, default_params/quad-can.parm ], periph_params_filename: [ default_params/periph.parm, default_params/quad-periph.parm ] }quadplane-can的定义结构相同只是default_params_filename换成quadplane-can.parm、periph_params_filename换成quadplane-periph.parm。从这份 JSON 可以确认三个关键事实主固件是 ArduCopterwaf_target均为bin/arducopter即 CAN 仿真场景复用四旋翼/垂起飞控固件作为“飞行大脑”。双进程架构SITL 会同时启动主飞控bin/arducopter与一个CAN 外设仿真进程参数来自periph_params_filename二者通过仿真 CAN 总线通信——这正好对应真实系统中“飞控 AP_Periph 外设固件”的部署形态。vehicleinfo_schema.mdTools/autotest/pysim/vehicleinfo_schema.md将该字段明确注释为 “Default parameter files for the CAN peripheral side of CAN-enabled simulations”。参数分两侧装载主固件读quad-can.parm/quadplane-can.parm外设侧读periph.parmquad-periph.parm/quadplane-periph.parm两侧通过CAN_P1_*/CAN_D1_*等参数协调。2.1 主固件侧默认参数quad-can.parm / quadplane-can.parmTools/autotest/default_params/quad-can.parm 内容CAN_P1_DRIVER 1 CAN_D1_UC_ESC_BM 0x0F SIM_CAN_SRV_MSK 0xFf SIM_VIB_MOT_MAX 270 GPS1_TYPE 9 RNGFND1_TYPE 24 RNGFND1_MAX 110.00 BATT_MONITOR 8Tools/autotest/default_params/quadplane-can.parm 内容CAN_P1_DRIVER 1 CAN_D1_UC_ESC_BM 0xF0 CAN_D1_UC_ESC_OF 4 CAN_D1_UC_SRV_BM 0x0F CAN_D1_UC_OPTION 16 SIM_CAN_SRV_MSK 0xfff SIM_VIB_MOT_MAX 270 GPS1_TYPE 9 ARSPD_TYPE 8 RNGFND1_TYPE 24 RNGFND1_MAX 110.00 RNGFND_LANDING 1 BATT_MONITOR 8其中CAN_P1_DRIVER 1把物理 CAN 接口 1P1绑定到第 1 个虚拟驱动CAN_D1_UC_*属于 DroneCAN 驱动UC_ 子组的参数。ESC_BMESC 位掩码与SRV_BM伺服位掩码将 CAN 外设上的通道映射到电调/舵机ESC_OF是电调起始偏移OPTION为 DroneCAN 驱动选项——从数值组合可以推断quadplane 场景把高 4 路通道映射为电调0xF0 偏移 4、低 4 路映射为舵面0x0F而 quad 场景则把低 4 路全部用作电调0x0FSIM_CAN_SRV_MSKSITL 仿真外设侧启用的伺服输出掩码quadplane 为0xfff覆盖 8 路输出以上GPS1_TYPE 9、RNGFND1_TYPE 24、ARSPD_TYPE 8、BATT_MONITOR 8等将 GPS/测距仪/空速计/电池监控器指向 DroneCANUAVCAN类型即这些传感器全部来自仿真 CAN 外设RNGFND_LANDING 1启用测距仪辅助着陆仅 quadplane。2.2 外设侧默认参数periph.parm 系列Tools/autotest/default_params/periph.parm 是所有 CAN 外设仿真的基础它把传感器指向仿真外设并默认关闭输出GPS1_TYPE 1 COMPASS_ENABLE 1 BARO_ENABLE 1 ARSPD_TYPE 100 RNGFND1_TYPE 100 RNGFND1_MAX 120.00 BATT_MONITOR 16 BATT_I2C_BUS 2 OUT1_FUNCTION -1 ... OUT8_FUNCTION -1 SIM_ADSB_COUNT 4 ADSB_PORT 2随后 quad-periph.parm 将 4 路输出OUT1_FUNCTION 33..36即电机 1-4映射为电调SIM_CAN_SRV_MSK 0x0fquadplane-periph.parm 则把前 4 路设为舵面OUT1_FUNCTION 51..54、后 4 路设为电调OUT5_FUNCTION 33..36带 1000/2000 的 PPM 限幅SIM_CAN_SRV_MSK 0xff。这正与主固件侧CAN_D1_UC_ESC_BM/CAN_D1_UC_SRV_BM的掩码设定一一对应——两侧配置必须匹配仿真才能正确驱动。3. 底层支撑AP_CANManager 的参数体系与初始化流程启动命令背后的核心库是 AP_CANManager。它作为 CAN 协议栈的“管理器”单例负责分配物理 CAN 接口HAL 层HAL_CANIface、按参数创建对应的协议驱动并完成注册。3.1 两级参数组结构从 AP_CANManager.cpp 的var_info可以看出参数采用两级分组接口级参数P1_、P2_、P3_取决于HAL_NUM_CAN_IFACES定义在 AP_CANIfaceParams.cpp每个物理接口包含CAN_Pn_DRIVER绑定到第几个虚拟驱动0 表示禁用1/2/3 对应第一/二/三个驱动修改需重启CAN_Pn_BITRATE经典 CAN 波特率范围 10000~1000000默认 1 MbpsCAN_Pn_FDBITRATECAN-FD 数据段波特率1M/2M/4M/5M/8M仅支持 CAN-FD 的板卡出现CAN_Pn_OPTIONS接口级位掩码选项bit0 为LogAllFrames记录全部 CAN 帧到日志。驱动级参数D1_、D2_、D3_取决于HAL_MAX_CAN_PROTOCOL_DRIVERS定义在 AP_CANManager_CANDriver_Params.cpp每个虚拟驱动包含CAN_Dn_PROTOCOL该驱动使用的协议。可选值来自 AP_CAN.h 的AP_CAN::Protocol枚举0:Disabled, 1:DroneCAN, 4:PiccoloCAN, 6:EFI_NWPMU, 7:USD1, 8:KDECAN, 10:Scripting, 11:Benewake, 12:Scripting2, 13:TOFSenseP, 14:RadarCAN默认 DroneCAN修改需重启CAN_Dn_PROTOCOL2辅助的 11 位地址协议7:USD1, 10:Scripting, 11:Benewake, 12:Scripting2, 13:TOFSenseP, 14:RadarCAN可与 29 位地址主协议同线复用CAN_Dn_UC_*当协议为 DroneCAN 时出现的子参数组在AP_DroneCAN.cpp中定义如CAN_D1_UC_ESC_BM、CAN_D1_UC_ESC_OF、CAN_D1_UC_SRV_BM、CAN_D1_UC_OPTIONCAN_Dn_PC_*当协议为 PiccoloCAN 时的子参数组。3.2 init() 的驱动创建链路AP_CANManager::init() 的执行逻辑与上文的参数一一对应遍历所有物理 CAN 接口读取其绑定的驱动编号_interfaces[i]._driver_number若 HAL 中该接口尚未分配则NEW_NOTHROW HAL_CANIface(i)创建底层接口并以_bitrate/_fdbitrate*1000000调用init()通过switch (drv_type[drv_num])按CAN_Dn_PROTOCOL创建驱动对象——DroneCAN 分支创建AP_DroneCANPiccoloCAN 分支创建AP_PiccoloCAN其余协议走default: continue将接口挂载到驱动add_interface并调用_drivers[drv_num]-init(drv_num)若CAN_Dn_PROTOCOL未在AP_CANManager中注册的驱动则CANSensor类传感器可通过register_11bit_driverAP_CANManager.cpp按PROTOCOL2注册到对应驱动。这也解释了为什么quad-can.parm中只需一行CAN_P1_DRIVER 1CAN_D1_PROTOCOL默认即为 DroneCAN接口 1 绑定到驱动 1 后DroneCAN 栈被自动实例化并完成初始化。4. 调试手段日志、SLCAN 桥接与自动测试4.1 CAN 日志LOGLEVEL 与 LogAllFramesAP_CANManager提供CAN_LOGLEVEL参数0~4不记录 / 仅错误 / 警告及以下 / 信息及以下 / 全部用于记录接口初始化与调试信息。若想抓取总线上的原始 CAN 帧可将某接口的CAN_Pn_OPTIONS置位LogAllFrames此时 check_logging_enable() 会在 IO 进程周期性地为对应接口注册帧回调由 can_logging_callback() 写入日志——CAN-FD 帧记录为CAFD消息经典 CAN 帧记录为CANF消息均含总线号、帧 ID、DLC 与完整数据载荷可用于离线分析总线流量。4.2 SLCAN 桥接无需硬件的总线观测AP_SLCANIface.cpp 定义了一组CAN_SLCAN_*参数把某个 CAN 接口“桥接”到串口用 SLCAN 文本协议在终端里收发 CAN 帧CAN_SLCAN_CPORT要路由到 SLCAN 的 CAN 接口编号0 禁用 / 1、2 对应第一、二接口需重启CAN_SLCAN_SERNUM使用的串口编号-1 表示不使用临时串口该参数会在重启或超时后自动复位CAN_SLCAN_TIMOUT无活动多少秒后切回原驱动0~127 秒CAN_SLCAN_SDELAY设置 SERNUM 后延迟多少秒再启动 SLCAN默认 1 秒。该桥接在init()中通过_slcan_interface.init_passthrough(i)判断并替换默认 ifaceAP_CANManager.cpp因此它同样适用于 SITL是排查仿真 CAN 帧收发问题的轻量手段。4.3 自动测试中的使用quad-can与quadplane-can不仅是手动仿真帧也直接用于仓库的回归测试在 Tools/autotest/arducopter.py 中quad-can被标记为 “needs CAN periph”在 Tools/autotest/arduplane.py 中quadplane-can同样作为需要 CAN 外设的测试帧出现并在 Tools/autotest/quadplane.py 中通过restart_SITL_frame(quadplane-can, ...)在用例中途热重启到该帧。这意味着运行Tools/autotest/autotest.py时这些帧对应的 CAN 外设仿真链路会被反复验证你手动复现的正是 CI 同款环境。5. 实战小结一条命令背后的完整链路将本文内容串起来sim_vehicle.py -f quadplane-can实际完成了以下工作sim_vehicle.py读取 vehicleinfo.json 的quadplane-can条目确定主固件为bin/arducopter为主飞控装载copter.parm与 quadplane-can.parmCAN_P1_DRIVER 1启用 CAN 接口并绑定 DroneCAN 驱动CAN_D1_UC_*完成电调/舵面通道映射传感器类型指向 DroneCAN为仿真外设装载 periph.parm 与 quadplane-periph.parm在 CAN 总线上模拟出 4 路舵面 4 路电调及 GPS/气压计/测距仪等外设飞控与 AP_Periph 两侧在仿真 CAN 总线上建立 DroneCAN 通信实现与真实无人机一致的外设发现、参数读取与输出控制逻辑。如需调整仿真场景例如改用其他传感器类型、改变电调映射或观察 CAN 原始帧可直接在上述.parm文件基础上追加CAN_Pn_*、CAN_Dn_*、CAN_SLCAN_*与CAN_LOGLEVEL参数或参考 AP_CANManager 的参数定义自行组合再通过sim_vehicle.py提供的--add-param-file等机制注入参数后重启验证。【免费下载链接】ardupilotArduPlane, ArduCopter, ArduRover, ArduSub source项目地址: https://gitcode.com/GitHub_Trending/ar/ardupilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
