Return submap ids in InsertionResult along with pointers#1413
Conversation
bfb64fc to
86d71fd
Compare
86d71fd to
f0b2f1c
Compare
11b8b53 to
b757831
Compare
|
Ping? |
|
@pifon2a since we're on a roll, if I could choose a PR review to get as a Christmas present :), it would be this one. I have encountered multiple times so far a need to know which submaps exactly changed with a recent insertion, and I think this would be a really useful extension of the API. |
|
@ojura nice try :). PR review is not really a good Christmas present. I hope you get a normal present instead. Merry Christmas! |
|
Damn :) Merry Christmas and happy new year to y'all as well! |
|
Another month has passed, so here's another friendly ping for this PR. |
|
@ojura Are you still interested in getting this merged? If so, please let me know and I will review. Also, it seems this PR is doing two completely separate things. Would it be possible to split off the |
|
Hi @wohe. One application is vertex coloring of scan matched point clouds according to the inserted submap ID (e.g. of the older one from the insertion pair). If you use that golden ratio HSV scheme, I think it’s a nice way to provide false coloring for checking the cloud quality. Sure, I can split the PR. |
|
@wohe here's a picture of coloring by submap ID: |
Related to cartographer-project#1413. Signed-off-by: Wolfgang Hess <whess@lyft.com>
Related to #1413. Signed-off-by: Wolfgang Hess <whess@lyft.com>

Returning just submap pointers in
InsertionResultis not very useful for libcartographer users. You can't really tell which submap IDs changed when insertion happened. Therefore, have the pose graph return the assigned submap IDs just like it does for the inserted node ID.Also, move
GetSubmapDatato the pose graph interface, so the user can query the pose graph just for these submap IDs (instead of having to useGetAllSubmapData).