Using robot_localization and navsat_transform_node to transform LIDAR point clouds

Question

Hello everyone,

I have a Velodyne VLP-16 LIDAR and a RTK-GPS Inertial Navigation System mounted on a UAV. GPS/IMU data are processed by third-party software and I import accurate GPS/IMU data into ROS. I plan on using robot_localization and tf to use this data for aligning Velodyne point clouds in the world frame (map).

Here's how I'm trying to merge point clouds from Velodyne LIDAR using the odometry information.

Step 1: navsat_transform_node to convert (lat,lon) to UTM and estimate odometry.

Step 2: ekf_localization_node to estimate nav_msgs/Odometry and extract pose

Step 3: Use pose to find the transform from base_link to odom to merge the velodyne point clouds in the world frame.

Is this the correct approach? If yes, these are my questions:

1. A key challenge I'm facing is regarding the inputs to the navsat_transform_node. Of the three required inputs, I have gps/fix and imu/data coming in. What data do I use for odometry/filtered?

2. An initial EKF instance used by others fuses the IMU data with compass, wheel encoder etc and broadcasts the odometry/filtered. For most applications, the wheel encoder provides displacement information for odometry. However, in my use case, I only have IMU, velocities and heading information. Should I estimate odometry information separately (by integrating velocities etc) and feed that into another EKF instance before Step 1?

3. What is the correct way to use RTK-fixed GPS and filtered IMU information with the robot_localization package?

Thanks!

---

Originally posted by Venkat Ganesh on ROS Answers with karma: 57 on 2016-05-24

Post score: 3

Answer 1

(1) On the wiki tutorial page, it states that you can run an instance of ekf_localization_node. That will output the message type you need. This is the same instance of ekf_localization_node that is taking in the output of navsat_transform_node. Yes, the data path is circular, but necessary: if you drive a robot around inside a building and fuse only IMU and wheel encoder odometry, and then drive outside, you need to know where the robot thought it was so that the transform from lat/long to your world frame is consistent.

(2) Where are you getting velocity information? The filter doesn't take wheel encoder data. It takes twist (velocity) data, which is usually generated from wheel encoders. In any case, yes, fuse all those things into an instance of ekf_localization_node and then pass that in as the third (missing) input from (1) above.

(3) Not sure what you mean here. Try searching for other r_l GPS integration questions, as there are many on ROS Answers, though I admit that the search functionality doesn't always produce the results you'd expect.

---

Originally posted by Tom Moore with karma: 13689 on 2016-06-14

This answer was ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by gvdhoorn on 2016-06-14:
re: searching ROS Answers: what works well for me is to use Google, and add site:answers.ros.org to the query.

Comment by sammas on 2017-07-30:
Did you end up resolving this problem?