I don't understand the problem. Tracking of the sphere is confused by the presence of another similar colour signal, miles away from the area the sphere is at. You can tell from limits in human physiology that the ball will be no more than...30 cms from frame to frame, which will be somewhere within a zone of the screen centered around the current signal. Thus you test for sphere presence in that box. In the above case, the presence of the hot zone in the bottom left would go ignored because it's too far from the current placement. I don't see why such a system could lead to sticking objects where the signal is lost. In the case the sphere isn't found (which would surely just be a poorly sized sampling window), you'd just extend the sampling window, maybe to the full screen. I suppose worst case, you could have the sphere lost, search the whole frame, and find a wrong signal. But that's no worse than we have here with the fan sticking to a false signal, while also this situation shouldn't arise.
My understanding specifically of Move:
- the failure is outside the scope of Move. (Move relies on the ball being a unique colour within the scene - that was the original reason given for the changing colour, so this "failure" is unlikely to keep the developers up at night). The only obvious problem for move is whether a reflection of the controller on a shiny surface would confuse the system (I suspect it might - although I guess that's not a very common occurance).
- in all likelihood move picks either the 'best' matching signal, or the 'first' matching signal. The requirement is to be able to carry out all the processing within the resource limits given to developers - e.g. miniscule lag/memory/99% predictable cpu usage, being able to handle stupid lighting arrangements isn't worth sacrificing system performance.
[I would expect this to be labelled 'wontfix'/pebkac]
The "constraint" in the movie appeared to be colour-based:
- at t=0 the best matching colour is purple, and it picked the wrong purple even if it was searching based on the last position - mistakes can happen.
- at t=1 the best matching colour is purple+1, so for the next frame it's looking for the colour purple+1. (the lighting etc may have changed)
- at t=2, the best matching colour is purple+2, so for the next frame it's looking for the colour purple+2.
- at t=255, the coloured light switches to red, but the system is still looking for a purple 255... (the actual Move controller led probably doesn't match this colour, leading to a system that doesn't know whether the led is obscured or the system is stuck).
[the patent below seems to say that this is how it works - and it can be broken in precisely the manner shown in that video]
---
Probably worth adding these 2:
Someone got hold of a move controller and opened it. The innards are spectacularly boring - the ALPS chip I'm guessing is an input controller-thing, it looks like an ARM chip in there too, and the rumble bit is clearly seen:
http://www.examiner.com/examiner/x-...ion-Move-controller-dissected-Images-and-more
And a patent that is 'mostly the Move' and probably should be included somewhere:
http://www.google.com/patents?id=cZjRAAAAEBAJ