XCCCCZ的博客

把nuScense的3d标注在图像上做可视化发现nuScenes的标注也做得不好 好些目标漏标了！只是目前没有更好的公开数据集出现，没银子自己采集和标注数据集的尤其是做学校研究发论文的就只能继续在nuScenes这样的数据集上干活了，尽管现在的车载激光雷达已经比nuScenes数据集采用的32线雷达好了几代了，还是不得不死磕nuScenes 32线雷达的稀疏点云用sweep帧对齐和叠加来模拟现在雷达的稠密点云。

对于有畸变的平面相机，则不能使用内参和外参矩阵连乘，而是需要先左乘以外参矩阵把点云3D坐标转到相机坐标系下的坐标(Xc,Yc,Zc)后，把Zc小于等于0的坐标过滤掉，然后需要把Xc和Yc除以Zc，得到未校正的相机坐标系下的2D坐标(Xc/Zc,Yc/Zc)，然后根据相机厂家给出的计算公式使用相机的畸变系数对此2D坐标做校正得出校正后的坐标(X,Y)，再将此坐标扩展为奇次坐标后转置再左乘以相机的3x3原始内参矩阵，得出像素坐标(u,v)，可以参考。很多文章里列出连乘公式都漏了这个重要的。

这里的错误导致分配CUDA内存的大小不对，导致后面给这块CUDA内存拷贝赋值时发生了越界访问从而把CUDA内存搞脏了，然后错误就发生在前面那个核函数调用的地方。CUDA内存弄脏后再访问CUDA内存会出错，但是报的错一般是让你根本无法看出准确原因的，出现莫名其妙的错误时，可能需要整个排查而不是只盯着出错处查，否则可能折腾很久浪费时间还是不知道原因在哪里。有时忘了这个经验浪费不少时间，记录一下备忘。

但是因为你的模型或cuda环境等约束，不能安装这么高的版本的pytorch和onnx组合时(例如我的环境是pytorch1.12，onnxruntime=1.19.2，即使onnxruntime版本比较高但是Pytorch的版本底也照样报这个错: tan2 to ONNX opset version 16 is not supported)，那就只能考虑自己基于torch.atan()实现torch.atan2()的功能了。测试验证发现是准确的。

对于带模板的函数的声明和定义代码不在一个文件里且调用此函数的代码也与函数的定义不在同一个文件里的情况，编译器除了查找调用此函数的代码所在的文件和声明此函数的代码所在的文件里查找外，并不会去其他文件里查找此函数的定义，因而无法根据模板参数展开此带模板函数的定义代码并编译出对应版本的目标代码，到了链接阶段，链接器为调用此函数的代码查找此函数的定义代码编译出来的目标代码时自然找不到而报错。对于普通函数，在源码文件(以.cpp为例)里的定义在编译阶段是会被编译器编译成完整的目标代码；

而我们自己的数据集一般都是在激光雷达坐标系或相机坐标系或者自车坐标系下标注的，所以需要先借助自车的定位数据把bbox的translation转换到全局坐标系去，然后求差再除以时间差获得速度，直接拿局部坐标系下的标注数据的translation值相减除以时间差显然是不对的，因为这只适合自车是静止的情况。

但是点云始终显示不出来，在dreamview的窗口里选择点云channel的下拉列表里也看不到自采集数据的点云topic名字，重启dreamview都不官用，只好去看dreamview的源码，在。dreamview主页面里选择点云的下拉列表里就可以看到自采集数据包里的点云topic了，选择topic后先关闭pointcloud再打开就可以看到点云的可视化效果了。

编译Apollo时报错Could not find any cuda.h matching version '' in any subdirectory。

总是报错说找不到libbackground_filter.so和libroi_boundary_filter.so，而这些so文件在编译后是已经在路径bazel-bin/modules/perception/lidar_detection_filter/object_filter_bank下是有了的。两个plugin就正常加载了！

然后create_data_bevdet.py就可以成功执行了！看来 numba0.53需要和numpy1.23.5组合才能使用。修改这个文件设置numpy==1.23.5，防止下次重新安装环境后再处理nuScenes数据集时出错。只好把自动安装的numpy1.24.4卸载掉，然后再安装网上有人推荐的numpy 1.23.5。

Apollo官网上下载的代码编译是没这个问题的，我用的这个是某个beta版，可能新旧版本代码和编译环境里的bazel版本之间兼容没做好。用Apollo的某个版本的源码，执行。创建容器并进入容器后执行。

使用的id_rsa和id_rsa.pub本来是可以用来正常访问github的，在github上个人的账号里也设置了对应的key，怎么在新机器环境下就不行了呢？查看网上别人说的解决办法，出这种错误后，一般人都是重新创建公私钥配置了一遍，这不是我想要的解决办法，但又不知道为何不让访问，感觉上面的Permission denied错误提示说的不明不白的。原来是文件的权限太多了，执行一下chmod 100 /home/g/.ssh/id_rsa只授予read权限，然后再执行。fatal: 无法读取远程仓库。

从pytorch导出onnx和onnx化简全过程中网络结构上的变化，发现上面有一个检测头和有多个检测头时的网络的onnx图，发现，只有一个检测头时，像上面提到，因为torch.cat()没有实质操作，pytorch导出onnx时虽然在onnx生成了Concat算子节点，但是后面用onnx simplifier化简时，它会把这个Concat算子节点删掉，Transpose算子的输出就直接作为网络的hm_preds输出了，而有多个检测头时，torch.cat()会有实质拼接操作，Concat算子自然被

使用PCL的PCL的fromROSMsg()函数将ROS的sensor_msgs::PointCloud2类型数据转换为PCL的pcl::PointCloud类型数据时，假如T只是PointXYZ没问题，假如是PointXYZI，intensity这个field的数据类型是float，但是数据长度就是不对的，数据占8个字节而不是float的4个字节！

另外，由于NuScenes数据集采集数据时是使用的32线扫描式激光雷达，这种雷达的点数实在是有限，和现在市场上自驾使用的128线扫描式激光雷达或固态激光雷达的密集点云比，成像效果真是太差了！因为采集数据的自车是运动的，Sweep帧采集时的激光雷达坐标原点和朝向和关键帧采集时的激光雷达坐标的原点和朝向是不一样的，所以点云合并时必须要考虑运动补偿做坐标转换！装载数据时，self.infos里的bbox已经在前面生成pkl文件时从全局坐标系转换到了对应的关键帧所在的激光雷达坐标系下，所以剩下的重点就是。

optimizer.load_state_dict()报错parameter group不匹配的问题的原因ValueError: loaded state dict contains a parameter group that doesn't match the size of optimizer's group

近期发现ROS2 galactic下生成的bag包在humble下回放时使用rviz可视化，bag里的点云可以正常看到，但是使用Marker和MarkerArray画的box却死活看不到，感觉很纳闷，看网上有人报告说foxy下生成的bag包在galactic下播放会报SQL错误，推断ROS2不同版本之间关于bag的实现可能有一些差异导致不兼容。考虑道ROS2生成的bag包实际上是个sqlitedb文件，于是下载sqlite3的可执行文件和给VS code安装Sqlite3 Editor插件

(Window or Screen Coordinates)是不同于视口坐标系的，是真实屏幕上的坐标，以屏幕左上方顶点为原点，x轴以向右方为正，y轴以向下方为正，一般UI软件涉及到的窗口(Window)的位置和鼠标相关事件都是屏幕坐标系下的，通过鼠标事件获取到的鼠标当前的位置坐标需要转换成视口坐标后才能逆向计算出鼠标在屏幕上的当前像素位置对应的实际空间中的世界坐标系下的位置。注意视口坐标系和屏幕坐标系是由区别的，经常有人搞混，把屏幕空间的视口坐标系叫屏幕空间的屏幕坐标系，实际上，

find_package(PCL 1.8 REQUIRED COMPONENTS common io visualization) but it set Qt5WebKit_FOUND to FALSE so package "Qt5WebKit" is considered to be NOT FOUND. Reason given by package: Qt5WebKit could not be found because dependency is required to have

以前以为rviz是用OpenGL渲染绘图，那么获取图像里像素点对应的真实3D坐标是采用的OpenGL里提供的API实现的，结果一看代码还真不是这样，rviz也就渲染用了OpenGL，其他都是自己实现的，图像界面的实现完全是遵循MVC设计模式自己实现的透视投影和坐标转换等所有相关类。世界3D坐标是用的射线法计算出来。SelectionManager::get3DPoint()被rviz里多个地方调用，凡是UI界面上需要查看点的坐标地方都是调用它。