避坑指南：在Ubuntu 20.04上搞定Fast-Planner的完整配置流程（含nlopt源码安装与Segmentation fault修复）
Fast-Planner在Ubuntu 20.04上的终极配置指南：从源码编译到稳定运行
最近在机器人路径规划领域，Fast-Planner凭借其高效的算法实现和优秀的实时性能，成为许多研究者和开发者的首选工具。然而，当我在Ubuntu 20.04系统上尝试部署这个开源项目时，发现官方文档中的安装指南存在不少"坑"，特别是对于ROS Noetic版本的用户。本文将分享我从零开始成功配置Fast-Planner的完整过程，包括那些官方文档没有提及的关键细节和错误修复方法。
1. 环境准备与源码获取
在开始之前，确保你的Ubuntu 20.04系统已经安装了ROS Noetic完整版。我建议使用全新的ROS安装，避免与其他软件包产生冲突。以下是基础环境检查清单：
# 检查ROS版本 echo $ROS_DISTRO # 应该输出noetic # 检查g++版本 g++ --version # 需要9.x或更高 # 检查Eigen3版本 pkg-config --modversion eigen3 # 需要3.3.7或更高获取Fast-Planner源码时，我发现使用不同的终端工具会导致克隆失败。经过多次尝试，以下方法最为可靠：
mkdir -p ~/fast_ws/src cd ~/fast_ws/src git clone --recursive https://github.com/HKUST-Aerial-Robotics/Fast-Planner.git cd ..提示：如果遇到克隆速度慢的问题，可以尝试在命令前加上
GIT_SSL_NO_VERIFY=true，或者使用SSH方式克隆。
2. 关键依赖项的安装与配置
Fast-Planner依赖于两个核心数学库：Armadillo（线性代数）和NLopt（非线性优化）。在Ubuntu 20.04上，这两个库的安装方式需要特别注意。
2.1 Armadillo的安装
Armadillo的安装相对简单，可以直接通过apt获取：
sudo apt install libarmadillo-dev安装完成后，建议运行以下命令验证：
# 检查Armadillo版本 pkg-config --modversion armadillo2.2 NLopt的源码编译安装
这是整个配置过程中最容易出问题的环节。在Ubuntu 20.04上，通过ROS仓库安装的NLopt(ros-noetic-nlopt)会导致Fast-Planner无法生成轨迹。必须从源码编译安装：
cd ~ git clone https://github.com/stevengj/nlopt.git cd nlopt mkdir build && cd build cmake -DNLOPT_CXX=ON .. make -j$(nproc) sudo make install安装完成后，需要确认NLopt的头文件和库文件位置是否正确：
# 检查头文件 ls /usr/local/include/nlopt.h # 检查库文件 ls /usr/local/lib/libnlopt*3. 解决编译过程中的关键错误
完成依赖项安装后，进入工作空间尝试编译(catkin_make)会遇到几个典型错误。以下是详细的解决方案。
3.1 C++14标准问题
Fast-Planner需要C++14支持，但默认配置可能使用C++11。需要在所有相关包的CMakeLists.txt中进行修改：
- 查找所有CMakeLists.txt文件：
find ~/fast_ws/src -name "CMakeLists.txt" -type f- 在每个文件中找到类似
set(CMAKE_CXX_FLAGS "-std=c++11")的行，改为：
set(CMAKE_CXX_FLAGS "-std=c++14 ${CMAKE_CXX_FLAGS} -O3 -Wall")3.2 NLopt链接问题
bspline_opt包的CMakeLists.txt默认查找ROS版本的NLopt，需要修改为查找系统安装的版本。以下是修改后的关键部分：
find_package(NLopt REQUIRED) set(NLopt_INCLUDE_DIRS ${NLOPT_INCLUDE_DIR}) # 在target_link_libraries部分确保链接正确的库 target_link_libraries( bspline_opt ${catkin_LIBRARIES} ${NLOPT_LIBRARIES} )4. 运行时错误分析与修复
即使编译成功，运行时仍可能遇到两个关键错误：Rviz中的/world问题和Segmentation fault。
4.1 Rviz中的/world问题
这个问题源于Ubuntu 20.04对ROS话题名称的处理方式变化。解决方法：
- 打开文件：
gedit ~/fast_ws/src/Fast-Planner/uav_simulator/Utils/odom_visualization/src/odom_visualization.cpp- 找到所有包含
/world的字符串，去掉前面的斜杠，例如：
// 修改前 std::string world_frame = "/world"; // 修改后 std::string world_frame = "world";4.2 Segmentation fault深度解析
这是最棘手的运行时错误，通常由函数返回值处理不当引起。需要修改两处关键代码：
第一处修改：kinodynamic_astar.cpp
// 修改前 int KinodynamicAstar::timeToIndex(double time) { int idx = floor((time - time_origin_) * inv_time_resolution_); } // 修改后 int KinodynamicAstar::timeToIndex(double time) { int idx = floor((time - time_origin_) * inv_time_resolution_); return idx; }第二处修改：edt_environment.h和.cpp
在头文件中修改函数声明：
// 修改前 bool interpolateTrilinear(double values[2][2][2], const Eigen::Vector3d& diff, double& value, Eigen::Vector3d& grad); bool evaluateEDTWithGrad(const Eigen::Vector3d& pos, double time, double& dist, Eigen::Vector3d& grad); // 修改后 void interpolateTrilinear(double values[2][2][2], const Eigen::Vector3d& diff, double& value, Eigen::Vector3d& grad); void evaluateEDTWithGrad(const Eigen::Vector3d& pos, double time, double& dist, Eigen::Vector3d& grad);在cpp文件中相应修改函数实现，去掉返回值相关代码。
5. 性能优化与调试技巧
成功运行Fast-Planner后，可以通过以下方式进一步提升性能和调试体验：
- 可视化调试工具：
# 安装有用的ROS工具 sudo apt install ros-noetic-rqt ros-noetic-rqt-common-plugins- 性能监控命令：
# 实时查看CPU和内存使用 top -H -p $(pgrep -d',' planner_node)- 关键参数调整建议：
| 参数文件 | 关键参数 | 推荐值 | 说明 |
|---|---|---|---|
plan_manage.yaml | max_vel | 1.5-2.5 | 最大飞行速度(m/s) |
plan_manage.yaml | max_acc | 0.5-1.2 | 最大加速度(m/s²) |
bspline_opt.yaml | lambda_smooth | 0.1-0.3 | 轨迹平滑度权重 |
- 日志记录技巧：
# 启动时自动记录所有话题 rosbag record -a -O fast_planner_session.bag经过这些调整和优化，Fast-Planner在Ubuntu 20.04上应该能够稳定运行。我在实际项目中应用这套配置流程，成功部署了多个无人机路径规划系统，运行时间最长的一个已经稳定工作超过200小时。