Rosanswers logo

I have a wheeled robot with a front mounted SICK laser scanner.

The recent addition of a kinect allows me to use the SICK laser for longer range nav planning and mapping, and the kinect for various 3d stuff.

So, my idea is to convert the kinect point cloud to laser scans at various heights (via pcl). Say for instance my SICK laser is at 8" above the ground. That will not tell me about a curb or some other obstacle that lies just under 8". So, if I were to map the appropriate Z value of the kinect's point cloud data to a new laser scan topic, I could then use it for navigation, and write some code to decide what to do at that Z level. A simple example would be to determine the height of an object that my robot could negotiate based on wheel size, and just slow it down to the appropriate speed. It could also check for height clearance when driving around by creating a laser scan that correlates to the highest Z value of the robot.

I see this being useful for quad copters... it is still not full 3D navigation, but it could allow for some decent object avoidance in the Z dimension by writing some code to determine which Z height has the most clear path.

My question is, is anyone using laser scans at various heights to evaluate navigation at different Z levels? Is the kinect2laser a viable solution, or is there a better way to do this?

I see this as a possible workaround for this problem.

Originally posted by evanmj on ROS Answers with karma: 250 on 2011-02-27

Post score: 5

Original comments

Comment by joq on 2011-03-06:
Have you considered using a Voxel Grid? Costmap2d offers that option.

Comment by KoenBuys on 2011-02-27:
I had the same idea with a master thesis student at our lab (Enea Scioni, also following the list), however he left back to Italy where he's doing a PhD now, perhaps he continued the work. The idea we had is to include Z acquisition information in a map, so that robots could reason how to interpret maps that where acquired by other types of robots. I also think this could be useful to quadrotors as long as you can encode it in a memory optimized way. Now the data coming from the kinect is to large to build full 3D maps on the limited onboard resources.

Comment by Eric Perko on 2011-02-27:
Why convert to laser scans in the first place? Much of the existing navigation stack can use PointClouds for sensory input.


1 Answer 1


Rosanswers logo

The navigation stack will support most of your use case out of the box -- because you have a true long-range laser for localization (which that other problem you reference did not). You might note that this is nearly identical forms of input as the PR2 uses, which has a Hokuyo laser on the base for localization and obstacle avoidance, and a stereo camera rig for additional obstacle avoidance in 3d.

When configuring your robot's launch and parameter files, use only the SICK laser as input to AMCL for localization. Then use both the SICK and the Kinect data as observation sources for the local costmap (see http://www.ros.org/wiki/costmap_2d for details on parameters).

It might also be advisable to setup a voxel_grid to downsample and clean your Kinect data before sending it into the costmap_2d. The pcl_ros contains a nodelet that can do such, so you could configure it entirely in a launch file without any new custom code (see http://www.ros.org/wiki/pcl_ros/Tutorials/VoxelGrid%20filtering for details)

Originally posted by fergs with karma: 13902 on 2011-03-06

This answer was ACCEPTED on the original site

Post score: 6

Original comments

Comment by ctguell on 2013-07-28:
Hi im could you accomplish the navigation using gmapping?? any help would be really apreciated


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.