Feature/lifelong compression

[kmilo7204]

Basic info

Information-Theoretic compression of Pose Graphs for Laser-Based SLAM.

Description of contribution in a few bullet points

• Added theoretic information functionality to find the laser range scan (In a set of laser range scans) which provides the less map's information.
• Documents

• Follow this link to access the Thesis document.
• Follow this link to access the paper.

Future work that may be required in bullet points

• Data structures and function improvements.

Current state

• Code refactoring
• Tests
• SLAM toolbox modifications

[hidmic]

@kmilo7204 I have the impression this is targeting the wrong branch -- quite a few commits in there are not yours.

[hidmic]

First pass @kmilo7204 !

[kmilo7204]

From my last discussion with @hidmic.

I am sharing a brief analysis of the Algorithm 1, this is my interpretation of it. From my POV the algorithm is confusing at some point, specially in the calculation of probabilities (Even when equation are really clear there), but based on the number of calculations I ended up with the right values to calculate.

I made calculations for two observations (Not with numbers but keeping the variable representation), you can find it in the attached document.

Algorithm 1 analysis.pdf

I will be moving from this point now.

[nahueespinosa]

@kmilo7204 Thanks for the analysis!

I need to clarify something. My interpretation would be the following:

Let's say that after applying Algorithm 1 to a set of 3 measurements, one possible outcome z' is 2 free, 1 not observed with 15% chance.

In order to compute the entropy of C given that particular outcome we would do:

And we would need to repeat that for every possible outcome in the resulting hashtable from Algorithm 1 to obtain the mutual information.

[kmilo7204]

@nahueespinosa

You are right about the clarification. I will correct the document so it is available for all of us!

Thanks for the clarification and comments!

[hidmic]

Quick partial pass (as I see the old approach is still here).

[kmilo7204]

@hidmic
I think the core functionality is ready for review. I am almost done with the test (still figuring out something), but I think we have a good amount of code to review.

[hidmic]

Nth pass :) Besides some oddities in the way the code is written, first impressions suggest it is correct. Did performance improve @kmilo7204 ?

[hidmic]

@kmilo7204 meta: I wonder, quite a few functions take segments and bounding boxes as a pair of 2D points (endpoints and corners, respectively). Why not adding Segment2 and Box2 structs for improved readability?

[kmilo7204]

Thanks for this suggestion.

From my perspective it is only worth the implementation of Segment2, because this kind of data structure is used a lot within this code. It was defined as a template structure in utils.hpp as shown next:

    template<typename T>
    struct Segment2
    {
        karto::Vector2<T> start;
        karto::Vector2<T> end;
    };

Regarding the Box2 I decided to not implement that structure for two reasons.

1. It is used only a couple of times, to pass the cell corners to find the intersection points between a laser beam and the current cell.
2. Sometimes and depending on the where the cell is located WRO the laser beam origin we need to modify the corners. So I found that it might be confusing to handle the changes with the Box2 structure. Please consider the following structure definition (Maybe the naming convention is what seems confusing for me):

    template<typename T>
    struct Box2
    {
        karto::Vector2<T> bl; // bottom left
        karto::Vector2<T> br; // bottom right
        karto::Vector2<T> tl; // top left
        karto::Vector2<T> tr; // top right
    };

I will leave this thread open!

[hidmic]

@kmilo7204 hmm, I don't follow why Box2 definition requires coordinates for each corner. Unless It's a four sided polygon, coordinates for two corners along a diagonal should always suffice.

[kmilo7204]

Nth pass :) Besides some oddities in the way the code is written, first impressions suggest it is correct. Did performance improve @kmilo7204 ?

@hidmic Yes performance improved a lot. Prior to this iteration we were calculating the mutual information for 7 scans (At max), now we are processing 19 or 20 scans and obtaining the same time.

This is a decent number for this calculations, but I think we can improve it a little bit more.

[hidmic]

@kmilo7204 what happened here? How far are we with this?