NanoMap: A GPU-Accelerated OpenVDB-Based Mapping and Simulation Package for Robotic Agents
Round 1
Reviewer 1 Report
The paper needs proof reading and the paper’s formatting needs improvement. The below are some examples:
General notes
---------------------------
In the abstract, onboard CPUs, onboard GPUs-à onboard CPUs, on the other hand, onboard GPUs.
Check line 81, the sentence “Section II…” should be on line 80.
Tables’ captions should be in the top of the table
On line 305: I suggest either putting the link of the video as a footnote or add it to the reference.
Why the figures captions are all have initial capital words? I suggest making them all initial small letters
Technical notes
Line 331: can you please explain more these limitations
To show the advantages of the proposed mapping
e.g. create a comparison table to show the pros and cons of the proposed system and compare it with the other systems (e.g. compare it with the Octomap, NanoMap CPU and the Discretized Octomap)
In the abstract, the author described the proposed system as a probabilistic mapping solution. However, it is not clear to me, how the proposed mapping system in a probabilistic one?
Author Response
The paper needs proof reading and the paper’s formatting needs improvement. The below are some examples:
General notes
---------------------------
In the abstract, onboard CPUs, onboard GPUs-à onboard CPUs, on the other hand, onboard GPUs.
Changed to:
However, while many modern robotic agents are still relatively limited by the power of onboard central processing units (CPUs), many platforms are gaining access to onboard graphics processing units (GPUs) and these resources remain underutilised with respect to the problem of occupancy mapping.
Check line 81, the sentence “Section II…” should be on line 80.
Corrected
Tables’ captions should be in the top of the table
Corrected
On line 305: I suggest either putting the link of the video as a footnote or add it to the reference.
Corrected
Why the figures captions are all have initial capital words? I suggest making them all initial small letters
Corrected
Technical notes
Line 331: can you please explain more these limitations
Added:
The age of the GPU architecture of the Jetson Nano means some CUDA features, data structures, and operations are not readily available and so not all NanoMap methods are usable on the platform. Additionally, the limited memory of the platform means running Filter Mode 0 of NanoMap at 0.01m grid resolution would crash the system.
To show the advantages of the proposed mapping
e.g. create a comparison table to show the pros and cons of the proposed system and compare it with the other systems (e.g. compare it with the Octomap, NanoMap CPU and the Discretized Octomap)
I am unsure how to create a useful comparison table that isn’t huge and covers all possible settings, especially because performance differentials change depending on the system hardware and grid resolution. The main downside is requiring a CUDA capable GPU, and consuming more memory than OctoMap, how much the system beats Octomap and the actual memory used, is up to the system configuration, which discretization/voxelisation filter is used on the input, and the settings used (map resolution, range of sensor etc).
In the abstract, the author described the proposed system as a probabilistic mapping solution. However, it is not clear to me, how the proposed mapping system in a probabilistic one?
The software uses a log-odds style probabilistic update method for determining cell occupancy in much the same way that Octomap and many other occupancy mapping algorithms use, this is why this particular detail was not elaborated upon.
Changed part of the mapping explanation to:
Meaning that the range for cell updates is limited to between -1.28 and 1.27 during a single update. Because NanoMap uses a log-odds style update similar to OctoMap and other probabilistic mapping techniques the slight loss in precision is acceptable. Values in the occupancy grid are capped between -0.87 and 1.5, allowing relatively large updates to still be made to each voxel at each time step.
To help explain the use of “probabilistic” within the abstract and elsewhere in the paper.
I hope these changes and comments are satisfactory, thank you for taking the time to review the work and provide feedback.
Author Response File: 
Author Response.pdf
Reviewer 2 Report
The authors present an interesting method for reducing the size and accelerating the dense cloud processing. The method has been tested in both simulation and on real-platforms, showing the performance of the proposed scheme.
The reviewer has the following comments:
- Please define the abréviations when they first appear in the text (VDB, GPU, CUDA, etc…)
- As a general comment, a big part of the paper reads as a thesis chapter than a journal paper, even though this provides useful information, but it does not contribute to the what the authors have to provide with their work. In Addition to that, the methods described are well known, thus there is no need to explain them in the paper. This should be reduced.
- How do you obtain the exact pose of the sensor?
- Line 176: unclear sentence
- On the evaluation section, tables 3 and 4 does not provide the difference between the Jetson nano and the laptop, this hinders from evaluating the difference of the NanoMap performance on both platforms. (It is confusing, the results should be shown on the same A-B type figures)
Author Response
The authors present an interesting method for reducing the size and accelerating the dense cloud processing. The method has been tested in both simulation and on real-platforms, showing the performance of the proposed scheme.
The reviewer has the following comments:
- Please define the abréviations when they first appear in the text (VDB, GPU, CUDA, etc…)
This has been corrected in the abstract and main text, VDB however does not actually stand for anything, it is just the name of the data structure.
- As a general comment, a big part of the paper reads as a thesis chapter than a journal paper, even though this provides useful information, but it does not contribute to the what the authors have to provide with their work. In Addition to that, the methods described are well known, thus there is no need to explain them in the paper. This should be reduced.
This is because this work is a chapter in a thesis by publication, which is why it tends to err on the side of being a little too verbose. I am unsure how to correct this without a complete re-edit.
- How do you obtain the exact pose of the sensor?
For the cases provided in this paper exact pose is assumed. During operation some form of pose could be provided via another subsystem or software library. Future work may investigate integrating some SLAM algorithms into the library, so an additional software component is not necessary.
- Line 176: unclear sentence
Changed:
With it having been established that on traditional systems with separate GPU and System Memory sparse NanoVDB grids are read-only, how does NanoMap accelerate the mapping process?
To:
Given that sparse NanoVDB grids objects are read-only on traditional systems with discrete GPUs, how does NanoMap accelerate the mapping process?
- On the evaluation section, tables 3 and 4 does not provide the difference between the Jetson nano and the laptop, this hinders from evaluating the difference of the NanoMap performance on both platforms. (It is confusing, the results should be shown on the same A-B type figures)
The memory consumption of the algorithm is relatively stable between the platforms, given that on both platforms the same type and number of data structures are instantiated and used, which is why a comparison of the memory consumption between the platforms wasn’t made. It doesn’t meaningfully change.
Additionally, comparing the performance directly between the laptop and the nano platforms wasn’t considered necessary, because the hardware available changes the performance drastically. The main purpose of benchmarking was comparing the performance between octomap and nanomap. Benchmarking was performed on two separate platforms with different capabilities to demonstrate the kinds of performance one can expect with different levels of CPU or GPU hardware for either algorithm.
I hope these changes and comments are satisfactory, thank you for taking the time to review the work and provide feedback.
Author Response File: Author Response.pdf
Reviewer 3 Report
The paper addresses the common 3D mapping problem in modern mobile robotics and proposes a faster solution when generating 3D occupancy grids compared to e.g. octomaps. Here the authors developed a new solution which generates a 3D occupancy representation in a shorter amount of time. The background of the algorithm based on OpenVDB data structures is clearly explained and evaluated.
The algorithm is mostly about memory management in order to reduce processing time. The scientific contribution is not too high but for field robotics where small, lightweight GPU based embedded systems (e.g. Jetson Nano) are often used - in order to reduce power consumption or minimize payload for UAVs or small rovers - the approach is really beneficial.
The authors compare the performance of NanoMap using simulated VLP16 data. As an improvement - which is not necessarily needed but would increase the overall interest to readers - the algorithm could be evaluated with dense 3D LiDAR data from a real scenario with reasonable range values, not reducing the data to just 5m. If the authors could provide some more info regarding a real-world use case, the impact of the paper and the significance would certainly increase.
Perfect and comprehensive language - a pleasure to read.
Author Response
The paper addresses the common 3D mapping problem in modern mobile robotics and proposes a faster solution when generating 3D occupancy grids compared to e.g. octomaps. Here the authors developed a new solution which generates a 3D occupancy representation in a shorter amount of time. The background of the algorithm based on OpenVDB data structures is clearly explained and evaluated.
The algorithm is mostly about memory management in order to reduce processing time. The scientific contribution is not too high but for field robotics where small, lightweight GPU based embedded systems (e.g. Jetson Nano) are often used - in order to reduce power consumption or minimize payload for UAVs or small rovers - the approach is really beneficial.
The authors compare the performance of NanoMap using simulated VLP16 data. As an improvement - which is not necessarily needed but would increase the overall interest to readers - the algorithm could be evaluated with dense 3D LiDAR data from a real scenario with reasonable range values, not reducing the data to just 5m. If the authors could provide some more info regarding a real-world use case, the impact of the paper and the significance would certainly increase.
Perfect and comprehensive language - a pleasure to read.
Response:
Thank you for the favorable review and for taking the time to provide feedback.
Unfortunately time does not permit benchmarking a real LIDAR dataset. The LIDAR component of benchmarking was simulated primarily because LIDAR datasets with ground truth were not readily accessible. Additionally, because the performance gains of the library are primarily for dense depth camera style sensors the focus was on their performance. This is also the reason why the benchmarking of the real dataset was capped at 5m, because the sensor being used in the dataset was a depth camera only reliable to 5m. In the case of the simulated VLP16 benchmarks that were performed, the sensor was benchmarked at 5m, 10m, and 20m lidar range, not just 5m.
The real-world application is primarily for reducing the cost of processing dense point clouds produced by stereo or RGBD camera style sensors commonly found on edge robotics and UAVs.
Author Response File: Author Response.pdf
Round 2
Reviewer 1 Report
The authors addressed my comments.
