Point clouds assembled in map raytrace from origin

[anderwm]

It is likely I am not using your software as intended, but if not this is a legitimate issue. I use laser_assembler to assemble point clouds from the laser source into the map frame. Then I am trying to run an octomap server to take the clouds in and also make the octomap in the map frame. Because the cloud is already transformed to map, your code

insertScan(sensorToWorldTf.getOrigin(), pc_ground, pc_nonground);

thinks sensorToWorldTf.getOrigin() is 0,0,0,0

This results in raytracing each hit in the point cloud from 0,0,0 in the map frame instead of from the actual origin of the scan.

I have to assemble the scans into a fixed frame, but when I do the location of the actual scan isn't used in your insertScan function anymore. How is this problem typically solved?

[ahornung]

The raycasts need an origin and yes, it is assumed to be the origin of the sensor coordinate system. Couldn't you assemble the scans in a local coordinate system and then publish the TF transform into the map frame? That's how nearly all drivers create point cloud data.

Otherwise you need to write a custom node that relies on some custom synchronized message for the sensor origin, since it's not contained in the point cloud. In that node you can then use insertPointCloud(...) of the OctoMap API directly.

[anderwm]

Couldn't you assemble the scans in a local coordinate system and then publish the TF transform into the map frame?

This may be where I am missing something simple, but I have thought about how to do this. The problem is the laser is on a trolly that moves (in x) in the map frame. The laser TF to all other frames except map is a constant value, so the scans assemble on top of each other rather than using the x information present in map.

As a temporary solution I am publishing point clouds in the laser frame, and letting octomap_server put them into the map frame. The caveat is that I have to publish the point clouds very often (before the laser moves an octomap resolution) as all of the scans are assumed by the assembler to be in the same x position. In my case, ideally I would use the laser to map tf at every scan time as the sensor origin...obviously this isn't encoded in the point cloud.

My fundamental concern: If I understood you correctly, an entire point cloud can have only one origin for raycasting. So does this make it impossible to accumulate a point cloud as the laser moves and then correctly apply it to octomap? This would mean I must publish point clouds very often (again at the resolution of octomap), although I'm not sure this is necessarily a problem.

[ahornung]

Ah, so each scan is taken from a fundamentally different origin? I had somehow assumed that this is assembled point cloud data from one location, e.g. from a tilting scanner.

My fundamental concern: If I understood you correctly, an entire point cloud can have only one origin for raycasting. So does this make it impossible to accumulate a point cloud as the laser moves and then correctly apply it to octomap? This would mean I must publish point clouds very often (again at the resolution of octomap), although I'm not sure this is necessarily a problem.

Yes, each single scan of the laser has to be a new point cloud with new TF data if your laser constantly moves while scanning.

If that's a problem, it might be more efficient to write a direct subscriber to laser scan data in OctomapServer.cpp and skip the conversion to and from PointCloud2.

[anderwm]

Ok, thanks for your time. If I need to write the laser to octomap code I will submit it back to you.