先交代一下背景。这个项目是在朋友球房里折腾了大半年的成果起因也很现实——球房里的积分赛靠人肉眼计分漏判、争执、记错盘经常让人头大偏偏台球这项运动对计分准确性要求极高。我当时就琢磨能不能在球台正上方装一个俯视摄像头配合视觉识别和球体跟踪直接把整局球的进出袋过程自动记下来。今天这篇就把整个AI台球自动计分系统的方案选型、硬件部署、算法实现、排查经验一次说透给想做类似项目的朋友一条能直接踩上去的路。1. 整体设计与方案选型1.1 为什么俯视相机是最稳的感知方式台球自动计分说白了就两个硬需求看得到每颗球在哪判断出哪颗球进了哪个袋。市面上有几种思路有人在台呢下面埋压力传感器有人给球装RFID芯片还有人在球台侧面架摄像头。传感器方案布线麻烦RFID要在球里嵌芯片成本高侧面相机最大的问题是视线遮挡太严重球员俯身击球时手和身体几乎能把半张球台挡死。俯视相机走的是完全不同的路子把相机架在球台上方正中央垂直向下拍摄整个台面就是一张干净的正射影像球、袋口、库边全在一帧画面里天然绕开了遮挡问题。只要高度够、畸变校正到位俯视图就是一套极其标准的坐标系统,每颗球都能换算成台面上的物理位置后续跟踪和计分全部基于坐标运算逻辑能简化一大截。1.2 系统架构与核心模块划分整套系统我拆成了四个模块各管一段图像采集模块负责预览画面和帧同步标定与预处理模块负责把畸变画面还原成真实比例、固定识别区域球体检测与跟踪模块在每一帧里找出球、给球编号、持续跟踪位置计分裁判模块在检测到进球事件后验证合法性、更新比分、处理复位。模块之间通过一个简单的共享内存队列通信检测模块每处理完一帧就把结果推给跟踪模块跟踪模块维护所有球的动态状态。这样拆的好处是每个环节都能独立调试比如检测不准时可以直接看检测模块输出的人工标注图不用连带着去翻跟踪逻辑的账。2. 硬件部署与图像预处理2.1 机位高度、相机选型与安装细节先说结论我最终用的是4K分辨率、最大30帧的USB工业相机配合6mm定焦镜头安装在球台正上方2.9米的位置视角能完整覆盖2540×1270毫米的台面内沿四周还留出一点余量看到全部6个袋口的外缘。为什么是2.9米而不是更低因为台球桌上方往往还有球灯灯架本身高度就在2.5米左右相机再低就要撞到灯再高又可能顶到天花板。这个位置实测下来单颗球在4K画面里能占到70像素左右完全足够识别颜色和球号袋口区域也能看得清清楚楚。装支架时最容易被忽略的一点是固定刚性别用那种可伸缩的自拍杆改装的架子每次球员大力击球、球体撞击库边时振动都会传到相机上哪怕只抖0.5像素对跟踪稳定性都是灾难。我后来换成了三角形钢结构支架固定在天花板承重梁上和球台完全独立彻底断了振动传递的路。相机供电和数据线也值得单独说。USB线超过5米就必须用带信号放大器或者光纤USB线否则帧率不稳定、偶尔丢帧排查起来非常痛苦。我用的10米主动式光纤USB3.0线实测稳定。另外强烈建议配一个工业级电源给相机独立供电别和球房的灯光共用回路不然灯光启动瞬间的压降会让相机掉线一掉线整场自动计分就中断了。2.2 镜头畸变校正与透视标定流程任何广角镜头拍出来的画面都有明显畸变尤其是球桌面这么大边缘的球会变形直接拿原始画面做坐标计算离中心越远误差越大。所以标定这步不能省。我用的是张正友标定法具体做法打印一张10×7的黑白棋盘格每个格子边长25毫米在台面上平铺、倾斜、旋转各拍几十张图用OpenCV的calibrateCamera提取角点计算出相机内参和畸变系数最后得到initUndistortRectifyMap的映射表。这一步做完画面边缘的直线都变成直线球从画面中心到边缘都保持正常的圆度。透视标定同样关键。俯视相机如果装得很正几乎可以当纯平面处理但实际安装时难免有一点倾斜这个时候就需要做透视变换。我在台面上固定四个标志点分别选在四颗袋口的内沿交点位置用它们的像素坐标跟实际桌面的物理坐标做一个单应矩阵Homography把图像坐标投影到标准的物理坐标系。打完这一个矩阵后后面所有计算都在物理坐标里进行球的真实速度、袋口距离都是毫米级概念做进球判定和规则判断时直接能用上真实尺度。2.3 灯光环境处理与拍摄参数固化球房灯光对视觉识别来说是把双刃剑。光线充足能提升球与台呢的对比度方便分离目标但灯光的直射反光会把球的颜色区域打出高光尤其新刷的台呢很亮高光区会“吃掉”球的边缘信息。我的处理办法是给相机加偏振镜在镜头前装一块线偏振片调整角度后能滤掉大部分非金属表面的镜面反射。另一个更省事的方案是尽量使用漫反射灯带或者在球桌上方加一块柔光布把硬光打散实测下来球体表面高光占比能降低百分之六七十。拍摄参数必须固定。相机设为手动模式曝光时间1/500秒左右光圈按现场亮度调到F4到F5.6ISO尽量低到100白平衡手动固定为5200K。为什么曝光要快因为球员击球瞬间白球速度可能超过3米每秒在1/500秒曝光下运动模糊能控制在可接受范围。自动曝光和自动白平衡绝对要关掉不然画面亮度随球员衣服颜色变化检测阈值就容易飘这是很多新手项目识别时好时坏的根源。3. 核心算法球体检测与分类3.1 为什么选择传统视觉加深度模型的双层方案台球识别看似简单实际上比想象中要难核心难点是球的颜色多、颜色之间还会互相污染球与球的反射、球员手臂和球杆经常大面积遮挡台面。单靠传统颜色分割很容易在遮挡和反光场景下崩盘单靠深度学习检测模型又对算力有要求而且小目标密集场景下的球体检测精度未必比几何约束下的传统方法高。我最终用的是双层方案先用传统视觉做快速候选区域提取再用轻量深度学习分类器对候选区域做最终类别判定。第一层在HSV颜色空间用阈值分割筛出所有可能存在球的区域第二层对这些候选区域用训练好的分类模型识别颜色和球号。这样既能过滤大量背景干扰又能绕开纯传统方法对阈值的极度敏感同时比直接在整图上跑检测模型快很多。我们训练的分类器输入是40×40像素的球体裁片标签分9类八种花球加一个白球。训练数据是自己采集的把相机架好后拍了大概两万张不同场景下的画面通过自动标注加人工复核的方式整理出来。训练时故意加入各种增广平移、旋转、缩放、亮度扰动还加入了高斯噪声模拟暗光场景。实测在验证集上准确率超过98%对遮挡比较严重、只能看到半个球的场景这种局部裁片分类的效果反而比完整检测好因为裁剪时只截取可见部分遮挡区域不会参与分类。3.2 球体坐标定位与尺寸约束的细节每个候选区域经过分类确认后需要从像素坐标映射到物理坐标。我在检测阶段就用轮廓拟合圆拿到圆心坐标和半径。标准台球直径是57.15毫米在标定好的物理坐标里某个球的理论半径应该是28.575毫米这个固定尺寸是一个非常强的约束条件。跟踪模块会把所有检测结果里半径偏离理论值超过20%的目标直接丢弃能滤掉大量误检比如球杆头部、观众的指尖、台面杂物等。袋口的圆形区域也通过这个方法标注出来六个袋口在物理坐标里各有自己的圆心和半径作为进球判定的锚点。角度和重叠问题也躲不开。当两颗球贴在一起时轮廓会把两个圆合并成一个葫芦形这时直接轮廓拟合会得到错误圆心。我的处理方式是在检测阶段引入分水岭算法做粘连目标分割加上几何约束把合并的轮廓拆成两个圆。如果粘连得太严重比如三颗球挤在一起拆出来的圆心误差还是偏大这种情况下游跟踪模块会用运动模型去修正靠上一帧的位置和速度预测来补偿。3.3 白球跟踪的单独设计白球是整台球的“发动机”每次击球都从白球开始所以白球的连续精确跟踪直接决定计分系统的可靠性。我给白球单独开了一条处理链路跟踪嵌套采用卡尔曼滤波加匈牙利匹配的框架位置和速度都作为状态量预测下一帧出现的区间然后在区间内找检测结果做匹配。白球的优先级最高当白球和其他球重叠导致漏检时系统会持续用卡尔曼预测的位置补位而不是马上判定白球消失。只有当连续预测误差超过一个球的半径、并且连续10帧画面里检测不到白球才认为白球可能进袋或需要重新定位。球房实战里白球贴库、贴袋口是家常便饭这个预测补偿机制非常管用。4. 球体跟踪与进球判定逻辑4.1 多目标跟踪框架与帧间匹配策略球体跟踪本质上是一个多目标跟踪问题。我采用的是经典的检测加关联框架第一层匹配用匈牙利算法基于IOU做全局最优匹配第二层用卡尔曼滤波预测的位置作为补充匹配依据。每颗球维护一份状态当前坐标、速度、置信度、连续未命中帧数、上帧是否有遮挡、是否处于袋口危险区。每帧检测完成后先把检测结果和现有轨迹按IOU匹配IOU大于0.3的直接关联剩下的检测结果再和预测位置做距离匹配距离小于1.5倍球半径的关联最后仍未关联的检测结果视为新目标但新目标必须连续3帧都出现在接近位置才转正避免台面反光等瞬态噪声产生假球。这里有个非常关键的设计跟踪器内部保留“当前置信状态”。每一帧里某颗球被匹配到一次置信度加1连续丢失一帧置信度减2。当置信度低于阈值时该球标记为“丢失”系统进入怀疑状态会在后台继续追踪它的轨迹但不会输出到计分模块。同时考虑球的进洞行为球一旦进入袋口区域边缘它的运动会被袋口边沿减速、反弹轨迹会出现明显异常这时就要触发起一双重验证机制而不是立刻判定进球。4.2 进球判定与袋口确认机制双重的进球判定是这样实现的。第一重球进入某个袋口对应的圆形检测区袋口区域半径设置为袋口物理半径的85%并且球在连续N帧内没有从这个检测区出来那系统先把这颗球标记为“准进袋”。第二重确认球确实从台面消失也就是连续若干帧检测不到这颗球的完整轮廓。只有这两重都满足时才算真正认定进球。为什么要等“消失确认”因为袋口边缘存在视野死角球正好卡在袋口边沿上时俯视图能看到半个球但球并未真正落袋如果只凭进入袋口区就判定进球会频繁误报。测试中卡袋口的场景真实存在而且在关键时刻直接改变比分走向。进球还需要记录落袋时间戳、袋号、球号三个关键信息。时间戳用于后续回放对账袋号用来校验计分规则比如8号球必须进指定袋才算赢球号用于累加得分。每次进球事件产生后系统会保存触发判定前后各2秒的原始视频片段方便人工复核。实测这个回溯机制在球房运营中特别受用减少了大量关于“到底进没进”的争议。4.3 计分规则引擎与复位处理计分规则看似简单真正实现起来有不少坑。国标八球的规则里击球方必须先命中自己的目标球白球不能先碰到对方球白球不能落袋8号球必须在打完己方所有目标球后才能打且必须按指定袋口落袋。这些规则都依赖球的位置关系和进球顺序。我把它做成了一个可配置的规则引擎事件驱动接收进球事件后根据当前比分、桌面球分布、上一杆是否犯规输出下一杆状态。规则引擎本身不写死任何球桌信息用一个JSON配置描述当前局型比如主队球色、是否自由球、黑八状态这样换别的玩法九球、斯诺克只需要换配置不用改代码。每次击球完成后还有一个隐藏动作复位处理。当球员进球后下一杆开始前摆球位置不会变但如果没有进球球员可能重新摆位或者白球被捡起放回开球区。计分系统必须识别这种人工干预。我在开球区设定了一个“白球放回区”如果白球当前状态是丢失并且在开球区检测到一个新的球就判定为人工复位不计进球只更新白球坐标。这个逻辑刚开始没做结果有一次球员打了违规球后自己去摆白球系统直接给你算成进球场面一度很尴尬。5. 常见问题与排查技巧实录5.1 高频故障漏检、误检、球被遮挡跑现场大半年把这几个高频排查点也整理出来了。漏检多数不是因为算法弱而是因为输入画质变差。相机长时间在球房灯光下工作镜头会沾灰画面发雾球的边缘模糊检测置信度骤降。如果某天系统报漏检率明显提升先别急着调参数拿一块镜头布擦一下镜头往往立竿见影。其次是台呢颜色变化。新球房的台呢是全新的翠绿用半年之后会发旧变灰颜色统计模型的背景簇中心会偏移阈值就可能不适配。我在系统里加了一个台面背景自动更新机制每隔一定时间取画面边缘和球洞周边的区域重新估算背景颜色让背景自适应缓慢变化。误检的来源主要是反光和观众区域。在球台边沿的金属和木框上也会产生高光色块看起来很像球尤其是当这些色块正好在袋口附近时会干扰判断。我的对策是给每个候选目标加一个位置合法性检查目标中心必须在台面内沿以内袋口区域外沿往内收缩一个球的半径作为安全边界。另外在袋口附近的候选目标还必须满足“半径约等于理论半径差不超过15%”的强约束这样能把绝大多数非球目标挡在外面。5.2 实战疑难重叠粘连、台面反射与快速击球三颗球挤成一条直线时视觉上接近一条长条拆分成三个圆会有多种拆分方案检测结果在多个解之间跳变导致跟踪轨迹断裂。我调试了很久最后提供了一个过渡方案当检测结果几何歧义无法消除时跟踪模块允许目标暂时丢失但保留“痕迹”。一旦后续帧里球分开、各个检测结果重新出现MOT跟踪器能根据原来的轨迹ID重新关联。这个机制在“开球瞬间炸球”的场景下非常关键开球之后球群剧烈散开短时间内大量重叠靠纯单帧检测根本撑不住只有靠多帧累积重建轨迹。台呢上的反射也是一大困扰尤其是深色球在水晶般光滑的新台呢上会倒映出一个模糊的同色影像。反射影像在HSV空间里经常和真实球同色且形状接近会形成“幽灵目标”。处理方法是利用真实球和反射影像的形变差异真实球在俯视图里是完美圆形反射影像会被台呢纹理拉长成椭圆形并且边缘模糊。我用轮廓的圆度指标加边缘梯度强度组合过滤圆度必须大于0.85平均边缘强度必须大于阈值两者都满足才认定为真实球。这套规则在绝大多数球房环境下都管用只有极少数特别光滑的台面还需要额外在袋口区域做特殊处理。快速击球瞬间球的运动模糊也不能忽视。我用1/500秒曝光已经把模糊压到最低但白球出杆速度极快时相邻两帧之间位移可能达到20像素按我们的物理坐标换算就是好几厘米。跟踪模块的搜索半径就必须按最高可能速度来计算否则高速球会直接跳出卡尔曼预测的关联窗口。我给搜索半径设定的是一个自适应的值根据最近5帧该球的平均速度计算预测位置然后在预测位置周围留出能覆盖最大可能位移的缓冲区域具体数值预留了30%的余量。这样既不会漏掉快速球也不会因为搜索范围太大匹配到旁边的假目标。5.3 系统调试三板斧录像回放、日志埋点和实时可视化调试这种视觉系统最忌讳闭眼改参数。我给自己立了一个规矩任何一次误判、漏判都要把原始视频片段、检测中间结果、最终计分输出三份数据一起保留下来。复盘时先看检测输出有没有问题如果检测没问题再看跟踪和判定逻辑逐层定位。为了实现对账我在系统里加了一套结构化日志每条日志包含帧号、时间戳、检测结果、跟踪状态、事件类型全部写入SQLite。发现有问题时直接按时间戳查日志配合保存的视频几分钟就能定位到出错环节。还有一个非常实用的工具是实时可视化窗口。调试阶段我会把检测框、球号、置信度、袋口区域、轨迹线全部画在画面上投到旁边的一块显示器上。这样现场操作人员能直观看到系统“眼中”的世界是什么样任何识别异常都逃不过人的眼睛。可视化层和核心逻辑层完全解耦只用于调试正式运行时关闭对系统性能几乎没有额外负担。6. 系统集成与后续演进方向6.1 与比分牌、手机端的数据联动自动计分系统如果只停留在算法调试阶段落不了地也白搭。我在算法稳定后做了一套集成方案计分裁判模块每产生一个有效事件就通过内部WebSocket推送给本地服务端服务端维护一份实时比分状态再通过HTTP接口输出给两块下游终端一块是球房的壁挂LED比分牌另一块是手机小程序。球员在小程序里能查看每局回放、进球时间线、个人统计数据比如进球率、连杀次数、平均每杆用时。这样系统就从一个“识别工具”升级成了完整的“球房数字运营工具”对球房老板来说会员的台账数据也有了日常运营价值一下子就出来了。手机端和实时比分牌之间用WebSocket做增量同步比分变化几乎是秒级到。有人问过我延迟问题实测下来从进球事件发生、算法确认到比分牌刷新整个链路在200毫秒以内和人眼感知基本同步。这个延迟主要取决于视频帧率和判定窗口帧数我设置的判定窗口是5帧约167毫秒加上网络传输正好200毫秒出头。6.2 数据闭环与模型迭代系统跑起来之后真正有价值的东西其实是数据。每一颗球的轨迹、每一次进球、每一次犯规动作都沉淀成结构化数据。我后来定期把实际比赛中遇到的困难样本导出补充到检测分类模型的训练集里每个月重训一次模型。刚开始每个月都能看到明显的精度提升后面数据集大了之后提升幅度放缓但系统在特定球房的稳定性也确实越来越强。因此我建议所有做类似项目的朋友从一开始就设计好数据回流机制别等模型上线才想起来补数据集。另外一个正在尝试的方向是用轨迹数据做更细粒度的行为分析比如根据白球击球瞬间的加速度曲线判定出杆力度根据进球后目标球的路径反推击球角度。这些数据对上专业训练系统非常有用一个视觉计分系统慢慢就演变成了一套“球技分析工具”。虽然目前还比较初级但我个人觉得这条路会比单纯计分本身走得更远。6.3 项目评估与投入产出最后说说这个项目到底值不值。硬件成本粗算一下工业相机加镜头一千五左右支架和线材五百补光和偏振镜三百加上一台只用来跑算法的普通工控机三千左右整套下来不超过六千块钱。对一家球房来说这个投入也就是几个会员月卡的价格。而换来的东西包括裁判人力节省、计分争议大幅减少、会员体验加分以及一套能持续产生数据的产品底座。如果你是自己练球、想搞个个人训练数据助手那硬件预算还能再砍一半用普通的高清摄像头配一台带独立显卡的电脑也能跑。算法部分只要你有点Python和OpenCV基础按我这篇文章的思路搭一套MVP一个周末就能通。这个系统后续还可以扩展比如接上电动摆球机实现进球后自动摆球复位整套自动化就更完整了。总之这套方案从零到能稳定运行我最深的体会是视觉识别看上去是个算法问题但实际上多半是硬件部署、数据质量和逻辑工程在约束上限。先把相机装稳、灯光调匀、标定做准算法才有发挥空间。希望这篇能把你的开始成本压到最低少走点我已经踩平了的弯路。