Merging ProcessorTrackerLandmark and ProcessorTrackerFeature?

Created by: joanvallve

As we designed the ProcessorTracker inheritance, there are two different cases: landmarks and features:

• Landmark: The search is done in the map (landmarks), so it is able to close loops but it is not actually tracking so big effort on projecting landmarks in the measurement space.
• Features: The search is done in the last capture features, so it isn't able to close loops. But it is faster since few candidates and may not require projecting the covariances..

In my opinion it is a suboptimal approach. We can take profit of both advantages by implementing a mix of both right?

The landmark processor could be tracking the features instead of projecting all landmarks and the feature processor need for some loop closure mechanism..

Created by: artivis

The problem is that it is difficult to define a generic work-flow for a tracker as the issue of what should be tracked and how can be tackled in many different ways... Maybe there should be tracker specializations based on the 'how to track what' approach rather than features/landmarks. E.g track features in subset of the map - track landmarks as long as they are observed.

Created by: AtDinesh

The main problem that you are mentioning with landmark is that we currently project all the landmarks of the map right ? But just as @artivis commented it is possible to define subset of maps to optimize this. (or "local maps"). This is already used in other SLAM libraries by taking profit of a covisibility graph. (Covisibility-based Map Learning Method for Mobile Robots) may interest you ! It might be something we will have to work on in the future.

Here are other papers using this method I think : H. Strasdat, A. J. Davison, J. M. M. Montiel, and K. Konolige. Double window optimisation for constant time visual SLAM. In IEEE International Conference on Computer Vision (ICCV), 2011.

D. G´ alvez-L´ opez and J. D. Tard´ os. Bags of binary words for fast place recognition in image sequences. IEEE Transactions on Robotics, 28(5):1188–1197, 2012.

Elena Stumm, Christopher Mei, Simon Lacroix ,Probabilistic place recognition with covisibility maps, Intelligent Robots and Systems (IROS), 2013 IEEE/RSJ International Conference on, 4158-4163

Created by: joanvallve

Yesterday, we were informally talking with @joansola about that...

There are two different functionalities actually: tracking/local loops and loop closure.

For each one of those, an specific implementation must be implemented. I think I mixed both functionalities in previous comments.

1. Tracking/local loops: Matching with landmarks that were seen "recently" (in time) or from a frame "close" to the current (in graph distance). It implies that the landmark can be searched in its projection "surroundings" since the error of the projection is not "too" big. This process should be fast so, tracking features, covisibility graph or the local maps (or all of them) help to reduce the match candidates and the cost of the matching check (maybe ther is no need to project covariances, for instance).

2. Loop closure: Matching with landmarks that were seen from a frame "far" from the current (in graph distance). The problem in this case is that the accumulated error in "large" loops is "huge", so false positives are quite more possible. However, this process doesn't need to be that fast. This process is actually a place recognition like the one that @artivis has implemented or the ones you point.

So, I would think in an architecture that allows having different data association algorithms.

Created by: artivis

@AtDinesh as for now the landmark tracker tries to match the current features against the whole map. This fact led to the first point of @joanvallve we need a smarter way to retrieve a 'relevant' map-subset. I quote 'relevant' since it means different things for different use-case, different sensors etc. See @joansola comment in #94. As for the second point, large loop closure, I have been working on the bag-of-words method with both laser-scan and rgb camera. As the software is already developed, this could be a first try at having a 'loop-closure processor'. Again we have to think ahead and integrate it in a 'processor-like' manner so that it can be 'easily' replaced by something else.

Now just to mention that Elena Stumm has some more recent and interesting work : E. Stumm, C. Mei, S. Lacroix, J. Nieto, M. Hutter, R. Siegwart," Robust Visual Place Recognition with Graph Kernels," in Conference on Computer Vision and Pattern Recognition (CVPR), 2016.

added Code organization label

I am currently implementing a processor tracker of features polylines in a set up working with landmarks. I inherited from ProcessorTrackerFeature but I had to overload some functions, I think some of them can be generalized in order to have a ProcessorTrackerFeatureLandmark meaning that it tracks features but the constraints are established with landmarks.

I hope someday I'll have enough time to create this abstract class to be also inherited in vision, for instance.

added Idea label and removed Code organization label