个人网站做电商,做网站代理拉不到人,网站开发属于软件开发类吗,网站建设网站规划书1. 为什么要在Ubuntu 20.04上源码编译hpp-fcl#xff1f; 如果你正在Ubuntu 20.04上捣鼓机器人、运动规划或者碰撞检测相关的项目#xff0c;那你大概率听说过或者用过hpp-fcl这个库。简单来说#xff0c;hpp-fcl是一个功能强大的碰撞检测和距离计算库#xff0c;它是大名…1. 为什么要在Ubuntu 20.04上源码编译hpp-fcl如果你正在Ubuntu 20.04上捣鼓机器人、运动规划或者碰撞检测相关的项目那你大概率听说过或者用过hpp-fcl这个库。简单来说hpp-fcl是一个功能强大的碰撞检测和距离计算库它是大名鼎鼎的FCLFlexible Collision Library的一个分支在机器人领域尤其是像MoveIt这样的规划框架里扮演着核心角色。官方其实提供了非常方便的安装方式就像原始文章里提到的一行sudo apt-get install ros-noetic-hpp-fcl就能搞定。那为什么我们还要“自讨苦吃”折腾源码编译呢这其实是我在好几个实际项目里踩过坑之后得出的经验。首先版本控制是最直接的原因。截至我写这篇文章的时候ROS Noetic官方仓库里的hpp-fcl版本已经更新到了2.4.4这很棒。但软件世界日新月异也许你正在阅读时GitHub上的主分支已经迭代到了2.4.5甚至2.5.0加入了一些你急需的bug修复或者性能优化。通过apt安装你被锁定在了仓库维护者打包的那个版本。而源码编译让你能直接追踪最新的开发进度第一时间用上新特性。其次是定制化需求。也许你需要开启某个特定的CMake编译选项来优化性能或者需要链接到你自己修改过的某个依赖库比如特定版本的Eigen。源码编译给了你完全的掌控权你可以像搭积木一样按需配置整个库的构建过程。最后对于想要深入理解或进行二次开发的朋友来说源码编译几乎是必经之路。你能看到整个项目的结构方便你后续添加自己的模块、调试代码或者为开源社区贡献补丁。所以这篇指南就是为你——这位不满足于“开箱即用”希望获得最新、最定制化hpp-fcl库的开发者——准备的。我会手把手带你走一遍在Ubuntu 20.04上从清理环境、安装依赖到编译安装hpp-fcl 2.4.4的全过程。整个过程我实测过很多遍只要跟着步骤走大概率能一次成功。即便遇到问题我也会把常见的“坑”和解决办法分享出来让你少走弯路。2. 战前准备彻底清理与依赖安装源码编译像盖房子地基不稳后面全是麻烦。在Ubuntu上编译C项目最常见的地基问题就是系统里残留的旧版本库文件和新版本冲突。hpp-fcl对线性代数库Eigen的版本有要求所以我们第一步就是确保有一个“干净”且版本合适的Eigen环境。2.1 彻底告别旧版Eigen很多朋友的系统里可能通过apt安装过libeigen3-dev。这个包提供的Eigen版本通常是3.3.7对于hpp-fcl 2.4.4来说可能不够新。更棘手的是系统里可能分散着多个Eigen的安装痕迹比如/usr/include/eigen3/usr/local/include/eigen3。编译时编译器如果找到了错误的头文件路径就会导致各种诡异的编译错误。我的经验是在开始之前进行一次彻底的清理。首先我们检查一下系统里是否存在Eigenpkg-config --modversion eigen3如果这条命令输出了一个版本号比如3.3.7说明系统里存在通过pkg-config可识别的Eigen。我们需要把它和相关文件找出来并移除。注意直接sudo apt remove libeigen3-dev可能无法清除所有文件特别是那些安装在/usr/local下的可能是你之前源码安装的。所以我们需要“手动侦查”和清理。下面是我总结的一套组合拳定位所有Eigen文件sudo apt-get install mlocate # 如果还没安装locate命令 sudo updatedb # 更新文件数据库 locate eigen3 | head -20 # 查看一部分eigen3相关的文件路径这个命令会列出大量包含“eigen3”的路径重点关注/usr/include,/usr/local/include,/usr/share等目录下的。执行清理请仔细核对路径谨慎操作# 移除apt安装的包如果存在 sudo apt remove --purge libeigen3-dev -y # 移除常见的安装目录根据上一步locate的结果调整 sudo rm -rf /usr/include/eigen3 sudo rm -rf /usr/lib/cmake/eigen3 sudo rm -rf /usr/local/include/eigen3 sudo rm -rf /usr/local/share/eigen3 sudo rm -rf /usr/local/share/pkgconfig/eigen3.pc sudo rm -rf /usr/share/doc/libeigen3-dev验证清理是否成功 再次运行pkg-config --modversion eigen3。如果命令没有任何输出或者提示找不到包并且locate eigen3命令返回的结果大大减少或只留下一些无关紧要的缓存条目那说明清理工作基本完成了。提示清理系统文件是一项需要谨慎的操作。如果你不确定某个目录是否该删除可以先将其重命名例如sudo mv /usr/local/include/eigen3 /usr/local/include/eigen3.backup等确认新安装的Eigen工作正常后再删除备份。这是我常用的“安全编译”小技巧。2.2 安装新版Eigen 3.4.0hpp-fcl 2.4.4推荐使用Eigen 3.4.0或更高版本。我们将采用源码编译安装的方式这样能获得最纯净、最可控的依赖环境。我习惯在用户主目录下创建一个专门的工作空间来管理这些手动编译的库这样结构清晰也避免污染系统目录。创建工作空间并下载Eigen# 在主目录下创建一个工作空间文件夹 mkdir -p ~/hpp_fcl_ws cd ~/hpp_fcl_ws访问Eigen官网https://gitlab.com/libeigen/eigen/-/releases找到3.4.0版本。你可以直接在网页下载.zip或.tar.gz包然后用图形界面解压到~/hpp_fcl_ws。但我更推荐用wget命令在终端里一气呵成wget https://gitlab.com/libeigen/eigen/-/archive/3.4.0/eigen-3.4.0.tar.gz tar -xzvf eigen-3.4.0.tar.gz编译与安装Eigen Eigen是一个纯头文件库只有.h头文件没有需要编译的.cpp源文件所以它的“编译”过程主要是运行CMake来生成一些配置文件如eigen3.pc供pkg-config使用和安装脚本。cd ~/hpp_fcl_ws/eigen-3.4.0 mkdir build cd build cmake .. -DCMAKE_INSTALL_PREFIX/usr/local这里我明确指定了安装前缀/usr/local这是Linux下安装本地软件的标准位置。接下来执行安装sudo make install这个过程很快因为它只是把头文件复制到/usr/local/include/eigen3并生成必要的CMake配置文件和pkg-config文件。验证Eigen安装 安装完成后我们再次验证pkg-config --modversion eigen3这次你应该能看到输出3.4.0。你还可以检查头文件路径echo #include Eigen/Core | gcc -x c -E -H - 21 | grep eigen3如果输出中包含/usr/local/include/eigen3说明编译器已经能正确找到我们新安装的Eigen了。至此一个干净、版本正确的Eigen地基已经打好。3. 获取与编译hpp-fcl源码依赖搞定主角就可以登场了。我们将从GitHub上克隆hpp-fcl的仓库。这里有个小细节原始文章里直接克隆了主分支。为了确保我们获取的是2.4.4这个特定版本避免主分支后续更新引入意外变化我建议克隆后切换到对应的标签tag。3.1 克隆源码并切换版本打开终端进入我们的工作空间cd ~/hpp_fcl_ws使用git克隆仓库git clone https://github.com/humanoid-path-planner/hpp-fcl.git克隆完成后进入仓库目录并查看可用的版本标签cd hpp-fcl git tag -l | grep v2.4.4你应该能看到类似v2.4.4的标签。然后切换到这个标签git checkout v2.4.4注意如果你看到的是2.4.4而不是v2.4.4就用你看到的那个标签名。这一步确保了你的源码树状态和官方发布的2.4.4版本完全一致对于可复现的构建非常重要。3.2 配置与编译接下来是标准的CMake构建流程。hpp-fcl的构建选项相对清晰对于大多数用户默认配置就足够了。但了解一些关键选项有助于排查问题。创建构建目录并配置mkdir build cd build运行CMake进行配置。这里我添加了-DCMAKE_BUILD_TYPERelease目的是生成优化过的发布版本运行速度更快。如果你在调试阶段可以换成Debug。cmake .. -DCMAKE_BUILD_TYPEReleaseCMake会运行一段时间它会检查你的系统环境找到我们刚刚安装的Eigen以及其他的依赖如Boost、octomap等。如果一切顺利你会在最后看到配置成功的总结信息。解决可能出现的CMake错误 如果CMake报错最常见的原因是找不到依赖。错误信息通常会明确指出是哪个包没找到比如Could NOT find Boost或Could NOT find octomap。缺少Boost安装开发包即可。sudo apt-get install libboost-all-dev缺少octomaphpp-fcl需要octomap库来处理网格数据。安装命令sudo apt-get install liboctomap-devEigen版本过低如果出现Eigen版本相关的错误请回头确认你是否彻底清理了旧版并且我们安装的3.4.0版本是否被正确找到。可以尝试在CMake命令中显式指定Eigen3的路径虽然通常不需要-DEigen3_DIR/usr/local/share/eigen3/cmake开始编译 配置成功后使用make命令开始编译。为了加快速度可以使用-j参数指定并行编译的作业数通常设置为你的CPU核心数。你可以用nproc命令查看核心数。make -j$(nproc)编译过程会持续几分钟屏幕上会滚动输出编译信息。这是最需要耐心的一步。如果遇到编译错误比如某个文件报语法错误首先检查是否严格遵循了前面的步骤特别是Eigen的版本和清理工作。绝大多数编译错误都源于依赖库的版本冲突或路径混乱。4. 安装、验证与集成测试编译成功只是第一步让系统和其他项目能方便地使用这个库还需要安装和验证。4.1 安装到系统目录编译完成后运行安装命令这会将编译好的库文件.so文件、头文件.h文件以及CMake配置文件复制到系统目录默认是/usr/local。sudo make install这个操作需要管理员权限。安装完成后hpp-fcl的头文件会被放在/usr/local/include/hpp/fcl/下库文件在/usr/local/lib/下CMake配置文件在/usr/local/lib/cmake/hpp-fcl/下。这样其他CMake项目就可以通过find_package(hpp-fcl REQUIRED)来轻松找到并使用它了。4.2 验证安装是否成功如何确认我们的劳动成果确实可用呢我来分享几个简单的验证方法。检查安装文件ls /usr/local/include/hpp/fcl/ # 应该能看到很多头文件 ls /usr/local/lib/libhpp-fcl* # 应该能看到libhpp-fcl.so等库文件编写一个简单的测试程序 这是最可靠的验证方式。在你喜欢的位置比如~/test_hpp_fcl创建一个测试文件test_collision.cpp#include hpp/fcl/collision.h #include hpp/fcl/shape/geometric_shapes.h #include hpp/fcl/narrowphase/narrowphase.h #include iostream #include memory int main() { // 创建两个球体 auto sphere1 std::make_sharedhpp::fcl::Sphere(1.0); // 半径1.0 auto sphere2 std::make_sharedhpp::fcl::Sphere(0.5); // 半径0.5 // 创建碰撞对象并设置位姿这里两个球在原点重合 hpp::fcl::CollisionObject obj1(sphere1); hpp::fcl::CollisionObject obj2(sphere2); // 创建碰撞请求和结果结构 hpp::fcl::CollisionRequest request; hpp::fcl::CollisionResult result; // 执行碰撞检测 hpp::fcl::collide(obj1, obj2, request, result); // 输出结果 if(result.isCollision()) { std::cout 碰撞检测成功两个球体发生了碰撞。 std::endl; std::cout 接触点数量: result.numContacts() std::endl; } else { std::cout 未检测到碰撞。 std::endl; } return 0; }然后编译这个测试程序。你需要告诉编译器头文件在哪、库文件在哪、要链接哪个库cd ~/test_hpp_fcl g -stdc11 test_collision.cpp -o test_collision \ -I/usr/local/include \ -L/usr/local/lib \ -lhpp-fcl如果编译成功运行它之前需要让系统知道动态库的位置export LD_LIBRARY_PATH/usr/local/lib:$LD_LIBRARY_PATH ./test_collision如果程序输出“碰撞检测成功两个球体发生了碰撞。”那么恭喜你hpp-fcl已经完美安装并可以正常工作了这个简单的测试创建了两个半径不同的球体由于它们的位姿都在原点所以必然会碰撞从而验证了库的基本功能。4.3 与ROS项目集成很多朋友编译hpp-fcl是为了在ROSRobot Operating System项目中使用。如果你用的是ROS Noetic并且已经通过apt安装了ros-noetic-hpp-fcl那么系统里现在就有两个hpp-fcl一个在/opt/ros/noetic下一个在我们刚安装的/usr/local下。这可能会引起冲突。如何让ROS项目使用我们编译的新版本关键在于CMake。在你的ROS包的CMakeLists.txt中在调用find_package(catkin REQUIRED COMPONENTS ...)之前可以通过设置CMake变量来优先从/usr/local中查找。或者更直接的方法是确保你的CMAKE_PREFIX_PATH环境变量包含了/usr/local并且顺序在ROS路径之前。你也可以在ROS工作空间的顶层CMakeLists.txt或终端中临时设置source /opt/ros/noetic/setup.bash # 先source ROS export CMAKE_PREFIX_PATH/usr/local:$CMAKE_PREFIX_PATH # 将我们安装的路径优先级提高然后重新编译你的ROS工作空间catkin_make或colcon build。这样CMake在查找依赖时会优先找到我们手动编译的、版本更新的hpp-fcl。5. 常见问题排查与性能调优即使按照步骤操作也可能会遇到一些意外情况。这里我汇总了几个我亲自遇到过的问题和解决办法希望能帮你快速排雷。5.1 编译或链接错误排查“undefined reference to ...” 链接错误这通常意味着编译器找到了头文件所以编译通过但链接器没找到对应的库实现。请确保安装步骤sudo make install确实执行成功了。你测试程序编译时-L参数指定的路径/usr/local/lib是正确的并且该路径下确实存在libhpp-fcl.so文件。运行程序前正确设置了LD_LIBRARY_PATH环境变量或者已将/usr/local/lib添加到系统的库配置中例如创建文件/etc/ld.so.conf.d/local.conf并写入/usr/local/lib然后运行sudo ldconfig。CMake找不到hpp-fcl如果你在其他项目中使用find_package(hpp-fcl)失败可以手动指定其路径cmake .. -Dhpp-fcl_DIR/usr/local/lib/cmake/hpp-fcl与ROS自带版本冲突症状可能是编译时出现函数签名不匹配等奇怪错误。最彻底的解决办法是卸载ROS通过apt安装的版本sudo apt remove ros-noetic-hpp-fcl。但请注意这可能会影响到其他依赖该版本ROS包的软件。更安全的方法是使用我上面提到的CMAKE_PREFIX_PATH方法来控制查找优先级。5.2 启用高级特性与性能考量默认编译的hpp-fcl已经功能齐全。但如果你对性能有极致要求或者需要某些实验性功能可以在CMake配置阶段开启一些选项。重新进入你的hpp-fcl/build目录如果存在先删除CMakeCache.txt尝试如下配置命令cmake .. -DCMAKE_BUILD_TYPERelease \ -DHPP_FCL_HAS_QHULLON \ -DHPP_FCL_USE_ASSIMP_UNIFIED_HEADER_NAMESOFF-DHPP_FCL_HAS_QHULLON如果你安装了Qhull库sudo apt-get install libqhull-dev开启此选项可以让hpp-fcl在计算凸包分解时使用Qhull可能在某些情况下提升性能或稳定性。-DHPP_FCL_USE_ASSIMP_UNIFIED_HEADER_NAMESOFF这是一个针对Assimp模型导入库头文件命名的兼容性选项。如果你在编译时遇到Assimp相关的头文件错误尝试关闭这个选项。配置完成后重新执行make和sudo make install。记住每次修改CMake选项后最好清空build目录重新开始或者至少删除CMakeCache.txt文件以确保配置被重新读取。5.3 保持更新与回滚源码安装的另一个好处是更新方便。当hpp-fcl发布新版本比如2.4.5时你可以进入之前克隆的源码目录cd ~/hpp_fcl_ws/hpp-fcl git fetch origin --tags # 获取最新的标签信息 git checkout v2.4.5 # 切换到新版本标签 cd build # 清空旧的构建文件建议 rm -rf * 或者直接删除build文件夹重建 rm -rf * cmake .. -DCMAKE_BUILD_TYPERelease make -j$(nproc) sudo make install这样就完成了升级。如果新版本有问题你可以随时用git checkout v2.4.4切换回稳定的2.4.4版本并重新编译安装这就是版本控制的魅力所在。整个流程走下来虽然比一句sudo apt install要繁琐不少但获得的控制权和灵活性是巨大的。尤其是在进行机器人算法研发时能够随时切换到库的最新修复分支或者为了调试而打开所有编译警告这些能力都能极大提升开发效率。我自己的项目就从源码编译中受益良多一次解决了因旧版库碰撞检测精度不够导致规划失败的问题。希望这份详细的指南能帮你顺利搭建起属于你自己的、最新的hpp-fcl开发环境。如果在实践中遇到本指南未覆盖的特殊情况不妨去hpp-fcl的GitHub仓库的Issues页面看看通常你遇到的问题别人也可能遇到过那里是寻找答案的好地方。