1、orb 是在先对图像进行特征提取，之后才是去除畸变
2、ORBextractor 在提取的过程中，必须是灰度图像！
3、在求取 orb 图像金字塔，每层特征数量时，一定需要按照 a1/scaleFactor 那样，递减吗？在 ORBextractor.cc 中 443 行。
4、在 ORBextractor.cc 中 775 行，ComputeKeyPointsOctTree() 函数中
const float w = 30 能否改变适量的值。变大一些符合条件可能会多些。这里每个格子粗略按照 30 大小来划分。
5、在特征提取时，他的做法是先在未去除畸变的图像上进行关键点提取、描述子计算。然后在得到所有关键点之后，在统一进行对关键点畸变去除。这样其实在畸变的图像上提取特征点，有可能造成错误。效果不太好！！有待测试
6、在 ORBmatcher.cc 中的 ORBmatcher::ComputeThreeMaxima（）函数，选取第二多、第三多特征点的阈值如何选取合适的？此时的 0.1 max1其实已经很小了，是不是应该提高这个阈值，就是变为 0.3max1 ，这样的话实际上会使成功匹配的点数量减少。反正在初始化阶段是有不好的效果。
当然如果让初始化成功率更高，那么这里其实可以降低阈值，为 0.05*max1，这样初始化的成功概率就会高，当然很可能引入了一些误匹配这个就需要后期如何剔除？
7、在 Frame::GetFeaturesInArea() 函数中，下面代码。其实在寻找潜在的配对点。这里面 if 语句其实感觉没有必要，因为上面已经确定了网格。实际上只要把网格内的所有关键点坐标记录下来就好了。这样就会增加潜在的配对点。另一种方法，就是增加半径 r。这样网格数量会增多，自然潜在配对的关键点相应的变多。
// 记录在半径 r 内的关键点，实际上这里应该把在 Grid 内的所有点都当做潜在的匹配点
if(fabs(distx)<r && fabs(disty)<r)
vIndices.push_back(vCell[j]); // 记录关键点在 mvKeysUn 中的序号8、在 Tracking.cc 中单目初始化阶段，Tracking::MonocularInitialization() 函数内部有下面的代码
int nmatches = matcher.SearchForInitialization(mInitialFrame,mCurrentFrame,mvbPrevMatched,mvIniMatches,100);
// Check if there are enough correspondences
// 匹配数量大于 100 个，才能算是初始化成功，实际上在初始提取特征时。一般都是在 1000多个特征点，
// 但是在实际跑的过程中初始化阶段成功匹配上的还是很少。说明 orb 特征点还是存在很大的变数。也许是描述子本身不太好，或者关键点不鲁棒
if(nmatches<100)
{
delete mpInitializer;
mpInitializer = static_cast<Initializer*>(NULL);
return;
}自己在 Frame 构造的过程打印了图像的关键点个数。实际上初始化阶段要求的特征点为 2000 个，但实际中从 900-2000 不等。但是在这里说明几次匹配是远远小于 100，要么就是运动过大，本来重合的特征点就很少，要么就是特征点不鲁棒，在关键点提取，或者描述子本身都是有很大问题的。实际上相机为 30 hz ，按理说。两帧之间的运动其实很小。正常匹配的点人眼看是多于 100 的。所以特征点本身的影响是很大的！或者潜在匹配时，窗口给定太小这里给 100。这个值应该根据相机本身的运动有关系！需要后面不同场景来进行调节！！！但是最根本的是如何选取更好的描述子？或者更好的关键点？但是计算量应该尽可能的小！
9、在 Initializer::FindHomography() 中内部使用的 ransac 方法不是标准的 ransac，论文中给出的仅仅是计算评分。没有考虑内点集的大小。需要结合评分以及内点集大小。来做一个最优的 ransac。还有两个模型之间的选择问题。
ransac 具体参考：
https://blog.csdn.net/robinhjwy/article/details/79174914
10、在 Initializer::Triangulate() 中的线性三角形法使用了 mvg 217 页的方法。但是最优的方法是 11.3 等等后面的。比如 218 页底部说的。所以后面优化的时候可以使用这些方法代替三角化！
11、在 Initializer::ReconstructF() 的时候那些参数其实可以进一步来调节。或者增加减少相应的条件！
12、系统在正常追踪时。利用了匀速运动模型，但是对于突变运动不能适用，这里解决方案是用 imu 预积分，但是如果不用与积分，如何处理？？？
13、在 Tracking::UpdateLocalKeyFrames() 函数寻找 K2 关键帧集时。里面找了孩子关键帧。但是孩子关键帧并没有像上面 CovisibilityKeyFrames(）共视图临近关键帧那样，按照共视强度 大--->小 排列孩子关键帧。这其实可以进行改进！！！！
14、在 Tracking::TrackLocalMap() 中，这里也是进行了追踪成功或失败的选项。实际上影响这里成功还是失败，最重要的是前面的初始匹配。初始匹配好，当然效果就好。这个就看假设的匀速运动模型是不是真正的符合实际运动状态。越接近效果越好！所以说能不能找到一个运动模型？？？
15、在 Map.cc Map::EraseMapPoint() 函数中，仅仅把地图资源擦除了。但是地图指针指向的内存好像没有擦除？？
16、在 void LocalMapping::ProcessNewKeyFrame() 中，其实 mlpRecentAddedMapPoints 这个变量可以用 std::set 类型替代。因为在这个函数中加入的地图点其实会有重复的。
17、找到 orb-slam2 中对于不好的地图点，该如何将其内存 delete 掉。目前程序中没有 在地图点剔除过程中没有 delete 内存
18、在 LocalMapping::MapPointCulling() 函数中，地图点的去除策略需要在找找。这个函数的策略就是论文中 VI B 部分的两个条件以及条件下面的那段话。实际上更好的剔除策略，会把无匹配讲到最低。这样前端的初始地图点越精确。那么优化时， pose 越是精确！
19、 在 MapPoint::Replace() 这个函数中，在 ORBmatcher::Fuse() 中调用时，替换和被替换的地图点之间 mnFirstId 可能是一样的。那么说明这两个地图点在追踪的时，都会同时增加 mnFound mnVisible。这样在 Replace() 函数中直接 Increase(nfound) ，我觉的是有问题的。所以需要改进.具体做法待做
20、在 KeyFrameDatabase::DetectLoopCandidates() 函数的实现方式看，可以发现一些小的闭环是没法检测到的。只有稍大一点才会检测到闭环。他的做法，其实因为小闭环在局部建图线程的局部 BA 优化已经能够优化误差了。所以对于小闭环。闭环线程尽量不要找到。大闭环一定要确保找到的成功率。
21、注意在计算 sim3() 时，相似变换其实也会影响平移向量。所以与刚体 T 投影地图点到相机坐标系还是有区别的。有些点 T 变换可能是在图像上，但是用相似闭环可能就不在了。
22、在局部建图线程中，当前正在处理的关键帧的临近关键帧在找到新的匹配时，都没有更新共视图。
23、在 LoopClosing::CorrectLoop() 函数中调用 SearchAndFuse() 函数说明处。记录了潜在的 bug 以及原因。
24、LoopClosing::RunGlobalBundleAdjustment（） 函数内部通过纠正局部建图增加的关键帧的 Pose。实际上纠正方法是基于新增加的关键帧和父关键帧之间在优化前后两帧之间的变换是固定的。但是这种假定其实是有问题。需要改进！！！
25、待做试验：对于前端的错误匹配，如何处理？？错误匹配中包含了什么样的信息？正确匹配之间的 haming 距离和错误匹配之间的 haming 距离有什么不一样吗？需要统计一下。如果是 hamiing 距离都是很小。但是其中确实有错误匹配。说明除了 haming 距离要小外。应该还有其他的因素暗含正确匹配。这个其他因素就需要看看现有其他特征 sift surf 误匹配率！然后分析哪个是决定因素？？？
26、在 ORBmatcher::SearchByProjection(Frame &CurrentFrame, const Frame &LastFrame, const float th, const bool bMono) 函数中，实际上这个函数严重依赖当前帧的初始运动估计，所以这里用 Imu 如何精确估计？
27、论文中的匀速模型除了用 Imu 多传感器融合外，用什么模型进行预测比较好？？使用加速度模型？
28、在 LocalMapping::ProcessNewKeyFrame() 函数内部发现了 bug，就是不同关键点会对应同一个地图点，目前没有详细分析问题出现在哪里。可能是匹配时出现了问题，也可能是在 Fuse 函数导致的。