CppCon 2014 学习: C++ on Mars

主要介绍了如何在火星探测器的飞行软件中使用 C++。：

• 介绍了火星探测器（如 Sojourner, Spirit, Opportunity, Curiosity, Perseverance）。
• 强调其复杂性和自主性。

延迟的现实：地球与火星之间的通信时延

• 单程信号延迟为 4 到 22 分钟。
• 无法实时操控火星车，因此必须让其具备 自主决策能力。

通信限制：深空网络（Deep Space Network）

• NASA 的 DSN 是多个任务共享的通信基础设施。
• 每天只能进行少量上/下行数据通信。

一天的任务可能包括：

• 驾驶（navigation）
• 机械臂操作（instrument usage）
• 远程科学观测（spectrometry, imagery 等）
  设计关键点：
• 火星车需要能“自主运行一天，然后发送数据”，系统必须可靠、健壮。

那么如何构建这样的系统？

1. 使用健壮、容错的软硬件设计
2. 尽可能加入自治功能
3. 用 C++ 构建自主逻辑
4. 测试测试测试

软件资源（Software Resources）

• 飞行软件的架构
• 使用的语言（C / C++）
• 驱动库、任务执行模块、计划系统（Plan Execution Engine）
• 容错机制（看门狗、故障检测与恢复）
• RCU（Read-Copy Update）、状态机、消息传递机制等

总结与应用场景

项目特点	设计需求与挑战
火星通信时延	系统必须具备高自治能力
通信带宽/窗口受限	必须高效计划与调度任务，压缩数据
环境恶劣	软件和硬件都需容错，尤其软件需鲁棒
软件不可远程修复	高质量测试和验证流程是前提
多任务执行（驾驶、采样）	高级调度逻辑、实时反应、状态管理需要更高层语言
使用 C++	提供抽象、模块化、状态表达和类型安全

展示了 NASA 火星探测器 MER（Mars Exploration Rover） 和 MSL（Mars Science Laboratory，搭载 Curiosity 火星车） 所使用的 软件与硬件资源。这对理解为什么和如何在火星探测器上使用 C++ 非常关键。

软件与硬件资源对比：MER vs. MSL

属性	MER（Spirit/Opportunity）	MSL（Curiosity）
CPU	RAD6000（PowerPC 架构） 辐射加固	RAD750（更强的 PowerPC） 辐射加固
主频	20 MHz	133 MHz
RAM（总）	128 MB	512 MB（其中一半用于 RAMFS）
代码地址空间	32 MB	32 MB
FSW + RTOS Code Size	10 MB	21 MB
操作系统	VxWorks 5.3.1（实时）	VxWorks 6.7（更新版本）
内存访问模型	Shared Memory（每任务共享）	Shared Memory
编程语言/编译器	C / Embedded C++ Green Hills MULTI 3.5	C / Embedded C++ GCC 4.1.2

关键理解

1. CPU：专为太空设计

• RAD6000 / RAD750 是专为抗辐射环境（如火星）设计的处理器。虽然性能低于地球上的普通手机 CPU，但稳定性高，能抗空间辐射。
• RAD750 相比 RAD6000 拥有更高频率和更强性能，是一种“升级版”。

2. 内存限制与优化

• 两者 RAM 都远低于现代计算机。
  • MER：仅 128MB RAM，总可用代码空间仅 32MB。
  • MSL：升级为 512MB RAM，但只有一半用于程序与数据（其余用于 RAMFS，即 RAM 文件系统）。
    这说明：软件必须极度精简与高效 —— 不能有内存泄漏，不能有膨胀的依赖链。

3. 操作系统：VxWorks 实时系统

• VxWorks 是商业级嵌入式实时操作系统，专为航空航天、军事和工业控制设计。
• 支持多任务、定时任务、优先级调度，是火星任务中关键的稳定基础。

4. 共享内存访问模型

• 所有任务使用共享内存模型，没有虚拟内存（无 MMU 保护机制）。
• 需要高度小心的数据访问同步（例如使用互斥锁、RCU 或类似机制）。

5. 编译器和语言

• MER 使用的是 Green Hills MULTI 3.5（商业高可靠嵌入式工具链），MSL 则使用了 GCC 4.1.2。
• 语言方面都使用了 C / Embedded C++：
  • “Embedded C++” 是 C++ 的一个子集，去除 RTTI、异常处理、多重继承等复杂特性。
  • 保留类、封装、少量模板，用于提高模块性和可维护性。

总结：这些资源对使用 C++ 的意义

资源限制	设计影响
CPU 频率低、RAM 少	要求代码高效、运行时开销极低
无 MMU / 无虚拟内存	需要手动管理内存，注意同步和隔离
实时系统 VxWorks	需要满足硬实时调度与确定性行为
嵌入式 C++	只能用有限的 C++ 特性，不能依赖运行时反射、异常等机制
编译器不同	要保证跨平台、跨编译器一致性；通常会编写适配层与兼容性代码
如果你愿意，我还可以继续帮你梳理：

• 后续如何在这种受限平台上实现复杂的自主导航与任务执行；
• 火星探测器的软件架构（调度器、状态机、任务模型）；
• 或者进一步讲解 VxWorks 与现代 C++ 的融合方式。

介绍了 NASA 火星探测器（MER 和 MSL）飞行软件（Flight Software, FSW）模块化设计 的关键特性。它为理解在极度受限、远程操作的航天系统中如何组织复杂软件系统提供了非常宝贵的参考。

Mars Rover FSW 模块化设计要点

1. 模块数量庞大

“MER and MSL each have over 100 individual source code modules.”

• 每个探测器的 FSW 拥有超过 100 个独立模块。
• 每个模块往往负责特定功能，比如：
  • 驱动控制（Drive Control）
  • 电源管理（Power Management）
  • 科学仪器数据处理
  • 通信系统（Uplink/Downlink）
  • 错误检测与恢复（Fault Protection）

2. 每个模块由一位开发者负责

“Each module had a single FSW developer as its owner.”

• 强调代码所有权和责任清晰。
• 在航天系统中非常重要 —— 任何一行代码都可能决定任务成败。
• 模块之间责任隔离，降低交叉错误可能性，提高可维护性。

3. 模块通信：消息队列而非共享内存

“Modules typically communicate by passing messages through Message Queues assigned to each task.”

• 每个任务有一个消息队列，模块间通过消息异步通信：
  • 避免共享内存引发的同步难题
  • 增强系统解耦性，便于调试与测试
  • 天然适配分布式和实时架构
    补充说明：
• 这是典型的 actor 模型 或 事件驱动架构（EDA） 变体。
• 类似于现代分布式系统中微服务通信（通过队列或总线）。

4. 几乎不用锁或共享内存

“Very minimal use of semaphore locks, shared memory.”

• 使用共享内存与信号量会带来：
  • 复杂的竞态条件处理
  • 难以验证的同步问题
  • 在无 MMU 系统中风险极高（例如数据破坏）
    他们刻意设计成消息驱动架构，以规避这些并发复杂性。

5. 深入学习推荐

Learn more: “Curiosity’s FSW Architecture: A Platform for Mobility and Science”, Dr. Kathryn Weiss, NASA JPL, video from 2012 Flight Software Workshop

• 这是 NASA Jet Propulsion Laboratory（JPL）在 2012 年的一场技术讲座。
• Dr. Kathryn Weiss 详细讲解了：
  • MSL 飞行软件的整体架构
  • 任务管理模型
  • 模块间通信机制
  • 软件测试与部署策略
    可以通过这个演讲进一步理解实际工业级航天系统中的软件工程实践。

总结：这个设计意味着什么？

特性	含义与优势
每个模块独立开发	清晰职责边界，易于管理与调试
模块间用消息通信	降低耦合，避免并发问题，增强可靠性
尽量不使用锁	适配实时系统，避免难调试错误
大量小模块	体现“微内核”或“组件式”设计思想
嵌入式 C++ 实现	精简、高效、靠近底层硬件控制层
如果你感兴趣，我还可以继续帮你分析：

• 消息队列的具体实现方式；
• 任务调度模型（比如是否采用优先级轮转）；
• 如何在没有标准库支持的情况下编写 C++ 模块化代码；
• 或者对比现代软件架构（微服务、actor 等）和它的设计异同。
  

展示了火星探测漫游车（MER，Mars Exploration Rover）移动软件（Mobility FSW Modules）的架构，来自 NASA/JPL-Caltech。以下是理解：

1. 标题和背景

• 标题：MER Mobility FSW Modules（火星探测漫游车移动软件模块）。
• 来源：NASA/JPL-Caltech。
• 问题：表面导航（Surface Navigation）是复杂度最高的模块，占 MER 目标代码的 21%，占 MSL（火星科学实验室）的 10%。如何管理其复杂度？

2. 模块架构图

• 模块和功能：
  • Cmd：命令模块，发出移动命令（如 goto_waypoint(x,y)）。
  • HO (Camera)：相机硬件，发送相机命令。
  • IMG：图像处理模块，生成立体图像对（take_stereo_pair），完成后通知（done）。
  • MOBM：移动管理模块，核心模块，协调视觉和移动操作，发出资源请求（request_resource）并接收 grant/refuse 响应。
  • ACM/ARB：仲裁模块，处理资源分配。
  • SAPP：表面评估和路径规划模块。
  • IMU：惯性测量单元，输出速率和加速度（rates, accels）。
  • RIMU HO：冗余IMU硬件。
  • DRIVE：驱动模块，执行移动模式（mobility_mode）、轮速（wheel odometry）、位置（position）、转弯（arc or turn）等。
  • NAV：导航模块，执行以下步骤：
    1. 计算视觉里程计更新（Compute vikom update）。
    2. 位置估计（Position est）。
    3. 地形评估（Terrain Assessment）。
    4. 选择路径（Select Waypoint Path）。
    5. 启动或转弯（Start or turn）。
  • MOT：电机模块，接收电机命令（motor commands）。
  • Motors HO：电机硬件。
• 交互：
  • 模块之间通过箭头表示数据流和命令流，例如从 Cmd 到 MOBM 的 goto_waypoint(x,y)，从 MOBM 到 DRIVE 的 start-stop driving。
  • 视觉和移动数据（如 visual odometry 和 mobility_mode）在模块间传递。

3. 复杂性分析

• 占比：
  • 表面导航占 MER 目标代码的 21%，MSL 的 10%。
• 挑战：
  • 导航模块需要处理多源数据（图像、IMU、电机反馈等），执行复杂的路径规划和地形评估。
  • 模块间的协调（资源请求、命令执行）增加了系统复杂度。

4. 管理复杂性的思考

• 问题：如何管理这种复杂度？
• 可能策略（未在图中直接说明，但可推测）：
  • 模块化设计：将功能分解为独立模块（如图所示）。
  • 异步通信：通过 request/grant 机制减少耦合。
  • 冗余设计：如 RIMU HO，提供备份以提高可靠性。
  • 优先级管理：通过 ACM/ARB 仲裁资源分配。

总体理解

• 这是一个复杂的移动软件架构，专门为火星探测漫游车设计，涉及导航、路径规划、图像处理和电机控制。
• 核心挑战在于协调多个模块（MOBM、NAV、DRIVE 等），同时处理火星表面导航的高复杂度任务。
• 管理复杂性可能需要进一步的模块化、异步操作和资源管理策略。

强调了在 NASA 的火星探测器任务中，使用 C++ 实现自主驾驶软件的重要性与实际应用领域。以下是详细理解与分析：

使用 C++ 的理由：Why Use C++

“Most of the onboard autonomous driving software on MER and MSL is written in C++”

C++ 的优势，尤其在嵌入式/航天领域：

• 性能高效：无需虚拟机或垃圾回收，适合资源受限环境（如火星探测器上的低功耗 CPU）
• 精细控制：对内存管理、对象生命周期控制精确
• 面向对象设计：便于模块化、抽象复杂行为（如多阶段路径规划）
• 兼容 C：可以调用底层硬件接口或 VxWorks API
• 嵌入式支持成熟：如使用 Green Hills MULTI 或 GCC 工具链进行静态编译

用 C++ 实现的关键自主功能（MER & MSL）

这些模块构成了“火星探测器自动驾驶大脑”的核心：

自主功能模块	功能说明
Dense Stereo Vision	基于左右摄像头图像生成高密度三维点云（depth maps）以估计地形高差和障碍物
Autonomous Terrain Assessment	自动判断路径是否可通行，识别危险地形（如沙丘、悬崖）
Local and Global Waypoint Planning	本地导航用于绕开眼前障碍物，全局规划确保前往更远的科学目标
Multi-sol Driving	规划持续数天（sols，火星日）的任务路径，支持长时间自主前进
Visual Odometry	通过比较图像估算实际行驶距离和姿态变化，防止轮滑（wheel slip）误判位置
Slip Checks	检测探测器是否“打滑”或陷入沙地，判断是否需要调整策略
Keepout Zone Prediction	动态预测并规避不可进入的区域，例如松软沙地或陡坡

总结：C++ 在任务中的角色

维度	C++ 的作用
性能	实时处理图像、点云等计算密集型任务
可维护性	面向对象结构支持模块间解耦，如视觉模块与导航模块分离
可扩展性	支持后续升级，如加入新传感器或算法
鲁棒性	静态类型系统、RAII（资源管理）提高稳定性

NASA 选择 C++ 的深层原因：

1. 不是“因为可以”，而是“因为必须” —— 在火星上没有调试器、没有救援，软件必须稳定而高效。
2. 火星探测器必须在 计算资源极度有限（如 20MHz、128MB RAM） 的硬件上运行高级算法，C++ 是少数能够满足这种苛刻要求的语言。
3. 多年来，NASA 积累了 可移植、高可靠的 C++ 工具链与编码规范，例如 MISRA-C++ 风格标准。
   如果你想了解更多，比如：

• 这些模块中使用了哪些 C++ 编程技巧（如虚函数、模板、内联等）；
• 火星探测器如何调试和测试这些 C++ 模块；
• 或者，如何在没有标准库、操作系统 API 限制下编写 C++ 自主系统代码；

回答了一个关键问题：“Why C++?（为什么使用 C++？）” 并以 NASA/JPL（喷气推进实验室）的实际经验作为依据，以下是详细理解与背景分析：

背景理解：Urbie 与 1990 年代的 JPL 研究

• Urbie 是 JPL 在 1990 年代开发的一种地面机器人平台，用于探索自动导航、自主任务执行等高级行为。
• 在这个过程中，JPL 开始在机器人自主行为开发中广泛采用 C++。

幻灯片重点解析

"Throughout the 1990’s, JPL researchers used C++ to develop high level autonomous behaviors like:

• stereo vision,

• map building,

• path planning,

• visual odometry."

这些任务的特点：

功能模块	说明
Stereo Vision	利用双摄像头构建三维环境感知（立体视觉）
Map Building	实时构建栅格地图或特征地图，供路径规划和导航使用
Path Planning	自动计算从当前位置到目标点的安全路径
Visual Odometry	通过图像跟踪估算自身运动，适应火星等无 GPS 环境
这些系统在逻辑上复杂、涉及多模块协作，而 C++ 的结构性特性正好满足此类需求。

为什么是 C++？（对技术点的分析）

“C++ class abstraction and encapsulation enabled rapid development and testing among multiple projects and developers.”

C++ 的优势在这里具体体现为：

特性	贡献
类抽象（abstraction）	将视觉、控制、运动逻辑抽象成独立模块，提升代码复用
封装（encapsulation）	降低模块之间的耦合性，便于多人协作开发
继承与多态	支持算法或行为的扩展，如不同导航策略的切换
可移植性强	可部署到多个机器人平台和嵌入式环境中
性能可控	满足实时性和资源限制下的运行要求

现实验证：Field-Tested, Field-Proven

“Many capabilities were field-tested and field-proven over years of testing.”

• NASA/JPL 不是实验性地使用 C++，而是在大量实地测试后，验证其：
  • 稳定性（对错误敏感任务稳定运行）
  • 可维护性（多年项目之间共享核心代码）
  • 性能表现（能在低功耗设备上实现高阶功能）
    这也为后续在 MER、MSL 甚至 Perseverance 等任务中继续使用 C++ 奠定了信心与技术基础。

总结一句话：

C++ 在 NASA 的机器人开发中不仅是“可行的”，而是“长期验证、不可替代的”。

它结合了高性能、模块化设计能力与工程成熟性，是在资源受限、高复杂度、自主系统中不可或缺的选择。

这部分内容是对 NASA 火星车使用的 C++ 软件的功能概览，特别聚焦于自主导航和视觉相关模块。以下是具体内容的逐条理解与展开：

“What Does our C++ Code Do?”

Here is an overview of the Mars Rover C++ software.

Most of it is based around the automatic interpretation of stereo pairs of images taken by the rover as it moves across the surface of Mars.

核心功能：自动处理火星地表图像，实现自主驾驶

火星车上的 C++ 代码的主要作用是：

• 自动解释（自动处理）立体图像对（stereo pairs）
• 每次火星车移动时，都会拍摄图像 → 自动进行三维重建 → 判断地形 → 规划路径
  这是实现“Autonav”（自动导航）系统的核心。

图像与传感器模块（Cameras）

• 火星车配备双目立体摄像头（stereo cameras），如：
  • NavCam（导航摄像头）
  • HazCam（避障摄像头）
  • MastCam（主相机）

工作流程：

1. 同时从左右摄像头拍图 → 形成图像对
2. 使用立体视觉算法（Stereo Matching）计算视差
3. 由此重建局部三维地形
4. 交由“路径规划”与“避障”系统决策行动

自主驾驶（Autonomous Driving）

• 不依赖实时地球控制（由于通信延迟）
• C++ 软件负责：
  • 路径规划（Waypoint Navigation）
  • 地形安全评估（Terrain Assessment）
  • 预测滑移与危险区域（Slip & Keepout Zones）
  • 避障判断（Obstacle Avoidance）
    NASA 的 Autonav 系统使火星车能够在无人操控的情况下，自行判断是否该前进或绕行。

视觉里程计（Visual Odometry）

• 火星车无法使用 GPS，只能依靠图像来估计自身移动距离
• 原理：
  • 比较相邻时间点拍摄的图像 → 找出特征点 → 计算它们的位移
  • 估算实际移动距离与方向
  • 同时结合 IMU 等数据融合，减少累积误差
    C++ 代码实现了高性能的视觉匹配与估算模块。

引用文献说明（如果深入阅读）

• 《Leave the Driving to Autonav》（2013 年）
  • 面向大众科普了 Curiosity 如何实现自动导航
• Maimone et al. (2007), Journal of Field Robotics
  • 介绍了 两年实际使用视觉里程计的经验与算法演进
• IEEE Aerospace 2006, “Driving Ambition”
  • 阐述 MER 的地面控制与飞行软件架构，包括路径规划决策逻辑

总结：C++ 在火星车中的作用一目了然

模块	功能	技术实现
立体视觉	重建3D地形	双目图像匹配、视差图、点云生成
路径规划	自主导航	A*、局部避障、代价地图
视觉里程计	估算移动	特征匹配、估计姿态变化
系统框架	稳定运行	模块化、事件驱动、多线程调度
火星车上的 C++ 软件是一个“分布式视觉导航系统”，运行在资源受限但要求极高可靠性的环境中，是 C++ 工程应用的极致案例。

展示了火星探测车“好奇号”（Curiosity）配备的 17 台相机及其分布，来自 NASA/JPL-Caltech。以下是理解：

1. 相机总数和分布

• 总数：好奇号共有 17 台相机，分布在车身不同位置。
• 具体相机：
  • Right and Left Navcams (2)：导航相机，位于桅杆顶部，用于立体导航。
  • Right Mastcam (100mm) / Left Mastcam (34mm)：桅杆相机，分别配备 100mm 和 34mm 镜头，用于高分辨率成像。
  • ChemCam RMI：化学相机远程显微镜成像仪，位于桅杆，用于化学分析和微观成像。
  • MAHLI：火星手持显微镜成像仪，安装在机械臂末端，用于近距离表面观察。
  • Right and Left Rear Hazcams (2 pair)：后部危险避免相机，成对分布，用于检测后方障碍。
  • Right and Left Front Hazcams (2 pair)：前部危险避免相机，成对分布，用于检测前方障碍。
  • MARDI：火星下降相机，安装在车底，用于拍摄下降和地表细节。

2. 功能和用途

• Navcams：提供导航数据，支持自动导航软件。
• Mastcams：捕捉地形和科学目标的高清图像。
• ChemCam RMI 和 MAHLI：用于化学分析和微观研究。
• Hazcams：检测周围障碍，辅助安全移动。
• MARDI：记录下降过程和地表特征。

3. 与自动导航软件的集成

• 说明：Hazcams 和 Navcams 与自动导航软件（auto-nav software）紧密关联。
• 意义：这些相机提供实时环境数据，支撑路径规划、障碍检测和自主驾驶功能。

4. 总体理解

• 好奇号的 17 台相机设计覆盖了导航、科学观测和安全避障的多重需求。
• 相机分布在桅杆、机械臂和车轮周围，确保全方位感知火星环境。
• 自动导航软件依赖 Navcams 和 Hazcams 的输入，体现其自主性，减少对地球指令的依赖。

解释的是**火星车上的避障摄像头（Hazard Avoidance Cameras，简称 HazCams）**的工作特性，以下是逐句的分析与理解：

🔹**“The hazard avoidance cameras give a 120° wide angle view of the area near the rover.”**

• HazCams 提供了 120 度的广角视野，用来观察火星车前后方的地面。
• 它们用于：
  • 探测靠近车体的障碍物（如石头、坑洼）
  • 在执行动作（如移动、机械臂作业）时判断是否安全
• 由于火星车无法实时遥控，所以必须由这些摄像头支持自主避障系统（Autonav）。

🔹**“Front cameras have 16 cm baseline, rear cameras have 10 cm baseline.”**

• “baseline” 指的是双目摄像头之间的距离，也叫基线长度。
• 前置 HazCam 的两个摄像头之间的间距是 16 厘米，后置的是 10 厘米。
  为什么基线长度重要？
• 双目立体视觉利用视差计算深度（即距离），而基线越长，深度精度越高。
• 前方可能面临更多复杂地形，因此使用更长的基线提高深度估计精度。

HazCam 总结

特性	前置 HazCam	后置 HazCam
视角	120 度广角	120 度广角
双目基线	16 cm	10 cm
功能	避障、机械臂保护等	倒车时避障等
数据用途	提供立体图像 → 三维建模 → 自主导航系统	同前

描述的是**火星车上的导航摄像头（Navigation Cameras，简称 NavCams）**的物理安装位置和视野能力。以下是逐句的详细理解：

原文逐句解析

🔹**“The 45° navigation cameras are almost 7 feet off the ground…”**

• 这说明导航摄像头安装在距离地面约 7 英尺（约 2.1 米）的位置，大致位于火星车桅杆（mast）顶端，接近人类站立时的视角高度。
• 安装角度为 45°（向下倾斜），可以获得前方与近距离地形的整体视图。
  作用：
• 提供较高视角，有利于判断整体路线、安全性。
• 高处布置可避免车身结构遮挡视野。

🔹**“…with 42 cm baseline…”**

• NavCam 也是一对立体摄像头，两个摄像头之间的基线长度为 42 厘米。
• 相比 HazCam 的 16cm 和 10cm，NavCam 的基线更长，这有助于更准确地进行远距离深度估计。

🔹**“…providing good views over nearby obstacles or hills and into ditches.”**

• 高视角 + 长基线 = 更好的远景深度感知能力。
• 能够“看过障碍物”或者“看进沟壑中”：
  • 比如前方有一块大石头，HazCam 看不见后面，而 NavCam 能从上方俯瞰
  • 同样可探测地形起伏，如沟、壑、陡坡

NavCam vs HazCam 对比总结：

特性	HazCam（避障摄像头）	NavCam（导航摄像头）
安装位置	车体前后底部（低）	桅杆顶部（高）
安装角度	朝前/后，水平或稍向下	约 45° 向下俯视
基线长度	前：16cm，后：10cm	42cm
主要用途	近距离避障、安全操作	中远距离导航与路线规划
视野覆盖	地面近处	俯瞰全局，可看进沟壑
优势	精细近景判断	全局场景判断与深度估计精度
如果你想进一步了解这些摄像头如何与视觉里程计（Visual Odometry）或自主导航系统（Autonav）协同使用，也可以告诉我，我可以继续帮你梳理整个视觉导航处理链。

这段内容描述的是人类地面操作员如何根据火星地形和资源情况，灵活选择火星车的自主程度（Autonomy Level）。它展示了从完全人工控制到高度自主导航的不同操作模式。我们逐句进行理解：

原文解析与理解：

🔹 “Human Rover Drivers Decide How Much Autonomy is Desired Based on Terrain and Available Resources”

• 地面操作员（Human Rover Drivers）：
  • 是指 NASA 的科学家和工程师，负责每天制定火星车的行驶和科学操作计划。
• “How Much Autonomy”：
  • 指火星车在执行任务时自主决策的程度。
  • 自主级别越高，越少依赖地球控制，火星车能自己应对复杂环境。
• “Based on Terrain and Available Resources”：
  • 地形复杂度：例如岩石多、坡度大或地面松软，需更精细控制；
  • 可用资源：如通信窗口、电量、计算资源等也会影响选择。

三种驾驶模式（Autonomy Levels）：

1. Directed Driving（指令驾驶）

• 操作员预先指令火星车：“你按我设定的路径移动”。
• 没有自主决策，只是沿着规划轨迹行驶。
• 优点：路径精确、容易预测。
• 缺点：对地形适应能力差，地形误差可能导致卡住。
  应用场景：在平坦地形上快速推进，且通信资源有限时。

2. Visual Odometry / Slip Check + “Auto”

• 火星车使用**视觉里程计（Visual Odometry）**来跟踪自身位置：
  • 比较前后图像差异，推断实际移动距离和方向。
• Slip Check：检测轮胎是否打滑（常见于沙地）。
• 带 “Auto”：火星车在一定范围内可自主选择路径修正。
  应用场景：轻度复杂地形，有一定不确定性时使用。

3. Auto-navigation（自主导航）

• 火星车完全基于摄像头输入自主判断：
  • 执行路径规划（如避开石头、绕过坑洼）；
  • 使用几何危险检测与避障算法（Geometric Hazard Detection and Avoidance）。
• 相当于“给我一个目标点，我自己找路过去”。
  应用场景：高度不规则地形、科学目标靠近障碍物，或任务时间紧张、地球控制延迟大时。

总结：人+AI 的协作驾驶策略

自主等级	技术支持	控制程度	适用场景
Directed Driving	人工路径、无感知	完全人工	平坦、安全地形
Visual Odometry + Auto	视觉定位 + 局部路径修正	部分自主	轻度不确定地形
Auto-navigation	全自主路径规划与避障	高度自主	陌生/危险/复杂地形

火星车使用**视觉里程计（Visual Odometry, VO）**技术来实时估计自己的位置，且它的运作方式与地面机器人有所不同。下面是详细理解：

关键点解析

1. Visual Odometry (VO) 的基本原理

• “the rover constantly compares pairs of images of nearby terrain to calculate its position.”
  火星车通过不断捕捉前后相邻时刻的地面图像，比较这些图像中的特征点或地形细节，计算自身的移动距离和方向，从而确定当前位置。
• 这是一种基于视觉传感器的自主定位方法，不依赖 GPS，而是根据地面特征的变化来推断位置变化。

2. Curiosity（好奇号火星车）在使用 VO 的特殊策略

• “Unlike terrestrial robots, Curiosity drives as far as possible between VO images.”
  和地球上的机器人相比，好奇号的做法是在两次视觉里程计图像采集之间尽可能地行驶更远距离。
• 地面机器人通常频繁拍摄和处理 VO 图像，实时估计位置并快速反应调整路径。
• 而火星车因通信延迟、计算资源限制及能耗等因素，倾向于减少图像采集频率，节省计算和通信资源，因此在两次 VO 之间行驶更长距离。

3. 背后的原因和意义

• 通信延迟：火星和地球之间信号往返时间长（4-22分钟），不能实时控制。
• 能耗和计算资源有限：拍摄和处理高分辨率图像很消耗资源。
• 环境复杂度：火星地形多样，误差累积需要定期校正。
  因此，火星车采用间隔更长、稳定性更强的视觉里程计采集策略，在确保定位准确度的同时，提高了移动效率。

总结：

• 火星车用视觉里程计来实时更新位置，基于地形图像对比。
• 它不像地面机器人那样频繁采集数据，而是在两次图像采集间尽量多行驶，提升效率。
• 这种策略适应了火星车的特殊环境与资源限制。

这段话描述了火星车在绕开障碍物时的自主驾驶流程，理解如下：

关键点解析

1. 火星车绕障碍物的动作节奏

• “the rover stops every 0.5-1.5 meters”
  火星车在行驶过程中，会每行驶大约半米到1.5米就停下来一次。
• 这意味着火星车在前进时非常谨慎，频繁暂停进行环境感知，避免碰撞危险。

2. 采集多组图像用于评估环境

• “takes 4 sets of images”
  在每次停车时，火星车会拍摄4组不同角度或不同传感器的图像。
• 这些图像用于详细观察周围地形，发现潜在的地形障碍物（如大石块、陡坡、坑洞等）。

3. 基于图像评估危险

• 火星车通过图像处理和分析，识别地形中的危险区域和安全路径。
• 这种基于视觉的环境感知是自动导航的核心。

4. 选择前进方向

• 在综合分析这些图像信息后，火星车自主决定下一步的行进方向。
• 这一步是自动导航（Auto-nav）系统的体现，它延伸了人工指令（Directed drives），可以让火星车在“之前未见过的地形”上安全行驶。

5. 总结

• 火星车在绕开障碍物时，采取**“走一小段，停下来观察”**的策略。
• 每次停车拍摄多组图像，分析风险后选择行进路线。
• 自动导航系统使得火星车可以独立应对未知环境，增加了行驶的灵活性和安全性。

这段描述了好奇号火星车基于地形评估做出的路径决策，理解如下：

关键点解析

1. 地图和轨迹反映决策过程

• “Curiosity’s map and tracks show this decision to turn was based on her evaluation of the terrain.”
  好奇号的地图和实际行驶轨迹清晰地展示了它为什么转弯——是基于对地形的评估作出的选择。

2. 避免较危险的区域

• “Curiosity avoids the darker orange in favor of yellow”
  地图上不同颜色代表地形危险程度，**深橙色（darker orange）**代表较高风险或障碍物较多的区域，黄色代表较安全或平坦的地形。
• 火星车自动选择避开“深橙色”区域，而倾向于行驶在“黄色”区域。

3. 导致转弯的结果

• 由于避开了危险区域，好奇号选择了转弯路线。
• 这种选择反映了火星车自主导航系统通过环境感知做出的安全路径规划。

总结

• 好奇号通过地图颜色编码识别地形安全性，避免高风险区域。
• 地形评估直接影响行驶路径，展现了其智能自主决策能力。
• 轨迹和地图可视化清楚显示了决策依据，帮助地面团队理解火星车行为。

火星车如何利用立体视觉生成地形安全地图，并根据安全级别做出驾驶决策，理解如下：

关键点解析

1. 立体点云简化为空间配置图

• “The rover reduces a stereo point cloud into a configuration space”
  火星车通过立体摄像头捕获的点云数据，经过处理转化为一个“配置空间”（configuration space），即地形的二维或三维表示，便于分析和规划。

2. 安全区域颜色编码

• 红色（red）表示不安全区域
  代表存在障碍、陡坡等危险地形，火星车避免进入。
• 绿色（green）表示安全区域
  地形平坦且适合行驶。
• 黄色（yellow）表示需要谨慎驾驶的区域
  类似地球上的交通标识，提醒火星车减速或小心驾驶。
• 白色区域是工程师指定的“安全行驶区域”
  火星车必须保持在这一区域内，确保行驶安全。

3. 工程师对火星车的约束

• 工程师提前设置好限制区域（白色），指引火星车的安全路径。
• 火星车基于实时感知和环境分析，结合这些约束做出驾驶决策。

总结

• 火星车利用立体视觉数据生成环境地图，标记不同安全等级区域。
• 颜色编码直观反映地形风险，辅助自主驾驶。
• 设定的“白色区域”作为必守范围，保证任务安全。
  这段内容讲的是2006年对火星探测车（MER）飞行软件（FSW）R9.2版本的更新，主要包括几个新技术模块，且它们都使用了C++编写。具体理解如下：

关键内容解读

1. 更新背景

• 2006年，MER飞行软件推出了R9.2版本，加入了多项当时的新技术，提升了探测车的自主能力。

2. 新技术亮点

• Field D*
  这是一种长距离路径规划算法，能计算出最优路径。后来也成为MSL（好奇号）标准配置中的功能。
• IDD Autoplace (Go and Touch)
  这项技术使探测车能自主驾驶到目标位置后，自动将机械臂放置到目标上，实现更高效的任务执行。
• Visual Target Tracking
  用于快速跟踪附近地形特征的视觉系统，帮助车辆更好地感知和响应环境变化。该版本已被MSL正在测试的新版本所替代。

3. 技术特点

• 这些新技术均用C++实现，体现了C++在复杂嵌入式和自主系统开发中的优势。

4. 推荐学习资料

• 推荐阅读《Overview of the Mars Exploration Rovers’ Autonomous Mobility and Vision Capabilities》论文（ICRA 2007），详细介绍了这些自主移动和视觉功能。

总结

• MER R9.2版本融合了先进的路径规划、自动机械臂定位和视觉跟踪技术，极大增强了火星车的自主操作能力。
• C++语言的使用为这些复杂功能的开发和维护提供了强有力的支持。
  如果你想，我可以帮你详细介绍这些技术模块的原理和实现细节！

“Field D*” 是一种路径规划算法，专门用于机器人在复杂环境中寻找最优路径，尤其适合像火星探测车这样需要在未知或动态地形上行驶的系统。以下是对 Field D* 最优全局路径规划的理解：

Field D* 最优全局路径规划理解

1. 算法背景

• Field D* 是基于经典的 D*（Dynamic A*）算法发展而来，目的是解决动态环境下路径重新规划的问题。
• 它不仅计算网格路径，还能提供连续空间的最优路径，避免路径过于“格子化”。

2. 关键特点

• 动态更新：能够应对环境中的障碍物变化，实时更新路径。
• 连续空间优化：不像传统A仅在网格节点移动，Field D 能计算“曲线”路径，结果更自然、平滑，适合实际移动。
• 代价场（Cost Field）：通过对地形和障碍的代价赋值，Field D* 计算路径总代价最低的路线，兼顾安全和效率。

3. 应用于火星车的优势

• 适应动态环境：火星地形复杂且可能随时有未知障碍，Field D* 能灵活调整路径。
• 节能高效：规划的路径更短、更平滑，减少机械臂和轮子的磨损与能源消耗。
• 全局最优：不仅局部避障，还能规划到目标的最优全局路径，提升任务完成速度。

4. 实现细节（简要）

• 在栅格地图上，每个格子有对应的移动代价（障碍高代价，平坦地形低代价）。
• 算法从目标点开始反向计算到起点的代价场。
• 当环境变化时，算法快速更新代价和路径，无需重新计算整个路径。
• 输出连续的移动指令，驱动火星车平稳行驶。

总结

Field D* 是一种强大的路径规划算法，结合了动态调整与连续空间优化，非常适合火星探测车这样的机器人，实现安全、高效的自主导航。
理解！

IDD Auto-Place（机械臂自动定位）与火星车排除区（Exclusion Zones）

IDD（Instrument Deployment Device） 是火星车上的机械臂，用于将科学仪器准确放置在目标位置。

关键点：

• 高分辨率地形模型
  火星车在车载计算机中实时处理附近地形，生成详细的三维地形模型。
  这使得机械臂能够评估目标位置的安全性和可操作性。
• 排除区（Exclusion Zones）
  根据地形模型和安全规则，系统标记出机械臂不可接触或放置的位置，这些区域被排除，避免机械臂碰撞或放置失败。
• 潜在放置目标
  系统会在地形中识别多个可行的放置目标点，经过安全评估后供机械臂选择和执行。

应用意义：

• 自动化
  机械臂可以自主选择和定位目标，减少人为干预，提高效率。
• 安全性
  通过高分辨率地形和排除区的结合，避免机械臂损坏或失败。
• 精度
  确保仪器准确放置于科学调查需要的位置。

MER Visual Target Tracking (Sol B-992)

• 背景：
  Visual Target Tracking 是火星车上的一种视觉跟踪技术，能通过连续图像定位和跟踪特定目标。
• 过程示意：
  从“Seed Image”（种子图像）开始，通过拍摄多张图像（比如7张）并旋转接近90度视角，逐步锁定和追踪目标。
• 作用：
  • 辅助机械臂定位目标
  • 支持自主导航和科学操作
  • 保证任务精度和目标稳定性

火星车航天软件初期对 C++ 的顾虑

• 异常处理（Exceptions）
  • 认为异常带来太多不可预测性
  • 验证所有控制路径非常困难，影响系统可靠性
• 模板（Templates）
  • 容易导致代码膨胀（code bloat），增加存储和执行负担
• 输入输出流（Iostream）
  • 由于遥远的控制台，传统控制台输出没有意义，无法实时调试
• 多重继承（Multiple inheritance）
  • 开发团队对其在航天环境中的表现经验不足，担心复杂度和稳定性
• 操作符重载（Operator overloading）
  • 可能令代码对其他开发者难以理解和维护
• 动态内存分配（Dynamic allocation）
  • 担忧系统堆内存耗尽
  • 以及动态内存回收时的不确定执行时间，影响实时性能
    这些顾虑反映了早期航天软件对稳定性和可预测性的高要求，但后来通过工程实践和工具改进，许多问题得到了缓解，C++被逐渐采纳并广泛使用。

火星车软件中使用的 Embedded C++ 限制

为了解决传统 C++ 在航天环境中的顾虑，JPL 团队采用了 Embedded C++，即限制只使用 C++ 的一部分特性，以保证软件的稳定性和可预测性：

• 异常处理（Exceptions）
  • 完全不使用，避免异常带来的不可控性
• 模板（Templates）
  • 不使用，防止代码膨胀和复杂度增加
• 输入输出流（Iostream）
  • 不使用，避免无意义的控制台输出和不必要的代码体积
• 多重继承（Multiple inheritance）
  • 不使用，简化类层次结构，易于维护
• 操作符重载（Operator overloading）
  • 几乎不使用，只保留了 “new” 和 “delete” 以支持动态内存管理
• 动态内存分配（Dynamic Allocation）
  • 使用专门的内存池（dedicated memory pool）
  • 通过 Placement New 保证不破坏系统堆，避免系统内存崩溃
    这种方法让团队在保持 C++ 抽象能力的同时，极大降低了潜在的风险和复杂度，确保航天系统的稳定运行。
    完全理解！

Placement New 在火星车 Embedded C++ 中的作用和实现

背景

• 火星车的操作系统使用的是共享内存，所有任务共享同一个系统堆（system heap）。
• 直接使用标准的 new 和 delete 可能会破坏系统堆，导致飞行软件不稳定，甚至崩溃。
  解决方案
• 重载 new 和 delete 操作符，让它们调用自定义的内存分配器，避免调用操作系统默认的堆管理函数。
• 通过 Placement New 语法，直接在预先分配的独立内存池（memory pools）中分配内存，而不是用系统堆。
  Placement New 语法示例：

void* buffer = my_memory_pool.allocate(size);
MyObject* obj = new (buffer) MyObject(args...);

• 这段代码不会从系统堆分配内存，而是“放置”对象到特定的内存地址。
• 同时，重载的 delete 操作符负责正确调用析构函数，但不会释放系统堆内存。
  总结
• 使用 Placement New 避免系统堆污染和内存碎片化
• 保证飞行软件对内存管理的完全控制，提高可靠性和实时性
• 这是火星车使用 C++ 在严格嵌入式环境下的关键实践之一

火星车内存分配器实现原理和特点总结

自定义内存管理器设计目标

• 保证对定义内存池的安全访问
• 处理内存不足的情况时有良好行为（比如返回错误，而非崩溃）
• 支持多个内存池，覆盖不同 RAM 区域，方便管理和隔离
• 提供诊断功能，支持在运行时显示每次 new 和 delete 操作，便于调试
• 维护内存空闲空间地图，用于内存使用的文档和分析
• 同一套分配器代码支持 VxWorks 和 Unix 开发环境，保证测试一致性
  内存管理的关键点
• 没有垃圾回收机制，要求所有内存泄漏在单元测试阶段被消除，保证飞行软件的稳定性
• 内存管理既要满足嵌入式系统实时性要求，又要确保高可靠性，防止内存损坏
  总结
  这个内存分配器就是一个轻量、确定性的内存池管理器，专门为航天嵌入式软件定制，保证内存操作可控、安全、可调试。

火星车软件测试流程及原则

1. 单元测试（Unit Tests）

• 开发者为每次代码更改编写单元测试
• 确保新代码不破坏已有功能（防止回归）
• 支持代码覆盖率分析（Code Coverage），提升测试完整度
• 使用内存检查工具（如 Valgrind、Purify）检测内存泄漏和错误
  2. 静态分析（Static Analysis）
• 利用多种本地和商业工具对代码进行静态检查
• 提前发现潜在缺陷和安全隐患
  3. 验证与确认（Validation & Verification, V&V）
• 由独立测试团队接收已交付代码
• 在多种测试平台和环境中进行全面测试
• 模拟真实飞行环境，确保软件表现符合预期
  4. 测试原则——“Test As You Fly”
• 尽可能让测试环境和条件贴近实际飞行环境
• 保证测试结果具有实际代表性和可靠性

这是关于MSL（Curiosity火星车）工程模型（Engineering Model，EM）和相关软件应用的内容总结：

MSL Engineering Model (工程模型)

• NASA/JPL-Caltech使用的火星车工程模型（EM），在地面进行测试和验证。
• 通过VSTB（Vehicle System Testbed）进行驾驶演示和测试，确保软件与硬件的协同工作。

VSTB Driving

• 展示了VSTB上火星车的驾驶过程。
• VSTB提供了一个接近实际飞行硬件的环境，能够模拟真实的驾驶场景和状态。

Curiosity的测程数据（Odometry）

• Per Sol Odometry：火星车每天（sol）移动的测程数据。
• Cumulative Odometry：累积的总测程数据，用于跟踪火星车在任务期间的总行驶距离。

C++的地球和火星应用

• 许多在地球上用于规划火星车路径的软件都是用C++编写的，显示了C++在航天任务和地面支持的广泛应用。
• 火星车任务中，C++不仅用于核心飞行软件，也用于地面数据处理和自动化工具。
• 例如，C++用于自动图形注释（annotation）下传数据，这些注释信息还能自动发送到团队成员的手机，提升数据共享和响应效率。
  总结来看，C++贯穿了火星车任务的软硬件生态，从飞行控制、地面模拟，到任务数据处理和团队协作，体现了其强大和适应性。

C++在其他航天器项目中的应用实例，具体如下：

C++在其他航天器上的应用

• Earth Observing 1 (EO-1)
  自2005年起，作为“自主科学航天器实验”（Autonomous Sciencecraft Experiment）的平台，使用C++实现自主科学任务的软件，支持自主数据采集和处理。
• ISS-RapidScat
  用于国际空间站上的海洋风速测量任务，C++参与实现了快速、精确的数据采集和处理系统。
• Aquarius
  用于测量海表盐度的卫星，C++支持其复杂的传感器数据处理与控制软件。
• GRACE Follow-On
  跟踪地球水体运动的卫星任务，C++用于实现高精度的测距和数据处理功能。
• Cubesats（立方卫星）
  小型低成本卫星项目，广泛采用C++开发飞控和载荷软件，保证可靠性和性能。

重点

• C++因其性能优越和面向对象特性，被广泛用于各类空间任务的飞行软件开发。
• 不论是大型卫星还是小型Cubesats，C++都是实现复杂功能和保证系统稳定的重要选择。
  火星车“好奇号”（Curiosity）在第122个火星日（Sol 122）及之后几天使用视觉里程计（Visual Odometry, VO）和惯性测量单元（IMU）姿态估计的对比和校正过程：
• 传统做法是，如果视觉里程计的姿态变化超过IMU的测量，会拒绝VO的更新，因为一般更信任IMU，尤其是短距离变化。
• 但是在Sol 122到124期间，好奇号用VO导航时，几次VO更新被拒绝了。
• 后来发现VO其实是对的，IMU的陀螺仪姿态估计器因为参数设置问题，在高加速度时会错误地拒绝姿态变化。
• 这个参数修正后，问题解决了。
• 截至Sol 650，VO尝试了3855次更新，失败仅13次，且只有2次因缺乏地面纹理无法收敛，成功率高达99.66%。
  总结来说，这说明视觉里程计在火星车定位和导航中非常可靠，甚至在某些情况下比IMU表现更好，体现了视觉导航算法的重要性和精准性。