Skip to content

dufo label的效果是否会影响训练 #10

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
houshuaipeng opened this issue Mar 19, 2025 · 20 comments
Open

dufo label的效果是否会影响训练 #10

houshuaipeng opened this issue Mar 19, 2025 · 20 comments

Comments

@houshuaipeng
Copy link

作者您好，非常感谢您的代码，我在用您的代码跑自己的数据集训练的时候发现loss下降的不是很好，尤其是cluster_based_pc0pc1和dynamic_chamfer_dis，然后我可视化看了一下dufomap的结果，看上去树叶会被判断为动态点云，怀疑是这个判断出错导致模型在计算loss的时候出现了问题，所以想请教您一下dufo label的效果是否会影响训练，模型在训练过程中会重新对动静态进行判断吗？期待您的回复
@Kin-Zhang
Copy link
Member

dufolabel会影响训练效果，正如我youtube视频中展示的 即使在av2数据里 dufo只是一个粗分割，效果也有很多误识别；其中我觉得误识别对效果影响不大，因为chamfer 能拉回来；但是漏识别就有比较大的问题了；模型训练过程 由loss会隐式的进行判断学习

如果可以的话，可以把数据给个demo 我看看 是不是对的

个人我测过三个公开数据集 基本都训的比较好

@houshuaipeng
Copy link
Author

感谢您的回复，这是我制作的一个clip的数据，我放在我的NAS上了，通过链接可以直接下载，请查收：
【绿联私有云】分享文件：https://web.ugreen.cloud/web/#/share/b6ca65177e0440b39921e436f89c4975
提取码：U383

@Kin-Zhang
Copy link
Member

Kin-Zhang commented Mar 20, 2025 •
edited
Loading

hello 我看到你的数据啦，首先有个比较大的问题是：

Image
这个baselink（传感器的问题有点不太对？）　具体是这个意思：https://github.com/Kin-Zhang/linefit/blob/master/assets/config/README.md

主要是dufo_label需要pose在传感器中心 才对；你能重新针对这个生成一次h5数据给我吗？（这样我再试试？

第二个发现的是，可能咱pose也没那么准？比如这个红绿只是把pose_flow加进去看一下static 有没有align 但是这里看到的 好像有点差距（不过我没量 所以上一个先解决先看看）

Image

@houshuaipeng
Copy link
Author

houshuaipeng commented Mar 21, 2025 •
edited
Loading

hello，感谢您的回复！
关于您提到的第一个问题，我这个数据中，自车pose和点云本来就是同一个坐标系（自车的后轴中心），所以这里pose应该就是在传感器中心的，只不过是默认为传感器在后轴中心而不是在车顶了，我在使用linefit生成地面mask的时候把sensor_height改为0了（改之前分割结果是错的，改为0之后是对的），；关于您提到的第二个问题，确实是有可能的，因为我用的是slam重建之后更新的pose，我可以直接使用原始的pose再试一下

@Kin-Zhang
Copy link
Member

第一个是我用linefit给你示意图一下，主要是dufo是raycasting-based 而射线应该从真实传感器中心出发，这个axis的位置应该反应的是真实传感器位置才行。

@houshuaipeng
Copy link
Author

好嘞，刚才仔细看了下您dufomap的论文，理解了您说的意思了，确实是不应该用后轴中心当做射线起点，我基于您说的思路，将点云的坐标转到了真实传感器中心为原点的坐标系下了，然后使用了采集到的绝对pose（原来是slam重建后更新的pose），新的数据链接是：
【绿联私有云】分享文件：https://web.ugreen.cloud/web/#/share/9a10231f395e44ee804d902b10352b96
提取码：UJ69
请查收
（PS: 我这边正在对这条数据做过拟合训练验证，目前来看除了static_flow_loss损失外，其他loss下降的貌似还是有点不太好，感觉可能还有其他问题😭）

@Kin-Zhang
Copy link
Member

I see 没事的，loss曲线并不是唯一标准 特别在数据噪音较大的情况，不知道你是否有val的结果，可以进行epoch下看看validation metric是否正确

这是waymo 论文中训练的 loss & val 曲线 （供你参考：

Image

关于这个数据，现在在我看来 没啥太大的问题，dufo的误识别 在高速场景下（新的那篇HiMo） 确实比较大，所以seflow++ 我类似于针对这一点由做了优化 虽然我还没把代码放上来，但是你可以看到（Scania数据 是卡车高速场景）seflow表现确实比较差

Image

@houshuaipeng
Copy link
Author

我的数据没有真值flow，所以不太好查看在自有数据集上的val的曲线，我是用的huggin face中的demo_data做的验证集，曲线是这样的：

Image
看上去损失和val曲线都不是很稳定，并且最终的值没有下降到像您图中那么低的程度，然后我在这个过拟合训练的clip上直接推理，可视化结果也不是很好，首先是远处的召回有点低（怀疑这个跟您上面说的dufolabel漏识别有关），然后是旁边的绿植被当成动态目标计算出了flow，还有就是近处的车辆方向（颜色）不对，我的参数是这样的：
python train.py model=deflow lr=2e-4 epochs=30 batch_size=2 loss_fn=seflowLoss num_frames=2 save_top_model=3 train_data=./test_one/val "add_seloss={chamfer_dis: 1.0, static_flow_loss: 1.0, dynamic_chamfer_dis: 1.0, cluster_based_pc0pc1: 1.0}" "model.target.num_iters=2"
不会是batchsize太低导致的吧😭我的24G显存就只能跑到batchsize=2

@Kin-Zhang
Copy link
Member

这个并不是optimization-based而是feed-forward 也就是说是需要一定数据量的，论文里Fig.4 的10%也是 10k数据，而demo_data的数据只有157帧训练；所以这个训练并不能作为参考....

针对batch size 如果batch size=2的话 对应的learning rate应该线性下降才行，你是一个gpu吗？总batch size是set_bz * #gpu；如果是一个的话 lr 需要对应缩小32倍。。。

@houshuaipeng
Copy link
Author

收到，那我多做些数据集再跑下试试，目前测试是用的1张卡，后面数据多的话可以用8张卡来训练，感谢您的时间和解答🙏

@Kin-Zhang
Copy link
Member

没事，然后我卡车数据集的总数据量是60K左右（论文实验部分有写），大概是av2的50%数据量来着；你可以参考着看看，有问题再随时留言~

@houshuaipeng
Copy link
Author

houshuaipeng commented Mar 25, 2025 •
edited
Loading

hello，我又来了😂我在大批量跑dufo label的时候发现有些数据会出现segmentation fault的问题（主要是这一行：mydufo.run(data['pc0'][range_mask], pose_array, cloud_transform = True)）
我做了以下尝试：

  1. 因为dufomap用的C代码写的，使用python的try except机制没法捕获并跳过异常数据；
  2. 使用multiprocessing.Process以子进程方式调用，能够捕获异常了，但是因为内存没有共享，导致mydufo中的属性不会更新，最终的数据中dufo_label是空的；
    请问有什么好的办法吗💗

@Kin-Zhang
Copy link
Member

大批量跑dufo是指一台机器吗？一台机器的L1 cache是共享的; 我大批量是在slurm下管理的：https://github.com/KTH-RPL/OpenSceneFlow/blob/main/assets/slurm/dufolabel_sbatch.py 用了五个机器来着..

但是如果数据量不大，我建议直接单个跑就行，单个dufo把thread拉满

异常数据是指？点云没点？还是什么？如果是没点，可以直接做一层判断 丢弃这个数据（我对数据异常的filter out是在process的时候做的，https://github.com/KTH-RPL/OpenSceneFlow/tree/main/dataprocess 比如这里面两个都会判断点数是否足够100个（已经很少了） 不然都不会成为frame

@houshuaipeng
Copy link
Author

houshuaipeng commented Mar 25, 2025 •
edited
Loading

是用一台机器批量跑多条数据的，用的process.py，我验证了一下，是固定有一些场景的数据跑mydufo.run的时候会出现问题的，报错的信息是这样的：

I20250325 20:02:57.674473 139807741925184 dufomap.cpp:80] Transformed point cloud to the pose you set...
*** Aborted at 1742900577 (unix time) try "date -d @1742900577" if you are using GNU date ***
PC: @ 0x7f25c6fc404a void ufo::impl::integrateHits<ufo::Map<1052680ul, 0ul>, ufo::Vector3, ufo::DummyType>(ufo::Map<1052680ul, 0ul>&, std::vector<ufo::CloudElement<ufo::CodeOrIndex, ufo::Vector3, ufo::DummyType>, std::allocator<ufo::CloudElement<ufo::CodeOrIndex,p�$
*** SIGSEGV (@0x7f264724c030) received by PID 120320 (TID 0x7f24a0a01700) from PID 1193590832; stack trace: ***
@ 0x7f2786e6f4df __pthread_once_slow
@ 0x7f25c70113b7 (/root/miniconda3/envs/opensf/lib/python3.8/site-packages/dufomap_bind.cpython-38-x86_64-linux-gnu.so+0x1013b6)
@ 0x7f2786ec4090 (/usr/lib/x86_64-linux-gnu/libc-2.31.so+0x4308f)
@ 0x7f25c6fc404a void ufo::impl::integrateHits<ufo::Map<1052680ul, 0ul>, ufo::Vector3, ufo::DummyType>(ufo::Map<1052680ul, 0ul>&, std::vector<ufo::CloudElement<ufo::CodeOrIndex, ufo::Vector3, ufo::DummyType>, std::allocator<ufo::CloudElement<ufo::CodeOrIndex,p�$
@ 0x7f25c6fc545d std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result, std::__future_base::_Result_base::_Deleter>, std::tp�$
@ 0x7f25c6f8c14b std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool)
@ 0x7f2786e6f4df __pthread_once_slow
@ 0x7f25c6f9b2ca std::thread::_State_impl<std::thread::_Invoker<std::tuple<std::__future_base::_Async_state_impl<std::thread::_Invoker<std::tuple<ufo::insertPointCloud<ufo::Map<1052680ul, 0ul>, ufo::Vector3, ufo::DummyType>(ufo::Map<1052680ul, 0ul>&, std::vector<ufop�$
@ 0x7f278355bdf4 (/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28+0xd6df3)
@ 0x7f2786e66609 start_thread
@ 0x7f2786fa0133 clone
Segmentation fault

我debug看了一下，这些数据的点数是正常的（30万左右），里面也没有nan、inf之类的值，我还在看这些数据与其他的数据有啥不同，希望能在跑mydufo.run之前过滤掉这些数据

@Kin-Zhang
Copy link
Member

Kin-Zhang commented Mar 25, 2025 via email

@houshuaipeng
Copy link
Author

我检查了一下数据，输入除了点云外就只有pose了，点云没问题，然后我看了下pose，目前用的是绝对pose，我换成相对于第一帧的相对pose后就可以正常跑了（我怀疑是绝对pose里的值太大了导致的），目前没问题啦，感谢您的回复

@Kin-Zhang
Copy link
Member

啊哈 那应该是我python binding的时候设置pose是float32 I see 那我后面更新一下 设一个警告比较好

谢谢告知～

@houshuaipeng
Copy link
Author

hello，我用自己的数据（8400帧左右）训练了一个模型出来，但是我发现这个模型在OpenSceneFlow提供的mini processed dataset中的val数据上推理的效果比较好，在自己的数据上推理的效果反而不好，我怀疑是跟您最开始说的我的pose不准有关，这个有什么好的解决办法吗？比如尝试把pose误差通过学习的方法看看能不能消除

Image

@Kin-Zhang
Copy link
Member

Kin-Zhang commented Mar 28, 2025 •
edited
Loading

对奥 跟你讨论让我想起来，最近我们也在做一个生成一个新的数据集，发现这个pose的精度得设到float64保存，主要是计算ego_motion的时候32在读取然后计算ego_motion会丢精度；但是这个现象我在av2, waymo, nus都没看到... emmm

-         group.create_dataset('pose', data=pose.astype(np.float32))
+        group.create_dataset('pose', data=pose.astype(np.float64))

如果可以的话 你可以给我分享一下你的原始数据和你的生成script （h5py的） 我可以再仔细看一下

@houshuaipeng
Copy link
Author

我知道什么问题了😭是因为坐标系不一致导致的，我这边数据的坐标系是右前上的，然后我可视化的时候发现点云坐标系不对，就把点云转成了KITTI坐标系，但是pose没有转。。我把pose转了之后就对齐啦，pose转坐标系前：

Image
pose转坐标系后：

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@houshuaipeng @Kin-Zhang