Vision utils

Temporal merge. All works but the vision part is however not finished yet.

merged

mentioned in commit 6a639c76

Why are we doing processNew() if we haven't decided yet if a new KF is made?

This is here to add more features in case there are less than required.

We made it so that we can ramp up the number of features across several captures. It's like a workaround. I would like to not have to resort to these kind of things, but it may happen that we are low on features for a while, and a condition featureList()->size() < min_ftr_for_kf in voteForKf() would fire one new keyframe per capture while the scene is not showing enough features.

But it has no impact if a KF is not created since no factors are added and these tracks are starting in a non-key frame...

Maybe...

So how to tacke this situation where there are insufficient features, less than the necessary for a KF? The think is that we need to avoid the processor creating KFs stupidly

Auxiliary frames are the solution (temporary KF), but you need to add the frame to the solver in order to make these features work.

Here, everything is based on the assumption of deciding KF (or auxiliary) in last. Maybe, this assumption is not fully applicable to the trifocal approach..

No no, these frames do not go into solving... if there's no features the only thing is wait, but we need to keep detecting things to see if there are indeed features!!!

Otherwise a processor that runs out of features is dead forever ! ??

If you run out of features, your problem gets disconnected. Apart from this drawback, the processor is not dead, whenever you (or other processor) create a KF, processNew() is called (and so detectNewFeatures()).

I think that to handle the case in which no new features were detected in processNew(), we should add a check after calling it inside the if(voteForKeyFrame()...). Then, abort the KF creation if no new features were detected.

But, now, this call to processNew() is dangerous because is not following the assumptions made in this function: (see comment from processor_tracker_feature.cpp)

/* Rationale: A keyFrame will be created using the last Capture.
     * First, we work on the last Capture to detect new Features,
     * When done, we need to track these new Features to the incoming Capture.
     * At the end, all new Features are appended to the lists of known Features in
     * the last and incoming Captures.
     */

Yes I agree it's not so good...

The check inside voteForKf() is insufficient, since it is only done once. If not passed, next time you dont vote and you never test again.

Unless you always vote when there are not enough features, but this destroys the logic of voting.

And waiting for external KFs is not good either because there might not be any other sensor.

Maybe this can be left to any one of the individual processors? I dont know how to tackle everything in the general case.

I do not understand why "If not passed, next time you dont vote and you never test again.", it depends on how the voteForKeyFrame() is implemented.. why "always vote when there are not enough features" destroys the logic of voting?