Octomap slows down with increase in map size

asked 2015-12-19 01:48:12 -0500

I'm trying to use octomap with a velodyne HDL-32E sensors point cloud. I move around in a large complex (Approx 1 km by 1 km) and generate the map. The map update rate is really good when the total map size is small (I can see moving cars and people being classified into obstacles), but as the map size increases, the update rate slows quite a lot. Can someone suggest me ways to overcome this problem? I'm currently considering just running the map in the local frame to get immediate obstacles, but this will defeat the purpose (global planning) for which I had switched to octomap.

edit retag flag offensive close merge delete

Comments

This obstacle detection of people and cars is running separately? Are you sure it is the Octomap update that's the bottleneck?

2ROS0 ( 2015-12-19 23:40:32 -0500 )edit

I meant those as examples to illustrate that moving obstacles are detected nearly instantly at the beginning but not at the end. Static fixtures such as walls and trees etc are detected properly all the way to the end but the updates get slower and slower with the increase in map size.

raskolnikov_reborn ( 2015-12-21 05:03:37 -0500 )edit

I can confirm that the problem is related to map size more than time of operation. If is create a local window map without a global frame that is both map and base frame are the sensor, the problem is greatly reduced. With a finite map size, octomap updates do not get slower over time.

raskolnikov_reborn ( 2015-12-25 00:50:51 -0500 )edit

I am trying to use octomap to create a 3D map form point clouds input in Pointcloud2 format. I have built the libraries. But, when I launch the octomap_mapping.launch file, I see no output in RVIZ in /map. Since, you have got it working, may I know the procedure to use this library?

krishnaece1505 ( 2016-03-01 07:02:14 -0500 )edit

I was told that octomap is used to create a map from already registered point clouds (or a set of point clouds and transforms). I haven't found a good way to register point clouds from a velodyne lidar (VLP-16 in my case). Can you please share how you are able to register point clouds?

chukcha2 ( 2016-03-02 16:07:09 -0500 )edit

Just start publishing a transform between your laser frame and your global frame. specify the sensor frame in the launch file and the global frame and you should be done. Make sure you provide the pointcloud in the sensor frame if you enable ground filtering otherwise you get out of range errors.

raskolnikov_reborn ( 2016-04-19 07:32:29 -0500 )edit

Thanks, but what I am asking is how to get that transform (between laser frame and global frame). What method are you using? Thanks.

chukcha2 ( 2016-04-19 10:31:19 -0500 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2016-04-20 01:31:17 -0500

Stefan Kohlbrecher

24361 ●173 ●299 ●444 https://www.energy-rob...

I would expect that map updates themselves do not slow down over time, as the computation of the voxels to "touch"/modify should take similar average computation time no matter where in the octomap the sensor is placed. Of course, if the average distance of range measurements increases over the course of your datasets, an increase in processing time is to be expected as the raytracing takes longer then. Of course, there are other factors at play that might have adverse effects, like allocation and placement of voxel information in memory.

What definitely takes longer the larger the map grows is iterating over all cells, for instance for visualization purposes. Are you possibly doing that somewhere in your code? If you are using the standard octomap_server , the publishAll() method is called after every map update. This method iterates over all cells, so it would explain a slow-down with increasing map size nicely.

edit flag offensive delete link

Comments

Thanks. That may be it. I sort of worked around the issue by only using a local map to navigate obstacles and clearing everything outside a bounding box every second. But Maybe If I could just get the map server to publish changes in cell state rather than all the cells, it'll be faster.

raskolnikov_reborn ( 2016-04-20 02:05:29 -0500 )edit

Hi. In line with my earlier comment. Is there a way I can configure octomap_server to not publish/iterate the entire map again and only publish the updates.

raskolnikov_reborn ( 2016-04-22 01:06:56 -0500 )edit

I don't think so, but you could easily fork it and then do whatever you want. Alternatively, you could use the octomap library in your own node and this way have full control over what happens.

Stefan Kohlbrecher ( 2016-04-22 01:54:51 -0500 )edit

add a comment

answered 2016-04-20 00:46:55 -0500

raskolnikov_reborn
53 ●2 ●5 ●9

I get the GPS/INS position in lat, long, alt, roll, pitch, yaw. Compute the utm odometry using the gps_common package. so I now have the value in meters (x,y,z,roll,pitch,yaw). Then publish a transform using this position. Look at the code below for reference

    void poseCallback(const gps_common::GPSFixConstPtr& msg){


  static tf::TransformBroadcaster br;
  tf::Transform transform;
  double x,y;
  std::string zone;
  gps_common::LLtoUTM(msg->latitude, msg->longitude, northing, easting, zone);

  transform.setOrigin(tf::Vector3( (easting), (northing),  0.0));
  tf::Quaternion q;
  q.setRPY(msg->roll ,msg->pitch, msg->track );
  transform.setRotation(q);
  br.sendTransform(tf::StampedTransform(transform, ros::Time::now(), "world", "vehicle"));

  publish_map_tf(msg);
}

I also publish a static transform between the vehicle and the velodyne frame which is the x,y,z translation and r,p,y rotation between the co-ordinate frame of the GPS/INS and the Laser Sensor. Hope that helps

edit flag offensive delete link

add a comment

Octomap slows down with increase in map size

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

Octomap slows down with increase in map size edit

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

Octomap slows down with increase in map size