NVlabs/FocalFormer3D

I would like to know whether the midpoint of your BEV feature map is the center point of the ego vehicle coordinate system when you embed Lidar features into the BEV space.

Zoewayho opened this issue · 5 comments

First of all, thanks for your excellent work, now I am trying some other experiments based on your work, but whenever I try to map the ground truth boxes in my ego vehicle coordinate system to the BEV space, they always mismatch with the feature map. I have been using the midpoint of the feature map as the origin for the coordinate transformation in the ego vehicle coordinate system. I would like to know if this is correct.

Hi, thanks for your interest! The BEV feature point mapped back to LiDAR coordinate relies on the transformation in the box_coder (basically it is a normalization). You can refer to the coding of my previous ablation option in this line that maps the bev_pos back to LiDAR coordinate system. (

temp_bev_pos = self.bbox_coder.decode_center(bev_pos.transpose(1,2)) # bev points
)

whhen you encode your box to BEB feature map, You didn't take into account the change in coordinate system orientation, is that a potential problem? Or are the world coordinate system and the feature map coordinate system in the same direction?

In my view, the feature map is trained with rotation augmentation. For example, if the input point clouds is rotated, the predicted boxes should be rotated too despite the anchor boxes remain the same.

I mean,


when encode the box to bev feature map, I should neglect the difference between ego coordinate and BEV coordinate?won't it cause errors in my coordinate mapping in bev space?

Target boxes and point clouds are already jointly rotated in the data loader. As the feature maps are from the point clouds, the feature maps are in the same coordinate system with point clouds. Also, the anchor boxes are fixed all the time.