Some more work on the Kalman stuff. Unfortunately, the camera isn't turning on, so I can't really test it. I'll try again tomorrow.
Started working on improving the cost function (item number 2 in the list below). Here's what I'm thinking:
-- Get Kalman prediction and uncertainty
-- Use the prediction to determine the center of the search window, and the uncertainty to determine its size
-- Run the cost function (possibly including a term that depends on the predicted location?)
-- Use the predicted location as an observation for the Kalman filter
-- Move the filter one step forward
Based on the meeting today, here are 3 things to work on going forward:
-- Improve change detection. Instead of just two running averages per grid square, keep several running averages, some with a much longer window. These can be used in the cost function to improve detection/tracking of slow moving (or stationary) objects.
-- Improve the cost function. In addition to the change detectors discussed above, also incorporate information from the Kalman filter. Use the location predicted by the Kalman filter (as well as its variance) to determine where to look for changes within the cost function. If the stick is not moving then the window will be small. If it is moving, the window will be larger, but it will at least be centered around the stick's predicted location.
-- Add more structure to the game. Instead of having a game based solely on spinning the stick, add some targets for people to hit with the stick.
I'll add some more detail to each of these before I start implementing them.
Started working on Prof. Freund's idea of including the predicted stick position as part of the update. I tried doing the Kalman step and then setting the new position based on the cost function (which now includes the updated position), but that doesn't work well. I'll have to try some other approaches.
--Yoavfreund 12:13, 4 February 2016 (PST) I think we are talking about different things. Lets meet in person.
Looked through some of the videos to find examples of when it loses tracking. The ones I saw fell into 3 categories
-- Someone in the background activates some squares and the stick tracks them instead of whoever is playing the game. Not sure what the best way to fix this would be. I added the color similarity term a while ago to address this, but it doesn't seem to be enough.
-- The player's arm stops activating squares, and we lose tracking that way. The obvious solution here is to increase the sensitivity of square activation. But we already get a lot of false positives, so this doesn't seem like the right solution.
-- Some other part of the player's body activates some squares, and the stick starts tracking those instead. This is related to the first problem above, but is slightly easier to solve. I increased the "activated squares" term of the cost function, so as long as the player's arm is activating more squares than the rest of their body, the stick should keep tracking.
--Yoavfreund 19:19, 31 January 2016 (PST) I think these problems can be solved by taking into account the predicted position of the stick. You want to ignore activity in all squares that are far from where the stick is likely to be. A nice thing about Kalman filters is that in addition to the estimate of future position it gives you the variance of the estimate.
--RobTimpe 21:18, 31 January 2016 (PST) Ok, I'll give that a try. Maybe add a momentum term to the cost function that is based on the Kalman filter?
Looking at the recent high scores, it looks like people aren't having a lot of success (i.e. lots of low scores, not many very high scores). I tweaked the cost function a bit to make the stick a little easier to spin.
--Yoavfreund 16:32, 24 January 2016 (PST) How about tweaking the tracking algorithm so that it loses the arm less frequently? You could harvest from the videos the moments where tracking was lost and then tune the algorithm so that the track loss does not occur or at least occur's later.