inwheel version 1, and new algorithm idea
cephdon at gmail.com
Sun May 6 07:34:48 CEST 2007
On Sat, 5 May 2007 20:10, Werner Almesberger wrote:
> Record the input trace as a sequence of vectors. Then determine
> for each possible path how different it is from it. If there's a
> sufficiently close and unambiguous match, take it.
> Possible paths would simply be from the center of the start zone
> to the center of the end zone, or with an intermediate stop for
> three-zone sequences.
> The difference could be calculated by viewing the reference paths
> as rubber bands and approximating the energy that would be needed
> to bring them into the shape of the input path. Now, trying to do
> this analytically would get us page-long integrals. But if one
> would just have a small fixed number of evenly spaced points on
> the respective paths, the sum of the distances of corresponding
> points in input and reference path should be a very good
> Such an algorithm would be tolerant against accidently crossing
> corners belonging to other zones. However, it probably wouldn't
> solve the common mistake of lifting off a bit too quickly. One
> could of course also calculate some form of "momentum" ...
> - Werner
Since your already recording vectors, why not just have the vectors
trace an infinite (larger than the screen size) line from wherever its
currently at and check for intersections of the hot zones.
If they are spaced in such a way that 2 zones are always side by side
and not overlapping, then the intersection of the vector and the hot
zone at the time of the pen leaving the surface would tell you what
character is intended.
Granted, I have not used the demo so I am just making a non-informed
suggestion, but it seems like intersection would be much faster than
modeling rubber-banding estimation algorithms. Plus, it automatically
builds in an even margin for error, the angle of which is the set of
lines from the sides of the hot zone to the center.
More information about the openmoko-devel