inwheel version 1, and new algorithm idea

Tim Newsom 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
> approximation.
>
> 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.
--Tim



More information about the openmoko-devel mailing list