https://quchaosheng.github.io/atom.xml 2026-08-25T01:30:00.000Z Quchaosheng https://quchaosheng.github.io/2026/08/25/ai-robot-acceptance-evidence/ 2026-08-25T01:30:00.000Z 2026-08-25T01:30:00.000Z

演示视频里机器人连续抓取了五次，现场验收却没有通过。评审问的是环境温度、模型版本、失败时怎么停、结果年龄是多少，报告里只有一张成功率截图。问题不一定是系统变差，而是报告把仿真、台架和真机证据混在了一起，读者无法知道每个结论到底由什么支持。 AI 机器人验收不该只写一个总分。感知、规划、控制和安全链路需要不同证据；成功率、P99 延迟、人工接管率和安全事件也不能互相替代。报告的任务是让别人知道“在哪些条件下观察到了什么”，以及“哪些地方还没有证据”。 定义任务和失败条件 → 固定代码、模型和设备指纹 → 分别收集仿真、台架、真机证据 → 记录成功、拒...

https://quchaosheng.github.io/2026/08/25/project-evidence-chain-retrospective/ 2026-08-25T01:30:00.000Z 2026-08-25T01:30:00.000Z

从 8 月 14 日到今天，这组札记依次整理了共享数据、跨层时延、设备确认、采集架构、BSP、驱动生命周期、任务取消、确定性回放、CAN 故障验证、视觉 Guard 和 RISC-V 边界。它们来自实际工程中反复遇到的问题，但文章刻意只留下可迁移的方法。 我如何判断一段经验能不能公开 首先删除能够识别业务和现场的信息：公司与客户名称、未公开项目名、设备序列、网络拓扑、接口地址、协议字段、日志原文和数据样本。其次删除可能暴露能力边界的参数：频率、阈值、超时、资源规模、故障统计和未公开性能结果。 最后检查结论是否越过证据。仿真结果只写仿真，软件注入只写...

https://quchaosheng.github.io/2026/08/24/qemu-riscv-boundary-validation/ 2026-08-24T12:30:00.000Z 2026-08-24T12:30:00.000Z

在 RISC-V 多执行域实验中，仅仅写出一份资源配置并成功启动，不足以证明隔离成立。配置声明描述“希望怎样划分”，异常探针才回答“越界访问是否真的被拒绝”。 声明资源边界 → 完成多域启动 → 正向功能验证 → 双向越界探针 → 保存异常证据 声明 资源与执行域配置 探针 正向对照和负向访问 边界 区分 hart、DMA 与硬件 启动与隔离是两个验收项 系统能进入各自运行环境，只说明启动链、内存映射和基本调度大体可用。隔离需要从两个方向主动访问对方受保护区域，并记录异常类型、地址和发起上下文。只测一个方向，可能漏掉配置不对称。 探针自身也要合法。...

https://quchaosheng.github.io/2026/08/24/ai-robot-rosbag2-failure-replay/ 2026-08-24T01:30:00.000Z 2026-08-24T01:30:00.000Z

机器人在现场偶尔导航超时，回到实验室却怎么也复现不了。开发者通常会加几条日志，再跑一次任务。等真正需要分析时才发现，录包里没有相机时间戳、TF、诊断状态或控制命令，留下的只有一行“action timeout”。 rosbag2 能保存一次运行中的消息，但它不会自动让实验变得确定。要复现故障，必须提前定义录哪些话题、使用哪种 QoS、回放时是否使用仿真时间，以及哪些硬件输入需要替换成回放数据。回放的目标是重建当时的输入和状态，不是把视频重新播放一遍。 定义故障假设和截止期 → 按时间与 QoS 录制闭环输入 → 检查包内容和版本指纹 → 用仿真时间...

https://quchaosheng.github.io/2026/08/23/vision-admission-guards/ 2026-08-23T12:30:00.000Z 2026-08-23T12:30:00.000Z

视觉检测输出一个 ID 和位姿，并不意味着机器人任务可以立即执行。检测质量、时间新鲜度、坐标变换和连续性任何一项不满足，单帧结果都可能把偶然噪声变成控制动作。 我会把这些条件写成显式 Guard，并在任务运行期间持续检查，而不是只在启动瞬间检查一次。 检测候选 → 质量与身份 → 新鲜度与 TF → 连续性 → 任务准入或取消 检测 身份与质量 时空 新鲜度与坐标变换 任务 持续准入与取消 Guard 应回答可审计问题 身份是否属于允许集合？检测质量是否达到当前场景要求？消息是否足够新？目标位姿能否变换到约定坐标系？相邻观测是否出现不合理跳变？这些...

https://quchaosheng.github.io/2026/08/22/socketcan-fault-injection-boundaries/ 2026-08-22T12:30:00.000Z 2026-08-22T12:30:00.000Z

CAN 控制链的异常处理不能只靠拔线测试，但软件故障注入也容易被过度解读。vcan、SocketCAN 错误消息和真实控制器状态属于不同层，测试报告必须说清楚注入点和能够证明的范围。 选择故障层级 → 注入可识别事件 → 观察状态机 → 验证恢复与发送上界 → 声明边界 应用层 ACK、反馈与 watchdog SocketCAN 错误消息接口 物理总线 控制器与电气状态 软件层适合验证什么 可复现注入适合覆盖 ACK 丢失、迟到、重复、反馈停滞、watchdog 超时、解码错误和应用可见的错误消息。它能验证上层是否进入预期状态、停止继续发送业务命...

https://quchaosheng.github.io/2026/08/21/schema-and-deterministic-replay/ 2026-08-21T12:30:00.000Z 2026-08-21T12:30:00.000Z

多人并行开发机器人系统时，最常见的摩擦不是代码写不出来，而是模块对字段、版本、启动顺序和失败语义的理解逐渐漂移。接口文档如果只靠自然语言，很难及时发现“双方都能运行，但理解不同”。 我的做法是把跨模块消息变成可检查的 schema，并把关键状态变化写成追加式事件，以固定输入进行确定性回放。 Schema 校验输入 → 模块处理 → 追加事件 → 固定 seed 回放 → 比较状态与顺序 合同 约束结构与版本 事件 保存身份与因果 回放 隔离输出并复核判定 Schema 是边界合同 Schema 应约束必填字段、枚举、范围、版本和条件关系，并为未知版...

https://quchaosheng.github.io/2026/08/20/ros2-deadline-cancel-budget/ 2026-08-20T12:30:00.000Z 2026-08-20T12:30:00.000Z

机器人任务通常不是一次函数调用，而是由规划、控制、设备通信和状态确认组成的长链路。每一层如果都有自己的超时，却不知道父任务还剩多少预算，最终就会出现上层已经放弃、下层仍在执行的“幽灵任务”。 父任务建立 deadline → 子步骤读取剩余预算 → 超时触发取消 → 停止并确认终态 父任务 维护绝对 deadline 子任务 消费剩余预算 设备层 停止并确认状态 deadline 比多个 timeout 更清楚 父层记录一个基于单调时钟的绝对 deadline。每个子 Action、设备请求和重试只使用剩余时间，不重新获得完整预算。这样可以保证嵌套...

https://quchaosheng.github.io/2026/08/19/driver-remove-lifecycle-order/ 2026-08-19T12:30:00.000Z 2026-08-19T12:30:00.000Z

驱动 remove 路径很容易在“正常运行”测试中被忽略。真正麻烦的是卸载时仍有中断、work、timer、DMA completion 或用户调用在路上：一边释放资源，另一边又重新入队，偶发卡死就出现了。 处理这类问题时，我会先画出谁产生事件、谁持有对象、谁可能睡眠，再按所有权逆序关闭。 拒绝新入口 → 关闭硬件事件源 → 同步在途回调 → 取消延后工作 → 释放资源 生产者 IRQ、timer 与用户入口 在途工作 同步回调与引用 所有权 逆序释放资源 先停生产者，再清消费者 如果先 cancel work，却没有屏蔽能再次安排 work 的 ...

https://quchaosheng.github.io/2026/08/18/bsp-bringup-evidence-order/ 2026-08-18T12:30:00.000Z 2026-08-18T12:30:00.000Z

板级适配最耗时间的地方，往往不是某个 API 不会用，而是硬件描述、运行镜像和驱动日志之间没有建立固定检查顺序。我的经验是先把原理图事实整理成资源表，再把每个事实映射到设备树和运行证据。 原理图资源 → DTS 描述 → 运行 DTB → 驱动匹配 → 真实功能 硬件事实 供电、时钟、复位与总线 软件描述 DTB 与驱动匹配 运行证据 日志、波形与真实读写 编译成功只是起点 资源表至少包括供电、时钟、复位、引脚、总线地址和中断。DTS 能编译，不代表板子运行了这份 DTB；节点存在，也不代表 regulator、clock、reset 和 pinc...

https://quchaosheng.github.io/2026/08/17/modular-multisource-data-pipeline/ 2026-08-17T12:30:00.000Z 2026-08-17T12:30:00.000Z

机器人采集系统会同时面对相机、传感器、控制状态和存储。它们的频率、数据量、时间戳和失败方式都不同。把所有逻辑放进一个进程，开始时简单，后期却很难隔离慢设备、编码抖动和磁盘压力。 我更倾向按职责和故障边界拆成四类角色：设备接入负责生命周期与原始数据，编码器负责格式转换，组装器按时间与任务语义形成一个 Episode，存储端负责有界落盘与结果清单。 设备接入 → 编码转换 → Episode 组装 → 存储与清单 接入 保留设备差异 队列 容量与背压可见 清单 记录完整性与版本 插件接口不能抹平设备差异 统一接口适合约束启动、停止、状态和错误传播，但不...

https://quchaosheng.github.io/2026/08/16/ack-is-not-completion/ 2026-08-16T12:30:00.000Z 2026-08-16T12:30:00.000Z

设备控制接口最容易产生的一类误判，是把“发送成功”“收到 ACK”和“设备达到目标状态”当成同一件事。它们属于不同边界，失败模式也不同。 请求已发送 → 收到匹配 ACK → 回读设备终态 → 业务判定完成 request_id 绑定请求生命周期 ACK 只证明协议确认 终态 由新鲜反馈确认 三个阶段各自证明什么 发送成功通常只表示数据进入本地协议栈或驱动队列。应用层 ACK 表示对端识别了某个请求，但可能尚未执行。终态反馈才回答设备是否到达目标位置、模式或清障状态。即使三者都成功，也不自动等同于物理安全认证。 因此，请求需要可匹配的标识。迟到 A...

https://quchaosheng.github.io/2026/08/15/cross-layer-latency-segmentation/ 2026-08-15T12:30:00.000Z 2026-08-15T12:30:00.000Z

一次控制回调超时，表面上只有一个总耗时。直接看 CPU 利用率或某一行日志，往往会把排队、调度和执行混在一起。我的做法是先建立统一事件时间线，再把一次请求拆成三个可验证区间。 进入业务队列 → 线程变为 runnable → 线程获得 CPU → 回调执行完成 业务事件 标记请求与阶段 调度事件 观察 wakeup 和 switch 证据质量 记录时钟与丢失 三段分别回答什么 队列等待 回答执行器或任务系统有没有积压； runnable-to-running 回答线程已经可运行却为何迟迟没有获得 CPU； 回调执行 回答函数本身、锁、I/...

https://quchaosheng.github.io/2026/08/14/versioned-snapshot-for-shared-data/ 2026-08-14T12:30:00.000Z 2026-08-14T12:30:00.000Z

在一类高频状态采集项目里，我遇到的核心问题并不是“怎样把数据放进共享内存”，而是读者怎样判断自己拿到的是 布局兼容、内容完整、仍然新鲜 的一份数据。共享内存只解决地址空间之间的数据通路，不会自动提供消息边界、一致快照或生产者生命周期。 本文只讨论可复用的设计思路。具体字段、采样频率、设备标识、内存布局和业务协议均不展开。 验证布局版本 → 读取版本号 → 复制快照 → 重读版本号 → 判断是否接受 版本头 拒绝不兼容布局 快照协议 识别并发写入 活性字段 区分进程和业务状态 先把三个问题分开 第一是 兼容性 。读写双方可能来自不同版本，必须用 ma...

https://quchaosheng.github.io/2026/08/14/ai-robot-edge-model-ota-rollback/ 2026-08-14T01:30:00.000Z 2026-08-14T01:30:00.000Z

模型更新后，设备能启动，推理进程却在加载 engine 时退出。更麻烦的是，部分设备已经换成新模型，另一部分还在旧版本，现场日志看起来像两个不同的产品。模型文件未必损坏，发布单元却散了：模型、TensorRT、GPU 架构、预处理和配置各走各的版本。 机器人上的模型升级要有回滚路径。签名只能证明文件来自某个发布者，不能证明它适合这台设备；兼容性检查只能筛掉明显不匹配，不能替代小流量运行和任务指标验收。发布系统需要把身份、版本、健康检查和回滚状态连起来。 生成带清单的模型包 → 验证签名和设备兼容性 → 写入备用分区 → 小流量启动并观察健康指标 →...

https://quchaosheng.github.io/2026/08/13/dds-rpc-timeout-debugging/ 2026-08-13T09:40:00.000Z 2026-08-13T09:40:00.000Z

证据边界 本文是一篇工程复盘稿。公开仓库未包含私有生产环境的原始抓包、设备日志和真实机械臂复现条件，因此文中的生产指标用于说明排查链路，不构成可由公开仓库独立复现的 benchmark。 复现高负载超时 → 排除网络与进程 → 对齐抓包和 DDS 日志 → 审查 QoS 深度 → 压力测试验证 现象 低负载正常，高负载偶发超时。 网络 在发送端和接收端同时抓包，并检查接口丢包计数。 Discovery 确认端点匹配，但不把“已匹配”当成交付证明。 QoS 分别核对兼容性、历史缓存、资源上限和应用取样速度。 超时 RPC 用请求 ID 和单调时钟定案...

https://quchaosheng.github.io/2026/08/13/i2c-high-frequency-sampling-loss/ 2026-08-13T09:39:00.000Z 2026-08-13T09:39:00.000Z

证据边界 公开仓库未提供对应 RK3576 板卡、示波器波形和驱动压测工程，文中的硬件日志与性能数字不能由公开仓库独立复现；本文重点记录分层定位方法和驱动设计取舍。 确认高频丢样 → 检查物理波形 → 用 ftrace 定位中断延迟 → 调整 IRQ 与 FIFO → 长时间压测 硬件层 检查上拉、频率、边沿与器件响应。 驱动层 观察中断处理、锁和队列是否阻塞。 数据路径 确认 FIFO 深度和消费速度能覆盖突发。 Threaded IRQ 把可睡眠和较重处理移出硬中断。 DMA 大批量传输时降低 CPU 搬运成本。 验证 同时统计丢样率、CPU ...

https://quchaosheng.github.io/2026/08/13/ros2-realtime-latency-optimization/ 2026-08-13T09:38:00.000Z 2026-08-13T09:38:00.000Z

证据边界 本文中的延迟、CPU 占用和控制精度数字来自工程案例稿，公开仓库没有提供相同硬件、RT 内核、LTTng trace 和完整基准脚本。读者应在自己的内核、DDS 实现与控制周期下重新测量，不能直接套用这些结果。 记录控制周期 → 追踪调度延迟 → 隔离实时 CPU → 设置实时策略 → 复测最坏延迟 Trace 用 LTTng 与 eBPF 分析回调和唤醒延迟。 调度 SCHED_FIFO 需要权限、优先级与预算设计。 绑核 实时线程与 IRQ、日志和桌面任务分离。 内存 锁页和预分配减少缺页与运行时分配。 DDS 按控制语义选择 QoS...

https://quchaosheng.github.io/2026/08/13/riscv-heterogeneous-smp-boot/ 2026-08-13T09:37:00.000Z 2026-08-13T09:37:00.000Z

证据边界 公开项目 quard-star-riscv64-net 提供 7+1 hart、OpenSBI domain 和 PMP 故障探针的相关实现；本文选择“平台 M-mode 固件直接接管 hart7”的设计路线。FreeRTOS 集成与部分性能数字不在该公开仓库的完整可复现实验范围内，应按架构说明而非已公开 benchmark 阅读。 平台固件分流 hart → OpenSBI 服务 Linux domain → hart7 进入 M-mode RTOS → 按 hart 配置 PMP → doorbell 与共享内存通信 hart0 承担...

https://quchaosheng.github.io/2026/08/13/can-bus-intermittent-fault-debugging/ 2026-08-13T09:36:00.000Z 2026-08-13T09:36:00.000Z

证据边界 公开项目当前主要提供 vcan 与故障注入层面的验证，不等同于真实七轴机械臂、物理 CAN 总线或量产环境。本文中的示波器记录、故障频率和修复后数字没有随公开仓库提供原始数据，应作为排查案例而非公开可复现结论。 复现偶发卡顿 → 检查物理层 → 分析错误帧与计数器 → 检查 SocketCAN 接收路径 → 核对业务响应时序 物理层 终端电阻、线长、波形和总线速率。 协议层 ACK bit、仲裁、错误帧、error-passive 与 bus-off。 内核层 控制器 FIFO、NAPI/offload 队列、socket 缓冲和驱动统计...