pv33
commented
3 years ago Current approach update
Puzzle manager can stay as a trackpointer. However, it is a special type that matches against some solution set. Such an implementation is not always needed. A simpler version just extracts puzzle pieces and does not try to associate. That is now called a puzzle.parser.fromLayer and does the 50% of work that was noted in puzzle.manager.
That means we are looking at puzzle.manager :arrow_right: puzzle.parser.fromLayer :arrow_right: trackpointer.centroidMulti
Adding puzzle.parser.fromLayer to issues.
Uio96
Questions
and
Current answer
The choice of a trackpointer was predicated on the fact that the surveillance system was going to provide the puzzle layer mask and the measured image (both most likely in rectified form to reflect a top-down view). Based on the fact that no extensive processing was going to be required, the initial choice was made to make it a trackpointer only.
Later on as code was being written, the superclass of the manager was sort of forgotten around the same time that necessity for a parser arose based on the bag-like
puzzle.boardclass and envisioned testing scripts. A parser will be used for calibration, for example. It might also be used in the surveillance system to process the surveillance data, since the final output might still need some processing to manage things. That processing can be shunted to a specialized detection routine. The output of the detection (mask + image) would then be sent along to the puzzle manager.Thus, it seems like the
puzzle.managerwould be thetrackpointerused by thepuzzle.parser.simple perceiver. In other application or test cases, thetrackpointermight be something else.Downstream consequences
Problem: The current
puzzle.parser.simpleseems to do its own trackpoint type processing and stuff within the measure instance. That should not be the case. What is needed is for the internal tracker to do the full job on its own. The current codebase is contradictory.Source: As noted in the meeting on Wednesday, one major difference between a true tracker and our problem is that we do not wish to associate pieces over time to each other, but wish to associate observed pieces to a calibrated set of pieces. However, there is benefit to understanding the temporal history of the puzzle pieces to, since they relate to atomic actions. All of these things are creating a slightly more complex design with possibly mixed aims.
Solution: I would advocate to sort of relax on this front (PAV). A few classes might need to be renamed by the time we are done, but the core functionality should not change. Keep the functionality in mind. Step one is to keep
manageratrackpointerfor now and to keepparser.simplea perceiver for now. In some cases thedetectorassociated to theparser.simpleinstance will be adetector.noneand that is OK. In other cases, it will actually do stuff, like be a single Guassian model. However, what makes it distinct from a traditional perceiver is that it contains apuzzle.boardinstance.Long Term puzzle board needs
Long term there might be three board instances at any given time.
The current code does not fully address the richness of this situation. We must work our way towards it. How does that impact the puzzle manager? Well, eventually the puzzle manager will be renamed to be just a
puzzle.trackerand a newpuzzle.managerwill be created that is more complex. That stores and manages all three types of boards.The
puzzle.parser.simpleperceiver for sure does not. At best it would directly have the current measured board, or the current estimated puzzle board, or the current measured board and the current estimated puzzle board. Note that its contained classes might have access to the solution/calibration puzzle board, but it wouldn't.Current approach
Let's ignore the puzzle solving problem for now, and focus on the interpretation of the scene. This interpretation or perception of the scene has many implementation cases as noted in the comments. For calibration, for the solver proper, for simulating scenarios, etc.
Keep
puzzle.manageras atrackpointeruntil said solution fails. Keeppuzzle.parser.simpleas a limited functionality perceiver (no filtering or long-term data association). Test for calibration purposes and as a raw baseline system.Eventually work towards
puzzle.parser.longTermwhich might consider the long-term data associated needs. Or call itpuzzle.parser.matchTemplatesto indicate that there is a template set to match against from the very beginning. Some pieces may be observed or not, but they'll always be estimated. This would need a fully fledged manager operating within it.