- 博客(118)
- 资源 (8)
- 收藏
- 关注
RSS订阅原创 车载Linux 系统问题定位方法论与实战系列 - OOM 与资源耗尽：系统是如何被“慢慢拖死”的
摘要： OOM（内存耗尽）在车载Linux系统中往往是系统性问题的最终表现，而非单点故障。由于车载环境内存资源有限、碎片化严重，且中间件持续累积内存压力，OOM通常作为内存回收失败的连锁反应触发。关键进程（如看门狗、日志服务）被意外终止可能导致系统崩溃，而内存泄漏会经历缓慢增长、性能下降、稳定性恶化直至系统重置的渐进过程。工程上需通过内存隔离、优先级调整和主动监控（如MemAvailable、Slab回收率）提前预警，将OOM转化为可预期事件。本质上，OOM反映的是系统架构在资源隔离和兜底机制上的缺陷。
2026-01-16 08:00:00
322
原创 车载Linux 系统问题定位方法论与实战系列 - 车载以太网问题定位：从 PHY 到 SOME/IP
车载以太网问题定位：从物理层到服务的系统性挑战 在车载以太网系统中，"Link up ≠ 服务可用"是常见误区。不同于传统网络，车载以太网作为功能链路的核心部分，问题定位需要跨层分析： 分层复杂性：从PHY层到SOME/IP服务层都可能影响功能，下层异常可能表现为上层问题 典型误判：VLAN配置错误等隐蔽问题可能导致"假正常"现象 关键检查点： PHY层需关注CRC错误等硬件指标 VLAN/TSN配置需要与交换机协同验证 tcpdump使用需考虑性能影响 系统性风险.
2026-01-16 07:45:00
548
原创 车载Linux 系统问题定位方法论与实战系列 - 当系统已经无法自救Core Dump —— 车载进程崩溃定位的标准流程
可以将整个分析过程抽象为一条固定 SOP：1️⃣ 确认 core 是否生成（机制检查）2️⃣ 定性崩溃类型（signal / 线程）3️⃣ gdb 还原调用栈4️⃣ 符号 + 源码定位5️⃣ 回到系统层做因果闭环当这一流程固化下来，进程崩溃将不再是“黑盒问题”，而是可解释、可复盘、可改进的工程事件。📌下一篇将继续沿事故链向下，展开：资源耗尽 / OOM 是如何在系统层面一步步放大并最终触发 reset 的。
2026-01-16 07:30:00
528
原创 车载Linux 系统问题定位方法论与实战系列 - 系统 reset / reboot 问题定位
摘要： 车载Linux系统中，reset/reboot是严重系统事故信号，必须单独分析。reset会清空现场，增加定位难度。分析路径为：reset reason→上次启动日志→异常积累过程→根因。通过reset reason缩小问题空间，如watchdog、panic等。重点查看上次启动日志(journalctl -k -b -1)，聚焦reset前关键时段和关键词。watchdog reset常是内存耗尽等问题的最终表现，而非根因。正确分析需将reset置于系统运行上下文中，还原异常积累过程，才能有效解决
2026-01-15 22:21:38
127
原创 车载Linux 系统问题定位方法论与实战系列 - Kernel Panic / System Hang：当系统已经无法自救
当系统陷入Kernel Panic或System Hang状态时，意味着系统已处于失控边缘。Kernel Panic是内核主动终止运行的行为，会留下结构化日志（如调用栈和寄存器状态），这些信息是定位问题的关键。System Hang则更为隐蔽，系统虽未崩溃但已失去响应能力。两者在工程定位上存在显著差异：Panic通常有明确日志，而Hang往往需要借助SysRq等工具获取现场信息。在车载Linux系统中，串口日志、pstore机制和SysRq是诊断这类问题的重要工具。理解这些状态的区别和联系，对解决复杂系统故
2026-01-15 08:30:00
1308
原创 Ethernet-SOME-IP — 附录A3 KPI 仪表板与 SLO 建议
本文提出了一套SOME/IP系统的可观测性方案。核心内容包括：1)详细指标建议，涵盖订阅管理、事件质量、网络队列、资源和时钟同步等维度；2)看板布局建议，包含5个关键视图；3)SLO示例，如事件到达间隔P95≤1.2×周期等；4)最小闭环实践，强调以数据驱动的排查和回归流程。方案基于现有exporter实现，旨在建立数据闭环，提升问题排查效率。
2026-01-15 07:30:00
337
原创 车载Linux 系统问题定位方法论与实战系列 - 开篇: 为什么需要一套“系统化”的 Linux 问题定位方法
本文探讨了Linux系统问题定位的系统化方法。针对服务器、嵌入式设备等场景中常见的系统级异常（如随机重启、内核崩溃、进程偶发故障等），作者指出传统依赖零散日志的排查方式存在局限性，尤其在车载等长周期运行环境中问题更为突出。文章提出了一套可复用的方法论框架，强调通过多层级观测工具（内核日志、系统日志、进程跟踪、硬件状态等）重建问题现场，并建立时间线分析因果关系。系列文章将分专题讲解reset/reboot、kernel panic、进程崩溃等典型问题的定位思路，旨在帮助工程师形成系统级问题分析的思维模型。
2026-01-15 07:00:00
500
原创 Ethernet-SOME-IP — 附录A2 回放与压力脚本示例
本文提供了五种网络问题复现与压力测试方法：1）使用tcpreplay回放PCAP流量；2）Python脚本生成自定义UDP组播流；3）通过中断合并和队列设置放大延迟抖动；4）MTU调整测试分片影响；5）PTP时钟同步监测。所有方法需在隔离环境中操作，避免影响生产设备，并建议配合抓包工具验证效果。这些方法可帮助定位网络延迟、丢包、时钟同步等问题。
2026-01-14 08:30:00
168
原创 Ethernet-SOME-IP — 附录A1 抓包与诊断速查表
本文提供了一份网络故障排查速查表，涵盖抓包、IGMP、QoS、MTU、PPS和时钟等关键环节。重点包括：1）抓包命令集，支持端口、组播抓取及离线分析；2）IGMP/组播路径验证方法；3）QoS队列与丢包检测技巧；4）MTU分片自检流程；5）带宽/PPS/CPU性能监控；6）时钟同步状态检查。最后给出6步最短路径复盘清单，从抓包验证到时钟检查，帮助快速定位网络问题。建议配合实战手册使用，通过系统化检查提升排查效率。
2026-01-14 08:15:00
632
原创 Ethernet-SOME-IP 系列 — 总结与展望：从 CAN 到服务化通信的工程方法
本文系统梳理了车载通信从CAN总线向车载以太网/SOME/IP演进的核心逻辑。文章指出，这一转变的本质是系统语义的升级——从周期性广播转向服务化通信架构。关键点包括：1）SOME/IP通过服务发现和订阅机制重构通信关系；2）事件建模需确保数据完整性和时序处理；3）性能评估需量化带宽、PPS和CPU开销；4）系统活性需多层检测与恢复机制；5）应用层治理强调版本控制和灰度发布。文章最终形成包含契约模板、算账模型、看板指标在内的工程工具箱，使通信系统实现可控、可观测和可演进。
2026-01-14 07:30:00
1384
原创 Ethernet-SOME-IP 系列 — SOME/IP 工程落地与演进：接口契约、版本管理与灰度发布
本文聚焦SOME/IP工程应用层治理，提出从接口契约到灰度发布的完整解决方案。通过定义清晰的语义边界、版本管理机制和消费模式，确保雷达对象列表事件的稳定处理与兼容演进。重点包括：契约模板明确事件语义和错误处理；版本控制通过major/minor和能力位实现兼容；消费者采用防御性处理策略；建立可靠性降级机制和可观测性指标；实施严格的测试矩阵和灰度发布流程。最终形成一套可演进、可回滚、可验收的工程化方法，将网络通信模型转化为量产可控的团队工作规范。
2026-01-14 07:00:00
1294
原创 Ethernet-SOME-IP 系列 — SOME/IP 的 Alive、Timeout 与 CAN 世界有什么不同？
本文探讨了CAN与SOME/IP在通信机制上的本质差异：CAN基于周期性信号监测，而SOME/IP强调服务生命周期管理。SOME/IP通过服务发现（SD）、订阅TTL和事件节律三层机制实现"失效可控"的通信模型，将工程安全从"永远在线"转变为"可预期恢复"。文章提出了具体的观测指标和恢复策略，建议通过量化SLO、建立KPI看板和设计降级剧本来实现系统稳定性。相比CAN的硬件级容错，SOME/IP需要在应用层实现更精细的状态管理和失效处理机制。
2026-01-13 08:15:00
746
原创 Ethernet-SOME-IP 系列 — Ethernet 带宽、CPU、拷贝次数：你真的“算过一次”吗？
本文针对SOME/IP Event通信中的性能问题，提出了量化分析方法。通过建立数据链路模型，计算了带宽、CPU拷贝次数和包处理能力(PPS)之间的数学关系。重点分析了5个雷达20Hz场景下的实际负载，对比了单播与多播的性能差异，指出PPS是隐藏的性能瓶颈。文章提供了可复用的工程算账模板，强调上线前应进行链路级带宽预算、PPS控制和CPU负载评估。最后给出测量方法和QoS优化建议，帮助团队在通信设计阶段准确预测性能瓶颈。
2026-01-13 08:00:00
1571
原创 Ethernet-SOME-IP 系列 — Radar Object List 上 Ethernet：从 CAN Frame 到 SOMEIP Event
本文系统阐述了雷达目标列表(Radar Object List)从CAN总线迁移至以太网SOME/IP服务的工程实现方案。核心内容包括：1) 将离散的CAN信号重构为完整的对象快照语义；2) 设计RadarObjectService服务接口与事件模型；3) 优化payload结构，确保版本兼容性；4) 基于UDP多播的传输策略与MTU优化；5) 时间同步与抖动控制机制；6) 消费者侧的可靠性处理策略；7) 带宽与CPU资源预估方法。该方案在保持算法语义完整性的同时，实现了高效、可观测的车载通信架构。
2026-01-13 07:00:00
678
原创 Ethernet / SOME-IP 系列 — SOME/IP 通信模型： Service Discovery、订阅与生命周期
SOME/IP通信模型与传统CAN总线存在本质差异。本文分析了SOME/IP特有的服务发现机制和订阅生命周期管理：1）通过Service Discovery动态管理服务可用性；2）明确区分Offer、Find、Subscribe三个关键步骤；3）强调ECU启动顺序对通信建立的影响；4）指出订阅关系需要主动维护而非永久有效。文章揭示了80%的"收不到数据"问题源于服务发现流程缺失或生命周期管理不当，而非协议或带宽问题。这种动态通信模型要求开发者转变CAN时代的静态假设思维。
2026-01-12 09:00:00
1083
原创 Ethernet / SOME-IP 系列 — SOME/IP 是什么？它解决的不是“传输”，而是“服务”
**摘要：**SOME/IP（Scalable service-Oriented MiddlewarE over IP）**是以太网车载通信的核心中间件，其设计目标明确体现在名称中： 可扩展：支持多ECU、多服务的动态扩展，适应域控架构需求； 面向服务：以“服务”为通信单位，定义接口、生命周期和语义边界，与CAN信号模型形成本质差异； 中间件：位于TCP/UDP之上，封装连接管理、编解码等底层细节，使开发者聚焦服务逻辑； 基于IP：天然支持跨ECU路由和跨域通信。
2026-01-12 07:30:00
1624
原创 Ethernet / SOME-IP 系列 — 汽车以太网到底和我们熟的 Ethernet 有什么不一样？
本文对比了车载以太网与传统以太网的关键差异，指出车载以太网从物理层开始就为汽车环境优化：采用单绞线设计（100/1000BASE-T1），取消CSMA/CD机制，通过交换机实现确定性传输。核心差异在于思维转变——从CAN的时间驱动、信号传输转向以太网的服务化架构（结合SOME/IP协议），实现数据订阅和服务管理。车载以太网本质是受控系统工程，通过固定拓扑、QoS优先级等设计满足汽车可靠性需求，其价值不仅是带宽提升，更是为智能驾驶提供结构化数据表达能力。
2026-01-11 20:21:59
777
原创 Ethernet / SOME-IP 系列 — 从 CAN 到 Automotive Ethernet：不是“带宽不够”，而是系统变了
汽车通信技术正从CAN向以太网迁移，根本原因并非简单的带宽不足，而是系统架构和数据处理模式的根本性变革。传统CAN擅长周期性控制信号传输，但无法适应现代智能驾驶系统对感知数据（如雷达目标列表、高清地图等）的需求——这些数据具有集合语义、可变结构和订阅消费特性。以太网/SOME-IP通过服务化模型实现了数据按需订阅和动态分发，使通信能准确表达系统结构关系。CAN仍将保留在控制回路等强实时场景，而以太网则成为感知主干网络，这一转变标志着汽车电子架构从信号导向转向数据服务导向。
2026-01-11 08:45:00
450
原创 自动驾驶中间件iceoryx - （附录）C++ 内存模型与原子操作详解
C++内存模型与原子操作详解 本文深入讲解C++11引入的内存模型和原子操作，重点分析acquire/release语义及其在生产者-消费者模式中的应用。通过对比不同内存序（relaxed、acquire/release、seq_cst）的性能和语义差异，揭示如何正确实现无锁同步。文章特别指出iceoryx等高性能系统如何利用这些机制优化进程间通信，并提供了实用建议：开发初期使用seq_cst确保安全，性能关键路径采用acquire/release提升效率。最后通过x86平台性能数据（relaxed比acq
2026-01-11 08:00:00
976
原创 自动驾驶中间件iceoryx - 同步与通知机制（二）
本文深入解析了iceoryx中间件的同步与通知机制，重点介绍了ConditionNotifier和ConditionListener组件的实现原理及其在ChunkQueue中的协同工作方式。ConditionNotifier作为通知生产者端，通过原子计数器和信号量实现高效的事件触发；ConditionListener作为消费者端，提供阻塞/非阻塞两种检查方式，并采用边缘触发机制避免虚假唤醒。文章还展示了这些组件如何集成到ChunkQueue中完成从发布者到订阅者的完整通知链路，并介绍了订阅者的三种消费模式（
2026-01-10 14:23:46
713
原创 自动驾驶中间件iceoryx - 同步与通知机制（一）
本章详细介绍了iceoryx的通知平面机制，包括信号量、WaitSet和回调等同步原语的实现与应用。通过对比轮询和事件驱动两种模式，分析了事件驱动在CPU利用率、延迟和功耗方面的优势。重点讲解了UnnamedSemaphore的实现，包括其POSIX底层封装、Builder设计模式和CRTP技术。内容涵盖从基础概念到性能调优的完整知识体系，并提供了三种学习路径（快速上手/深入理解/按需查阅）以满足不同需求层次开发者的学习目标。
2026-01-10 14:19:36
995
原创 CAN系列 — (10) 从一帧报文到系统行为：CAN 的工程边界在哪里？
《CAN工程实践：从协议到系统的认知跃迁》摘要： 本文作为CAN系列收官之作，揭示了工程实践中CAN问题的本质——不是协议本身的问题，而是对CAN在系统中的角色认知偏差。通过拆解一帧报文在ECU中的完整流转过程（物理层→驱动层→协议层→应用层），指出真实工程问题往往发生在层级交界处。文章列举了三大典型问题场景：带宽未满但CPU中断被打爆、Alive信号存在但系统已不安全、规范配置反而导致Object List维护困难。特别强调在感知系统中，CAN适合作为状态同步接口但不适合承载算法内部模型。
2026-01-10 08:30:00
1636
原创 CAN系列 — (9) Fail-Silent / Fail-Operational：CAN 通信在功能安全里扮演什么角色？
本文从通信视角澄清了功能安全中Fail-Silent与Fail-Operational的核心区别。指出它们不是ECU属性而是系统行为：Fail-Silent要求故障后停止输出可能误导的信息，Fail-Operational则需维持可接受的安全功能等级。
2026-01-10 07:30:00
1448
原创 CAN系列 — (8) 为什么 Radar Object List 不适合“直接走 CAN 信号”
本文探讨了Radar Object List在CAN通信中的处理方式演变。文章指出，尽管早期项目常将Object List拆分为独立CAN信号处理，但随着系统复杂度增加，这种"信号化"方式会带来生命周期撕裂、安全语义错位和性能问题。Object List本质上是一个完整的感知结果集合，而非独立变量组合。因此，成熟项目往往会改用Raw PDU方式整体处理，仅保留Header报文走标准信号流程。这反映了CAN在感知系统中的合理边界：适合传输稳定状态量，但不适合承载动态的算法输出集合。文章强调
2026-01-09 22:08:03
817
原创 CAN系列 — (7) Alive、Counter、Timeout：CAN 报文里的功能安全不是“多几个字段”
功能安全通信机制解析：Alive、Counter与Timeout的正确使用 在CAN总线功能安全设计中，Alive、Counter和Timeout常被误用。Alive检测的核心是功能逻辑的周期性执行，而非简单的报文存在；Counter用于验证报文序列完整性，两者功能互补。Timeout的关键在于层级选择，应用层Timeout比通信层Timeout更能反映系统真实状态。特别要注意，Object Data报文不适合承载Alive信号，应将其置于Header/Status报文中。功能安全设计的本质是将机制置于正确
2026-01-09 21:59:18
521
原创 CAN系列 — (6) CAN FD 带宽、CPU、中断：工程上是如何一起算的？
摘要： 在毫米波雷达系统中，CAN FD总线负载、MCU中断和CPU处理需同步计算。5个雷达（50ms周期，64对象/周期）在CAN FD总线上产生约53%负载，瞬时突发发送导致高密度中断（无FIFO时1600次/秒，FIFO优化后400次/秒）。CPU平均负载约10%，但周期边界可能出现4-6ms集中峰值。关键结论：周期延长仅降低平均值，瞬时压力仍需通过总线优化、FIFO配置和峰值管理协同解决，避免实时任务延迟。（149字）
2026-01-09 21:42:38
870
原创 CAN系列 — (5) COM / PduR / CanIf 的职责边界：为什么它们不能互相越界
雷达Header报文作为MCU感知周期的语义锚点，其周期管理和完整性判断逻辑必须由应用层（SWC/CDD）处理，而非通信底层模块（CanIf、PduR或COM）。CanIf仅负责原始帧收发，PduR专注路由分发，COM只做信号解包，三者都不应包含业务语义。将感知周期状态机置于应用层可保持架构清晰，避免通信层与业务逻辑耦合，确保系统在雷达升级或策略变更时的可维护性。这是保证量产系统可靠性的关键设计原则。
2026-01-09 21:39:09
486
原创 CAN系列 — (4) Radar Header 报文：为什么它是 MCU 感知周期的“锚点”
摘要： Radar Header报文并非数据载体，而是MCU感知周期的"语义锚点"，其核心价值在于定义周期边界和系统状态。它通过Cycle Counter、Object Count等字段声明当前周期的完整性条件，使MCU能准确拼装Object List。Header缺失将导致周期数据失效，因此工程中遵循"宁可丢周期，不可用错周期"原则，其稳定性优先于单个Object精度。此外，Header还承担系统活性监控、功能安全触发等关键角色，是感知系统可靠运行的基石。
2026-01-08 21:50:01
783
原创 CAN系列 — (3) Radar Object List 在 MCU 内部是如何被拼装、校验并最终被消费的？
本文探讨了雷达CAN FD报文在MCU中的接收与处理流程。指出CAN报文接收仅是物理层完成，MCU需重建完整的语义信息。关键点包括：1）以Header为周期起点，通过expected_obj_num验证数据完整性；2）遵循"全有或全无"原则进行一致性校验；3）采用双缓冲机制，确保上层算法获取稳定的Object List快照。整个过程体现了MCU作为"感知事实"验证者的核心作用，而非简单的报文转发节点。
2026-01-08 21:46:27
889
原创 CAN系列 — (2) CAN 接收中断是如何触发的？一帧一中断真的合理吗？
摘要： 在ECU开发中，早期采用“一帧一中断”的CAN接收设计在低频控制场景（如车身控制）表现良好，但当引入高频批量数据（如CAN FD雷达Object List）时，该模型会导致CPU被频繁打断（如5雷达场景达1500次/秒中断），引发调度抖动。通过配置Rx FIFO+Watermark（如水位8/16），可将中断次数降至100次/秒，实现从“帧驱动”到“周期语义驱动”的转变。关键判断标准在于数据特性：低频离散信号适用单帧中断，而高频批量数据需采用FIFO批量处理以保障系统稳定性。
2026-01-07 22:54:40
739
原创 CAN系列 — (1) 一帧 CAN 报文在 ECU 中的完整生命周期
fill:#333;important;important;fill:none;color:#333;color:#333;important;fill:none;fill:#333;height:1em;CAN BusCanIfRxPduId映射, Controller状态PduRI-PDU路由COMSignal解包, Alive/Deadline监控RTESignal映射到SWC端口业务处理这张图清楚展示了报文的传递路径和每层的主要职责。一帧 CAN 报文的生命周期，是。
2026-01-07 22:00:37
1220
原创 现代汽车中的通信方式 ——以智能驾驶系统为例
车载通信网络：智能驾驶系统的隐形支柱 智能驾驶系统的性能不仅依赖算法与算力，更受限于车载通信网络这一基础架构。随着车辆功能复杂化，传统点对点线束被多协议协同的网络体系取代：LIN处理低成本车身控制，CAN/CAN FD保障控制指令的实时性与可靠性，FlexRay满足高安全需求，车载以太网则承载高带宽感知数据。不同协议在分域架构中各司其职，形成带宽驱动（感知）、确定性优先（控制）和闭环反馈三大典型场景。通信能力直接决定系统架构可行性，其设计需与算法开发同步推进，成为智能驾驶工程化的重要前提。
2026-01-06 22:08:11
718
原创 自动驾驶中间件iceoryx - 内存与 Chunk 管理（三）
本文深入剖析了iceoryx中间件的无锁并发内存管理机制。重点解析了Compare-And-Swap(CAS)原子操作的原理及其在Chunk分配中的高效应用：通过CAS循环实现多进程并发访问内存池，相比传统互斥锁方案可显著降低延迟（从200ns降至40ns）并提升吞吐量（5M/s到20M/s）。关键创新在于利用CAS失败时自动更新期望值的特性，避免了重复原子读取操作，使高优先级进程无需等待即可获取内存资源，完美满足自动驾驶系统对实时性的严苛要求。
2026-01-06 21:29:56
1674
原创 为何高阶自动驾驶偏爱 Raw Sensor？
高阶自动驾驶系统普遍选择输出原始RAW数据的摄像头而非自带ISP处理的智能摄像头，这源于对信息完整性和算法自由的追求。RAW数据保留了12-14位光强信息，支持端到端AI训练和多摄协同HDR，而ISP处理会丢失动态范围并引入非线性失真。尽管RAW传输需要更高带宽（如8MP@30fps约3Gbps），但GMSL等高速接口能胜任。特斯拉、小鹏等L3+方案均采用Raw Sensor+中央ISP架构，而智能摄像头仍适用于L2及环视等场景。Raw Sensor为算法演进提供了原始信号基础，是实现真正机器视觉的关键。
2026-01-05 22:00:00
881
原创 自动驾驶中间件iceoryx - 内存与 Chunk 管理（二）
本文深入剖析了iceoryx零拷贝通信的内存管理机制，重点讲解了共享内存布局、MePoo内存池结构及Chunk生命周期管理。主要内容包括：1）BumpAllocator线性分配器的初始化策略；2）Chunk的64字节头部结构（含魔数校验、序列号、引用计数等关键字段）；3）Chunk从分配、借出、发布到释放的完整状态转换流程。文章通过详细的内存布局图和状态转换图，系统性地展示了iceoryx实现高效零拷贝通信的核心机制。
2026-01-05 21:00:00
1055
原创 Windows 11 + WSL2 搭建开发环境
这次问题的本质，不是“无法访问某个网站”，而是“虚拟机环境与主机服务之间的网络可见性配置”。理解 WSL2 的虚拟网络架构让本地工具监听对外接口（0.0.0.0在 WSL2 中正确指向 Windows 虚拟网关 IP为不同工具配置代理（Git 需单独设置）希望我的这次排查记录，能帮到同样在 WSL2 中遇到网络问题的开发者。技术问题，终究要靠技术手段解决。附：关键配置速查# WSL2 中设置代理（永久）# Git 全局代理# 验证Hope的每一次git clone都秒速完成！
2026-01-04 20:50:40
455
原创 自动驾驶中间件iceoryx - 内存与 Chunk 管理（一）
本章详细介绍了iceoryx的内存管理机制，主要包括共享内存架构、内存池管理和Chunk生命周期等核心内容。系统采用Segment和MemPool两层架构，通过预分配共享内存实现零拷贝通信。关键点包括：1) MePoo内存池的配置与计算；2) 共享内存创建流程(shm_open→ftruncate→mmap)；3) Chunk的生命周期管理(分配、借出、发布、释放)；4) 基于RelativePointer的跨进程内存访问机制。设计上强调确定性，避免运行时动态分配，使用无锁数据结构满足实时性要求。
2026-01-04 14:38:00
615
原创 Tesla 用人眼都看不懂的 RAW 图像训练 AI？
Tesla 的做法看似矛盾——用 RAW 训练，却用 RGB 标注——实则体现了深刻的工程哲学：🔑让机器看原始世界，让人看可理解世界，再用系统对齐二者。这不是偷懒，而是在信息完整性与标注可行性之间找到最优解。所以，下次惊叹于 Tesla 在暴雨夜中精准识别交通灯时，请记住：那背后不仅是 AI 的胜利，更是一套精密协同的数据生产体系的胜利。灵感来源：Tesla AI Day 2021/2022, CVPR 自动驾驶研讨会, NVIDIA 技术博客。
2026-01-04 13:56:07
610
原创 自动驾驶摄像头链路：从像素到决策的高速通道
摘要： GMSL（Gigabit Multimedia Serial Link）是自动驾驶摄像头数据传输的核心技术，解决了传统LVDS方案的短板。相比LVDS，GMSL通过单根同轴电缆实现长距离（≤15米）、高带宽（6–12 Gbps）传输，并集成供电（PoC）和双向控制功能，将每路摄像头的线束从6+根缩减至1根。其工作流程包括串化（Serializer）和解串（Deserializer），最终输出标准MIPI CSI-2接口供自动驾驶SoC处理，对上层完全透明。特斯拉等车企通过GMSL大幅简化了整车线束架
2026-01-04 12:59:11
657
原创 为什么 PROSAC 是 RANSAC 的“智能升级版”？实时系统首选！
PROSAC算法是RANSAC的智能升级版，通过利用数据点的先验信息（如特征匹配得分）实现高效模型估计。核心优势在于： 渐进式采样策略：优先选择高置信度点生成假设模型，大幅提升收敛速度（比RANSAC快5-10倍） 精度保障：找到内点后精化拟合，精度与MSAC相当 天然适配现代视觉系统：可直接利用特征匹配得分等现有信息 典型应用场景： 有先验信息的视觉任务（特征匹配、SLAM等） 实时性要求高的系统（AR/VR、自动驾驶） 特征提取器提供置信度得分的场景 算法仅需提供数据点和对应置信度得分，即可实现智能采样
2026-01-03 09:05:18
924
【计算机视觉】基于蒙特卡洛预处理的GPU加速RANSAC模型：三维点云平面分割中的高效一致性集生成方法
2025-12-28
quaternion.pdf
2020-04-04
road environment modeling using robust perspective analysis
2020-04-11
MIMO技术浅谈.pdf
2020-04-04
转动参考系——位置、速度、加速度详细推导公式.ppt
2020-04-06
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人