简介本资源是一套面向无人机开发初学者与竞赛备赛者的实践型学习项目聚焦高分无人飞行器智能感知技术竞赛场景基于DJI Mobile SDK构建Android/iOS手持端控制应用覆盖飞行控制、实时图传、航点规划、视觉SLAM与避障算法集成等核心能力。压缩包共217个文件含89个XML布局与配置文件、35个ZBAK备份文件、35个Java源码及Native SO库用于图像处理与底层通信、9个H.264视频流样例及PNG/JPG资源素材整体大小为11.71MB结构完整包含gradle构建脚本、参数配置文件flyc_param_infos、gimbal_param_infos及Git版本管理痕迹便于理解工程组织逻辑。已有108人学习下载资源提供可运行的主控框架、飞行状态监控模块、任务执行流程代码及典型智能飞行模式实现辅以README说明与目录注释有助于快速掌握SDK集成要点、调试技巧与安全机制设计是深入理解无人机自主感知与远程控制协同开发的优质入门范例。 前阵子有朋友问我大疆自己的App已经做得那么成熟为什么还要花力气开发一个手持端控制应用这个问题我几乎每年都会被问一次。实际原因是DJI Fly和DJI Pilot这一类通用App功能是围着大众用户和通用场景设计的到你真正面对一个具体作业任务时就会觉得它们“差一点”。农业植保要按田块边界自动生成喷洒航线电力巡检要在同一个屏幕上叠加杆塔缺陷识别结果应急救援需要把图传画面同时推送给后台指挥席。这些需求靠官方App改不出来只能基于DJI Mobile SDK自己开发一套手持端控制应用。这篇文章不打算从“什么是DJI Mobile SDK”开始念官方文档而是站在一个已经做过几套地面站App的开发者角度把这套方案从环境搭建、核心控制链路、地面站功能、避障数据接入到和机载平台配合的完整思路讲清楚。适合两类人看一类是准备接无人机项目的研发团队另一类是已经有初步MSDK经验、想避开常见坑的开发者。1. 自研手持端App真正的驱动力是任务不是App本身1.1 官方App与你的实际任务之间的距离很多人一开始会陷入“我到底要不要用MSDK”的纠结。先想清楚一个事情你的项目里无人机是产品还是只是业务系统里的一个执行单元。如果只是偶尔飞一次拍个照那直接用DJI Fly、DJI Pilot就好了。但如果你要做的是一个面向特定行业的作业平台比如植保队管理系统、园区巡检系统、电网缺陷排查工具那官方App完全不够用。原因不是它不好用而是它无法和你的业务数据打通。你需要在同一个界面里看到“这架无人机正在执行第3号杆塔的精细化巡检当前发现绝缘子发热点”同时还能让现场操作人员一键暂停、调整航点、回传缺陷照片。这个所谓“手持端控制应用”本质上是一个嵌入了飞行控制能力的业务APP。大疆官方提供了几套SDK给开发者Mobile SDK只是其中之一。把这套东西用在什么位置决定了你的整体架构。一个常见误区是所有功能都往Mobile SDK里塞连实时避障计算也想在手机上跑这在小飞机上基本行不通。后面我会详细讲这个边界问题。1.2 DJI Mobile SDK在整个大疆生态里的位置先简单梳理一下大疆面向开发者的几套东西这能避免你文档看混。SDK/平台运行位置主要职责典型场景Mobile SDK (MSDK)Android/iOS手机或平板连接飞机、图传、飞控状态、虚拟摇杆、航线任务、相机控制手持遥控端App、地面站AppUX SDK基于MSDK的UI组件库提供通用控件和页面加快界面开发不想从零写控件的AppOSDK (机载SDK)机载计算平台自主飞行逻辑、高频传感器数据、实时控制科研、自主巡检、AI实时处理PSDK (负载SDK)挂在飞机上的负载/机载计算单元第三方云台、相机、投掷器、多光谱载荷、机载处理行业负载开发、机载算力扩展Cloud API云端云平台接入、直播推流、云端调度多机协同管理平台你去开发手持端控制应用核心用的是MSDK有时候会用到UX SDK来省界面工作量但项目计划里通常不会把OSDK/PSDK写进去。不过到了实际交付阶段你会发现很多需求绕不开机载端这就是我最后一章要讲的内容。1.3 什么人适合走MSDK这条路线MSDK开发不是“会飞无人机就能写”。我记得刚开始带团队的时候招人时最怕遇到两类第一类是完全不懂无人机以为MSDK是类似调蓝牙手柄那种简单API第二类是飞控理论很熟但连Android的Activity生命周期都搞不定。实际上你需要同时具备Android或iOS开发经验、基本的GIS/地图知识、对飞行安全和飞控保护逻辑的理解还要有排查无线链路问题的耐心。如果你的项目满足下面任意一条走MSDK基本是必要的需要把无人机数据和你们的业务后台打通需要自定义航线生成和作业流程需要面向非专业飞手做定制交互需要控制多台不同型号的飞机需要在飞行中实时展示第三方传感器数据。如果只是临时做一次航拍或者想做一个大而全的“仿DJI Go”的通用App那我劝你谨慎。MSDK的维护成本和真机测试成本都不低而且大疆每年都在调整SDK版本和固件协议做通用App很容易变成给SDK打工。2. 开发环境与项目初始化认证和适配是最大的隐形门槛2.1 注册、App Key和设备绑定那点事MSDK的初始化流程不算复杂但坑特别多。第一个坑就是App Key。你需要去DJI开发者平台注册账号、创建应用拿到一个App Key。这个Key不是随便填进去就完事了它和你的应用包名Android、Bundle IdentifieriOS是绑定的。如果你在开发者平台填的包名和代码里实际用的一致才能通过鉴权。我们曾经在iOS项目上因为Bundle ID里的大小写问题卡了一整个下午初始化回调一直报错后来把签名和Bundle ID逐字符比对才找出来。不同MSDK版本对App Key的要求不完全一样。早期版本对包名、签名校验很严格新版本增加了更多联网校验逻辑。所以当你集成到一半发现registerApp回调失败先别急着怀疑飞机先查三件事网络能不能连通大疆的鉴权服务器、App Key字符串有没有复制错、包名和开发者平台是否完全一致。还有一点容易忽略测试用的飞机和遥控器最好在DJI开发者平台完成设备激活和绑定。有些机型在未绑定开发者账号时SDK无法获取完整控制权限。国内调这个环境时最好提前把飞行器和遥控器的固件升级到官方最新版否则新版本MSDK和旧固件协议对不上也会导致初始化失败。2.2 Android/iOS权限、SDK版本和机型适配的完整清单MSDK不是加个依赖就能跑权限配置是第一个让新手头皮发麻的地方。以Android为例除了常规的网络权限还需要蓝牙权限、定位权限、USB设备权限部分机型还需要读取外部存储权限来写日志。Android 6以上要动态申请定位权限Android 10之后对USB外设的访问方式也有调整很多原生USB连接问题都出在这个权限模型变化上。iOS这边比较容易踩的是“本地网络”权限。如果你在做Pilot类的App手机会连接遥控器Wi-Fi或使用局域网通信iOS会弹“允许App访问本地网络”很多人直接点了拒绝图传和命令链路就废了。另外iOS的蓝牙权限也要申请别只写NSBluetoothAlwaysUsageDescription旧的NSBluetoothPeripheralUsageDescription在某些基础库版本里也需要。MSDK版本选择上我的建议是新项目直接选5.x不要再从4.x起步。5.x的API命名和架构更清晰4.x虽然网上资料多但很多接口已经废弃后面想升级成本会很大。另外要注意的是MSDK 5.x对Android项目的依赖注入方式、以及iOS的Swift支持都比4.x好至少不用再写一堆Objective-C胶水代码。机型适配方面Android阵营问题最多。小米、华为、三星这些主流机型在连接遥控器时经常出现“USB设备已连接但SDK识别不到”的情况。有些是因为手机系统把遥控器识别成了“充电设备”需要在通知栏里手动切换USB模式有些是因为手机默认关闭了OTG供电。iOS这边相对稳定主要分辨率适配和刘海屏安全区问题但这属于UI层面的常规工作。2.3 第一次真机连接SDKManager的初始化时序MSDK的初始化有一个非常容易踩的顺序问题必须在SDKManager.registerApp成功之后再调用任何和无人机相关的组件。如果你在Application的onCreate里只调了registerApp然后在Activity里立刻去getFlightController大概率会得到空对象或者非法状态。我在项目里习惯先把初始化封装成一个单例对外暴露一个准备好状态的事件等收到这个事件后才去创建主界面。这样既保证时序也方便后续断线重连。大致代码结构如下class DroneSDKManager { private var isRegistered false fun register(application: Application, callback: (Boolean) - Unit) { if (isRegistered) { callback(true) return } SDKManager.getInstance().registerApp(application) { error - isRegistered (error null) callback(isRegistered) } } fun connectDrone() { if (!isRegistered) return // 启动产品连接组件比如连接遥控器或绕开遥控器直连机型 } }注意MSDK里连接飞机的入口在不同版本里也有改动。老版本是DJISDKManager.getInstance().startConnectionToProduct()新版可能变成了产品连接守卫之类的组件。不要死记API名重要的是理解时序先注册App再连接产品注册产品回调最后通过产品对象获取各个功能模块。2.4 常见连接失败排查固件版本、USB调试和网络区别我把这几年代码里常见的连接失败场景整理成一个表每次排查可以先对着过一遍。现象可能原因处理方式registerApp失败回调返回网络错误App无法访问DJI鉴权服务器检查网络、代理、企业网络策略一直提示“正在连接”但不到达已连接遥控器固件和MSDK版本不匹配升级遥控器/飞机固件到兼容版本Android上识别不到遥控器USB模式被识别成充电/文件传输关闭仅充电模式确认OTG开启iOS上可以打开App但无图传本地网络权限未授权在设置里允许App访问本地网络连上后频繁掉线信号干扰或缓存内容过多更换信道、重启遥控器、清理App缓存飞行器无法解锁未绑定开发者账号或飞控保护检查设备绑定确认飞行环境无异常我特别想提醒“网络”这一点。MSDK初始化时要访问大疆的服务器如果你在公司内网或者开了某些网络代理初始化回调可能一直失败。这时候不要以为是代码问题先换移动热点试一下。很多开发现场“查不出原因”的问题最后都是网络策略导致的。3. 核心控制链路虚拟摇杆、状态回传与图传渲染3.1 用虚拟摇杆还是物理遥控器通道手持端控制App首先面临一个选择是让用户继续用物理遥控器摇杆控制飞机还是完全在App里用虚拟摇杆控制。这不是一个随喜好选的问题它直接影响你整个任务调度逻辑。物理遥控器的控制指令走的是遥控器到飞机的私有链路稳定性和实时性最好。App在这个模式下更像一个“状态监控终端”。适合手动飞行、精细操作、安全要求高的场景比如无人机在狭小空间起降。虚拟摇杆则是MSDK通过App向飞控发送姿态指令完全绕开物理摇杆。这时候你必须自己管理杆量回中、速度限制、异常情况下的自动悬停。实际做地面站时我的推荐是混合模式航点任务用自动飞行遇到特殊情况时一键切换到“虚拟摇杆接管”模式或者让操作员直接用物理遥控器接管。这里有一个容易出问题的点你用MSDK开启了虚拟摇杆后物理摇杆指令和虚拟摇杆指令可能会互锁不同产品型号的行为还不一样。所以在设计UI时要明确告诉用户当前是“虚拟摇杆模式”还是“物理控制模式”不要两个同时输入。3.2 FlightController状态信息从哪来、怎么用MSDK里获取飞行器状态主要靠FlightController组件。通过getFlightController()拿到对象后注册FlightControllerState回调就能收到一系列状态字段经纬度、相对高度、速度、姿态角、卫星数、电量、飞行模式、避障状态等。这里要说清楚一个频率问题。MSDK状态回调的频率大概在5到10Hz对显示和任务调度足够想拿来做高带宽实时控制则远远不够。如果项目里需要那种“高频闭环控制”比如自主避障、精准降落应该放到机载端做而不是在手机端造轮子。在手持端应用里状态数据的最大价值是帮助业务逻辑做安全决策。比如我们做巡检App时会设定一个“电子围栏”飞机靠近指定边界时App里弹出警告并且不允许继续下发航点当电量低于25%时强制把返航按钮放大变成红色并暂停正在执行的任务。这些策略全部基于FlightControllerState来实现。因为这些数据是不断变化的要注意UI更新要走主线程避免在SDK回调线程里直接改View。3.3 图传VideoFeed在Android上的Surface渲染图传是手持端控制应用里最影响体验的部分。MSDK提供的是视频流数据不是你直接可以ImageView.setImageBitmap的现成帧。Android端的常见做法是拿到一个SurfaceView把MSDK的视频源绑定到Surface上。这个过程有几个容易踩的细节。首先是Surface的生命周期Activity或View销毁时要做解绑否则再次进入时会黑屏或者崩溃。其次是解码器兼容性MSDK底层用的是硬解不同厂商的Android机型对H.264/H.265的支持广度不一样真机上如果图传花屏先查解码器日志别急着怀疑飞机。代码层面可以这样写简化示意videoFeeder VideoFeeder.getInstance() videoFeeder?.primaryVideoFeed?.addVideoDataListener { videoBuffer, size - // 将videoBuffer交给解码器或底层渲染 }但这里我不建议大多数人自己处理解码能用SDK自带的渲染就尽量用。自研解码和渲染是一个大坑你需要同时处理I帧判断、硬解Buffer管理、分辨率切换、Surface重建开发周期至少要按周算。对于一般手持端项目把精力放在业务层、地图和任务管理上比死磕图传渲染更有价值。3.4 别踩的控制冲突飞控保护限制与自定义指令很多人一开始会以为“我发什么指令飞机就执行什么”。这是最大的误解。飞控内部有一堆保护逻辑低电量返航、信号丢失返航、避障刹车、限高限远、新手模式限制。当你通过MSDK下发控制指令时如果和飞控保护逻辑冲突飞控有绝对优先权。我们在测试虚拟摇杆时遇到过这样一个问题飞机在向前飞行突然进入避障刹车状态但App端还在持续发送“前进”指令结果飞机就一直在“刹车-前进-刹车”的循环里抖非常危险。后来我们加入了飞行模式判断只有确认当前飞行模式是“普通模式”或“姿态模式”时才允许发送操作指令当监测到AVOIDANCE、GO_HOME等模式时立刻停止虚拟摇杆发送并在UI上弹出提示。另外要注意虚拟摇杆指令的发送频率。MSDK文档里对发送间隔有建议不要低于20Hz不然飞控会认为指令超时自动退出虚拟摇杆模式。我们在实现时用了一个定时器保持25Hz到50Hz的发送频率并且每次发送前检查一下当前飞行模式。4. 手持端地面站航点规划、地图联动和动态调整4.1 Waypoint Mission的API组合方式航点任务是地面站App最核心的功能。MSDK里管理航点任务的是MissionOperator通过MissionControl获取。标准的航点任务流程是构建航点任务对象设置任务模式、航点数、飞行速度、完成动作等。获取MissionOperator上传任务。监听上传和执行的各个状态。调用startMission开始执行。构建航点时有几个参数特别影响实际飞行。一个是航点的转弯模式默认可能是在航点悬停转向如果你希望更流畅的飞行可以设置为掠过该点转弯。另一个是航点间的速度曲线如果下一段要做“加速飞行”需要设置合理的速度值。对于植保类任务通常还要把每个航点的飞行高度设置成相对起飞点的高度避免地形起伏导致碰撞。但这里必须提醒一下MSDK的WaypointMission是离线任务模型它的执行逻辑是上传到飞控后在机载侧执行的。也就是说一旦开始任务飞机会按预先设定好的航线走App端的网络波动不会直接终止任务。这个设计有好处也有坏处。好处是即使手机和遥控器之间状态断开飞机大概率还会继续执行坏处是你很难在任务执行中实时插入一个动态航点除非你主动中止任务重新上传。4.2 地图SDK接入坐标系和旋转角度的坑地面站离不开地图。市面上常用的地图SDK有高德、百度、Mapbox等但做无人机地面站时坐标系的坑是第一天就会遇到的。飞机的GPS/RTK输出通常用的是WGS84坐标系但国内的高德地图、百度地图为了合规要求显示坐标使用的是GCJ-02或BD-09偏移坐标。如果你不做坐标转换直接把WGS84坐标放到高德地图上显示位置会偏移几百米。第一版我们没注意这个问题在办公室里看着屏幕上的飞机在小区里乱飞实际飞机已经挂在楼顶了。当然不是真飞但定位显示完全不可信。解决方案有两个思路。一是用Mapbox或Google地图这种接受WGS84的地图底图但国内使用场景要考虑访问稳定性和合规性二是自己写坐标转换工具把WGS84转成GCJ-02/BD-09。很多开源库都提供转换但务必仔细测试边界值的精度会影响航线显示位置。还有一个和地图旋转相关的坑当用户旋转地图视角时航线的箭头和飞机朝向会容易让人困惑需要时刻明确飞机机头方向是相对正北的而不是相对屏幕的。4.3 飞行中接管动态改点、暂停、返航的边界条件真实的地面站不是“上传一条航线然后干等”。操作员随时可能因为现场突发情况改计划比如发现前方有高压线想跳过下一个航点或者发现某一个目标区域需要再飞一遍。MSDK对正在执行的任务提供了暂停、继续、停止等操作。但“动态改点”不是直接改运行中航点任务的某个坐标字段这是个常见误解。正确做法是先暂停或停止当前任务等MissionOperator进入可上传状态再构建新的航点任务上传和启动。这个过程中状态管理的复杂度远高于“调一个接口”。我记得自己在一个项目里写了个状态机包含空闲、已上传、已开始、已暂停、已停止、断线重连等状态。每次任务的切换必须经历完整状态流转避免在错误状态里发送startMission。还要留一个“手动优先”的入口。无论航点任务做得多智能都必须让操作员能一键切换回手动控制。特别是飞行中遇到突发障碍物或信号问题时依靠自动逻辑去处理往往是慢的。我们一般在UI顶部放一个非常显眼的“手动接管”按钮按下后立即暂停当前任务并把虚拟摇杆的悬停指令发送给飞控让飞机保持悬停。4.4 飞行记录与日志反查设计地面站App不只是控制工具它还是事故分析和作业报告的数据来源。我强烈建议从第一个版本就开始记录飞行日志。日志字段至少包括时间戳、GPS坐标、高度、速度、姿态、电量、卫星数、飞行模式、当前任务ID/航点序号、用户操作事件按钮点击、任务切换、SDK回调的错误码。保存方式上本地SQLite或者按天写CSV都行。关键是这些日志要和云端平台打通这样作业完成后后台可以自动还原整个飞行过程。我们在对接后端时用的是一套JSON消息格式每200毫秒记录一条飞行数据业务事件单独记录。这样回放的时候能精确看出“在第几秒App发出返航指令、飞机在第几秒进入GoHome模式、中间有没有出现过断连”。日志反查帮我们排查过很多问题。有一次用户反馈“飞机在地图上轨迹乱跳”排除了GPS后通过日志发现是手机定位权限被系统回收导致App端显示用了错误的模拟坐标。这类问题如果没有日志根本没法复现。5. 避障、视觉感知和智能任务从读取数据到真正可用5.1 拿到避障系统状态后第一件事不是判断“有没有障碍”现在主流无人机都有前后下视觉避障或者红外感知MSDK把避障状态封装成了传感器状态。你可以拿到前、后、左、右、下各个方向是否有障碍物、避障是否启用等数据。但我要泼一盆冷水这些状态字段给你的最多是一个“感知提示”不是“决策依据”。因为视觉传感器受光照、纹理、透明物体影响很大树枝、电线、玻璃常常会被漏检或者误报。你把障碍物状态当成布尔量直接用在复杂环境里一定会出问题。正确做法是把避障状态和飞控的飞行模式、速度、距离综合判断。比如我们做一个室内巡检项目时会设置阈值只有当前方障碍物距离小于2米且飞行速度大于1米/秒时才触发警告和自动悬停逻辑如果飞机本身已经悬停只是传感器短暂报警那就只记录状态不打扰用户。同时当环境光线变暗时视觉避障可能失效UI上要有明确提示不能给操作员一种“飞机有避障所以很安全”的错觉。5.2 视觉传感器能输出什么、离机载智能还有多远MSDK里的视觉系统一方面用来避障一方面也可以提供部分视觉数据。有些机型支持通过摄像头拿到原始视频流可以用来做实时识别。但你要明白把这些视频流传到手机端再做AI推理延迟和算力都是问题。市面上有些方案用手机端的NPU跑轻量模型但实时性仍然不稳定。我们做过一个输电线路缺陷检测的雏形手机端用TensorFlow Lite跑模型帧率大概只有8到12FPS遇到复杂背景还会掉到5FPS以下。实际飞行时图传画面已经是压缩后的再做推理精度会进一步下降。所以我的结论是手持端可以做“事后分析”和“抽样识别”实时预警最好还是机载端做。视觉感知在行业应用里更多是采集数据、构建数据集。比如你想训练一个识别农场作物长势的模型无人机按航线采集大量图片这些图片在手持端打标、上传后台、训练模型。移动端App在这个链路里承担的是数据采集和现场标注的角色而不是实时推理平台。5.3 路径规划算法和SDK交互时的链路约束热词里有一个“复杂静态环境与动态障碍物下的无人机实时轨迹规划框架”这说明现在很多团队在关注轨迹规划。但如果你的算法跑在手持端有一个绕不开的约束链路时延和带宽。MSDK的指令通道和状态通道不是为此设计的它更适合任务级交互而不是毫秒级循环控制。实现路径规划时需要把算法结果转成飞控能理解的任务。如果规划结果是平滑的轨迹曲线你可以离散成一系列航点再通过WaypointMission上传。但航点数量有限制航点间距太近会让飞控执行很僵硬。另一种方式是用虚拟摇杆做增量控制把规划结果转换成速度指令流。这个方案对指令发送频率要求高并且对链路稳定性非常敏感。实测中遥控器信号稍微波动速度指令不及时更新飞机就可能偏离轨迹。所以我现在做项目时凡是涉及动态避障和实时轨迹规划的都会建议放到机载端。Mobile端只做人机交互和任务编排。这样既保证安全也减少很多开发工作量。5.4 一个真实教训回调顺序与断线重连处理不到位说一个我自己踩过的坑。那是在一个室外巡检项目上飞机在离我们大概两百米的位置执行航点任务突然经过一片强干扰区遥控器信号短暂丢失MSDK断线。我们当时在代码里监听MissionOperator的状态结果断线后所有回调都停了。等信号恢复时SDK自动重连回调又恢复但这中间状态没有同步。问题出现在这里我们的App在断线时把MissionOperator的状态还停留在“正在执行”用户界面上也显示“任务进行中”。重连后程序检测到任务状态是“正在执行”就自动调用了startMission希望把任务“续上”。但飞控那边的任务其实已经因为链路断开自动暂停了这导致App端和飞控端状态不一致。最终飞机在收到重复start指令后出现了诡异的加减速虽然没有酿成事故但把我们吓得不轻。事后我们做了两件事。第一在MissionOperator回调里维护严格的状态机每次状态变化都记录时间戳第二在断线重连后不自动恢复任务而是强制进入“已暂停”状态等待操作员手动确认。这个原则我现在一直沿用自动重连可以自动继续任务不行。6. 平台演进Mobile SDK与机载计算平台/PSDK的配合6.1 什么业务场景必须上PSDK或OSDK当你做的已经不只是“控制飞机”的时候就要考虑机载平台了。举几个典型场景需要调用第三方传感器比如多光谱相机并把数据实时融合到飞行控制中。需要在飞行中跑AI模型比如实时识别目标并跟踪识别结果需要立刻参与云台控制。需要高频读取飞控IMU、GPS等数据做毫秒级控制。需要挂载投掷器、探照灯、喊话器这类行业负载并和飞控联动。这些场景里MSDK负责手持端展示和人工操作真正的智能和控制都由机载端完成。大疆的PSDK就是给行业负载/机载计算平台用的。如果你只需要在飞机上挂一块开发板跑自己的算法同时能控制相机、获取飞控数据那PSDK是主流选择。OSDK更多被用在科研领域支持更底层的自主飞行逻辑。网上经常看到有人问“大疆无人机的PSDK开发板可以用RK3588吗”。答案是可以但需要满足硬件接口要求。PSDK的底层通信接口有UART、Ethernet、USB等RK3588这类Linux开发板资源比较丰富理论上可以对接。实际做的时候要注意电平匹配、供电能力、以及PSDK硬件认证的兼容性。不要只看“开发板能不能跑”还要看整条链路能不能达到实时性要求。6.2 RK3588这类机载平台和手机App怎么分工如果项目最终形态是“无人机 RK3588 手机App”那要尽早把分工定清楚。我的建议是RK3588机载端负责任务关键路径视觉识别、实时避障、云台控制、数据采集、路径规划。手机App负责用户交互路径地图显示、任务编排、飞行状态展示、结果回传、人工接管。RK3588和手机App之间通过消息协议通信比如MQTT over Wi-Fi或者自定义TCP/HTTP根据业务实时性选择。这里有一个重要的设计原则不要把手机App变成所有数据的必经通道。比如机载端识别到电力线缺陷后可以直接通过4G/5G网卡上传到云端照片和缺陷信息不进App也可能更稳定App只负责下发“开始巡检”任务和展示最后的汇总结果。这样即使手机断线机载端依然能完成大部分工作。6.3 链路时延和带宽取舍从图传到控制指令很多手持端控制应用最终都会在“图传延迟”上栽跟头。MSDK图传在正常环境下延迟大概在200毫秒到500毫秒之间具体取决于码率、分辨率、干扰情况和解码性能。这个延迟对于看画面、监控进度是够的但如果你试图让操作员看着图传画面进行精细吊舱操作体验会非常差。控制指令的链路又不一样。遥控器直接控制的通道延迟通常更低但MSDK下发的虚拟摇杆指令也要经过同样的射频链路延迟波动无法避免。因此凡是要求“图像实时操作闭环”的功能比如精准降落、穿环、目标跟踪微调都应该在机载端完成把末端动作变成自动程序。手持端做得再好也弥补不了物理链路时延。带宽上图传已经占用了大部分无线带宽。如果再往手机端塞大量原始传感数据或高分辨率图片流很容易把链路挤爆。我们通常把图传分辨率设到1080P码率根据信号强度动态调整同时业务数据走独立的小包通道。机载端采集的大数据统一走4G/5G网卡绝不抢占图传信道。6.4 一套可落地的端到端架构参考最后给一套我现在常用的架构参考不是标准答案但适合大多数行业应用。层级组件职责手持端Android/iOS App MSDK用户登录、任务创建、地图显示、航线上传、飞行监控、图传显示、结果查看通信链路遥控器链路 Wi-Fi / 4G / 5G远程控制、图传数据、业务消息、云端推送机载计算平台RK3588 PSDK/OSDK算法推理、实时避障、负载控制、高频数据采集、局部路径规划无人机平台DJI行业机 飞控 传感器飞行执行、安全保护、状态采集、云台相机控制云平台自建服务 对象存储 数据库任务下发、日志存储、数据回放、统计报表、远程指挥在这个架构里手持端不再是“控制中心”而是“任务入口和监控窗口”。你可以理解成机载端是副驾驶负责盯着路面手机App是驾驶员助手负责导航、通讯和记录飞控才是真正握着方向盘的人。三者各司其职系统才稳定。实施时有一个先后顺序建议先把手持端App做稳能连接、能看状态、能传航线然后再逐步增加机载端AI能力。不要一开始就并行做两个端的大系统否则联调的时候你根本不知道问题出在哪一端。最后说一点我个人这几年的体会每次遇到有人说要“做一个无人机控制App”我第一句话都是先问业务场景。MSDK本身不复杂复杂的是你把它放到什么场景里、怎么跟飞控的保护逻辑相处、数据链路断掉时你的代码能不能保持清醒。如果一开始就把这些想清楚后面能少熬很多夜。项目里没有一套代码能适配所有飞机也没有一个方案能解决所有需求真正的经验都是在一次次真机调试和问题复盘里攒下来的。手持端控制应用只是一个入口背后考验的是对整个无人机系统、无线链路和飞行安全的理解。本文还有配套的精品资源点击获取