nettercm's profile - activity

@Mork the source code is here: link text It works but it did not improve the performance of mapping and localization a

Updated answer: I think what I'm looking for is LaserProjection::transformLaserScanToPointCloud() from the laser_geometr

So I looked at the laser_assembler package. I ran the provided example but it did not seem to do any correction. Maybe

Are you trying to do something similar as I am? https://answers.ros.org/question/242658/how-to-deal-with-slow-rplidar-s

I updated my answer to add an image that shows the output of my own solution. Its not bad. Still some minor issues / s

So I have asked this question about 3.5 years ago. I think the answer is "No, ROS will not perform any kind of motion

So I have asked this question about 3.5 years ago. I think the answer is "No, ROS will not perform any kind of motion

Thanks! I figured that there had to be something like this. I recall having looked at some other packages in the lase

Thanks. Apologies for my imprecise language. What I meant, and should have asked of course, is "Is there a ROS compone

So I have asked this question about 3.5 years ago. I think the answer is "No, ROS will not perform any kind of motion

I'm relatively new to ROS, but I'm not new to Robotics.

I'm trying to understand if and how hector_slam, gmapping and similar packages that are typically used for mapping and/or localization, deal with the following:

Suppose the robot moves at 1m/sec. Suppose the Lidar is completing a 360deg scan at a rate of 5Hz, i.e. it takes 0.2sec for one full scan.

In the time it takes for one scan to complete, the robot will have moved as much as 0.2meters (around 8 inches) if it is going straight at full speed. A similar statement can be made about rotation.

Are the ROS components that consume laser scan messages simply assuming that the robot has not moved during the time it took to complete a scan?

Or is there some logic somewhere that does some sort of motion compensation.

Before I started working with ROS and RPLidar, I was in the process of putting the various pieces together "from scratch". For example I was using parts of the MRPT, specifically ICP, to localize the robot within an existing map / occupancy grid. Also, this occupancy grid was created by simply updating the gird cell after doing all the necessary calculations to map each laser reading into the what's called the "ocometry frame" in ROS speak. I was using the XV-11 laser sensor, instead of RPLidar, but its the same thing at the end of the day...

In order to build up this occupancy grid while the robot is in motion, I found it to be necessary to use odometry information and transform the incoming laser scan information in such a manner that it effectively is "motion compensated".

Is the equivalent of this "motion compensation" happening in ROS anywhere is what I'm asking I guess. Or is the problem simply getting ignored, because most people are using laser scanners with a scan rate that is 10x that of RPLidar?

Thanks.