Any plan to reproduce AFDet?

[muzi2045]

the AFDet paper looks like the same idea as CenterPoint. But the backbone looks much lighter than original pointpillars:

@tianweiy

[tianweiy]

@muzi2045 it still uses (7+8) conv? My current setup is (3+5+5) which is not that heavy? Also, see table 3, they seem to have multiple architectures. Also please note that this is only on kitti. If I understand correctly, on waymo, their backbone is much larger.

[tianweiy]

the AFDet paper looks like the same idea as CenterPoint. But the backbone looks much lighter than original pointpillars:

@tianweiy

Also, it will be a really easy change if you want to try this. Simply change the [3, 5, 5] in the config to [7,8]

[muzi2045]

in RPN module, when layer setting is [3, 5, 5], here is actually (4+6+6) convs. and normally will have two transpose conv. in AFdet, the main idea to change RPN part is to want to make feature map shape same as pseudo image if I understand correct. larger feature map is better in anchor-free detector as the paper claimed. and there still some place slightly different such as heatmap encode part, offset reg encode part, loss func setting.

[tianweiy]

larger feature map is better in anchor-free detector as the paper claimed.

Larger takes much more memory and in practice becomes slower without much accuracy improvement. Another thing is that you can't do the max-pooling if your dataset contains many small objects. E.g for nuScenes 3x3 max pool for a feature map with stride 8, voxel size 0.1, will suppress too many pedestrians and traffic cones. Change to stride 1 will solve this problem but it will be much slower. Instead, in CenterPoint we use circular NMS to solve this.

I think the general idea is about the anchor free detection head, so I didn't spend time tuning other backbones. The hope is to provide a plug and play framework for any backbones / downstream tasks.

and there still some place slightly different such as heatmap encode part, offset reg encode part, loss func setting

There is no way to know which one performs better yet as most of their results are on kitti which is quite noisy. I do plan to support waymo some time in the future. (though without a timeline yet because I am doing an internship in a different area.)

For further discussions, you can just send me an email.

[tianweiy]

Close for now. In general, this repo means for a general framework of anchor free detection. You can try out different designs and create a pull request if they perform comparably better. We plan to support Waymo in the future.

[tianweiy]

@muzi2045 Waymo is up now which to my knowledge transfers better to the real-world setting