视觉SLAM学习【4】----- ubuntu16.04上KDevelop的安装、配置、项目创建以及外部嵌入式项目导入如果你正在学视觉SLAM大概率已经受够了这种日子辛辛苦苦把框架跑起来代码却只能躺在Vim或者gedit里翻来翻去想看个函数定义得开三个终端来回切编译报错只能靠肉眼在满屏日志里找线索。我记得自己刚接触某经典开源SLAM框架的时候光是梳理多线程之间的数据流就花了一整天中途还因为忘记某个头文件路径在命令行里折腾了半个多小时。从那时候起我就确定必须给这套开发流程找一个像样的集成开发环境而不是继续当远古程序员。KDevelop就是我当时选定的工具。在Ubuntu 16.04上把它装好、配好、用起来前后花了一个下午。这个工具对CMake工程的支持几乎是天生的——槽点少、索引快、调试集成顺手。而对视觉SLAM这种重度依赖CMake组织、动辄几十个源文件、还带一堆第三方依赖的项目来说KDevelop的外部工程导入能力简直戳中命门。这篇教程会把安装、配置、项目创建、外部嵌入式项目导入这四段流程完整拆开按我实测的顺序和踩坑的先后顺序写出来适合正在跑SLAM代码但还在用文本编辑器硬扛的朋友也适合想从命令行转型IDE但不知道从哪里下手的初学者。1. 为什么是KDevelop视觉SLAM开发环境的选型思考1.1 视觉SLAM开发环境的痛点视觉SLAM项目的工程结构通常是主干简洁、分支复杂。主干就是传感器数据进来、前端估计、后端优化、回环检测、建图这么一条流水线但分支可能包含大量工具类、第三方库的封装层、可视化模块、数据集读取模块。而这些模块之间靠什么粘合靠CMake。几乎每个SLAM框架都和CMake绑定得天衣无缝一个顶层CMakeLists.txt下面挂着一堆子目录的CMakeLists.txt再用find_package把OpenCV、Eigen3、Sophus、g2o这些外部依赖拉进来。这种结构在命令行下编译没问题但编程体验很差。你想查某个类在哪里定义只能一层层翻目录你想看某个函数被谁调用没点趁手工具还真做不到。调试的时候更难受终端里跑GDB打几个断点就要敲一长串命令效率低得让人怀疑人生。所以痛点很明确不是编译不过这关是阅读代码和调试代码的效率上不去。IDE的价值不在于帮你把代码写完而在于把阅读、跳转、编译、调试这个过程串成一条流水线。视觉SLAM学习阶段大量的时间花在读代码——读别人怎么调Eigen、怎么构建图优化、怎么管理关键帧。这些内容靠看静态文本真的能看吐但一个趁手的IDE可以把代码变成一张可以随时跳转的网络效率完全是两个量级。1.2 KDevelop的设计哲学与SLAM项目的契合点KDevelop出身于KDE社区名字里的Develop已经暗示了它不是一个花哨的编辑器而是一个面向正经开发任务的工具。它对C和CMake的支持是骨子里的因为我个人感觉它几乎就是为CMake工程量身定做的IDE原生识别CMakeLists.txt打开一个工程文件夹就能解析出所有target、源文件、头文件路径和宏定义内置语义代码分析引擎能在编辑时检查语法和类型错误而这个引擎对Eigen这种模板大户的支持很不错不会动不动就飘红调试器集成GDB可视化断点、变量监视、调用栈都比命令行舒服得多支持外部工程的非侵入式导入不会往你的源码目录里塞额外配置文件——这对SLAM项目尤其友好因为很多开源SLAM框架对工程目录要求很干净。相比较而言顺手但笨重的方案也有有人推荐用VSCode配CMake插件这条路我也走过补全和调试都还行但第一次配置tasks.json和launch.json就能劝退一批人。也有人用Qt CreatorSLAM可视化部分用的库很多都基于 Qt配合起来确实顺但工程一旦复杂索引慢的问题就会被放大。KDevelop在这堆方案里是最中庸也最稳的那个学习SLAM阶段拿来已经不缺什么了。1.3 与Eclipse、Qt Creator等IDE的对比拿几种常见IDE拉出来对比能更直观地看出KDevelop适不适合SLAM场景对比维度KDevelopEclipse CDTQt CreatorCMake原生支持极佳直接解析一般需插件辅助较好但偏向Qt工程外部工程导入无损导入不改原目录结构有时需重新生成工程文件支持但偶有缓存问题代码索引速度快索引规模可控中规中矩工程大了会变慢调试集成GDB集成流畅配置稍重流畅学习成本低界面朴素直白中界面偏老中对Eigen模板库的支持理想一般一般光看参数会觉得差异没有天翻地覆但实际用起来KDevelop在处理别人写好的CMake工程时给人的感觉是它完全理解了工程结构而不是简单地把一堆文件名塞进列表里。这一点从导入外部工程的操作里就能体会到后面我会详细拆步骤。2. Ubuntu 16.04环境准备与KDevelop安装2.1 换源与系统依赖库准备Ubuntu 16.04已经是个老系统了如果这是一台新装好的机器或者刚换的虚拟机第一步不是直接敲安装命令而是先把软件源换到国内镜像。这一步能省下后面大量的等待时间因为KDevelop会拖进来很多依赖源的速度直接决定成败。换源的方法不展开细讲但可以给一句提醒Ubuntu 16.04的/etc/apt/sources.list里那一串archive.ubuntu.com全部替换成镜像站地址即可。建议用清华源或阿里源。替换完以后执行sudo apt update sudo apt upgrade -y更新完成之后建议先把基础编译工具链装好因为后面不管是KDevelop还是SLAM编译都绕不开这一套sudo apt install -y build-essential cmake git gdbCMake版本要注意一下。Ubuntu 16.04仓库自带的CMake版本比较旧某些新的SLAM框架会要求更高版本。建议先运行cmake --version看一眼如果低于3.10建议后面考虑用pip安装新版CMake或者加入Kitware的APT源这一步在第6章会单独提。2.2 安装KDevelop的三种方式对比在Ubuntu 16.04上装KDevelop主流有三条路按推荐程度排序方式一APT直接安装最推荐sudo apt install kdevelop这是最省心的做法。Ubuntu 16.04软件源里自带的KDevelop版本虽然不算最新但胜在稳定而且是和系统GCC、GDB这些组件一起测试过的各种动态库的版本匹配不会出问题。方式二Flatpak安装sudo flatpak install flathub org.kde.kdevelop好处是能拿到新版本但Ubuntu 16.04上要先把Flatpak整套环境装好而且Flatpak的应用跑起来相对沙箱化访问系统目录和库有时候会有限制。配置编译器时可能找不到系统GCC新手很容易卡在这里所以不推荐做主力方式。方式三自己编译安装源码编译需要拉一堆KDE的开发依赖包耗时长而且Ubuntu 16.04上编译新版KDevelop还可能会遇到Qt版本不匹配的问题。除非你明确知道为什么要编译否则完全没必要。我当时的做法就是APT一把梭装完直接能用后面配置也只是在软件界面里点几下没有遇到过动态库缺失的问题。2.3 安装后的版本检查与首启配置安装完成后在终端里执行kdevelop --version能看到类似KDevelop 4.7.0的输出16.04仓库的实际版本可能略有差异。首次启动KDevelop它会弹出一个首次运行配置向导主要完成以下事情选择一个配置目录默认~/.kde或~/.config/kdevelop保持默认即可询问是否使用KDE外观设置选是询问是否需要Clang Code Model插件强烈建议开启这个插件承担了大部分语义分析和代码补全工作是KDevelop在C方面好用的核心原因。首启配置完成后会进入一个空界面。先别急着创建项目接下来要做的配置会让后面所有操作都少走弯路。3. 首次启动后的必备配置3.1 配置编译器套件与构建工具KDevelop解析CMake工程时需要知道使用哪套编译器和构建工具。这一步配置不做好后面打开任何工程都会报找不到编译器之类的红字错误。打开菜单设置 - 配置KDevelop - 构建 - 构建器你会看到几个可选项CMake、Make、Ninja。CMake项下有自动、CMake 2.8等选择CMake并确认路径指向/usr/bin/cmake即可。再点开编译器选项卡KDevelop会尝试扫描系统GCC正常情况下能看到GCC和G都自动识别出来。识别不到时可以手动添加名称填GCC路径填/usr/bin/gccC语言和/usr/bin/gC语言。这个路径用which gcc就能确认。注意如果系统里装了多个GCC版本比如软链接指向了GCC 5但你实际需要GCC 7来编译SLAM项目需要在这里手动指定具体版本路径并把软链接调整好。KDevelop在构建时会调用这里配置的编译器配置错了会引发各种莫名其妙的编译错误。3.2 添加Qt5环境变量与包含路径这一条很多人容易漏掉但它直接影响KDevelop能否正确解析代码。SLAM项目里经常用到Qt比如GUI工具、Pangolin依赖的某些部分如果KDevelop不知道Qt5的头文件在哪代码语义分析就会报一堆找不到QtWidgets/QApplication这样的错误虽然编译器能通过但你在IDE里看着满屏飘红会非常闹心。打开设置 - 配置KDevelop - C或环境- 添加搜索路径。不同版本菜单位置稍有差异核心操作是往编译器的默认包含路径里增加几个目录/usr/include/x86_64-linux-gnu/qt5 /usr/include/x86_64-linux-gnu/qt5/QtWidgets /usr/include/x86_64-linux-gnu/qt5/QtCore /usr/include/x86_64-linux-gnu/qt5/QtGui同理如果后面SLAM项目用到了自定义的Eigen路径也可以在这里加上。这一步说白了就是告诉KDevelop的代码分析引擎这些头文件都是合法的别标红。3.3 开启语言服务协议与代码补全KDevelop较新版本支持Language Server ProtocolLSP可以接入Clangd做更智能的补全和诊断。在Ubuntu 16.04自带的老版本上这个功能默认可能没开或者叫Clang Code Model插件。检查方式设置 - 配置KDevelop - 插件展开C支持确认Clang Code Model处于启用状态。如果版本较老至少确保KDevelop自带的C插件C11/C14支持是打开的。代码补全面板在编辑器 - 代码补全里建议勾选自动调用补全方便写代码时直接弹出候选列表。触发阈值默认就可以不用调。这样设置完编辑代码时按下CtrlSpace就能手动触发补全。实测对Eigen的矩阵运算补全效果不错Eigen::Matrix4d后面能自动提示.inverse()、.transpose()这些成员函数。3.4 调试器准备与GDB配置视觉SLAM学习离不开调试配置好GDB能省下大量排查内存错误的时间。KDevelop菜单里设置 - 配置KDevelop - 调试器确认调试器路径指向/usr/bin/gdb。如果系统没装先执行sudo apt install gdbKDevelop还支持用调试器打开核心转储文件SLAM程序崩溃时生成的core文件可以直接丢进去看调用栈。我个人比较喜欢先把ulimit -c unlimited设置好跑程序崩了之后用KDevelop分析core文件比反复打日志定位错误快捷多了。调试相关的另一个实用设置在运行选项卡里。配置运行项时可以指定工作目录为数据集所在路径这样调试时不用每次都在终端里cd来cd去。4. 从零创建一个CMake项目以HelloSLAM为例4.1 新建项目的向导操作步骤做视觉SLAM的人长期接触的往往是别人建好的工程但从零建一个CMake项目也是基本功KDevelop也提供了现成模板。打开KDevelop后点击 项目 - 从模板新建左侧选择Standard分类右侧选C弹出的模板列表里找到CMake相关的模板通常名为CMake Project填项目名称比如HelloSLAM选择工作目录建议放在~/Projects下给每个SLAM学习项目建独立文件夹。向导底部有几个选项需要仔细看生成器建议选Unix Makefiles。Ninja也可以但Ubuntu 16.04默认没装Ninja选它还得额外安装发布类型选Debug。学习阶段基本都在调试Release会优化掉很多变量信息断点看变量内容时会看到optimized out构建目录KDevelop默认采用out-of-source构建也就是在源码目录旁边生成一个build文件夹不要改成源码内构建否则容易弄脏工程目录。点击确定后KDevelop会执行一次CMake配置然后弹出一个项目管理视图左侧是文件树右侧是带行号的编辑器。到这里一个空壳工程已经建好了。4.2 手动补全CMakeLists.txt和main.cpp向导生成的CMakeLists.txt通常非常简陋类似cmake_minimum_required(VERSION 2.8.12) project(HelloSLAM) add_executable(HelloSLAM main.cpp)这个模板只够用来编译一个没有依赖的单文件程序。视觉SLAM学习时第一步建议改成下面的内容让它能正常加载OpenCV和Eigen这两个最常用的依赖cmake_minimum_required(VERSION 3.10) project(HelloSLAM) set(CMAKE_BUILD_TYPE Debug) find_package(OpenCV REQUIRED) find_package(Eigen3 REQUIRED) include_directories(${OpenCV_INCLUDE_DIRS}) include_directories(${EIGEN3_INCLUDE_DIR}) add_executable(HelloSLAM main.cpp) target_link_libraries(HelloSLAM ${OpenCV_LIBS})然后右键工程根目录选择重新加载或CMake - 重新配置KDevelop会重新解析CMakeLists.txt并刷新文件树。现在main.cpp里可以写一小段验证代码#include iostream #include opencv2/opencv.hpp #include Eigen/Core int main(int argc, char** argv) { cv::Mat image(480, 640, CV_8UC3, cv::Scalar(0, 255, 0)); std::cout Hello SLAM, image size: image.size() std::endl; Eigen::Matrix3d R Eigen::Matrix3d::Identity(); std::cout Rotation matrix:\n R std::endl; return 0; }这个实验验证了最基本的依赖路径配置是否生效。如果这段代码能编译运行说明KDevelop的工程配置已经打通后面接入真SLAM项目也只是把依赖换成g2o、Sophus这些而已。4.3 构建与运行写完代码后直接按快捷键F8触发生成或者点击菜单栏构建图标。KDevelop的构建输出会显示在底部的构建工具面板里效果比终端友好得多会列出警告和错误的具体文件和行号点击错误项还能直接跳转到对应代码。运行配置也很简单右键工程名 - 运行 - 添加运行配置选择当前工程程序路径一般会默认指向构建生成的二进制文件。设置好后按F4就能编译并运行底部的应用程序面板会显示运行日志。常见的小细节如果修改了CMakeLists.txt里target的名字对应的运行配置路径可能失效需要在配置里手动点一次重新加载按钮刷新。4.4 清理与目录结构说明KDevelop为每个工程会生成一个.kdev4文件夹里面存放的是IDE自身的工作区信息比如打开的文件列表、断点位置、界面的窗口布局。这个文件夹通常放在工程根目录旁边或根目录内仅属于本机开发配置不影响源码工程本身的便利性也不会被写入到CMake自动生成的构建产物中。对于SLAM项目这种经常要同步到远端服务器的场景可以把.kdev4目录加到.gitignore里避免把本地工作区状态推到仓库里。构建目录build同样建议忽略。这个习惯能让工程在别人手里和在自己手里以同样的方式打开。5. 导入外部嵌入式SLAM项目5.1 什么情况需要导入而不是新建做视觉SLAM的人经常遇到一个流程从GitHub上把某经典框架clone下来build目录里跑一遍cmake拿到可执行程序然后想开始改代码。这时候问题来了——直接在终端里改呢还是另起一个IDE项目重新组织代码正确答案是导入不是新建。新建项目意味着要把别人的CMakeLists.txt重写一遍或者让IDE用一套新的构建系统去接管原工程。而SLAM项目的CMakeLists.txt往往经过作者精心调教里面包含你会发现手动重建根本不划算的诸多细节——比如针对第三方库版本的条件判断、特定的编译选项、甚至是跨平台分支。用导入方式打开KDevelop会完全尊重原工程的构建描述你只负责在这个骨架之上阅读和修改代码。具体场景举几个用某开源ORB特征提取与匹配框架跑数据集需要在原有工程上加一段可视化代码在某个数据集的评估工具上修改统计指标基于某图优化库的官方样例二次开发。这几个场景都不应该新建工程。正确方式是让KDevelop直接识别已有的CMake工程。5.2 导入ORB-SLAM类项目的正确姿势假设你已经把某个SLAM项目clone到了~/Projects/ORB_SLAM2里面自带CMakeLists.txt和完整的源码结构。导入操作如下打开KDevelop点击 项目 - 打开/导入在弹出的文件选择器里直接选中包含CMakeLists.txt的文件夹例如~/Projects/ORB_SLAM2注意不要手动去选里面的单个.cpp文件KDevelop会自己识别CMakeLists.txt如果KDevelop询问是否创建一个新项目选择导入已有项目/作为现有工程打开选择构建目录建议指定为build并勾选使用现有构建目录如果该目录已存在CMake缓存点确定KDevelop开始跑一次CMake解析。解析完成后左侧文件树会呈现整个工程的目录结构源文件、头文件、第三方库全部在里面展开。此时你会开始体会到KDevelop对CMake工程的理解力它能自动识别哪个源文件属于哪个可执行target头文件包含路径会自动关联上#include opencv2/opencv.hpp不会因为找不到头文件而标红。重要如果原工程的构建目录build已经用命令行配置过导入时务必选中使用现有构建目录这样KDevelop不会重新执行CMake配置而是直接复用缓存的配置信息。好处有两个一是少跑一次CMake省时间二是避免因为配置参数差异比如原本指定了某些-D选项导致导入后编译行为突然变化。5.3 导入后代码阅读、索引、调试的体验优化导入完成后KDevelop会自动建立一份代码索引。这个索引过程在工程首次打开时会占用一定CPU但通常几分钟内完成。索引完成后以下能力会陆续生效跳转到定义光标放在某个函数名上按CtrlG能跳到函数实现位置在SLAM框架里看后端优化器怎么定义全局变量时非常方便查找引用右键某个变量选择查找引用能列出所有用到这个变量的地方排查数据竞争时很实用全局搜索符号按CtrlAltG输入Optimizer能快速定位所有与优化相关的类或函数悬停提示鼠标放在类型名上会显示类的成员变量和成员函数看多线程循环里调用的mpCurrentKeyFrame到底有哪些字段时不需要翻头文件。调试体验上导入工程和新建工程一致。在左侧文件树双击源文件打开行号旁点击设置断点按F5启动调试即可。SLAM程序经常跑数据集启动时间可能很长建议提前在断点处设置好条件断点避免每次都从头跑。5.4 不重建CMake缓存的好处与机制说明很多新手导入工程时喜欢顺手在KDevelop里重新配置一次CMake。这个操作本身没问题但如果原工程里有很多通过命令行传入的配置项比如-DUSE_GPUON、-DCMAKE_BUILD_TYPERelease而你导入后在KDevelop里重新配置时忘了补上同样的选项构建产物就和原来的行为不一致了。KDevelop的使用现有构建目录机制就是为这个场景准备的。它会读取build目录里已有的CMakeCache.txt识别里面的变量值然后把它导入到IDE的构建配置中。这样你在IDE里修改源码、重新编译得到的结果和你原来命令行编译一脉相承不会出现明明没改代码编译行为却变了这种诡异情况。如果确实需要改CMake配置项KDevelop里可以通过菜单 项目 - 打开配置 - CMake看到所有缓存的变量直接修改后点重新构建。注意这等于手动重配CMake务必清楚自己在改什么。6. 在SLAM学习中遇到的几个真实坑6.1 CMake版本过低导致兼容问题Ubuntu 16.04自带的CMake是3.5.x而很多较新的SLAM工程在cmake_minimum_required(VERSION 3.10)甚至更高。导入时KDevelop调用CMake解析工程如果版本不满足会直接报CMake 3.10 or higher is required然后中止解析。解决方案两种第一种加入Kitware官方APT源关键是执行顺序wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc 2/dev/null | sudo apt-key add - sudo apt-add-repository deb https://apt.kitware.com/ubuntu/ xenial main sudo apt update sudo apt install cmake第二种更省事用pip装sudo pip install cmake --upgrade这种方式装好之后的CMake在/usr/local/bin下会自动覆盖系统路径。装好后在终端里验证cmake --version输出如果是3.16以上KDevelop解析工程就不会再卡在版本检查了。记得装完新CMake之后重启一次KDevelop让它重新加载构建器路径。6.2 Qt5路径不对导致语义分析飘红导入SLAM工程后有时会遇到这类现象编译能通过但KDevelop编辑器里一堆#include QtWidgets/Xxx下面画红波浪线。问题根源就是第3.2节里提到的Qt5头文件路径没配。如果第3.2节没做现在补救也快。打开 设置 - 配置KDevelop - C - 添加搜索路径把Qt5相关的目录全加进来。加完以后KDevelop会自动重新解析一次工程飘红会消掉一部分。还有一种情况SLAM工程自带的include路径本身就不完整。典型例子是代码里写#include opencv2/opencv.hpp而工程CMakeLists只加了include_directories(${OpenCV_INCLUDE_DIRS})按理说没问题但若KDevelop没正确解析出OpenCV_INCLUDE_DIRS的值就会在语义分析阶段报头文件缺失。此时可以右键工程 - CMake - 重新配置让KDevelop重新拉取变量值。6.3 导入后出现无头文件错误但能编译通过这个坑在导入外部SLAM项目时非常常见。建议先去工程构建面板里看CMake的配置日志确认有没有报某个find_package失败。如果真的失败先看终端里用命令行跑同一条CMake命令能否成功如果不能问题在系统依赖层——用sudo apt install把对应库补上再回KDevelop重新配置。如果命令行能但KDevelop不能绝大多数是KDevelop缓存了旧的CMake变量此时把工程构建目录里的CMakeCache.txt删掉再重新配置即可。6.4 KDevelop卡顿与索引优化SLAM项目体量不小尤其包含大量第三方源码时KDevelop首次建立索引会比较吃力。如果发现索引时CPU一直满负荷、界面卡顿可以这样缓解在 设置 - 配置KDevelop - C - 索引 里把文件数限制调低或者把部分无关目录加入忽略列表比如/usr/include这种大目录KDevelop未必需要全量索引把工程里的第三方源码通过CMakeLists.txt里的add_subdirectory排除出工程主视图关闭自动命名空间补全。KDevelop对C工程确实比很多重量级IDE轻但也不是吃素的优化索引能明显改善体验。6.5 导入后找不到目标可执行文件KDevelop导入外部工程后运行配置里的可执行文件路径可能不会自动关联需要手动指定。在左下方运行面板里新建一个Compiled Binary的配置目标选择/path/to/工程/build/可执行文件名。这个路径一定得是实际生成出来的二进制KDevelop不会帮你猜测。有个更省事的办法在CMake配置面板里找到该target右键选择设为启动目标。这样按F4会直接编译并运行选中的目标不用手动填写路径。7. 终端、编辑器与IDE配套使用的实战建议最后分享一个我折腾了很长时间才想明白的观点KDevelop并不是要用它替代所有开发工具而是作为主战场和终端形成配合。在KDevelop里我给每个SLAM工程设置好构建和运行配置日常写代码、跳转、调试都在这里完成但涉及到跑数据集、查看日志、管理git分支时我仍在终端里操作。例如KDevelop底下有个主终端面板切换过去就能直接执行rosbag play或python evaluate.py。这比来回切换窗口舒服得多因为你的工作流始终留在一个界面里不会因为切界面而打断思路。我的实际体会是IDE和命令行从来不是二选一的敌人而是各管一段的工具。KDevelop在代码层面解放了你命令行在数据和系统层面帮助你。视觉SLAM学习阶段先把环境搭到手、把项目导进来后面大量阅读和调试代码时才不会被工具卡住。这套配置流程走完后续学习的关键不再是编译环境而是算法本身。装好工具之后下一步就轮到真正跑起第一个SLAM框架、分析每一帧的位姿输出的时候了——那时候你会感谢当初花这一个下午把开发环境彻底收拾利索的自己。