Skipping fingermapping entirely

[sid9102]

The current way we're attempting to implement the software back end is heavily reliant on the t9 system of prediction. This created a chicken and egg problem of calibrating an unreliable sensor, using a fingermapping, and mapping the fingers, using a reliable sensor.

What if we sidestepped our current sensor data -> finger -> letter design, and directly attempted to go from sensor data to letter? Who cares what finger the user moved if we know what letter they typed?

The calibration process would now be a simple set of sentences. For the initial seed data, we could work off of a huge data set collected off sensor data from 3 or 4 people. From there, we could have individual people do a much smaller data gathering calibration process (which would work the same way as I planned finger mapping to work) that would hopefully take no more than 5 minutes (ideally as long as it takes to get an iPhone 5S to learn your fingerprint).

On the data structure side, the structure of the trie would no longer be based on fingers. It would be based on the number of different "buckets" that we could sort sensor data into.

This might be a little more dangerous, so I suggest we work off the sensor -> finger -> letter system first, and then once the machine learning system is relatively robust, we can try this out in a different branch.

[sid9102]

Pure RMSE:

sensor data is grouped into elements in an array or some other indexable structure.
The calibration process occurs as follows:

First, have the user type a sentence, quick brown fox or whatever. Then make them type it again. Find a section in each that correspond to each other. We can do this by searching for a sequence for which both sequences are within some RMSE value. Then we do individual words in the sentence. After doing this same process for another couple of sentences, we will begin to observe the bounds of the variance for each bucket of characters.

We then generate paths for which there is a maximum RMSE in order to activate a bucket. The RMSE would be a way for us to say that there is no doubt that a certain pattern of sensor data belongs to a bucket, because it is within that buckets error range, but outside of all the other buckets' error ranges.

RMSE in this case is an average of RMSE of sensor data. So we calculate the error between sensor data values, then calculate the new bit of sensor data's values against the second sensor event in a path, then average the errors out. Once that average drops below a number (which is determined through the calibration system) we send that bucket to the Trie and reset to the root.

For example, bucket 1 is indicated by the following values:

Sensor 1, Sensor 2, Sensor 3
45, 27, 28
25, 29, 30
11, 20, 30

And bucket 2 is indicated by the following values:

Sensor 1, Sensor 2, Sensor 3
20, 47, 27
20, 35, 17
17, 36, 23

And we get the values:
40, 25, 29
24, 30, 30
7, 17, 28

The RMSEs are:
2.67, 1, 3 or an average of 2.3 for bucket 1 and
11.3, 7.3, 11.3, or an average of 10 for bucket 2.
So clearly bucket 1 is the bucket we should transmit.

Any values not received can be assumed as all 0s or something, to seriously skew the mean RMSE until we get a sufficient number of inputs.

[sid9102]

There could be a weighting system for values that are ambiguous, based on likelihoods of the next bucket. But the bucket error correction builtin to the Trie may already handle that.