#gitee上传了代码 我的账号是l****Z**一、调试进展总结本次调试已经实现从起点前往识别板1、二维码任务识别、取样点导航等部分比赛流程。其中表现最好的一轮成功完成起点 → 识别板1 → 识别ABC任务3号窗口→ C取样点 → A取样点 → B取样点随后小车前往识别板2但未能完成板2导航。另一轮在降低前进速度后成功完成起点 → 识别板1 → 识别AC任务2号窗口→ C取样点 → A取样点随后同样在板2导航阶段中止。目前已经验证小车具备部分自主导航、二维码识别和取样路线执行能力但尚未完整完成配送、核验、返回起点和裁判评分。二、调试环境项目配置小车系统Ubuntu 18.04ROS版本ROS Melodic小车用户名EPRobot小车主机名EPRobot210月12日小车IP10.189.140.4210月12日虚拟机IP10.189.140.66ROS主服务http://10.189.140.42:11311工作空间/home/EPRobot/robot_ws主程序pharmacy_pkg/scripts/smart_pharmacy2.py可视化环境Ubuntu虚拟机RViz控制方式Windows PowerShell通过SSH连接小车IP由当前网络分配重新连接热点后可能发生变化不能长期使用固定IP。三、已解决及改善的问题3.1 ROS通信与RViz显示曾遇到RViz无法正常打开、ROS主服务连接失败、2D Pose Estimate操作后地图激光扫描不发生预期变化等现象。采取的措施包括统一ROS网络地址、在Ubuntu虚拟机本地启动RViz、重启相关ROS节点和重新初始化AMCL。处理后能够正常显示地图、激光雷达和机器人定位信息。3.2 板1导航反复调整原主程序在板1导航阶段临时将TEB位置容差设置为0.03m即3厘米。问题小车在板1前反复修正最终触发振荡中止。导航日志出现Clearing both costmaps to unstick robotAborting because the robot appears to be oscillatingGoal failed with state: 4Navigation failed: board1其中状态4表示move_base目标被中止。之后将板1位置容差从0.03m调整为0.08m即8厘米其余导航速度暂时保持不变。调整后至少有一轮成功到达板1并完成二维码识别及后续C、A、B三个取样点导航。阶段结论8厘米容差改善了板1到点判定但尚不能认定振荡的唯一原因是3厘米容差。3.3 取样点停留时间将主程序中pickup_dwell默认值由1.5秒调整为0.0秒取消A/B/C取样点额外等待同时保留语音播报。修改已保存到小车主程序并通过Python 2语法检查。但最新日志显示从一个取样点到达至下一个目标下发仍约3秒尚未达到包含播报在内12秒的目标。3.4 前进与倒车速度通过ROS dynamic_reconfigure调整TEB运行参数参数原参数调试参数max_vel_x0.83m/s0.20m/smax_vel_x_backwards0.40m/s0.10m/s降低前进速度后小车运行表现有改善迹象并完成了AC任务对应的C、A取样流程。随后只调整倒车上限到0.10m/s的测试现场反馈效果不理想但缺少该轮完整日志无法判断原因。以上速度修改均为运行时参数尚未写入原始YAML。重启导航后可能恢复文件中的设置。四、关键测试结果轮次调整条件结果测试1板1容差0.03m板前反复修正触发振荡中止测试2板1容差0.08m其余速度保持原样识别ABC→3完成C→A→B随后板2约60秒超时测试3板1容差0.08m额外取样等待0秒板1导航成功但二维码获取或解码失败测试4人工摆车后独立调用识别服务连续返回ABC→3测试5前进速度上限0.20m/s识别AC→2完成C→A板2约35秒后状态4中止测试6倒车速度上限进一步降至0.10m/s现场反馈未成功缺少详细失败日志注意ABC任务和AC任务的路线不同不能简单地通过完成度对比证明降速一定有效。五、当前四项重点问题问题1板1的3厘米导航容差与底盘执行能力是否匹配已知现象板1原来要求进入3厘米目标范围。底盘存在最小非零速度约0.1m/s的执行限制。小车曾在目标附近反复前后修正最终因振荡中止。可能原因TEB希望输出较小速度进行精细调整但实际底盘对低速指令进行放大或限幅可能导致越过目标并反复修正。还需核对角度容差、底盘反馈、制动和最小转弯半径等影响。当前处理将板1位置容差暂定为0.08m并保留导航保护机制。问题2板1到点改善后为什么无法稳定通过板2板1容差调整后小车曾完成ABC任务的全部取样点导航但在板2阶段超时。另一轮AC任务完成取样后板2导航返回状态4。目前需区分以下原因板2目标坐标或目标朝向不合理。接近目标后发生局部路径振荡。小车运动中打滑里程计与实际位移产生偏差。AMCL定位与场地地图发生错位。TEB规划的转弯动作与底盘执行能力不匹配。当前处理优先分析导航中止前的move_base日志不直接取消振荡保护也不盲目延长超时。问题3小车到达识别板前停车朝向不正导致二维码读取不稳定小车到板1后有时识别成功有时无法获取或解码二维码。可能与停车位置、停车朝向、摄像头视野、图像质量及识别算法有关目前尚未完成定量验证。拟改进方向在板1导航到达后增加视觉对准检测。首先检查识别板在相机图像中的位置和倾斜程度。必要时设计受速度、角度和超时限制的小幅车头角度修正再执行二维码识别。修正过程必须与move_base导航控制分阶段执行避免两个节点同时控制底盘。问题4板1同时存在ABC和AC程序却选择了AC有一轮比赛中板1存在ABC3号和AC2号两种有效任务但小车最终选择AC。已知本地备份的选择规则是优先选择解码字母较多的合法任务。因此若同一次识别同时完整解出ABC和AC理论上应选择ABC。可能是某一帧只成功解出AC识别程序就提前返回未继续等待ABC。拟改进方向每次保存四个二维码区域的原始解码结果。记录每个候选任务的窗口编号。对同一次识别请求采集多帧。在多帧候选中进行合法任务筛选及优先级判断。不将不同窗口、不同任务的字符随意拼接。使用比赛主程序实际调用的Board1Reader验证不只测试独立识别服务。六、其他未解决事项裁判TCP通信日志持续出现Judge TCP reconnect: timed out尚未确认裁判服务连接成功。干扰码播报出现Interference announcement failed需要查明缺失文件或可执行程序。取样停留额外等待已降至0秒但包含语音播报和程序调度的总停留仍约3秒。底盘打滑已有现场观察但尚缺少同步的速度指令、里程计和定位记录不能直接认定所有导航误差均由打滑造成。物理取样验证pickup_completed仅表示程序到达取样阶段不代表已通过传感器确认取样动作完成。七、下一轮调试建议建议按照以下顺序进行保存并分析最新失败轮的导航终端日志确认具体失败阶段。核对当前实际加载的TEB前进和倒车速度避免重启后参数恢复而不知情。将板1的0.08m容差作为当前已验证的调试基线不一次修改多个导航参数。优先检查板2目标位姿与停车阶段的路径振荡。独立开展板1视觉角度校正与二维码多帧识别测试。在同任务、同起点及同朝向条件下进行速度对照。导航成功后再逐步处理播报时长和裁判TCP通信。调试原则一次只调整一个主要变量每轮保留日志、参数、任务内容、RViz画面和实际运行结果。穿插10.14-10.16内容截至本次整理- 板一的新二维码识别链路、二维码专用 YOLO 模型、微信解码器及原录音提示已有装车和静止测试记录。-板二已修复图像转换和日志编码错误保存了新目标点取消固定边缘裁剪固定单线程和 PSM 6并修复空闲结果因杂数字被拒绝的问题。- 板二空闲识别、等待8秒的识别有现场结果后续日志出现等待10秒需结合当时板面和话题结果确认不能把建议测试6秒写成6秒已通过。- 板二近期截图的单帧 OCR 多数约2秒仍有约3秒及以上波动。尚不能证明满足空闲时3秒内通过整个区域的要求。- 完整流程曾到达板二也曾完成 C、A、B 取样同时存在导航碰撞判定、定位偏差和板二识别失败记录。没有证据证明最新版从起点到配送、返回的全部流程已经稳定通过。- 当前最近报告的问题是 RViz 不工作已给出重启及连通性检查步骤尚未收到恢复结果。二、资料接收和程序关系梳理1. 读取比赛规则已读取用户提供的《智能安全赛—智慧医运机器人对抗.docx》核对任务流程、评分要求和板二内容。规则涉及板一任务和干扰判断、A/B/C 取样、板二状态识别与播报、等待或通过、窗口配送、动态避障、MD5 核验及裁判通信。板二只有两类提示、七种业务结果| 板面内容 | 业务结果 ||---|---|| 化验区空闲中请快速通过 | 空闲播报并尽快通过 || 化验区忙碌中需等待 n 秒 | n 为5、6、7、8、9、10播报并等待相应时间后通过 |规则要求空闲时在3秒以内尽快通过。本文未擅自确定现场计时起点性能测试应覆盖识别、决策、播报和驶离而不能只测 OCR。2. 确认实际入口根据10月13日代码和后续交接版阅读主程序为 smart_pharmacy2.py扩展功能集中在 pharmacy_extensions.py。不是看到旧 detect_char.py 或 detect_board2.py 文件就能认定它是当前被执行的实现。板一后续链路为textsmart_pharmacy2.py→ pharmacy_extensions.Board1Reader→ board1_fast.FastBoardReader→ qr_remotePython2 ROS 调用端→ qr_worker独立 Python3.8 视觉进程→ 四格定位、整图解码、必要时区域检测与解码兜底→ 返回任务组合与窗口号并处理干扰播报板二由主程序到达识别区域后启动 pharmacy_extensions.py --ocr节点订阅 /ocr_image_raw并向 /ocr_text 发布结果。三、板一二维码识别改进### 问题一人能看到二维码程序仍识别失败早期程序过度依赖先找到四个外框再开始解码。停车位置、倾斜、反光或轮子打滑后即使四个码在人眼看来完整外框定位和安全检查仍可能阻止识别。处理方法包括增加整图直接解码通路、保留和改进四格空间定位、增加解码器兜底、保存失败帧与诊断信息以及保留多帧确认。检测到框不等于解码成功解码失败也不能直接判定为干扰码。早期35项离线回归通过。在两张交接原图及其变形构成的16个样例上四格全部正确的样例数从9个增至11个。这是有限本地回放结果不是实车总体准确率也不是最新版的最终性能指标。### 问题二模型下载与运行环境不兼容下载了微信二维码检测与超分辨的4个文件以及二维码专用 QRDet nano 权重。后续将 qrdet-n.pt 导出为 qrdet-n.onnx并使用 OpenCV DNN 做实际加载和推理验证。ONNX 是模型格式本身不保证加速没有把普通 COCO 检测权重冒充二维码权重。车端历史检查发现 Python2 OpenCV 3.2.0 无法承担这套新版视觉功能Python3.6 环境也缺少依赖。因此保留原 ROS Python2 环境另外建立 Python3.8 视觉环境再通过独立进程通信接入主程序。交接记录中的独立解释器为 ~/venvs/board1_cv38/bin/python依赖包括 numpy 1.24.4、opencv-contrib-python-headless 4.8.1.78、pyzbar 0.1.9。没有用 Windows 环境直接覆盖树莓派环境也没有为此整体升级 ROS 的 Python2 OpenCV。### 问题三偏左靠边时四格被拒绝现场诊断显示左边框约距图像边缘14像素但原 margin_fraction0.04 在640像素宽图像中要求约25.6像素触发 near_image_border。off_center 当时只是诊断提示不是该次主要拒绝原因。将 board_alignment.py 默认 margin_fraction 从0.04改为0.015640像素宽时对应约9.6像素。仍保留完整性和几何检查没有把已经被画面切断的二维码一概视为有效。偏左、偏右、轻度斜视的后续静止测试成功若干结果耗时约2.06、1.92、2.24秒。四格读到 ABC、ABC、BC、网址最终选中当前演示的窗口1任务。### 问题四YOLO 加载和实际触发混淆worker 报告 yolotrue、wechattrue证明模型加载。清晰画面现场日志中的方法为 whole_image说明该次由整图解码成功并不代表该帧实际走过 YOLO 裁剪。YOLO 接入为按需兜底没有强行每帧执行检测。四、板一干扰判断与语音二维码上显示的 BD 等可见字符不一定等于二维码真实载荷。实际测试中第4格解出了网址按内容判断为非法任务而不是打开该网址。干扰处理使用空间窗口位置和多帧确认接入小车原有 frame1.mp3frame4.mp3。用户确认原录音音色和对应窗口播报正确包括“窗口四出现虚假信息”。后台播报避免阻塞识别并对同组提醒去重。该部分已制作完整接入包、语音小补丁、边缘补丁和队友说明后续完整包整合了这些修复。五、ROS 环境、摄像头和终端调试### 1. 摄像头网页能打开但没有图像排查区分了端口连通、网页服务启动和图像话题实际发布。HTTP 200 或8080端口可达不等于摄像头有画面。现场曾出现相机话题无发布者、识别脚本持续等待新图像也出现 /dev/video0 不存在、UVC 子节点退出。检查后使用车上已有 Astra 驱动并通过 RGB 话题发布者、帧率和实际浏览器图像确认。部分记录中 RGB 约29.6 FPS。### 2. 节点名称与文件名不同camera_publisher.py 注册的节点实际为 /image_forwarder_node。最初按 camera_publisher 筛选导致误以为少了节点随后更正。/ocr_image_raw 的转发频率约2.83 Hz。### 3. 多终端和同名节点导航、摄像头、网页服务等长期节点与短期识别测试需要分开管理已有节点不应重复启动。相同 /detect_board2 节点再次注册会让旧进程退出出现同名节点替换提示。单独 OCR 只识别和发布不负责导航、播报或实际等待。完整主程序会自行启动 OCR运行前需退出手动 OCR避免会话冲突。### 4. 虚拟机与小车环境分工虚拟机曾没有 ~/robot_ws/devel/setup.bash这不代表小车工作空间缺失。标准 RViz 可使用虚拟机的 ROS 环境连接车端不应让虚拟机强行 source 不存在的小车目录。历史联调地址为小车10.40.33.42、虚拟机10.40.33.68这些是测试时地址换热点后需要重新确认。六、导航与停车调试### 1. 速度过快和打滑用户尝试过前进0.6、1.0 m/s随后因速度过快、打滑明显逐步降为0.6、0.4 m/s倒车保持0.2 m/s转弯速度上限由历史0.79降到0.6 rad/s。最近确认的运行上限为前进0.4、倒车0.2 m/s、转弯0.6 rad/s。动态参数会受节点重启和其他配置覆盖影响因此不能仅凭旧截图认定永久生效。这属于降低运行激烈程度的措施尚未通过米尺、里程计和定位对照实验彻底证明或解决打滑根因。### 2. 动态参数命令卡住rosrun dynparam 曾在查找或调用阶段卡住倒车参数仍显示0.4。后续改用动态配置服务设置并用 rosparam get 验证。参数服务器数值和规划器实际接收情况应结合检查不能只写静态参数就假定动态配置已更新。### 3. 板一到点后反复微调某次日志显示板一位置要求为0.08 m而距离长时间在约0.0830.133 m附近波动持续约38.43秒后中止。现场按最小改动将板一临时位置容差调到0.12 m并在之后日志中确认position tolerance0.12m。该处理针对到点判定门槛不代表机械打滑或 AMCL 漂移已被修复。### 4. 保存板二新目标点用户键盘调整到可识别位置读取 AMCL 位姿并保存textx -2.827748y 1.436142yaw -2.125442 rad约 -121.8°qz -0.873678qw 0.486505板二位置容差0.12 m朝向容差0.14 rad约±8°。容差是在导航阶段临时设置并恢复。摄像头需要大致面向板面所以没有直接取消板二朝向。### 5. A/B/C 不强制精确到达朝向对比发现早期代码发送完整 Pose10月14日交接版对 A/B/C 已有临时放宽朝向逻辑。后续补丁按当前车端保留原导航函数并加外层处理取样阶段把 yaw_goal_tolerance 放宽到略大于π结束后恢复原值。板二仍按上述位置和朝向容差执行。这取消的是取样点的严格到达朝向条件不等于取消转弯也不保证规划路径完全不受目标姿态影响。不能把四元数设成(0,0,0,1)当成“无朝向”那表示0°。### 6. state4 与碰撞不可行完整测试日志出现 TEB infeasible: footprint collision、trajectory is not feasible、恢复后仍无有效路径并返回 state4。某些记录还出现传感器位置超出局部代价地图范围。已检查全局/局部代价地图、地图边界、激光订阅。实际 move_base 与 AMCL 订阅 /scan_filtered说明参数里的 scan 已经由启动重映射不能据参数文字认定订错话题。实际地图为384×384、分辨率0.05 m、原点(-10,-10)目标没有超出其矩形范围。另一次去板一时位置固定、pose_age递增随后激光约10 Hz、odom约50 Hz不能把定位陈旧直接等同于传感器停止。直接导航失败证据仍是轨迹碰撞/不可行定位、障碍层和足迹的具体根因尚需现场对照。### 7. rosrun 找到多个同名主程序一次安装把可执行的 smart_pharmacy2.py 同名备份放进包内目录导致 rosrun 弹出多个候选。已说明原因启动时改用 Python2 加主程序完整路径后续安装器备份采用 .bak 后缀避免新备份再次被当作同名入口。旧备份并未擅自删除。七、板二 OCR 不输出的排查与修复### 1. 分层确认输入可用通过节点、话题连接、图像频率和直接一帧测试确认 /ocr_image_raw 有新图、CvBridge探针能转换中文 chi_sim 语言包存在。某次探针显示图龄0.076秒、图像480×640×3。直接一帧 OCR 曾用3.54秒读出“化验区空闲”等内容。说明相机输入和 Tesseract 能工作但未解释节点完全不发布的现象。### 2. 早期判断纠正最初把不输出归因于图像有效期2秒过短随后核对发现原代码过期分支本应发布0因此完全无输出不能只由超时解释。后续增加临时回调诊断追查到真正异常。### 3. 修复 Python2 unicode 与字节字符串不兼容模块使用 unicode_literals编码名 bgr8 在Python2中成为unicodeCvBridge底层 cvtColor2 接口要求字节字符串报参数类型不匹配OCR尚未开始就失败。将 imgmsg_to_cv2(msg, bgr8) 改为 imgmsg_to_cv2(msg, bbgr8)修复图像转换。### 4. 修复日志编码异常遮住原始错误中文日志格式与UTF-8字节参数触发 UnicodeEncodeError/UnicodeDecodeError原始异常甚至在记录错误时再次被遮住。经过临时安全日志输出找到原始错误后将 OCR 日志改为ASCII格式和 %r 转义输出并用ASCII错误日志格式记录异常。\u…… 是中文的转义表示不是识别本身乱码。某次补丁脚本也因遗漏Python2 UTF-8编码声明无法解析补充声明后安装成功解析失败时尚未改动车端文件。### 5. 调整结果有效期原2秒有效期会拒绝部分39秒完成的识别后续默认调整为15秒。其含义是允许源图像从拍摄到结果完成的最大年龄不是每次固定等待15秒也不会直接提升速度。15秒是当前容错设置不是符合比赛3秒要求的证明。八、板二识别准确性和速度的逐步优化### 1. 取消固定裁剪根据用户要求不再固定裁掉四周各10%避免停车偏斜时人为截断文字。当前输入改为 croppedcv_image但保留原有最大宽度600的缩放逻辑不应描述为始终保留原分辨率。用户要求控制变量后曾准备的“灰度图新解析PSM6”组合方案被收缩先只安装取消裁剪的小补丁阈值65、原识别模式和原解析当时保留。静止空闲识别返回1截图中四次耗时4.21、5.76、5.07、4.27秒。### 2. 同帧方法比较制作 board2_ocr_compare.py用同一帧比较全图灰度PSM6、全图Otsu阈值PSM6和全图灰度PSM11。它只保存图片、执行识别、打印结果不发送导航或轮速指令。一次全图灰度PSM6读出“空闲”解析值1用时3.83秒。该试验不等于正式程序已永久改成灰度输入当前正式程序仍保留手动阈值65。### 3. 限制线程使用 OMP_THREAD_LIMIT1 临时启动并对比。后续部分帧降到约1.62.8秒但仍有45秒波动。由于板面从空闲切换为忙碌等条件不同不能把这些截图直接计算为严格单因素加速倍数。### 4. 固定 PSM 6在单线程条件下临时给 pytesseract 注入 --psm 6只改变版面识别模式随后用户要求保存生成安装补丁使正式 OCR 子进程默认单线程与PSM6。保持阈值65、取消裁剪和原业务解析。PSM6把输入看作单个文字块适合目前两行提示文本它不是目标检测器也不能保证所有背景、角度和字体下都最好。### 5. 修复“读对空闲却返回0”连续观察发现空闲结果在1和0之间变化。增加只打印原文和解析值的临时诊断确认部分帧读成“6区空闲中请快速通过”。原解析要求整段原文中完全没有数字因此杂数字6会导致0。日志还存在另一层误导显示的是过滤后的 clean_text而解析的是 raw_text不能只看日志中的剩余文字就推断解析原因。最终只改空闲判断一行明确有“空闲”或“快速通过”没有“忙碌/等待/不空闲”等冲突且没有数字或中文数词加“秒”的时长证据时允许孤立杂数字。忙碌秒数分支保持原样。该补丁通过24个离线用例包括杂数字空闲、忙碌510秒、忙闲冲突、15秒等非法时长以及只有数字等情况。用户安装后反馈本次更准确截图大部分耗时约1.92.4秒个别3.06秒。0始终表示无法确认不代表忙碌也不能默认转换为空闲。不能为提升通过率随意猜秒数。## 九、板二语音和等待逻辑核对已找到主程序现有分支result1时播放 ~/Downloads/shibieban2/free.mp3忙碌时播放 busy_n.mp3然后执行 rospy.sleep(result)之后才发送配送导航目标。例如result8当前顺序为播报结束→再等待8秒→继续导航。因此识别后停留时间包括播报时间和等待时间。空闲也会先同步播报再继续导航。speak函数优先使用play播放文件缺失时尝试espeak中文合成。代码中的路径存在不等于7个音频均已在车端核听正确已给出文件检查命令但本轮没有收齐所有音频的现场确认。单独执行 --ocr 不会执行这段主流程动作。完整流程的准确等待时长、音频内容、识别后出发时间仍需录屏或时间戳实测。rospy.sleep 是暂停任务流程不是持续发布刹车指令该分支依赖导航已经到达停止测试时应避免键盘遥控等其他速度发布者干扰。## 十一、当前版本参数与主要文件| 项目 | 当前记录值或行为 ||---|---|| 板二输入 | 完整画面不固定裁边最大宽度600 || 二值化 | 固定阈值65尚未切到纯灰度正式方案 || Tesseract模式 | PSM6 || 线程限制 | OCR启动时设置OMP_THREAD_LIMIT1 || 源图像有效期 | 默认15秒允许启动参数覆盖 || 板二结果 | 1为空闲510为等待秒数0为未知 || 空闲解析 | 允许杂数字但排除忙闲或等待证据冲突 || 板二目标点 | (-2.827748, 1.436142)参考朝向约-121.8° || 板二到达容差 | 位置0.12 m朝向0.14 rad || A/B/C到达朝向 | 放宽阶段结束恢复 || 最近速度上限 | 前进0.4 m/s、倒车0.2 m/s、转弯0.6 rad/s重启后需确认 || 语音和等待 | 同步播报忙碌分支播报后再等待n秒 |电脑主目录C:/Users/21087/Documents/ChatGPT/信息安全对抗赛。关键代码在 EPRobot_20261013/pharmacy_pkg/scripts 下smart_pharmacy2.py、pharmacy_extensions.py、board1_fast.py、board_alignment.py、qr_robust.py、qr_remote.py、qr_worker.py。小车运行目录/home/EPRobot/robot_ws/src/pharmacy_pkg/scripts。主要交接和补丁- board1_yolo_update_20261015.zip板一当日完整接入包。- 队友说明_YOLO与语音_20261015.md、任务交接_最终版_20261015.txt板一环境、安装与测试证据。- install_board2_navigation_20261016.py板二坐标、到达容差、取样朝向及15秒默认有效期。- install_board2_nocrop_only_20261016.py取消裁边撤回当时未采用的额外OCR修改。- install_board2_psm6_singlethread_20261016.py保存单线程与PSM6。- install_board2_free_parser_20261016.py空闲杂数字解析修复。- install_board2_fullframe_20261016.py早期组合试验补丁已被后续控制变量方案替代不作为当前推荐入口。- board2_ocr_compare.py静止同帧对比工具不等于正式运行入口。- checkpoints/board2_ocr_20261016_psm6_free_parser/OCR版本快照和说明不代表车端所有文件已经逐字节校验同步。本地smart_pharmacy2.py与车端可能存在日志等后续差异不应未经比对用整个本地文件覆盖车端此前主要通过小补丁保留车端已有逻辑。## 十二、尚未实施的方案与下一步已讨论但没有当作已部署成果的方案Tesseract引擎常驻/预加载、tessdata_fast核验与替换、按固定版式匹配、轻量七分类网络、移动端中文OCR以及空闲时播报和导航并行。板一YOLO已接入不等于板二也已加入YOLO或神经网络分类器。建议按优先级继续1. 先恢复并确认RViz、定位和代价地图记录全流程失败的真实阶段。2. 在同位置、同光照下补齐空闲及等待510秒的连续结果统计同时记录0和错误秒数不只截取成功帧。3. 完整流程测量到板二、首次有效识别、播报开始/结束、等待结束和实际离开区域的时间。4. 保持当前准确版可回退再一次只改变一个提速变量。优先消除进程初始化和同步播报的额外等待再根据实测决定是否换识别方法。5. 比较米尺位移、odom和AMCL确认打滑/定位偏差的来源不靠无限放大导航容差掩盖问题。本轮最重要的经验是先确认当前实际执行文件和新鲜输入再区分图像处理、文字识别、业务解析与导航控制模型已下载、已加载、该帧已调用、实车已通过是不同证据层级。## 十三、历史检索说明这次在本机Codex会话索引中找到“研读小车代码与比赛规则”并读取两个相关主会话日志。它们包含10月14日到16日的项目交流实际会话内容跨日期不能只按日志文件名日期判断是否包含昨天。
求解)
