1. 问题背景与现象
在机器人开发过程中，我们经常需要在各种硬件平台上编译ROS2工程。特别是在NVIDIA Jetson Nano这类低算力平台上，编译大型ROS2工程时经常会遇到系统卡死甚至编译进程被强制终止的情况。这通常是由于编译过程中占用了过多的CPU核心，导致系统资源耗尽。
很多开发者会尝试使用colcon build --parallel-workers 1命令来限制编译核数，期望能够缓解这个问题。但实际测试发现，即使设置了该参数，系统仍然会使用大量CPU核心，问题并未得到解决。这让我意识到，我们对colcon build的并行编译机制可能存在理解上的偏差。
提示：在Nano这类仅有4核CPU的开发板上，不当的编译参数设置很容易导致系统无响应，甚至需要强制重启。
2. 问题本质分析
经过深入研究和测试，我发现--parallel-workers参数的实际作用与大多数开发者的理解存在差异。这个参数并不是直接限制CPU核心使用数量的，而是控制同时编译的软件包(package)数量。
在ROS2工程中，一个工作空间(workspace)通常包含多个独立的软件包。colcon build的并行编译机制实际上包含两个层次的并行：
- 包级并行：决定同时编译多少个软件包
- 包内并行：决定每个软件包编译时使用多少线程
真正的CPU核心使用量是这两个参数的乘积。这就是为什么单独设置--parallel-workers无法有效控制CPU使用率的原因。
3. colcon build并行机制详解
3.1 并行计算模型
colcon build的并行编译遵循以下计算公式：
code复制总CPU核心使用量(n) = 并行包数量(k) × 单个包编译线程数(j)
举例说明：
- 如果设置
--parallel-workers=2且MAKEFLAGS="-j2" - 那么实际使用的CPU核心数就是2×2=4
3.2 关键参数解析
colcon build中影响并行编译的主要参数如下：
| 参数名称 | 作用域 | 默认值 | 说明 |
|---|---|---|---|
--parallel-workers |
包级 | 通常为CPU核心数 | 控制同时编译的软件包数量 |
MAKEFLAGS="-jN" |
包内 | 通常自动检测 | 控制每个包编译时的make线程数 |
3.3 参数设置示例
正确的核数限制方法应该是同时设置两个参数：
bash复制MAKEFLAGS="-j2" colcon build --parallel-workers 2
这个组合将确保：
- 最多同时编译2个软件包
- 每个软件包使用2个编译线程
- 总CPU核心使用量不超过4个
4. 低算力平台优化方案
4.1 Nano平台推荐配置
对于Jetson Nano这类4核ARM平台，经过多次测试验证，推荐以下配置：
bash复制MAKEFLAGS="-j1" colcon build --parallel-workers 2
这样设置可以：
- 保持总CPU使用量在2核心以下(2×1=2)
- 留出足够系统资源维持UI响应
- 避免编译进程被OOM killer终止
4.2 内存考虑因素
除了CPU核心数，内存也是重要限制因素。在编译大型包如rviz2时，可以进一步降低并行度：
bash复制MAKEFLAGS="-j1" colcon build --parallel-workers 1 --packages-select rviz2
4.3 温度监控技巧
长期编译时，建议监控CPU温度：
bash复制watch -n 1 cat /sys/class/thermal/thermal_zone*/temp
如果温度超过80°C，应考虑降低并行度或增加散热措施。
5. 高级配置技巧
5.1 持久化MAKEFLAGS设置
为了避免每次都要输入MAKEFLAGS，可以将其加入shell配置：
bash复制echo 'export MAKEFLAGS="-j$(($(nproc)/2))"' >> ~/.bashrc
source ~/.bashrc
这样会自动设置为CPU核心数的一半，比较平衡。
5.2 包级并行控制
对于包含异构包的工作空间，可以针对不同包设置不同并行度：
bash复制colcon build --parallel-workers 2 --packages-up-to package1 package2
colcon build --parallel-workers 1 --packages-select large_package
5.3 资源监控方案
建议在另一个终端窗口运行资源监控：
bash复制watch -n 1 "echo 'CPU: ' $(uptime) && echo 'MEM: ' $(free -h)"
这样可以实时观察系统资源使用情况，及时调整编译参数。
6. 常见问题排查
6.1 编译进程被kill
现象：编译过程中进程突然终止，无错误信息
原因：通常是触发了OOM killer
解决：
- 降低并行度
- 关闭不必要的应用程序
- 增加swap空间
6.2 系统完全无响应
现象：整个系统卡死，需要硬重启
原因：CPU/内存资源耗尽
解决：
- 使用更保守的编译参数
- 考虑使用nice降低优先级：
bash复制nice -n 10 MAKEFLAGS="-j1" colcon build --parallel-workers 1
6.3 编译速度过慢
现象：编译能完成但耗时过长
平衡方案：
bash复制MAKEFLAGS="-j2" colcon build --parallel-workers 2
这样在4核CPU上使用4个"逻辑核心"，但实际由于超线程，物理核心压力较小。
7. 性能优化实践
经过在Jetson Nano上的多次测试，我总结出以下经验数据：
| 配置方案 | 总核心数 | 编译时间 | 系统稳定性 |
|---|---|---|---|
| 默认参数 | 8(4×2) | 最快 | 经常崩溃 |
| -j2 --parallel-workers=2 | 4 | 中等 | 较稳定 |
| -j1 --parallel-workers=2 | 2 | 较慢 | 非常稳定 |
| -j1 --parallel-workers=1 | 1 | 最慢 | 极其稳定 |
实际项目中，我通常采用折中方案：
bash复制MAKEFLAGS="-j1" colcon build --parallel-workers 2
这样既能保持相对合理的编译速度，又能确保系统稳定性。对于特别大型的包，再临时调整为单包编译。