OctoMap with CUDA or OpenCL

[ahmedshafeeq]

I think it'll be cool to have OctoMap implemented in CUDA or OpenCL to speed things up even more.

[aitjellal]

Hi Ahmed is there anything new about Implementing OctoMap
with CUDA/Opencl
Please let me know if you are working on this project

[ahmedshafeeq]

How urgently do you need this feature? If you'd like to work together, I'm willing to commit time on this.

[aitjellal]

Thanks for you reply.
It will be perfect if it implemented within 1 or 2 months.
I am new in programming with opencl and have no experience in programming with CUDA
so I am not sure if I will be very helpful.
But what I can do is that once a first version is released I can enhance it.

[ahmedshafeeq]

Alright let me try to get this out within 2 months.

[aitjellal]

If you can divide the task into some sub-tasks I will be glad to contribute by
making one or two tasks to speed up things.

[ahmedshafeeq]

@aitjellal How about looking at https://github.com/OctoMap/octomap/blob/26dc8e9ab51a51bcd0dd6297f20d11a127a7076b/octomap/include/octomap/OccupancyOcTreeBase.hxx and re-writing what you can using only the functions in http://www.cplusplus.com/reference/algorithm/

The parts that can be re-written functionally are the easiest to speed up.

[ahmedshafeeq]

I'll move to them to CUDA after.

[aitjellal]

Ok I will work on it in my free time

[ahmedshafeeq]

The thrust library has implemented efficient parallel versions of the algorithms in http://www.cplusplus.com/reference/algorithm/. Check thrust out here: https://github.com/thrust/thrust. In those cases that thrust has no equivalent function, I can implement them myself. The nature of the functions in the algorithm header file make it easy for one to parallelize as they tend to be very declarative in nature rather than imperative.

[Squelsh]

Hey guys!

I am the maintainer of the GPU-Voxels lib, which is a kind of improved Octomap for the GPU and which also handles real time collision detection.
Have a look at the website www.gpu-voxels.org.
There you can also find my 80-slides-presentation from a Workshop on the lib that we gave on the IAS conference in Padua 3 weeks ago. Our lib will go OpenSource on github within the next days / few weeks.

My intention once was to offer the same API as Octomap but we did not put that too high on our feature list, as our main intention is Collision Detection with real time 3D maps. But if you like, we could join forces and come up with a wrapper or API enhancement, so that people could easily switch and use the computational power of GPUs... (Just to get an idea: The insertion of Kinect data into a TITAN-GPU Octree is about 100 times faster than into Octomap on a high end Intel machine, including raytracing for free space calculation).

Best,
Andreas

[aitjellal]

Hi Andreas,
thank you for this valuable information.
I think it is a good idea to colaborate to come up with a wrapper or API enhancement for the GPU-voxels.
cheers

[ahmedshafeeq]

Hi Andreas,

What's stopping me at this point is access to a Linux-based GPU machine. Would you be able to provide access to one? I'd be able to put in time for this if I had access.

On 21 Aug, 2014, at 7:35 PM, "Andreas H." [email protected] wrote:

Hey guys!

I am the maintainer of the GPU-Voxels lib, which is a kind of improved Octomap for the GPU and which also handles real time collision detection.
Have a look at the website www.gpu-voxels.org.
There you can also find my 80-slides-presentation from a Workshop on the lib that we gave on the IAS conference in Padua 3 weeks ago. Our lib will go OpenSource on github within the next days / few weeks.

My intention once was to offer the same API as Octomap but we did not put that too high on our feature list, as our main intention is Collision Detection with real time 3D maps. But if you like, we could join forces and come up with a wrapper or API enhancement, so that people could easily switch and use the computational power of GPUs... (Just to get an idea: The insertion of Kinect data into a TITAN-GPU Octree is about 100 times faster than into Octomap on a high end Intel machine, including raytracing for free space calculation).

Best,
Andreas

�
Reply to this email directly or view it on GitHub.

[Squelsh]

I would recommend, that we wait until I get a version to github, so you could have a look at the code.
@ahmedshafeeq: Sorry, but our company policies do not allow VPN access for non company members. So no remote access.

[ahornung]

👍 Great to see this level of collaboration here, keep it up and let me know if there are any open questions!

[yincanben]

Have you implemented in CUDA or OpenCL to speed OctoMap ?

[Squelsh]

The GPU-Voxels Library is written in CUDA.
But up to now there is no integration between Octomap and GPU-Voxels.
A common interface is still on the wish list.

Am 13.12.2014 um 13:39 schrieb yincanben [email protected]:

Have you implemented in CUDA or OpenCL to speed OctoMap ?

—
Reply to this email directly or view it on GitHub.

[Dr-LingyunXu]

Is there any new progress in Octomap and CUDA combination ?

[Squelsh]

Nope. But if you don't have to put complex datatypes into your octree nodes, just download GPU-Voxels and have a try.

[Squelsh]

I just spent some time in investigating the OctoMap API and the collision check implementation of FCL that collides URDF-models with an Octree.

Long story short: The approaches are so different, that this can not be solved by intelligent wrapping / interfacing.

Longer version: FCL works with a Bounding Volume Hierarchy (a space dividing tree structure) and recursively iterates over models to lookup Voxels in the Octomap selectively. On the other side, GPU-Voxels uses an articulated pointcloud-representation as robot model and collides this with our own Octree implementation. This is done in a highly parallel manner, so we don't need a BVH.

So, when someone needs a collision check between a URDF-Robot and a live pointcloud, GPU-Voxels is magnitudes faster than OctoMap, as we can update our GPU-Octree with the data of several Kinects at full framerate AND do collision checking in parallel.
But as soon as you need a templated Octree with your own Voxel-DataTypes, use OctoMap.

Unfortunately I don't see a way to integrate this into MoveIt / FCL in a straight forward manner. So we stick with our own planners.

Regarding an OctoMap compatible API the insertion of Pointclouds is no problem, but it makes absolutely no sense to query single coordinates / voxels in GPU-Voxels in a serial fashion, as it is done with OctoMap. We can query whole pointclouds with a single call in a millisecond but serialization would nevertheless destroy performance.

[ahornung]

Thanks for the detailed clarification, Andreas. I'm closing this issue for now.