ProcessorTrackerLandmark::ProcessKnown() quickly untractable
Created by: artivis
As for now ProcessorTrackerLandmark::ProcessKnown() calls internally findLandmarks(*(getProblem()->getMapPtr()->getLandmarkListPtr()), ...).
This function is supposed to match all known landmarks of the map to the incoming capture.
This eventually becomes untrackable, possibly rather quickly.
There should be somewhere in the Wolf tree some intelligence that could figure out which are the 'relevant' landmarks and give access to them on query.
I see two manners of approaching this issue :
- Some kind of TrajectoryProcessor that first filters 'relevant' frames and return the landmarks constrained by those frame
- Some kind of MapProcessor (think of it as an Octree)
I mentioned Processor above because of course the 'relevance' might differs from an application to another or a sensor type to another therefore the adopted solution should allows one to define its own relevance.
Any suggestions / remarks / etc ??
Activity
Created by: joansola
Some random comments:
The function ProcessorTrackerLandmark::findLandmarks() is not supposed to match all landmarks in the map. It is just supposed to project them and see if they are in the field of view. After that, you can select, from those inside the field of view, a subset that you want to try matching.
Still, projecting everybody and checking whether they are in the field of view needs linear time with the number of landmarks in the Map. Therefore a method to pre-select relevant landmarks, as you say, is of course welcome. This method does not have a generic form: it depends a lot on the map type and the sensor type. It is also unclear where should be put in the Wolf tree:
- As it depends on the landmarks in the map, it could be part of Map
- As it depends on a pre-selection of relevant frames, it could be in Trajectory.
- As it depends on the sensor type, it could be part of the sensor's Processor
In my opinion, because of this variability of dependencies, such intelligence must not be in any of these branches. Then, it is either in Problem, or it is free-flying somewhere (odd).
In my opinion, we need a function that, depending on which sensor we are using, returns a number of relevant landmarks to work with. These are examples (not to be taken strictly):
- Problem.getRelevantLandmarks
- Problem.getRelevantLandmarks(Sensor*)
- Sensor.getRelevantLandmarks()
Of course we may have a version that ignores the sensor, and returns the same for everyone. This makes it easier to generalize:
- Map.getRelevantLandmarks(Frame, ...)
- Problem.getRelevantLandmarks(...)
- Trajectory.getRelevantLandmarks(...)
where my preference is to put it in Problem, either directly, or through a processor or manager of some type: Problem.getManager().getRelevantLandmarks(...)
Created by: joanvallve
Indeed, an important and complex issue..!
As JoanS pointed, is not only about the landmark search but also about frames (for feature matching). So, this issue wound't only be about ProcessorTrackerLandmark but also ProcessorTrackerFeature (loop closing mechanism for it hasn't been even pointed.. issue #95 related)
I would say that the relevant landmarks depend not only on the sensor but also on the capture. For instance, from a laser scan we can extract the area where the landmarks sould be searched.
We definitely must meet for discussing this issue..
-
Created by: joansola
More on this. These I consider facts:
-
We need to be able to easily obtain a subset of 'relevant' landmarks.
-
The word 'relevant' depends qua_L_itatively on the type of sensor:
- bearing only
- range only
- range and bearing
-
The word 'relevant' depends qua_L_itatively on the type of landmark
- point landmark
- line landmark
- polyline landmark
-
The word 'relevant' depends qua_NT_itatively on other parameters
- sensor range
- sensor field of view
- size of map
- size of trajectory
-
The actual subset of relevant landmarks depends on the algorithm we design
- Tesselation grid in Map space (i.e. make a grid in the Map and reason on neighbor cells)
- Tesselation grid in Sensor space (i.e. same but in sensor space --> 'active search' in visio uses this)
- Neibourhood conditions (i.e. closeby frames) in Trajectory space
In my opinion,
- we should ignore the dependencies on landmark type by now.
- we MUST be able to define different algorithm strategies depending on the type of sensor ('bearing only' and 'range and bearing'), which are tuned with the sensor parameters ('range' and 'field of view')
- in case of multiple sensors, these methods will have to coexist
An idea that I find interesting:
- Run different algorithms S(n+1) = A(n,S(n)) in a chain:
- Let S(0) be the set of all landmarks in the Map.
- S(1) = A(0,S(0)) is very quick and discards a lot of landmarks from S(0). It returns S(1) subset of S(0).
- S(2) = A(1,S(1)) is maybe slower but only works on the subset returned by A(1)
- S(3) = A(2,S(2)) ... bla bla bla ...
- Each A(n,S) takes care of one aspect of the problem. For example:
- A(0,S) selects a subset of S based on a subset of frames
- A(1,S) selects a subset of S based on the sensor field of view
- We can therefore code eacn A(i,S) independently, starting with only one, and makin it clear which strategy is using, so that A(j,S) is not acting on the same principles as A(i,S). In a way, we want A(i) orthogonal to A(j) for (i != j), if you know what I mean.
-
Created by: artivis
I think there is one missing remark about the landmark 'relevance', we should take into consideration the uncertainty of the current position. In the case it has grown bigger than, let say, the laser max range, naive landmark retrieval will most probably fail. @joansola your draft of a cascade of filtering function looks very similar to the ROS laser_filter. Different types of filter can be instantiated, in a given order so that they feed each other until the last layer. I am very much in favor of such solution. In case of multi-sensors, a cascade of filters should be defined for each one.
added To Do (release) label
added Idea label and removed To Do (release) label
