再分析一下vins的加载位姿图 重定位

在回环节点输入s并敲回车，保存在pose_graph文件夹下的东西
 

似乎就是关键点和关键点对应的描述符？
 

 

还有一个pose_graph.txt
 

https://blog.csdn.net/qq_45306739/article/details/135003796

这里对输出的文件整理得很全面
https://blog.csdn.net/weixin_43821376/article/details/103601569
 

我的pose_graph文件夹里面没有图片是因为我的save_image参数选择的0

vins_mono里面还真有个快速重定位的参数，vins-fusion里面都没有的。
config/euroc/euroc_config.yaml · 马熙/VINS-Mono - Gitee.com
 

https://www.guyuehome.com/15320

所以LOAD_PREVIOUS_POSE_GRAPH是为了更快地回环，还是为了重定位？

好像vins-mono里面有专门的重定位位姿话题
https://blog.51cto.com/u_14439393/5737457
 

这些话题你是否都能分析清楚
https://blog.51cto.com/u_14439393/5737457

看这似乎加载位姿图是为了更好地做位姿图优化?
https://zhuanlan.zhihu.com/p/624732822?utm_id=0

你的问题我总结下应该可以概述为，vins回环后的位姿以及重定位后的位姿的世界系原点是哪个？

这里说 重定位就是想计算出世界坐标系和vio坐标的漂移位姿（shift_t）
https://blog.csdn.net/weixin_43821376/article/details/103601569

所以vins_estimate节点发出重定位话题（是漂移的相对位姿）后给回环节点订阅，回环节点得到回环后的位姿发出来，是不是这个道理！！！这也就发生了我们看到的回环时位姿的突变。
https://blog.csdn.net/weixin_43821376/article/details/103601569

vinsfusion的回环节点发出的话题有这些

/loop_fusion/base_path
/loop_fusion/camera_pose_visual
/loop_fusion/margin_cloud_loop_rect
/loop_fusion/match_image
/loop_fusion/odometry_rect
/loop_fusion/path_1
/loop_fusion/path_2
/loop_fusion/path_3
/loop_fusion/path_4
/loop_fusion/path_5
/loop_fusion/path_6
/loop_fusion/path_7
/loop_fusion/path_8
/loop_fusion/path_9
/loop_fusion/point_cloud_loop_rect
/loop_fusion/pose_graph
/loop_fusion/pose_graph_path

注意vins-mono和vins-fusion回环部分的区别
https://blog.51cto.com/u_13157605/6038033

加载和不加载之前的位姿图，在代码上的区别。
https://blog.51cto.com/u_13157605/6038033

从这看感觉加载之前的位姿图，似乎就是多了一些点来进行位姿图优化。
https://blog.csdn.net/moyu123456789/article/details/104048426

/loop_fusion/pose_graph_path话题并不是一开始就有的，似乎是发生了回环之后才发出来的。

看这个图，发生回环的就会红线连起来，实际跑vins时也是有红线连着的
 

回环后的位姿应该是这个位姿。

绿色是没有回环的位姿轨迹，红色是有回环的位姿轨迹。
这个情况下，回环节点发出的odom应该是有跳变的。路径肯定是跳变了，odom没道理不跳变呀，不知道无人车上是如何应对回环位姿跳变的影响的。

https://github.com/njauwangkai/A-LeGO-LOAM/commit/65ce258d60840556a7192eb1d1419d1ad2a21e97

T265也有回环，回环也可能发生位姿跳变
https://blog.csdn.net/crp997576280/article/details/109544456
 

我自己测试了下 /loop_fusion/odometry_rect话题是一开始就有值，但是/loop_fusion/pose_graph_path是过一阵子才有值（可能是真正发生回环后才有值？）。
但是我看/loop_fusion/pose_graph_path话题有值时终端打印还没有optimize pose graph ，是过了好一阵子才打印出optimize pose graph

所以densesurfelmapping给的bag包，并不是起飞刚开始的，而是飞了一阵子才录的包是。

/loop_fusion/pose_graph_path这个话题到底是起什么作用的呢，显示路径？为什么是过了一阵子才有。

自己用真实D435i跑时也是需要先晃动一下摄像头，这个话题才出来，如果摄像头一直静止，它也不出来，而且我刚才看了，这个话题出来的时候，回环终端还没有打印optimize pose graph，过了一阵子才有。

我发现一个规律，我摄像头不动的时候，这个话题就不会发出来，一旦动了摄像头，这个话题就立马发出来了。

还有我发现单用灰度图跑densesurfelmapping好像还是有点小问题的。

/loop_fusion/pose_graph_path这个话题就是path类型的，可能你没有大的位移它也懒得移动吧。 densesurfelmapping订阅的路径而不是位姿，可能是为了方便融合，所以并没有路径也就没有建图。
 

 

我估计/loop_fusion/pose_graph_path这个话题，没有回环的时候也是有值的，你的之前没有值可能是因为相机没有怎么动，它可能需要有一定位移才会发出新的话题。之前可能误解了densesurfelmapping，以为一定要发生了回环有了 /loop_fusion/pose_graph_path 话题才能建图， /loop_fusion/pose_graph_path 话题应该也是一开始就有的。

回看两年前跑vins回环的录屏，是一开始就有红色路径，也就是回环路径了的，不是非等到回环发生才有红色路径，再看别人使用densesurfelmapping也没有说要过一阵子等回环了才有建图出来对吧。 所以跟你之前有没有保存位姿图也没什么关系，有没有保存加载位姿图影响的是开始回环的时间，但是不影响/loop_fusion/pose_graph_path 话题的发出。