Skip to content
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

Axis definitions #9

Open
bmankirLinker opened this issue Aug 10, 2019 · 14 comments
Open

Axis definitions #9

bmankirLinker opened this issue Aug 10, 2019 · 14 comments

Comments

@bmankirLinker
Copy link

I'm trying to transform the dataset to KITTI format, but I think the export_to_KITTI file is not updated so I've made some modifications but the axis transformation part is more complicated.
Are the axis definition is the same as in NuScenes, such that for KITTI transformation we can apply kitti_to_nu_lidar = Quaternion(axis=(0, 0, 1), angle=np.pi / 2) ?

@bmankirLinker
Copy link
Author

For anyone who's interested in transformation, can update the line as below if wanna convert KITTI format.
kitti_to_nu_lidar = Quaternion(axis=(0, 0, 1), angle=np.pi)

@gakkiri
Copy link

gakkiri commented Sep 21, 2019

Thank you so much for pointing this out. I am also doing the kitti format conversion. Is there anything else I should pay attention to?
I replaced most of the self.nusc class in export_kitti.py with class provided by lyft. Does this work?

Edit: I found that the center provided by get-box in the two SDK is different, so I replaced it.

@Tai-Wang
Copy link

So do your experiments show that the LiDAR axis definition in lyft data is "x-back, y-right, z-up"? @bmankirLinker

@bmankirLinker
Copy link
Author

That transformation definition makes the https://github.com/nutonomy/nuscenes-devkit/blob/master/python-sdk/nuscenes/scripts/export_kitti.py#L153 assertion pass. However after converting the PCD and GTs accordingly, GT and the image don't match. And also training with PRCNN also gives bad results, unlike NuScenes. So apparently I'm missing some stuff as well but unfortunately, hope an update will come.

@gakkiri
Copy link

gakkiri commented Sep 23, 2019

Oh, I can comment an assertion without modifying the axis definition, which seems to get the correct visualization, use the render module in the script. @bmankirLinker

@Tai-Wang
Copy link

Maybe some functions are not affected by its axis definition, but we are indeed encountered bugs when inferencing orientations of objects by using some models adapted from NuScenes/KITTI. BTW, @joinssmith do you know the clear definition of LiDAR in Lyft dataset?

@gakkiri
Copy link

gakkiri commented Sep 23, 2019

@Tai-Wang Sorry, I don't know.

@bmankirLinker
Copy link
Author

@joinssmith so you've used the same transformation as in NuScenes, but also updated z of cuboid GT based on definition?

@Tai-Wang
Copy link

All right, hope an update...Thanks all the same~

@pyaf
Copy link

pyaf commented Sep 25, 2019

Just found out:

KITTI lidar frame is 90 degrees rotated from nuScenes lidar frame

here
So, kitti_to_nu_lidar = Quaternion(axis=(0, 0, 1), angle=np.pi / 2) makes sense.

@pyaf
Copy link

pyaf commented Oct 12, 2019

I can confirm two things:

  1. kitti_to_nu_lidar = Quaternion(axis=(0, 0, 1), angle=np.pi / 2) and with no assert (velo_to_cam_rot.round(0) == np.array([[0, -1, 0], [0, 0, -1], [1, 0, 0]])).all() gives perfectly transformed boxes in KITTI format but 90 degrees rotated x-y axes.

  2. kitti_to_nu_lidar = Quaternion(axis=(0, 0, 1), angle=np.pi) and with assert (velo_to_cam_rot.round(0) == np.array([[0, -1, 0], [0, 0, -1], [1, 0, 0]])).all()gives perfectly aligned axes, but 90 degrees horizontally-off boxes.

@pyaf
Copy link

pyaf commented Oct 12, 2019

@joinssmith

Edit: I found that the center provided by get-box in the two SDK is different, so I replaced it.

Could you please tell me what exactly is different in them?

@gakkiri
Copy link

gakkiri commented Oct 12, 2019

@pyaf Sorry for my belated clarification. I ignored the transformation of the coordinate system at that time, and in fact the BOX given is the same. I'm sorry very much.

@pyaf
Copy link

pyaf commented Oct 12, 2019

@joinssmith there's nothing to be sorry about :)

The thing is if we could swap x and y axes, we'd be able to fix this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants