Yolo11 基于DroneVehicle数据集的无人机视角下车辆目标检测

Yolo11 基于DroneVehicle数据集的无人机视角下车辆目标检测

1、关于DroneVehicle数据集介绍

DroneVenicle数据集是由天津大学收集、标注的大型无人机航拍车辆数据集。
DroneVehicle 数据集由无人机采集的共 56,878 幅图像组成,其中一半为 RGB 图像,其余为红外图像。我们对五个类别进行了带有方向性边界框的丰富标注。其中,汽车car 在 RGB 图像中有 389,779 个标注,在红外图像中有 428,086 个标注;卡车truck 在 RGB 图像中有 22,123 个标注,在红外图像中有 25,960 个标注;公交车bus 在 RGB 图像中有 15,333 个标注,在红外图像中有 16,590 个标注;面包车van 在 RGB 图像中有 11,935 个标注,在红外图像中有 12,708 个标注;货车freight car 在 RGB 图像中有 13,400 个标注,在红外图像中有 17,173 个标注。

2、DroneVehicle数据集下载

 参见作者Github:https://github.com/VisDrone/DroneVehicle

3、DroneVehicle数据集处理

在 DroneVehicle 中,为了标注图片边界上的物体,作者在每张图片的上下左右四边设置了宽度为 100 像素的白色边框,这样下载的图片尺寸就是 840 x 712。在训练我们的检测网络时,我们可以进行预处理,去除周围的白色边框,并将图像尺寸改为 640 x 512。

处理前后对比。

去除白边代码:

import numpy as np import cv2 import os from tqdm import tqdm def create_file(output_dir_vi, output_dir_ir): if not os.path.exists(output_dir_vi): os.makedirs(output_dir_vi) if not os.path.exists(output_dir_ir): os.makedirs(output_dir_ir) print(f'Created folder:({output_dir_vi}); ({output_dir_ir})') def update(input_img_path, output_img_path): image = cv2.imread(input_img_path) cropped = image[100:612, 100:740] # 裁剪坐标为[y0:y1, x0:x1] cv2.imwrite(output_img_path, cropped) dataset_dir_vi = r'valimg' # 处理前可见光图片目录 output_dir_vi = r'valimg2' # 处理后可见光图片目录 dataset_dir_ir = r'valimgr' # 处理前红外光图片目录 output_dir_ir = r'valimgr2' # 处理后红外光图片目录 # 检查文件夹是否存在,如果不存在则创建 create_file(output_dir_vi, output_dir_ir) # 获得需要转化的图片路径并生成目标路径 image_filenames_vi = [(os.path.join(dataset_dir_vi, x), os.path.join(output_dir_vi, x)) for x in os.listdir(dataset_dir_vi)] image_filenames_ir = [(os.path.join(dataset_dir_ir, x), os.path.join(output_dir_ir, x)) for x in os.listdir(dataset_dir_ir)] # 转化所有图片 print('Start transforming vision images...') for path in tqdm(image_filenames_vi): update(path[0], path[1]) print('Start transforming infrared images...') for path in tqdm(image_filenames_ir): update(path[0], path[1]) 

4、制作Yolo目标检测需要的数据集文件

4.1、下载DroneVehicle的coco格式的检测框标签文件

4.2、通过标注软件将coco格式的标签文件转为VOC格式的标签文件

这里我用的是X-AnyLabeling作为标注软件。

4.3、处理VOC格式的标签文件并转成Yolo格式的标签文件

处理该数据集标签文件时发现部分检测框的位置可能会在图片边缘外面,导致直接转成YOLO的时候,会出现负坐标或者大于1的坐标值,这样会导致模型训练不了或者存在一定问题,所以对该部分检测框在转换时需进行特殊处理。注意:X-AnyLabeling也可以直接导出YOLO格式标签,但是经测试X-AnyLabeling也没有处理大于1的坐标值。

xml2txt.py

import xml.etree.ElementTree as ET import shutil import os import imagesize # 定义识别目标或类集合 object = 'datasets' # 根据自定义的数据集名称 if os.path.exists("./%s/labels/"%object): # 如果文件存在 shutil.rmtree("./%s/labels/"%object) os.makedirs("./%s/labels/"%object) else: os.makedirs("./%s/labels/"%object) sets = ['train', 'val'] # 修改类别(自定义) classes =["car", "truck", "bus", "van", "freight_car"] def convert(size, box): # 坐标信息归一化至0-1 dw = 1. / size[0] dh = 1. / size[1] x = (box[0] + box[1]) / 2.0 y = (box[2] + box[3]) / 2.0 w = box[1] - box[0] h = box[3] - box[2] x = x * dw w = w * dw y = y * dh h = h * dh return (x, y, w, h) def convert_annotation(image_id): in_file = open('./%s/xml/%s.xml' % (object,image_id)) # xml文件 out_file = open('./%s/labels/%s.txt' % (object,image_id), 'w') # txt文件 image_file = open('./%s/images/%s.jpg' % (object,image_id)) # pic文件 print("in_file,",in_file) tree = ET.parse(in_file) # f = open(in_file.name,encoding="utf-8") # tree = ET.parse(f) root = tree.getroot() size = root.find('size') # 这里的width 和 height 在Autolabelimg下自动标注可能会被修改,需替换成图片的真实宽高 # w = int(size.find('width').text) # h = int(size.find('height').text) w, h = imagesize.get(image_file.name) for obj in root.iter('object'): difficult = obj.find('difficult').text cls = obj.find('name').text if cls not in classes or int(difficult) == 1: continue cls_id = classes.index(cls) # 类别序号 xmlbox = obj.find('bndbox') xmin = float(xmlbox.find('xmin').text) xmin = xmin if xmin >= 0 else 0.0 # 左上角x坐标如果小于0都化成0 xmax = float(xmlbox.find('xmax').text) xmax = xmax if xmax <= w else float(w) # 右下角x坐标如果大于图片宽度了都为图片宽度值 ymin = float(xmlbox.find('ymin').text) ymin = ymin if ymin >= 0 else 0.0 # 左上角y坐标如果小于0都化成0 ymax = float(xmlbox.find('ymax').text) ymax = ymax if ymax <= h else float(h) # 右下角y坐标如果大于图片高度了都为图片高度值 b = (xmin,xmax ,ymin ,ymax) bb = convert((w, h), b) # 归一化 out_file.write(str(cls_id) + " " + " ".join([str(a) for a in bb]) + '\n') for image_set in sets: if not os.path.exists('./%s/labels/'%object): os.makedirs('./%s/labels/'%object) image_ids = open('./%s/ImageSets/%s.txt' % (object,image_set)).read().strip().split() list_file = open('./%s/%s.txt' % (object,image_set), 'w') for image_id in image_ids: list_file.write('./images/%s.jpg\n' % (image_id)) # 要注意图片的后缀名是什么 convert_annotation(image_id) list_file.close() 

 4.4、按上述步骤处理train、val、test三个数据集文件

我在这里只处理可见光部分的数据集,红外光数据集处理跟该处理方式相同。
我的处理思路:
1)因为不需要测试集,所以我将val验证集的1469个数据和test测试集8980个数据的20%的数据作为我的验证集,即1469+8980*0.2=3265个数据验证集。
2)将train训练集的17990个数据和test测试集8980个数据的80%的数据作为我的训练集,即17990+8980*0.8=25174个数据训练集。
3)整理我的训练集和验证集

此时数据集已是YOLO格式,可以直接训练。

5、在Yolo11网络中训练

我选择了yolo11s的网络权重进行模型训练,训练100个epoch结果如下:

可以看到训练结果还不错。

验证集上标签可视化:

6、使用训练好的模型进行预测

第一张图片是val验证集中找的,第二张图片是网络上随便找的,检测结果比较理想。

7、结语及注意事项

虽然从训练结果上看效果还不错,但是仅针对于该种无人机航拍视角下,如果是斜视视角则效果较差。其次红外光下的检测效果目前还没测过,以及可见光和红外光融合检测效果也未经测试。

需要注意的点:处理白边、处理在图片边缘外的检测框问题。

 

Read more

高性能加法器的FPGA综合优化策略

以下是对您提供的技术博文进行 深度润色与结构重构后的专业级技术文章 。全文已彻底去除AI痕迹、模板化表达和生硬术语堆砌,转而以一位 深耕FPGA架构设计十年以上的资深工程师口吻 娓娓道来——既有对器件原语的“手感”理解,也有项目踩坑后的实战反思;既讲清“怎么做”,更说透“为什么这么干才对”。语言精炼、逻辑闭环、案例真实、代码可复用,符合一线研发者阅读习惯与工程决策需求。 加法器不是“写个+号就完事”的电路:我在Zynq Ultrascale+上把1024点FFT加速器的加法瓶颈砍掉76%功耗的真实过程 去年冬天,我们在做一款面向5G小基站的实时FFT加速IP核时,遇到了一个看似简单却卡了整整三周的问题: Vivado综合后WNS = -2.4 ns,布局布线死活不过,结温飙到98°C,风扇狂转像拖拉机……而问题根源,就藏在蝶形运算里那几行 assign sum = a + b; 。 这让我意识到:很多工程师(包括曾经的我)对加法器的认知,还停留在“

FPGA中加法器资源利用深度剖析

FPGA中加法器资源利用深度剖析:从底层硬件到高效设计 在数字系统的世界里, 加法器 看似平凡无奇——它只是把两个数相加。但在FPGA的舞台上,这个“最基础”的模块却扮演着举足轻重的角色。无论是信号处理中的累加、FFT蝶形运算里的核心操作,还是神经网络推理时的偏置叠加,几乎每一项复杂计算的背后都离不开成百上千次的加法执行。 而真正决定一个FPGA项目成败的,往往不是你写了多少行代码,而是这些加法器 跑得多快、占了多少资源、能不能上200MHz甚至更高频率 。更关键的是:同样的功能,不同实现方式可能导致性能差出3倍以上。 本文将带你深入Xilinx与Intel FPGA的内部架构,揭开加法器背后的硬件真相。我们将不再停留在HDL语法层面,而是从 查找表(LUT)如何构造一位全加器 讲起,逐步解析快速进位链的工作机制、DSP Slice中的专用加法路径,并结合实战案例说明如何避免综合工具“误判”而导致资源浪费或时序失败。 这不是一篇教你怎么写 a + b 的文章,而是一篇教你 让每一个加法操作都物尽其用 的技术指南。 加法器的本质:不只是“+”这么简单 当我们写下: ass

PRIDE-PPPAR终极指南:多系统GNSS精密定位开源解决方案

PRIDE-PPPAR是武汉大学GNSS研究中心开发的一款革命性开源软件,专门解决全球导航卫星系统精密单点定位中的模糊度解算难题。作为多系统GNSS数据处理领域的先进工具,该软件基于GNU General Public License v3协议发布,为科研工作者和工程技术人员提供了强大的数据处理能力。 【免费下载链接】PRIDE-PPPARAn open‑source software for Multi-GNSS PPP ambiguity resolution 项目地址: https://gitcode.com/gh_mirrors/pr/PRIDE-PPPAR 传统定位瓶颈与PRIDE-PPPAR的突破 在传统GNSS定位中,相位模糊度问题一直是制约精度的关键因素。PRIDE-PPPAR通过创新的算法设计,成功实现了全频段PPP-AR功能,让用户能够在任意双频电离层自由组合上进行高效作业。这种突破性技术为用户带来了前所未有的数据处理灵活性。 核心技术特性详解 多系统兼容性支持 软件全面支持GPS、GLONASS、Galileo、BDS-2/3和QZSS等主流导

机器人灵巧手:技术演进、市场格局与未来前景

机器人灵巧手:技术演进、市场格局与未来前景

机器人灵巧手:技术演进、市场格局与未来前景 机器人灵巧手作为具身智能的”最后一厘米”,正经历从实验室技术到产业化落地的关键转折点。2025年,全球灵巧手市场规模已达63.39亿元,中国市场规模更高达501.33亿元,年复合增长率超过300%。随着特斯拉Optimus Gen3等产品的量产计划推进,灵巧手技术正向”全感知”和”自适应”方向发展,逐步突破”性能、成本、可靠性”的”不可能三角”。从驱动系统看,空心杯电机和微型丝杠+腱绳传动方案成为主流;感知系统则通过触觉传感器与AI视觉融合实现突破。产业链国产化率已达70%以上,核心部件如空心杯电机、谐波减速器、传感器等均实现自主可控。未来5-10年,灵巧手有望从工业制造向家庭服务、医疗康养、特种作业等多元场景扩展,2030年全球市场规模预计达450亿元,2035年销量将突破百万只,迎来百亿级市场。 一、技术发展路径与核心模块创新 灵巧手技术发展经历了三个主要阶段:1970-1990年的基础结构阶段,1990-2020年的系统集成阶段,以及2020年至今的”全感知”和”自适应”