weixin_45533366的博客

Ceres options可以选择优化的策略，一开始我用的是Levenberg-Marquardt优化。因为需要对姿态进行优化，当执行行驶的时候，姿态残差优化正常能够收敛。后来发现Levenberg-Marquardt不适合初值不好的情况，当初值和最终优化值比较接近时才比较好用。所以拐弯的时候，姿态初值偏离最终优化值较大，LM就不能正常收敛了。自己用轮式码盘的速度写了一个约束Factor，后面优化的时候发现这个约束的残差越迭代越大。但是我Evaluate函数里面的雅可比矩阵是正常的。

opencv中goodFeaturesToTrack()是检测角点的函数，然后在ROS中调用这个函数检测图像角点出现了Segment Fault错误。然后我排查了所有参数，都没有任何问题。然后我在Debug模式中，发现最后出问题的地方是。以前也经常在ROS中调用其它的版本的OpenCV的库。编译的时候会提示冲突，我没有管，也可以正常运行。没想到这次栽在这上面了。所以怀疑是库版本不一致导致的冲突。我的OpenCV版本是4.10, ROS2中。

最近写了一个IMU-轮式紧耦合的里程计，IMU的角速度积分比较准确，但是IMU加速度积分出的速度漂移特别大。轮式的速度比较准确，因此轮式的速度来约束IMU加速。但是，雅可比矩阵就是单位矩阵，为什么或错了。Eigen：：Map如果不声明，就是按照列顺序填充，举一个例子。不可能这么小，因此只有一种可能，就是雅可比矩阵。特别下，梯度非常小，优化几步就停止优化了。,行数与残差维度相同，列数与变量维度相同。算出的列向量中最大的那个值，其中。是按照行顺序计算的雅可比矩阵，即。如果按照列顺序填充，如果按照行顺序填充，

可以避免重复引用，同一个源文件如果已经引入过一次莫个头文件就不会再引入第二次。因为引入头文件，可以理解为把头文件的内容赋值粘贴到当前文件中。的时候就不会出现多重定义的错误，因为所有源文件都共享同一个变量。但是上述代码只针对同一个编译单元（同一个源文件）有效。,并且它们两个编译为一个可执行程序。就会报多重引用的错误。如果解决这个问题，就需要用到。中间文件，再连接为可执行文件。中就会报错多重定义的错误，因为。，相当于把里面的内容复制两次到。都是单独编译的，先编译为。被定义了两次，一次在。如何引用并不会影响到。

使用初始化列表: 在构造函数的初始化列表中初始化成员变量是 C++ 的标准做法，确保成员变量在构造函数主体执行之前被正确构造。避免赋值: 在构造函数主体中对成员变量进行赋值可能会导致错误，特别是当成员变量没有默认构造函数时。始终在初始化列表中进行初始化。如果B的构造函数参数需要在A的构造函数中才能确定，可以使用或者在A的构造函数中进行一些计算或逻辑处理，然后在初始化列表中使用这些计算结果来初始化B的实例。使用可以延迟B的构造，直到有足够的信息来初始化它。

Linux系统下编译和运行程序时候，经常出现动态库链接的问题，主要有两种情况，一种是编译的时候链接问题，另一种是运行的时候链接。

所以上述bug是因为shared_ptr的reset()函数传参时将boost::shared_ptr* 的变量赋值给laserScan*的变量，因为指针类型不同出现报错。cast一般用于类型转换，BOOST_ASSERT( p == 0 || p!= px )表示指针为空或在指针类型不同。所以，根据上述报错信息可以判断Bug是源自指针赋值时类型不同。’ ，另一个是‘boost::shared_ptr::element_type。然后提示信息中指出一个指针类型是‘boost::shared_ptr。

运行kalibr中相机-IMU标定节点kalibr_calibrate_imu_camera 报错。kalibr_calibrate_imu_camera是一个python ROS节点。python ROS节点运行时需要在开头指定对应的python解释器。

这种情况一般是有两种一种是A.h中引入了B.h，然后是B.h中引入A.h了，就是嵌套引用，这种情况可以看一下下述链接的解决方法。后来排查我是在A.h中不小心又#include <A.h>

在lauch,json文件里，因为加了“ ”，所以当成一个字符串处理。自己debug一点问题没有，没有任何报错，代码也想不出哪里有问题。解决方法是要么将wall contour2.pg改成wall_contour2.jpg或者在终端输入的时候加入双引号。上面代码是opencv对图像进行裁切的函数，代码非常简单。这段程序需要在命令终端传人参数。

自己定义了一个二维数组，初始化值为0，大小是图片mask的大小，里面的值代表点云的索引，即point_index。程序里面索引到mask.rows和mask.cols时就越界了，导致值溢出。通过Debug调试软件定位，发现是point_index超出点云最大的索引了。上述代码运行的时候报一下错误。但是取值的时候忘了，其。

根据报错信息发现是矩阵相乘维度不统一的错误,一个矩阵是Derived = Eigen::Matrix<double, 4, 4>，另外一个矩阵是Eigen::Matrix<double, 3, 1>。Eigen可以表示空间转换的还有两种形式，一个是Eigen::Affine3d, 另一个是Eigen::Isometry3d。它们之间的区别在于它们所表示的变换类型和所包含的自由度。Eigen::Isometry3D 和Eigen::Affine3D是可以和3维向量直接相乘的。T是齐次转换矩阵，维度是。

开始以为是pcl::CorrespondencesPtr的变量声明有问题，后面发现不是这个问题。当一个局部变量的名称与外部作用域的参数名称相同时。这种情况可能会导致混淆和错误的使用，因此编译器会给出警告或错误。解决 “shadows a parameter” 错误的方法是避免在局部作用域内使用与外部作用域同名的变量。可以通过修改变量名或者将变量的作用域限定在不同的范围内来解决这个问题。原因是自定义的变量名与函数的输入参数同名了，所以会出现shadows a parameter的问题。

cloud_max_cluster是Ptr的格式，所以传入*cloud_max_cluster，对指针进行取值，结果还是出现报错。在函数声明的地方忘记改了，函数声明的地方，参数是智能指针。将函数声明的地方和函数定义的地方改成一样的即可。

例如，在 C++ 中，uchar value = img.at(y,x) 中，y 代表纵坐标，x 代表横坐标，ptr(y)[x]。但是在运行过程中发现有些点的像素值大于39，例如153，255等。我是用指针的方法查询像素值的。后来打印出来像素值异常的像素点的横纵坐标，发现v的坐标比cols大，但是程序并没有越界报错。当索引像素值时，只有当y为负数时，才会越界报错， y比行数大的时候，不会报错只会出现错误像素值。这里不得不提一下opencv像素索引的规则了，无论是用指针的方式，还是at的方式，都是y,x。

总结一下，这个是一个由于多版本第三方库导致的问题，当我们运行的程序多的时候，电脑上有时候不可避免要装多个版本的第三方库，所以在编译的时候，一定要指定好第三方库的版本，如下面所示。Linux文件管理方式和Windows是不一样的，windows是把同一个库装到一个包中，Linux是按照文件类型进行分类的，比如把不同的库的头文件都放到 /usr/include中，把库文件放到 /usr/lib中，比较杂。找了好久才发现，他们不是同一个版本的库，头文件是7.1，源文件是9.2.2，我怀疑是库版本错误导致的。

近日在Ubuntu20.04上编译PCL 1.08，在cmake时遇到一个问题CMake Error at /usr/local/vtk922/lib/cmake/vtk-9.2/vtkDetectLibraryType.cmake:23 (message): The `PATH` argument is required.Call Stack (most recent call first): /usr/local/vtk922/lib/cmake/vtk-9.2/FindFreetype.c

这类错误一般都是链接库时出现问题，但是我在CMakeLists.txt中已经链接了${PCL_LIBRARIES}，后来查资料，发现undefined reference to 除了因为是没有找到库外，也有可能是函数定义的头文件没有引入。之前自己尝试写过很多代码调试的笔记，但是都是在飞书上写的。但是飞书上记录有个问题，就是自己没有动力去整理笔记，每次都相当于草稿一样简单记录一下。一个是给大家分享解决方法，另一个也是想当成一个笔记记录自己debug思路，同时也为自己积累经验。结果编译时出现如下问题。