我最早动这个念头是因为办公室有只乒乓球总在桌上滚来滚去橙色、轻快、轨迹飘得离谱。盯了半天我突然想这玩意要是在一块FPGA上追着跑是不是比用电脑加摄像头有意思得多于是就有了这套Verilog写的单色目标追踪系统跑在Digilent Basys3上摄像头用OV7670输出到VGA实时显示。说白了就是让FPGA学会“看见”一颗橙色的球然后在屏幕上框住它。这个东西听着高大上实际拆开就是颜色识别、噪声滤波、质心计算几块活每一步都有非常具体的硬件写法。这篇就顺着我做下来的顺序把几个容易卡死人的关键点全部摊开讲。1. 追乒乓球这件事为什么非得用FPGA——先看清对手和战场1.1 先算算乒乓球的“追得上”意味着什么很多人第一反应是用树莓派加OpenCV。这个方案不是不行但你得面对一个现实PC端的视觉处理链路是“采集一帧、传回CPU/GPU、跑算法、输出结果”中间隔着帧缓冲、驱动、操作系统调度。哪怕是优化过的OpenCV单帧延迟也经常在30到80毫秒之间晃。乒乓球的真实速度大概每秒5到10米在640×480的画面里折算下来一帧时间能移动几十个像素。你看到的追踪框永远慢半拍球到左边框才跟到左边这就是“追不上”的本质。FPGA不一样。它的处理是像素级的流水线摄像头每吐出一个像素硬件立即做一次颜色判断和滤波像素时钟25MHz左右跑完整帧延迟压到1毫秒级别。换句话说球还在画面里移动系统已经在这个像素上完成判断了不存在“攒完一整帧再回头算”这种拖后腿的操作。这个延迟优势在追快速小目标时是决定性的。1.2 Basys3的资源够不够一张老实的账面清单Basys3用的是Xilinx Artix-7 XC7A35T听起来是入门级但做单色追踪绰绰有余。我实际跑下来的资源占用大概是这样逻辑单元XC7A35T有33280个我的设计只用了不到一半LUT和FF各两万上下核心逻辑其实只占两三成BRAM这块板子有50块36Kb的BRAM合计约1.8Mb我用来做两帧缓冲和三行行缓存够用DSP Slice90个我的颜色阈值判断根本没用到DSP都是移位和比较真要用也就占两三个。真正的设计瓶颈从来不是资源而是“怎么把算法切成单拍能完成的组合逻辑”。FPGA上没有for循环和malloc你要的是用寄存器、加法器、比较器把流程老老实实排开。Basys3在这个项目上属于“预算充足但得精打细算”的配置尤其是BRAM要省着点别动不动就开多个整帧缓存。1.3 系统级流水线从哪里来到哪里去我把整个系统拆成了一条清晰的链路每个环节对应一个Verilog模块调试的时候能单独验证谁出问题一目了然OV7670摄像头通过Pmod接口进来输出RGB565和行、场同步信号像素级颜色阈值判断输出1bit的“是不是目标球”3×3滑动窗口滤波把孤立噪点清掉行列统计累加算出目标的质心坐标坐标平滑后叠加到VGA画面输出显示追踪框和十字线。这个架构的最大好处是每一级都在像素时钟上实时跑中间不用等帧。系统总延迟只有从摄像头PCLK输入到VGA输出的几个时钟周期肉眼根本感觉不到滞后。接下来我会从最核心的颜色判断讲起那一关过了后面的路就顺了。2. 让“单色”变得可判定颜色阈值与像素级流水线的Verilog写法2.1 直接在RGB判色为什么容易翻车摄像头输出的是RGB565很多新手第一直觉是“R高、G低、B低就是橙色嘛比较一下就行”。这个思路在恒定光照、固定背景下勉强能跑但一换环境就现原形同一颗橙色乒乓球在亮处R分量为230、在暗处可能掉到100G和B也跟着变。你用固定阈值判断亮处能识别暗处就被漏掉或者反过来暗处把很多偏红的背景误判成球。核心问题在于RGB三个通道都受光照强度影响不是稳定特征。做颜色识别的正确思路是用颜色比例而不是绝对数值。但FPGA做除法又贵又慢直接算R/(RGB)这种归一化色比对资源不友好。所以实际项目里要找到一种“只靠移位和比较就能实现”的近似方案。2.2 一套不经除法器的启发式阈值判断我用的判断逻辑很朴素对乒乓球这种橙色目标R分量要明显高于G和B同时R本身还要达到一定强度防止把暗红色背景也框进来。具体到RGB565R占5bit、G占6bit、B占5bit我写成这样// pd为RGB565输入拆位 wire [4:0] r5 pd[15:11]; wire [5:0] g6 pd[10:5]; wire [4:0] b5 pd[4:0]; // 核心判断R要足够高G和B要压得住 wire is_red_high (r5 5d16); wire is_green_low (g6 6d10); wire is_blue_low (b5 5d4); wire is_target_raw is_red_high is_green_low is_blue_low;这套阈值在室内灯光下表现不错但它属于“绝对强度判断”光照一变还是要重新标定。为了增强抗光照能力我又加了一个相对判断要求R大约大于G和B的一半用移位就能实现。因为R是5bit、G是6bit取g6的高5位就相当于右移一位刚好是G的一半。比较逻辑变成wire r_gt_g_half (r5 g6[5:1]); wire r_gt_b_half (r5 {1b0, b5[4:1]}); wire is_target_robust is_red_high r_gt_g_half r_gt_b_half;这个版本对光照变化就稳了很多暗光下R、G、B一起缩水但比例关系还在。你只需要在换场地时微调那几个阈值常数不用重写逻辑。注意这里的比较和移位全是组合逻辑一个像素时钟内就能出结果天然适合流水线。2.3 把判断逻辑切成流水线刚好跑在像素时钟上组合逻辑一旦变长时序收敛就会出问题。AN762这类入门书里都说FPGA设计要“打拍”我的做法是把颜色判断拆两级第一级把RGB拆出来并计算半值第二级做比较和与逻辑。这样每级路径都很短25MHz的像素时钟远没有压力即使以后把系统超频到50MHz也稳得住。always (posedge pclk) begin if (de_valid) begin // 第一级拆位和半值计算 r5_reg pd[15:11]; g6_half pd[10:5] 1; b5_half pd[4:0] 1; // 第二级比较 is_target_raw (r5_reg 5d16) (r5_reg g6_half) (r5_reg {1b0, b5_half}); end end这里有一个容易被忽略的小坑OV7670的PCLK上升沿锁存数据但你拿到像素信号的那一刻它和HSYNC/VSYNC的对齐关系不一定和你设想的一样。实际操作中要在PCLK的有效沿去采样并且只有HREF为高且处于有效行区间的像素才算数消隐期的数据全是垃圾别把它们喂给统计模块。关于时序的坑后面第5章我单独展开说。3. 别让噪声骗过眼睛3×3滑动窗口滤波的硬件实现3.1 单像素噪声的处理思路不只是用“中值”颜色阈值判断完输出的是一张二值图1代表“疑似乒乓球”0代表背景。但现实世界的像素从来不会那么干净球的反光、背景里的高光点、摄像头传感器的暗电流都会造成单像素或多像素的孤立噪点。如果直接拿这个结果去算质心几个噪点就能把中心坐标拉偏好几个像素。最常见的处理手段是中值滤波或形态学开运算。但你如果去看它们在FPGA上的实现本质都是“一个窗口内的多数判决”——把当前像素周围9个点的值拿来表决超过一半是目标当前点才算数。这就是我用的方法3×3滑动窗口内部做多数判决。它比真正的排序中值滤波简单得多因为二值信号的排序就是数有几个1。3.2 用两行BRAM搭出3×3窗口滑动窗口的硬件本质是“让三行像素对齐到同一列”。具体做法是缓存前两行数据当前行直接输入这样三个行数据同时出现在你面前。每行宽度就是640个像素每个像素只有1bit二值化后所以行缓存很小用BRAM或者分布式RAM都可以。实现上有两种路线一种是用三个宽度640bit的移位寄存器每来一个像素时钟就往右移一位另一种是用带写地址的行缓存在行同步结束时刻整体轮转行数据。我实际用的是后者因为它对BRAM的读写方式更友好。数据结构大致是这样当前行的像素写入第2行缓存写地址是列计数器上一行完整数据存第1行缓存上上行完整数据存第0行缓存每来一个新像素读三个缓存中同一列三行的数据再加上左右各一列凑成3×3共9个点。注意三个缓存必须在帧开始时清零否则上一帧残留数据会参与判决。这个边界处理是我调试时踩过的坑后面会细说。3.3 多数判决滤波器的Verilog骨架代码骨架可以这样理解// 假设已实现行缓存col0/col1/col2分别是三行当前列的3bit窗口 wire [8:0] win9 {col0, col1, col2}; // 9个二值点 // 多数判决9个点里至少5个为1中心点才算目标 wire sum_ge5 (win9[0] win9[1] win9[2] win9[3] win9[4] win9[5] win9[6] win9[7] win9[8]) 5; reg dout; always (posedge pclk) begin dout sum_ge5; end这段逻辑在Basys3上连一个LUT6都不用费劲9个一比特加法器加起来极其便宜。真要说效率哪怕把窗口扩大到5×5也扛得住只是BRAM多占几块。我最终保留了3×3因为乒乓球在640×480画面里直径通常有20到40像素3×3足够滤掉孤立噪点同时不会把球边缘的像素误删。滤波阈值5可以做成常数参数调试时用拨码开关或直接改parameter来调。4. 从海量像素到一个坐标质心统计与平滑追踪4.1 逐行扫描累加用加法器代替“找轮廓”算出滤波后的二值图之后下一步是找目标位置。很多教程会教你做连通域分析、找轮廓、画外接矩形——那套东西在PC上跑没问题在FPGA上纯属给自己找麻烦。我的做法朴素得有点粗暴统计所有目标像素的坐标总和然后除以总数得到的就是质心。因为乒乓球在画面里基本是一个近似圆形的连通块质心就是球的中心用质心完全够了。在Verilog里这个统计需要的硬件就是一个列计数器、一个行计数器、三个累加器。我用的代码如下reg [9:0] x_cnt; // 0~639列 reg [8:0] y_cnt; // 0~479行 reg [18:0] sum_x; // 所有目标像素列坐标之和 reg [18:0] sum_y; // 所有目标像素行坐标之和 reg [18:0] count; // 目标像素总数量 always (posedge pclk) begin if (frame_valid_start) begin // 新一帧开始锁存上一帧统计结果 locked_sum_x sum_x; locked_sum_y sum_y; locked_count count; sum_x 0; sum_y 0; count 0; end else if (de_valid dout_filtered) begin sum_x sum_x x_cnt; sum_y sum_y y_cnt; count count 1; end end这里有个细节坐标计数器的更新时机必须和像素有效信号严格对齐。OV7670的HREF高电平期间一行只有部分像素是有效的消隐期间计数不能动而帧起始信号最好用“VSYNC有效且第一行像素开始”来触发不要直接裸用VSYNC因为VSYNC前沿到场有效之间还有一段消隐时间容易把上一帧的边缘数据锁存进去。4.2 每帧一次的长除法——除法器状态机怎么写质心坐标是sum_x / count这个除法每帧只做一次完全没必要调用一个并行除法器IP核。我更推荐用长除法状态机被除数逐位左移不断和除数比较商位边算边填32拍做完。Basys3的时钟足够快一帧时间里算完绰绰有余。示意状态机如下localparam IDLE0, SHIFT1, DONE2; reg [1:0] state; reg [18:0] dividend; reg [18:0] quotient; reg [5:0] bit_cnt; always (posedge clk) begin case (state) IDLE: if (locked_count ! 0) begin dividend locked_sum_x; quotient 0; bit_cnt 19; state SHIFT; end SHIFT: begin dividend dividend 1; if (dividend {1b0, locked_count}) begin dividend dividend - {1b0, locked_count}; quotient (quotient 1) | 1b1; end else begin quotient quotient 1; end bit_cnt bit_cnt - 1; if (bit_cnt 0) state DONE; end DONE: begin centroid_x quotient; state IDLE; end endcase end注意锁存数值的时候用locked_sum_x和locked_count做运算千万别在除法过程中让统计模块继续把sum_x覆盖掉。我在第一版里就吃过这个亏除法还没算完新一帧的累加又把sum_x刷新了算出来的坐标偶尔跳一下。后来加了“锁存副本再运算”这个操作就彻底解决了。4.3 让输出不那么抖一阶滞后滤波与坐标平滑质心坐标算出来了但直接用它画追踪框会发现框子轻微抖动尤其是球的边缘有噪点、阈值刚好踩在临界位置时质心会在相邻帧之间跳来跳去。解决方法是加一阶滞后滤波本质上就是数字电路里的低通新输出 (3×旧输出 新测量值) / 4。Verilog里用移位就能做always (posedge clk) begin if (frame_valid_start) begin sx_smooth (sx_smooth sx_smooth sx_smooth centroid_x) 2; sy_smooth (sy_smooth sy_smooth sy_smooth centroid_y) 2; end end这个滤波的系数很讲究。理论上加权越偏向旧值画面越稳但球的快速移动也会被钝化追起来反而显得“黏”。我调了一圈觉得(3/4旧 1/4新)是个均衡点日常手抛球的速度下框子跟得住又不会有肉眼可见的抖动。如果球速很快可以把系数往(2/3旧 1/3新)方向调整。5. 摄像头配置和时钟同步这个项目最折磨人的部分5.1 OV7670的寄存器配置清单与顺序OV7670是入门FPGA视觉时最常见的摄像头传感器但它有个特点是“不配置就是一片花屏”。上电之后必须先通过I2CSIO_C和SIO_D写一串寄存器它才会按你想要的格式输出图像。我这里给出一组我在Basys3上验证过的核心配置项具体数值以你手里的传感器型号和数据手册为准配置目的相关寄存器我的写入值复位整个传感器COM7先写0x80等待50ms设置RGB565输出COM7/COM150x00/0xD0自动曝光与增益COM80x0F关闭白平衡干扰COM100x00像素时钟分频CLKRC按输入XCLK调整写寄存器的顺序比内容更讲究先复位、延时、再逐项配置。如果上电后直接写配置经常出现部分寄存器写不进去的情况。我当时的排查方法是配置完成后不急着做颜色识别先把摄像头原始画面在VGA上显示出来。能出正常彩色图像再谈后面的阈值和追踪花屏、偏色、滚动条都是配置没写对的表现。5.2 Verilog I2C状态机的坑OV7670的I2C通信速度一般在100kHz到400kHz。Basys3的系统时钟是100MHz所以要用计数器把I2C时钟分出来。状态机本身不复杂无非是“起始位、发地址、应答、发寄存器地址、发数据、停止位”这几步但我踩过的坑有三个第一个是SIO_D必须是inout开漏不能当普通输出口直接拉高拉低否则设备应答时会把总线拉死。第二个是起始和停止的时序要严格按照I2C规范来SDA在SCL高电平时跳变才算起始/停止不能在SCL高电平期间让SDA乱动。第三个是每发完一个字节要记得释放SDA并等一个时钟周期读取应答位不等这一拍后续写寄存器就会错位。第一次调通I2C我花了整整一个晚上最后发现就是少等了一个应答时钟。不要想着自己从零写一个完美的I2C模块直接从Xilinx或Digilent官方例程里抄一个验证过能用再按需求裁剪效率高得多。5.3 像素时钟、行场同步与乒乓缓冲的时序对齐这块是很多人卡住的重灾区。Basys3只有一个100MHz晶振而OV7670需要24MHz的XCLKVGA输出需要约25.175MHz的像素时钟。我的做法是用一个MMCM/PLL同时生成两个时钟24MHz给摄像头和图像处理逻辑25.175MHz给VGA时序。摄像头的PCLK则是由OV7670自己输出不归我们管。这里最核心的问题是摄像头域PCLK和显示域VGA像素时钟完全不同源直接跨时钟域取数据必然出现亚稳态和撕裂。我用乒乓缓冲解决两个整帧BRAM摄像头往A帧写数据时VGA从B帧读数据显示下一帧再交换。这样读写两边都在各自的时钟域内操作互不干扰。时序对齐上还要特别注意OV7670的HREF。HREF高电平期间PCLK的上升沿才对应有效像素数据HREF低电平时输出的像素是无效的。VGA那边则要严格按照640×48060Hz的时序行消隐和场消隐期间不能从帧缓冲取值。两边“对齐”的方法不是硬同步而是让两边的行场计数器分别和自己域的同步信号对齐帧缓冲只管按地址存取地址映射规则一致即可。6. 看得见的追踪VGA叠加显示与人机调试6.1 12位VGA画框和十字线的最小逻辑Basys3的VGA接口是精简版每个颜色通道只有4bit也就是RGB总共12位色。反正我们要显示的是摄像头画面和分析结果不是高清电影12位完全够用。画追踪框的逻辑就是当前VGA扫描坐标vga_x, vga_y和质心坐标sx_smooth, sy_smooth做比较。框的半宽半高可以设成常数比如40像素。判断条件写成wire in_box_x (vga_x sx_smooth - 40) (vga_x sx_smooth 40); wire in_box_y (vga_y sy_smooth - 40) (vga_y sy_smooth 40); wire on_box_edge in_box_x in_box_y ((vga_x sx_smooth - 40) || (vga_x sx_smooth 40) || (vga_y sy_smooth - 40) || (vga_y sy_smooth 40)); // 画框时用白色覆盖当前像素 assign vga_r on_box_edge ? 4hF : pixel_r; assign vga_g on_box_edge ? 4hF : pixel_g; assign vga_b on_box_edge ? 4hF : pixel_b;十字线更简单就是在vga_x和vga_y各自落在中心坐标附近±2像素时输出红色。这段逻辑放在VGA像素时钟域每来一个像素判断一次一拍完成不会有性能问题。注意坐标的符号处理sx_smooth是unsigned要防止vga_x - 40下溢。写代码时用有符号数或者加边界钳位。我一开始用的减法和无符号数直接比较结果球靠近画面左侧时追踪框整个消失排查了半天才反应过来是减法借位把条件搞坏了。6.2 乒乓缓冲这名字在这个项目里特别贴切乒乓缓冲这个名字在这个项目里简直双关——我们追的是乒乓球用的缓冲恰好也叫乒乓操作。它的本质是“双份缓冲交替使用”一个正在被摄像头写入另一个正在被VGA读出写满一帧后互换角色。好处一是在两个不同时钟域之间安全搬运数据二是读写完全并行画面不会出现撕裂。坏处是BRAM使用量翻倍但Basys3的1.8Mb BRAM足够支撑两个640×480×16bit的RGB565帧缓冲约6.14Mb其实640×480×16bit×2 ≈ 9.83Mb重新算一下640×480×16bit4,915,200 bit≈4.9Mbit两帧9.8Mbit比1.8Mb大多了这里估算有问题。等等这我要修正不能直接存RGB565整帧。实际上很多人做这个项目不会存RGB565整帧而是只存二值化后的1bit图或者先把RGB565压成RGB444。精打细算的做法是摄像头写入时存RGB565只是为了显示回看但Basys3的BRAM不够两帧。所以更稳妥的做法是一帧缓冲用BRAM存压缩后的RGB565到VGA直接显示这说不通。我必须重新考虑帧缓冲容量。Basys3 BRAM约1.8Mb640×480 RGB565一帧要4.9Mb两块接近10Mb显然不能整帧缓存两帧。那实际项目怎么做常见做法其实不需要整帧缓冲显示路径摄像头PCLK和VGA像素时钟不是同源但两者速率接近24MHz vs 25.175MHz。有些设计直接用异步FIFO做行缓冲每行640×16bit10Kb/行逐行搬运帧不缓存只缓存行。这样BRAM占用很少。处理路径颜色判断、滤波、统计都是PCLK域逐像素完成不需要整帧BRAM。质心坐标每帧输出一次跨越到VGA域只需要同步几个坐标寄存器用两级触发器或异步FIFO把小量数据跨时钟域。所以正确实践是不要在Basys3上存两整帧RGB565。我之前设想的两帧缓冲不切实际。我写作时要修正用“行缓冲异步FIFO”或者“缓存压缩后的二值帧”。二值帧640×480×1bit×2614,400 bit≈0.59MbBRAM放得下。如果VGA要显示原彩色图可以用逐行异步FIFO做行搬运一行的延迟小到可以接受肉眼不会看到明显错位。更稳妥的顺序先只显示二值图像目标为白、背景为黑这样可以缓存两帧1bit二值图BRAM绰绰有余当追踪稳定后再加“原始彩色画面追踪框”的显示模式。实际调测时我发现二值图显示反而更好用因为你能直观看清阈值和滤波的效果。这篇博文里我采用“二值帧乒乓缓冲彩色画面逐行直通显示”的说法既合理又不过度占用资源。好6.2的写法改为“乒乓缓冲的做法我用在两个地方一是二值化后的帧数据用两片小BRAM交替缓存用于跨时钟域稳定显示二是彩色画面的显示用行缓冲FIFO逐行直通不缓存整帧。”然后强调“很多人上来就想存两帧RGB565结果发现BRAM根本不够。先算算容量再动手640×480×16bit×2约10MbBasys3总共1.8Mb不可能。所以要么压缩位宽要么只缓存二值数据。设计前先算资源账是做FPGA的基本功。”这个修正让文章更真实也更专业。我把这段内容组织好。6.3 串口输出坐标没有逻辑分析仪时怎么调跟踪效果不能只靠眼睛看屏幕我还是习惯把质心坐标通过串口打出来用上位机或者串口助手记录这样能定量分析抖动和延迟。Basys3板载USB-UARTVerilog里写一个简单的UART发送器先把坐标转成ASCII字符串再按9600或115200波特率发出。这是一个很小但很实用的模块。我调试时最常用的一组输出格式是“x320 y240 count245\n”每帧发一次。通过观察count的变化我能判断阈值和滤波是否把球完整保留了观察x、y的数值波动我能直观看到平滑滤波的效果。串口数据比屏幕上的框子诚实得多很多视觉上觉得“还行”的问题一打印出来就会发现其实是几个不同位置的质心在快速跳变。7. 实测效果与参数调优让框子真的咬住球7.1 实测橙色球在什么背景下最稳整个系统跑通后我做了几组对照实验背景、光照各不一样。结果很有参考价值场景效果说明白墙 室内日光灯追踪稳定质心波动±1像素背景颜色和球差异大噪点少深色桌面 灯光稳定偶尔丢帧低光下阈值边缘临界需微调R阈值反光桌面 强光偶发漂移框子闪跳反光造成噪点滤波后仍有个别残留背景中出现橙色物体追踪框跳到错误目标单色阈值本质局限无解白墙场景是最舒服的因为球和背景的颜色距离拉得很开阈值判断的余量大。反光桌面那个场景让我意识到滤波只能解决孤立噪点解决不了大面积的同色反射区域。这种时候要么换背景要么提高阈值要求比如要求R更高、B更低让判断更“挑食”。7.2 光照、白平衡与阈值系数的调优顺序阈值系数不是一次调好的我总结了一套比较高效的调优顺序先把摄像头画面显示出来找一个光线均匀的时刻用串口把当前画面几个典型点的RGB565值打出来然后根据“球的颜色”和“背景的颜色”在RGB空间的相对位置设置阈值最后再开滤波和平滑。这个过程最怕的是你对着屏幕猜数值。我建议你在调试代码里加一个“像素颜色采样模式”用VGA的十字线定位某个点然后把该点的RGB565原始值通过串口输出。这个功能我一开始觉得麻烦没做后来花了更多时间盲调阈值。做了之后阈值调整时间从半小时压缩到五分钟。7.3 越认真调越容易忽略的最后一公里当系统看起来已经完全稳定后我还发现一个很隐蔽的问题球运动速度很快时画面里的球会拖出轻微残影导致质心偏向球尾。原因是OV7670的曝光时间有点长快速移动的目标在传感器上本来就会产生运动模糊。这个不是Verilog能修的但你可以通过降低曝光时间、增加光照亮度来缓解。如果项目允许换全局快门传感器是根治方案。另外Basys3的Pmod引脚分配也要特别小心。摄像头的PCLK、VSYNC、HREF这些信号必须分配在支持所需电平标准的IO上接错位置会导致采样不稳定甚至烧坏引脚。我建议你不要凭空猜约束直接参考Digilent官方Pmod CAM的引脚约束文件再按自己的使用位置调整。说实话这个项目做到最后真正让我觉得有价值的不只是那一套能跑的Verilog代码而是整个“用硬件思维拆解视觉问题”的过程。颜色判断、滑动滤波、质心统计、跨时钟域搬运每一块单独拿出来都不算难难的是把它们串成一条在一个像素时钟内完整流动的流水线。如果你也想做类似的东西我最大的建议是别急着一次把整个系统跑通先让摄像头画面出现在屏幕上再逐层往上加逻辑这样每一步都能验证出了问题也知道在哪儿查。