[M3RSM] Implementation of basic classes#1
Conversation
|
Tagging @hidmic for awareness. For some reason I can't add reviewers. |
| # configure_file (test_config.h.in ${PROJECT_BINARY_DIR}/include/rndf_gazebo_plugin/test_config.h) | ||
|
|
||
| # Build gtest | ||
| add_library(gtest STATIC gtest/src/gtest-all.cc) |
There was a problem hiding this comment.
@LucasJSch FYI: you don't need all this, ament_add_gtest will take care of everything if used like it is used here.
| } | ||
| karto::MockLookupTable lookup_table(data, 1, 2); | ||
|
|
||
| EXPECT_TRUE(lookup_table.isMaxResolution()); |
There was a problem hiding this comment.
@LucasJSch what's the purpose of this isMaxResolution method?
There was a problem hiding this comment.
This method will be used eventually by the heap entries to determine if to continue the expansion of the search space.
Citing the paper: Each heap entry specifies which point cloud and lookup tables should be used (...). If the associated lookup table isn't the max-resolution one, the entry should expand the search space. If not, it's probably the best pose estimation entry.
There was a problem hiding this comment.
I see. As per f2f chat, this might be redundant with the resolution attribute.
| occupied_cells.emplace_back(std::make_pair(2, 0)); | ||
| occupied_cells.emplace_back(std::make_pair(3, 0)); | ||
|
|
||
| EXPECT_EQ(table.computeCost(occupied_cells), 11); |
There was a problem hiding this comment.
@LucasJSch meta: I take that the current implementation of computeCost is a mock, correct?
There was a problem hiding this comment.
Exactly. Let's talk about this off-thread.
| int kernel_width_; | ||
| }; // class MockLookupTable | ||
|
|
||
| class LookupTableManager { |
There was a problem hiding this comment.
@LucasJSch meta: only to not lose track of our discussion today.
Rasterized image pyramids can be cached (or managed) for a single scan matching request, but it is not clear how and if we can cache these pyramids across scan matching requests. We could simply persist the cache but it is unlikely we'll be given the same set of reference scans often enough for the cache to be worth it. We could cache a pyramid per scan and merge them, but the candidate scan pose (and thus the search window pose) changes over time. It is hard to tell whether we can freely apply translations and rotations to decimated rasterized images or not.
How can we maximize cache hits across scan matching runs? I'll sleep on it.
2 participants
Note
Please ignore the first two commits, they're related purely to structural/compiling purposes. In the future we'll work on doing that in a nice & pretty way.
Changes
The 3rd and last commit addresses the following things:
MockLookupTableandLookupTableManagerand other tentative headers just as a POC. More on these classes below this list.MockLookupTableandLookupTableManager.On mocked/uncomplete classes
MockLookupTableis called like that because it won't be the final version of aLookupTable. We'll start by ignoring the integration withslam_toolbox's codebase to avoid coupling problems. So we'll start directly with rasterized maps and rasterized scans, and work with those entities to make the M3RSM workflow work, as stated in Olson's paper.Once we verify that it works, we'll start integrating our code with
slam_toolbox's. I.e. we'll introduce classes such asLocalizedRangeScanas the input for the lookup tables generation and as the input to generate decimated pointclouds.