GSoC 2008

[joerg]

Am Di  25. März 2008 schrieb Andy Green:
> - gpg control packet
> Somebody in the thread at some point said:
> > Am Di  25. März 2008 schrieb Andy Green:
> > [...]
> >> It means that a perfect solution is predicated around
> >>
> >>  - 16 bit integer arithmetic -- ha "no float" is too easy
> >>  - per-sample short processing rather than large batching
> >>  - multiply is expensive (but hey shifting is cheap :-) )
> > Divide?
> > Hey, for normalizing vector direction of gestures to different orientation 
of
> > NEO, we will need trigonometric calculations, no?
> > Anyway, it shouldn't be much harder than trainable OCR of PALM 
(Tealscript?),
> > and i think we can compare the power of PalmCPU to that of MPU.
> >
> > If anything else fails, MPU has to buffer the G-meter data, and 
recognition of
> > the actual gesture has to be done on main CPU. (no real option)
> 
> Well it depends entirely on the algorithm and how smart we are.  If we
> can bend the algorithm to use right shift instead of divide, or small
> precomputed tables for the key actions, we can do it on a pretty weak
> device.
> 
> Ultimately the "gesture recognition" action is about eating 200 3-byte
> packets of data a second and issuing only one or two bytes per second
> about any "gesture" that was seen.  I guess one way or another we use
> ringbuffers to keep averages of actions in each axis and try to match
> that against templates.  Depending on the algorithm it can be the kind
> of thing that can be done on a 16MHz MPU.

It's not that simple, I guess. See "gesture" 'from_AT-EAR_to_LOOK-AT' (recent 
topic). It will be completely differently distributed on the 3 axis, 
depending on user being upright, lying in a chair or lying in bed (and 
there's right-hand/left-hand too ;-)
Or a rotating shake with axis long side: it looks completely different when 
device is upright, 45°, or flat (in fact this gesture isn't detectable at all 
in upright position, in the first place).
Only correct way is to calculate real heading and velocity vector of device, 
as accurate as possible. Then accumulate a "route", and this route you may 
compare to a set of templates for best match (after transforming for size and 
orientation). All this is very low accuracy, so 16bit integer and sine-tables 
will do easily, but i don't think it will become much cheaper than this.
That is, if the gestures are more complex than just "one sharp shake" "2 
gentle shakes" etc.

jOERG