joerg.twinklephone at gmx.de
Tue Mar 25 12:27:08 CET 2008
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
> > NEO, we will need trigonometric calculations, no?
> > Anyway, it shouldn't be much harder than trainable OCR of PALM
> > 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
> > 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
> 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.
More information about the community