简介基于yolov5与大疆教育无人机Tello TT的完整目标识别、检测、追踪及测距解决方案面向K12学生与AI初学者将深度学习理论与无人机真实场景结合适合校园社团、科技课堂及个人自学。压缩包共1667个文件容量约269MB其中包含758张带标注的图像数据集jpg与txt配对、94个yaml配置文件、46个Python脚本以及9个已训练好的模型权重文件pt还附带多个训练日志文件覆盖从数据准备、模型微调到边缘部署的全流程。目前已有681人学习人气稳步上升。得益于已收敛的模型权重使用者无需从零训练即可直接开展目标检测实验配套说明文档对环境配置、模型加载、无人机飞控、视频流处理及常见排错技巧均做了细致讲解结合“旗”和“圈”两类目标的检测任务可帮助初学者快速掌握人工智能与机器人交叉领域的核心方法并在动手实践中完成追踪与测距功能全面提升STEM素养和工程实践能力。1. YOLOv5 Tello TT 不是玩具一套能复现的空中目标识别与追踪测距方案把“基于 yolov5 大疆教育无人机 Tello TT 实现目标识别检测 追踪测距完整源码 数据集 训练好的模型 说明文档.zip”这个标题拆开看就是三件事用 YOLOv5 在无人机图传画面上识别目标解出目标相对机体的位置偏差再换算成可执行的追踪和测距结果。这套东西最常见的落地形态是地面站 PC 实时推理再通过 Tello TT 的 SDK 把控制量发回去。它解决的问题很具体让一架几百克的 Tello TT 学会“盯住一个人 / 一辆车 / 一张 A4 纸”并且给出距离。适合毕设、无人机竞赛、巡检课设、机器人开题这类场景。如果你手头也有这样一个包含完整源码、数据集和训练好权重的交付包别急着解压跑先理解整条链路后面才不会翻车。2. 为什么是 YOLOv5 以及怎么让“训练好的模型”在本地跑起来2.1 选 YOLOv5 的三个理由生态成熟、模型体量小、导出链路顺目标检测框架现在很多v6、v8、v11 都不缺但在 Tello TT 这个场景里v5 依然是最省心的选择。第一社区教程密度大遇到问题搜索最快搜“yolov5 训练自己的数据集”能找到大量可参考的讨论踩坑成本低第二yolov5s 和 yolov5n 的权重体量在几十 MB 这个量级消费级显卡能训CPU 也能推理对着 Tello 这种轻量平台不浪费第三导出 ONNX、TensorRT、rknn 都有现成脚本后面想下沉到边缘设备路径是通的。另外v5 的检测头输出结构直观把 xyxy 和 conf 取出来做追踪时代码改动小于某些自带复杂后处理的新框架。一个完整交付工程里核心资产是三样训练好的模型权重一般是 best.pt、数据集images labels、说明文档。权重是目标识别检测的直接产物数据集决定模型在新场景下的泛化能力文档则记录训练超参数和复现步骤。我拿到这类包会先看这三样有没有对齐——很多包权重大、数据杂、文档只抄 API这种基本没法直接复现。说明文档真正该记录的是训练超参数、标定数据、复现步骤而不是把函数签名抄一遍。2.2 用 torch.hub 跑通 best.pt 的最小推理脚本先不管无人机把模型在本地跑起来这是整个链路能往下的前提。常见的做法是用 torch.hub 加载官方 yolov5 仓库里的 custom 接口指定你自己的权重路径不用手动 clone 整个工程。import torch # 加载训练好的模型权重没有 best.pt 时可以先加载官方 yolov5s 顶替 model torch.hub.load(ultralytics/yolov5, custom, pathbest.pt, force_reloadFalse) # 推理阈值对追踪链路影响最大的是 conf model.conf 0.25 # 低于 0.25 的框直接丢弃 model.iou 0.45 # NMS 合并重叠框的 IoU 阈值 model.max_det 10 # 每帧最多保留 10 个目标 results model(demo.jpg) results.print() # 取关键字段xyxy 坐标、置信度、类别 boxes results.xyxy[0].tolist() for x1, y1, x2, y2, conf, cls in boxes: print(x1, y1, x2, y2, conf, cls)torch.hub.load 的第一个参数指向 ultralytics 官方仓库custom 后面接你自己的权重代码会在本地缓存里复用已经拉取的仓库如果网络环境差建议手动把 yolov5 仓库 clone 下来然后把 path 指向本地目录可以少踩很多环境问题。model.conf、model.iou 在推理时等价于命令行里的 --conf-thres 和 --iou-thres在这里设置后后续每一帧推理都会生效不用每次调用都传参。这里有一个直接影响追踪效果的参数匹配问题。conf 和 iou 不是越大越好具体按场景调参数建议范围对追踪的影响model.conf0.2 - 0.5低于 0.15 误检刷屏无人机乱动高于 0.5 漏检目标消失model.iou0.4 - 0.6数值过小会把重叠框全删过大又可能保留两个重复框model.max_det5 - 20室内单目标取 5 就够多目标再放开减少后处理耗时2.3 yolov5 训练自己的数据集目录结构、标签文件与两个最容易踩的设置交付包里带的数据集不管从哪来的拿到后第一件事是检查标注格式。yolov5 用的是 YOLO 格式每个 .txt 文件与图片同名内容格式是“class x_center y_center width height”全部归一化到 0-1。类别编号从 0 开始不能从 1 开始这是新手翻车率最高的地方。data.yaml 里 classes 列表的顺序必须和标注编号一致否则模型训练完推理输出全部错位。$ tree datasets/ datasets/ ├── train │ ├── images/ # 训练图片 │ └── labels/ # 同名 txt 标注 └── val ├── images/ └── labels/data.yaml 通常长这样train: datasets/train/images val: datasets/val/images nc: 2 names: [person, car]训练命令按官方仓库的标准写法常见做法是用迁移学习微调别从零训练python train.py \ --img 640 \ --batch 16 \ --epochs 100 \ --data data.yaml \ --weights yolov5s.pt \ --hyp hyp.scratch-low.yamlyolov5 超参数里最值得动的第一个是 hyp.scratch-low.yaml 里的 lr0默认 0.01 对微调偏大我一般改成 0.001第二个是 mosaic默认 1.0数据量小的时候保留 mosaic 能明显涨点。训练完看 runs/train/exp/weights/best.pt用第 2.2 节的脚本替换权重路径即可。3. Tello TT 通信链路先拿到画面再谈识别和追踪3.1 SDK 模式UDP 8889 端口的指令交互Tello TT 飞控本身没有计算能力去跑 YOLOv5它提供的是一个 UDP 指令接口。常见做法是电脑连上 Tello TT 自带的 Wi-Fi往 8889 端口发文本指令飞控回一个字符串这是整个控制链路的起点。import socket import time TELLO_IP 192.168.10.1 CMD_PORT 8889 LOCAL_PORT 9000 # 本机绑定端口不同固件要求一致 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((, LOCAL_PORT)) sock.settimeout(5) def send(cmd): sock.sendto(cmd.encode(), (TELLO_IP, CMD_PORT)) try: resp, _ sock.recvfrom(1024) return resp.decode() except socket.timeout: return ERROR time.sleep(1) print(send(command)) # 进入 SDK 模式所有指令的前提 time.sleep(1) print(send(streamon)) # 打开视频流实际码流走 11111 端口 time.sleep(2) print(send(takeoff)) # 起飞气压计稳定后才有意义这段代码有两点值得说明。一是顺序必须先 command 再 streamon很多人先开视频流再进入 SDK 模式导致画面怎么也出不来这是最常见的手势错误。二是 takeoff 和 land 必须成对测试室内测试时先手抓起飞确认姿态回中、油门响应正常再放开让它自己飞别上来就全自动。send 函数里收到的返回值command 应该是 ok如果不是检查本机是否已经连上 Tello 的 Wi-Fi以及 LOCAL_PORT 是否被占用。3.2 视频流udp://0.0.0.0:11111 的 H.264 原始流streamon 之后视频流从 UDP 11111 端口出来。这里常见做法是用 PyAV 拉流解码而不是直接用 cv2.VideoCapture。区别在于OpenCV 的 VideoCapture 对 UDP 丢包容错差花屏之后容易卡死PyAV 基于 ffmpeg丢帧自动跳过更适合实时链路。import av import cv2 # Tello 视频流H.264 over UDP端口 11111 container av.open(udp://0.0.0.0:11111, timeout5) for frame in container.decode(video0): img frame.to_ndarray(formatbgr24) # 单帧推理模型对象沿用第 2 章的 model results model(img, size640) det results.xyxy[0] for *xyxy, conf, cls in det: x1, y1, x2, y2 map(int, xyxy) cx, cy (x1 x2) // 2, (y1 y2) // 2 # 画检测框和中心点后续追踪逻辑从这里取坐标 cv2.rectangle(img, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.circle(img, (cx, cy), 4, (0, 0, 255), -1) cv2.imshow(tello_tt_detect, img) if cv2.waitKey(1) 0xFF ord(q): breaksize640 要和训练尺寸保持一致Tello 图传画面原始分辨率是 960x720模型内部会缩放但 xyxy 坐标会映射回原分辨率所以画框不会错位。这里还有个容易被忽略的点Tello 视频流默认是竖排还是横排取决于固件但 UDP 裸流出来的是整帧 YUV420PyAV 的 to_ndarray 会自动转成 bgr24不需要手动做颜色转换。解码慢的话优先降低解码分辨率而不是动模型输入尺寸模型输入尺寸一降检测率立刻掉。3.3 延迟评估体感 300ms 很正常以及怎么缩短很多第一次做的人以为画面卡顿是代码写错了其实不是。整条链路是Tello 摄像头感光编码约 20-30ms→ Wi-Fi 传输几十 ms→ PC 解码约 20ms→ YOLOv5 推理CPU 上约 80-120msGPU 上约 20-40ms→ 画面显示。体感延迟 300ms 是常态不是 bug。但延迟超过 1 秒就是问题了。最常见的原因是解码和推理串在同一个线程里一帧推理没跑完后面的帧全在 UDP 缓冲区排队越积越多。解决方法是把解码、推理、显示拆成三个线程用队列传递帧。简单做法是 Python 里开一个 deque最大长度固定为 2新帧进来直接替换最旧的帧保证推理永远拿到的是最新画面而不是排队排了 500ms 的旧帧。这个改动对追踪跟随的稳定性提升比调任何模型参数都明显。4. 目标识别检测追踪测距的实现从像素坐标到飞行指令4.1 追踪检测框中心偏差如何转成 rc 控制指令识别到目标只是第一步追踪的本质是把目标的像素中心偏差换算成无人机的偏航和前后速度。这里不引入复杂控制算法一个带死区的 P 控制器就能动起来后续再叠 PID。def tracking_outputs(cx, cy, frame_w, frame_h, w_px, kp0.5): cx,cy: 目标中心像素坐标 w_px: 目标框宽度用于测距 返回: yaw_rate, fb_speed, dist_cm # 归一化偏差[-1,1]左负右正 dx (cx - frame_w / 2) / (frame_w / 2) dy (cy - frame_h / 2) / (frame_h / 2) # 目标在右侧(dx0)机头应右转 yaw_rate -dx * kp # 目标偏上说明飞过头了给一点后退 fb_speed dy * 0.3 # 测距见 4.2 dist_cm estimate_distance(w_px) return yaw_rate, fb_speed, dist_cm这里的方向正负号我吃过亏Tello SDK 的 rc 指令方向约定和直觉相反不同固件版本还有差异。例如 yaw 正值是顺时针但 rc 指令里的第四通道正值对应的旋转方向要靠实测确认。建议在地面把飞机拿在手里发送小油门值试一次比看文档猜方向快得多。注意Tello 的 rc 指令是四通道整数 yaw 速度都在 -100 到 100 之间。把上面返回的浮点值乘以 100 再取整直接传浮点会导致指令被忽略。# 发送 rc 控制left_right, fb, up_down, yaw yaw_cmd int(max(-100, min(100, yaw_rate * 100))) fb_cmd int(max(-100, min(100, fb_speed * 100))) send(frc 0 {fb_cmd} 0 {yaw_cmd})kp 值调大响应快但容易震荡调小跟随平滑但容易跟不上。单目标室内追踪0.5 起步加了平滑滤波之后可以提到 0.7。还有一个建议输出控制指令的更新率不要跟着视频帧率走固定 10Hz 左右就行Tello 的飞控响应带宽有限指令发太密反而会抖。4.2 单目测距反推焦距法不要盲目抄网上公式单目测距有个前提必须说清楚只能测已知物理尺寸的目标。没人知道画面里一个陌生物体的真实大小距离就是不可观测的。做追踪测距时先假定目标是人的躯干宽度约 40cm或者 A4 纸短边 21cm在这个假设下才能算出距离。网上很多教程让你直接用官方 FOV 算焦距我一般不用因为标称 FOV 和实际镜头有偏差。更可靠的是反推焦距法把 A4 纸立在 3 米外测一次框宽反推出等效焦距之后每一帧都用这个焦距算距离。def estimate_distance(w_px): # 像素宽度太小的时候噪声会被几何放大不输出距离 if w_px 5: return None return F_PX * W_REAL_CM / w_px # 标定步骤 # 1. 把 A4 纸短边 21cm立在 3m 远处 # 2. 跑一次检测读出 w_px比如实测 124 D_MEAS 300.0 W_PX_MEAS 124.0 # 实际读到的值每次标定都不同 W_REAL_CM 21.0 F_PX W_PX_MEAS * D_MEAS / W_REAL_CM # 得到 F_PX 后estimate_distance 才能投入使用为什么限幅在 w_px 5目标在 10 米外时框宽可能只有 3-4 个像素这时候目标框上下抖动 1 个像素算出来的距离会从 9 米跳到 14 米象这种跳变纯粹是量化噪声不是真实距离。限幅之后宁愿不输出距离也不要输出一个错误距离给上层逻辑。4.3 追踪与测距同一套坐标把目标框宽度作为距离可信度追踪和测距应该共用同一个检测结果不要拆成两条独立的链。每次推理拿到 xyxy 之后同时计算中心点和宽度中心点喂给追踪控制器宽度喂给距离公式然后还要做一个一致性检查如果某一帧的框宽突然翻倍或者减半多半是误检或者两个目标合并这时候距离输出要保持上一帧的值而不是跟着跳。我常用的做法是在检测之后加一个宽度平滑。距离更新率限制在 3 帧一次同时用中值滤波处理 w_px 序列from collections import deque import statistics # 宽度历史队列窗口 5 w_history deque(maxlen5) def smooth_width(w_px): w_history.append(w_px) if len(w_history) 3: return None # 中值滤波抗单帧噪声 return statistics.median(w_history)这样做的代价是距离响应变慢但换来的是距离数字稳定对上层决策更有意义。追踪跟随用原始中心误差测距用平滑后的宽度两者互不拖累。5. YOLOv5 Tello TT 追踪测距的避坑清单五次现场翻车换来的经验5.1 现象一图传延迟超过 1.5 秒追踪必然甩丢现象画面里的目标明明在原地无人机却像在追一个不存在的东西等画面反应过来目标早就走出画面了。用手在空中晃一下屏幕上要 1 秒多才看到动作。原因解码、推理、显示全在一个线程里串行执行加上 UDP 接收缓冲区满了之后旧帧堆积推理永远在消费最旧的帧。另外模型用的可能是 yolov5x 这种大权重CPU 单帧推理 300ms 起步直接拖垮整条链。解决先拆线程用固定深度为 2 的队列新帧顶掉旧帧保证推理永远处理最新画面。再把模型降级到 yolov5n640 输入下 CPU 单帧可以跑进 100ms 以内。最后确认本机无线网卡没有同时连手机热点2.4G 频段干扰会直接放大延迟。5.2 现象二悬停时目标框抖动测距数字跳来跳去现象无人机完全悬停目标也没有动屏幕上的检测框在目标边缘来回抖动距离数字在 2.8m 和 3.6m 之间跳。原因单帧检测没有时序平滑置信度略低的帧里框会往左或往右偏半个身位。测距公式对像素宽度的微小变化很敏感框抖 3 个像素距离就抖 30%。解决对检测框的 cx、cy、w 分别做一阶指数平滑例如 cx_ema 0.8 * cx_ema 0.2 * cx。测距用第 4.3 节的中值滤波窗口同时把 model.conf 从 0.25 提到 0.35低置信度误检引发的框抖动会明显减少。这一套做完数字基本就稳了。5.3 现象三目标靠近后距离越测越不准现象目标从 3 米走近到 0.8 米距离输出从原本的 5% 误差恶化到 20%再近直接乱跳。原因目标靠近后一部分身体走出了画面检测框被画面边缘截断框宽不再等于目标真实宽度。另外近距离下目标的像素宽度很大但标注框本身的回归偏差也被放大导致单目公式失真。解决距离低于 1 米时停止使用视觉测距改交给定高数据或超声波类传感器视觉只负责追踪不负责测距。如果必须视觉测距标定焦距时增加近距样本分两段标定2m-5m 一段0.5m-1.5m 一段分别用不同的 F_PX 系数。5.4 现象四SDK 握手成功但视频流黑屏/花屏现象send(command) 返回 oksend(streamon) 也返回 ok但 PyAV 一直拿不到帧或者画面是绿花屏。原因本机防火墙拦了 UDP 11111 端口或者之前某次程序异常退出Tello 的视频流状态卡在半开再有就是本机同时开着多个占用该端口的进程。解决先重启链路按顺序 command → streamon → av.open中间各间隔 1 秒。确认 Windows 防火墙对 python 放行 UDP。在 av.open 之前先用 netstat 确认 11111 端口没有被占用。这些做完还黑屏重启 Tello 电源让它重新初始化 Wi-Fi八成能恢复。5.5 现象五模型在 Tello 视角下识别率骤降现象同一套权重拿笔记本摄像头测识别率 90%换到 Tello 图传上只有 60%而且目标稍微移动就丢。原因这是视角和分布不匹配。数据集里大多是平视地面拍摄的样本Tello 是 3 米高度俯视目标在画面里的角度、光照、运动模糊都不一样。yolov5 对训练集的分布很敏感换个视角性能断崖式下跌。解决收集 200-500 张 Tello 实拍帧混进训练数据重新微调。采集方法很简单Tello 悬停目标在地面走动用第 3.2 节的代码边跑边存帧。训练时开启 mosaic、mixup再给随机运动模糊增强模拟无人机抖动。这个操作对室内落地场景的涨点效果比换任何模型都快。6. 交付前的验证与进阶把能跑的 demo 变成能交付的结论6.1 静态测距误差与动态跟踪响应两个指标怎么测很多人拿到工程跑起来就认为完了实际上还差最后一步用数据证明它真的能交付。我一般固定两套验证都用手抓试车完成不急着起飞。指标测试方法合格线静态距离误差目标分别立在 3m / 5m / 8m各取 50 帧算平均距离平均误差 10%追踪建立时间目标从画面外走入视场 300ms 输出稳定框偏航响应延迟目标以 0.5m/s 横向移动机头跟随延迟 500ms测法就是飞机放桌面不上电PC 端对着视频流跑检测人在另一侧走动记录数据。距离误差超了就重新标定 F_PX响应延迟超了就调大 kp 或减少平滑深度。这两个数据填到说明文档里比写十行“效果良好”都管用。6.2 进阶把推理下沉到树莓派4B或RK3568边缘盒子如果目标是竞赛或者真实巡检PC 在地面站着是不够的得把整个推理链路放到空中。常见的做法是导出 ONNX再把树莓派4B或RK3568这类边缘盒子装在 Tello TT 的扩展板上直接跑推理Tello 只当图传和飞控。导出命令很简单python export.py --weights best.pt --include onnx --dynamic边缘侧用 onnxruntime 加载int8 量化时一定要带校准集不然定点精度掉得厉害。量化 rk3568 还得转 rknn 格式转换时固定输入尺寸 640别开动态尺寸NPU 上动态分辨率支持很差。这套架构的好处是控制回路不出机延迟低也是树莓派4B 部署 yolov5 的常见玩法。我拿到这类交付包时第一次犯的错就是急着把模型往板端塞结果发现算力根本不够后来老老实实改回 PC 推理 SDK 指令回传才把追踪跑起来。还有一次把 conf 调到 0.1 想“看清一切”结果室内灯管和风扇都被当成目标无人机在半空自己转圈。从那以后先标定、再平滑、补验证表才敢让飞机自动跟随。这个方向值得做但一定要按链路来先本地推理再通视频流最后才动控制。以上经验希望帮到你。本文还有配套的精品资源点击获取