（十一）ORBSLAM2在ROS下运行
ORBSLAM2运行ROS节点障碍
ORBSLAM2集成了一系列与ROS兼容的应用程序，并将这些应用程序独立设置在专门的ROS文件夹中。此外，它还提供了一类不依赖于ROS的应用程序来满足不同的需求。为了简化流程，在本研究中主要专注于其在ROS环境下的功能实现。具体而言，在测试ORBSLAM2时发现该系统运行较为复杂，在处理大量数据时容易出现性能瓶颈问题。因此，在本文中对这一系统的运行机制进行了详细分析并提出了相应的优化建议以提高其运行效率和处理能力
问题1：ROS路径设置的问题
问题2：cv_bridge的opencv版本冲突的问题；
ROS路径设置的问题
因为ORBSLAM2实现了rosbuild_init()函数，在进行编译操作之前必须首先将工作区间的相关配置完成。ORBSLAM2所附带的文档中，并未包含我们熟悉的标准ROS目录结构下的package.xml及devel目录。因此，在开始编译操作时，笔者遇到了诸多困惑与不解。
直接编译会显示ORBSLAM2路径冲突之类的问题，具体错误是：
[rosbuild] rospack has identified the package "ORB_SLAM2" at "", indicating that the current directory is "/home/xiaoC/ORB_SLAM2/Examples/ROS/ORB_SLAM2"
通常情况下，在此路径上配置了ORBSLAM2程序。出现错误提示表明 ROS环境未被正确配置。
因此，笔者首先在~/.bashrc上设置了路径：
sudo vim ~/.bashrc
export ROS_PACKAGE_PATH=${ROS_PACKAGE_PATH}:/home/xiaoC/ORB_SLAM2/Examples/ROS
source ~/.bashrc注意，后面这个path是笔者的路径，不同用户路径不同。
在理论上，在理论上而言而言而言而言而言而言而言
echo $ROS_PACKAGE_PATH当终端显示出了笔者刚刚输入的路径信息时，则表明ROS的路径配置已经完成。然而遗憾的是，并未实现这一目标。
具体可以参考：https://github.com/raulmur/ORB_SLAM2/issues/url
后来
cd /opt/ros/indigo/
sudo vim setup.bash
export ROS_PACKAGE_PATH=${ROS_PACKAGE_PATH}:/home/xiaoC/ORB_SLAM2/Examples/ROS
source setup.bash同样地, 我们可以采用两种方法来验证路径是否成功添加了. 其中一种是我们之前提到的echo方法.
roscd ORB_SLAM2如果能进入这个文件夹，说明我们路径设置成功了。
具体可以参考：https://www.cnblogs.com/xy123001/p/6918334.html
于是，通过这个设置，笔者便把ROS编译这关通过了。
cv_bridge的opencv版本冲突的问题
这个难题一直萦绕在笔者的一个下午里, 让他苦思冥想不得其解. 晚饭后回来后不久就迎刃而解了. 由此可见, 在精神食量不足的时候真正的需求是能够激发灵感.
这个问题主要出现的位置是，在笔者运行RGBD节点的时候：
rosrun ORB_SLAM2 RGBD ../../../Vocabulary/ORBvoc.txt ./Asus.yaml显示的问题主要是OpenCV版本冲突的问题。实际上，在之前的编译过程中多次警告过我们关于这个问题
. . .
[ 33%] [100%] [100%] Building CXX object CMakeFiles/Stereo.dir/src/ros_stereo.cc.o
Building CXX object CMakeFiles/Mono.dir/src/ros_mono.cc.o
Building CXX object CMakeFiles/RGBD.dir/src/ros_rgbd.cc.o
Linking CXX executable ../Mono
/usr/bin/ld: warning: libopencv_core.so.3.0, needed by ../../../../lib/libORB_SLAM2.so, may conflict with libopencv_core.so.2.4
[100%] Built target Mono
Linking CXX executable ../RGBD
Linking CXX executable ../Stereo
/usr/bin/ld: warning: libopencv_core.so.3.0, needed by ../../../../lib/libORB_SLAM2.so, may conflict with libopencv_core.so.2.4
[100%] Built target RGBD
/usr/bin/ld: warning: libopencv_imgproc.so.3.0, needed by ../../../../lib/libORB_SLAM2.so, may conflict with libopencv_imgproc.so.2.4
[100%] Built target Stereo笔者并未过多关注。直接跳过了这段代码。料着编译顺利通过。毕竟对程序员而言, warnings不足为奇, errors才是重头戏。
经过进一步分析发现，在安装ORBSLAM2时所使用的OpenCV版本（即opencv 3.2.0）与ROS Indigo框架自带的OpenCV版本（即cv桥接工具包基于2.4.x构建）之间存在不兼容问题。具体来说，在运行ROS节点的过程中，默认情况下会调用liborbslam2.so库进行功能对接。由于该库依赖于安装了3.2.0版本的OpenCV进行动态链接引入（linking against the 3.2.0 version of OpenCV），而cv_bridge工具包则以安装了2.4.x版本的OpenCV进行链接（linking against the 2.4.x version of OpenCV），因此在系统中形成了配置冲突。这导致系统在启动相关节点时出现配置错误并最终无法正常运行
OpenCV Error: Bad argument (Invalid pointer to file storage) in cvGetFileNodeByName, file /build/buildd/opencv-2.4.8+dfsg1/modules/core/src/persistence.cpp, line 740
terminate called after throwing an instance of 'cv::Exception'
what(): /build/buildd/opencv-2.4.8+dfsg1/modules/core/src/persistence.cpp:740: error: (-5) Invalid pointer to file storage in function cvGetFileNodeByName
Aborted (core dumped)为了更好地看到问题是什么，笔者在RGBD所在节点下看了一下链接情况：
ldd RGBD | grep opencv
libopencv_imgproc.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_imgproc.so.2.4 (0x00007f67d053f000)
libopencv_highgui.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_highgui.so.2.4 (0x00007f67d02f4000)
libopencv_core.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_core.so.2.4 (0x00007f67cfebc000)
libopencv_core.so.3.2 => /usr/local/lib/libopencv_core.so.3.2 (0x00007f67ced2b000)
libopencv_imgproc.so.3.2 => /usr/local/lib/libopencv_imgproc.so.3.2 (0x00007f67cd4f7000)
libopencv_contrib.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_contrib.so.2.4 (0x00007f67cac9b000)
libopencv_calib3d.so.3.2 => /usr/local/lib/libopencv_calib3d.so.3.2 (0x00007f67c4db9000)
libopencv_features2d.so.3.2 => /usr/local/lib/libopencv_features2d.so.3.2 (0x00007f67c4ae7000)
libopencv_highgui.so.3.2 => /usr/local/lib/libopencv_highgui.so.3.2 (0x00007f67c48da000)
libopencv_features2d.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_features2d.so.2.4 (0x00007f67c24fd000)
libopencv_calib3d.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_calib3d.so.2.4 (0x00007f67c2266000)
libopencv_ml.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_ml.so.2.4 (0x00007f67c1fee000)
libopencv_video.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_video.so.2.4 (0x00007f67c1d9a000)
libopencv_objdetect.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_objdetect.so.2.4 (0x00007f67c1b1f000)
libopencv_flann.so.3.2 => /usr/local/lib/libopencv_flann.so.3.2 (0x00007f67ba0c1000)
libopencv_imgcodecs.so.3.2 => /usr/local/lib/libopencv_imgcodecs.so.3.2 (0x00007f67b9e80000)
libopencv_flann.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_flann.so.2.4 (0x00007f67b980b000)不难看出，这是一长串令人头疼的链接库，并有3.2.0版本和2.4.x版本的OpenCV可用。笔者花费了不少时间思考相关问题。
显然此问题在GitHub上相关的问题上仍存在争议[Ref. 1]
也有部分解决方案在这里：https://github.com/raulmur/ORB_SLAM2/issues/103
然而这确实无法解决我的问题。另一方面是希望自动移除OpenCV 2.4，并发现需要卸载多个软件包以及其中就包含了图形界面等复杂内容而让我暂时放弃了这个想法。此外还有重建系统这让我更加不考虑了因为这让我认为捡芝麻丢了西瓜并不划算所以最终决定继续寻找解决方案
有三个比较有参考价值的回答：
1. <>
2. https://github.com/introlab/rtabmap/issues/86
3. https://www.cnblogs.com/cv-pr/p/5366764.html
建议我们卸载原始的cv_bridge，然后重装新版本：
sudo apt-get remove ros-indigo-cv-bridge
git clone https://github.com/ros-perception/vision_opencv.git
catkin_make --pkg cv_bridge注意，上面是在ROS的工作区间中运行的。
于是，ORBSLAM2的ROS节点便可以运行了。
实际运行情况
1. RGBD
首先, 笔者采用了ASUS XTion Gen1 RGBD摄像头进行实验. 基于ROS框架的标准配置实现了该设备的基本运行, 其中最为关键的是深度相机标定的难度较大. 在ORBSLAM2算法中, 笔者对节点进行了针对性的优化, 将原本仅适用于理论推导的默认内参参数进行了实际应用层面的改进.
然后就是跑起来了，效果如下(由于没办法插入视频，笔者就只能放图片了)：
ORBSLAM2在实际应用中展现出色性能；然而，在深入测试过程中，我们考察了纯色墙面、快速移动物体、物体遮挡以及明暗变换四种典型场景。
白墙：面对白墙的情况确实存在较大的挑战。这是因为ORBSLAM2主要依赖于角点信息，在缺乏纹理特征的情况下难以提取足够的关键点。值得注意的是，在快速移动时，在从纹理丰富区域进入纹理稀疏区域时容易导致关键点丢失；通常会返回重定位以恢复状态。
快速运动：其定义方式因情况而异。建议读者自行设定并进行测试。在笔者的研究中，主要关注的是帧率超过的基本运动。很快消失于视线之外。即使速度降低后仍可完成重新定位过程。
该方法同样也能够实现短暂的时间内进行阻挡测试。
光环境变化：笔者于夜晚进行了相关测试。首先，在开启光源时进行了定位操作；随后关闭了光源；随后发现ORBSLAM2立刻失去了跟踪；值得注意的是，在关闭光源后系统能够重新恢复定位状态；此外，在观察连续未检测到目标位置超过设定帧数时（例如5秒），系统将判定当前定位状态为丢失并启动重定位流程或执行初始化重置过程
2. AR
除了基于RGB-D的节点外，在此基础上作者还进行了Mono-AR相关节点的测试。研究者在配置参数时主要参考了Asus.yaml文件中的设置，并在此基础上采用了Xtion RGB摄像头作为数据采集设备进行实验。值得注意的是，在这一过程中并未获取深度信息
跑起来的效果如下：
启动时感到困惑，
为什么没有定位，
一直显示SLAM未初始化，
后来发现ORBSLAM2对单目初始化要求过于严格，
于是选择在一个纹理丰富的地点停留片刻，
随后略微有些许平移才使初始化成功，
最后放置模型就绪。
该AR系统的定位表现尤为出色。然而尽管 RGBD 存在问题 AR 同样也存在一些挑战因此笔者不再赘述细节希望读者能在其基础上取得新的进展.Enjoy.
好的今天决定不再进行总结了哦！这篇博客相当于笔者昨天运行程序所做的笔记记录哦！希望能为读者提供一定的帮助呢~
PS：
如您认为我的博客对您有帮助，请给予关注；如需转载文章，请注明出处并标明链接。
对于本文中的任何问题，在线读者可以在留言区进行讨论。此外，在泡泡机器人论坛：[http://paopaorobot.org/bbs/index.php?c=cate&fid=1]中的SLAM技术专门讨论区域定位与环境建模的技术交流模块中发布你的问题。
我的github链接是：https://github.com/yepeichu123/orbslam2_learn。