Aggregating Point Clouds in Fixed Frame

Question

I'm working on a project where I'd like to aggregate/concatenate several filtered point clouds produced by a Kinect into a single point cloud in the fixed (/map) frame. This is not for mapping purposes, so I don't want to explicitly match scans; I would just like to combine several views of the same thing into one point cloud. I am, however, doing mapping simultaneously with a 2D laser scanner in order to correct the odometry.

The basic approach I'm taking is to take the kinect point cloud, transform it from the /openni_depth_frame to the /map frame, process it, and then add it to an aggregate point cloud that is then published to the /map frame. It seems like this would produce a point cloud that is fixed with respect to the map and aligned with the rest of the laser and kinect data. However, this produces a point cloud that is fixed, but not aligned (it's floating above the plane of the map and rotated). On the other hand, if I publish the aggregate cloud to /openni_depth_frame, it is then properly aligned, but moves relative to the map. I suspect that the alignment problem has something to do with the difference in axis alignment conventions between tf and image frames, but I thought I was taking care of that by using the depth frame.

Supposing that you're dealing with odometry independently, what would be the right way to project a bunch of point clouds to the fixed frame and concatenate them? I'd be happy to provide some code if it's unclear what I'm trying to do, but this portion is kinda buried inside a bigger project, and I'd have to take some time to work up a toy example.

Thanks for your thoughts.

-Jeff

---

Originally posted by jeffdelmerico on ROS Answers with karma: 31 on 2012-02-21

Post score: 3

Answer 1

Your approach is correct, but it sounds like you might be using the wrong moving frame, ie /openni_depth_frame instead of /openni_depth_optical_frame.

The best practice is to look up the tf between the fixed frame (/map) and the cloud.header.frame_id of the cloud message you receive. This way, you don't need to hard-code the moving frame id.

---

Originally posted by Ivan Dryanovski with karma: 4954 on 2012-02-21

This answer was ACCEPTED on the original site

Post score: 5

---

Original comments

Comment by jeffdelmerico on 2012-02-22:
Thanks Ivan. That turned out to not be the main issue, but I will adopt these best practices in the future. I must have missed the bit in the tf documentation that transforms are always frame_id to child_frame_id for transformations in either direction, so I was transforming the wrong way. Thanks!