-
Notifications
You must be signed in to change notification settings - Fork 298
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.
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
Unable to reproduce CBGS's results on NuScenes #47
Comments
Closing the issue as I found my ground truth velocities are incorrectly set (#46). |
the same result, I have check the box velocity, it's normal
|
I am waiting for my experiments with fixed ground truth velocities to finish, but so far it does not look like numbers are getting better than the ones that I posted here. According to README.md, CBGS on NuScenes is not yet released officially. I am hoping the authors would address this issue. Also, I am not sure why the velocity-related error (AVE) seems unreasonably large. |
the boundingbox velocity x,y loss are abnormal large than other elements in the box. |
OK, the CBGS use the global velocity of the annotations.
maybe need to check velocity loss compute function.... |
Below are the results of my second run after fixing the ground truth velocities. What I did was to use the nuscenes devkit provided by the authors instead of the official devkit. Looks like numbers still do not match what's in the paper. Something must be off.
|
I cannot reproduce the results for nuscenes either. It took five days to train on 8 P100 even after I did some speed-up for the code. There is still difference because I use the official nuscenes devkit and ignore nan velocities. I am going to follow the exact instructions so that duplicated sweeps are trained as 0 velocities. Not sure if this will affect results.
|
Thanks for sharing. I also ended up ignoring NaN velocities in the smooth L1 loss, but my mAVE (#55) is much higher than yours. and got similar results. The difference is likely related to whether using the official devkit or not. |
the most important metrics are mAP, mATE, mASE, mAOE, if you don't want to predict the velocity, just set velocity loss to 0, the really metric confused me is the mAOE metric. it's much larger than the report value. |
@peiyunh I also used nuscenes devkit provided by the authors and got very similar results:
|
My recent result is
After I fixed the code weight bug as @muzi2045 pointed out. I think mAOE is a bug. I found there is a little difference in direction classifier as in SECOND. I tried to disable direction classifier to see whether that would help. waiting for the results. |
But the way the code has too many bugs for lyft. I got almost 0 accuracy trying to reproduce. The code from this original repo isn't even runnable. |
Why the mAVE you reproduced is normal? the others are get a larger value, could you share your modified version or config? |
Maybe you should pay attention to the arg nsweep in NuscenesDataset(https://github.com/poodarchu/Det3D/blob/b4cb6428b807d8cfe2135b535961d710ff9d41c1/det3d/datasets/nuscenes/nuscenes.py#L35), its default value is 1. However the name should be n_sweep which is the same as the one in config. So I think you may train with only one lidar frame. |
Comparing to the current master branch, I made two changes in order to fix the NaN training loss.
The first change is described in #46 .
The second change is to add what's below before line 193 in losses.py
Besides, I set
in
examples/cbgs/configs/nusc_all_vfev3_spmiddleresnetfhd_rpn2_mghead_syncbn.py
andin
tools/train.py
.Here are my results on the validation set after training 20 epochs:
Overall the mean AP is 38.2, which is much lower than what's reported.
Can someone point me to what I might have missed? Thanks!
The text was updated successfully, but these errors were encountered: