Feb 14

Instrumented Steering Wheel Project Update

The Instrumented Steering Wheel members, Adam Leone (CS) and Travis Royer (CE), have further refined the software and hardware used in this project.  The goal of the project is to add an authentication factor to vehicle security through a password tapped on an array of force sensing resistors (FSR) and processed on an Arduino microcontroller.

The system currently stores three passwords, selected by a tap on the corresponding FSR.  The user selects an FSR and chooses to either log into that profile with a short tap or input a new password for that profile with a three second hold.  If logging in is selected, the user enters his password attempt and the Arduino compares it against what is stored and outputs success/failure.  If inputting a new password, the user taps the pattern three times and the Arduino determines if they are within the defined error bounds.  If so, it averages the patterns, stores the new one in the profile, and outputs success.  Otherwise, it discards the new input, retaining the old password, and outputs failure.  Program flow is visually demonstrated in Figure 1:

Figure 1 - Flow chart of ISW tapped password program


The algorithm used to compare a password input against the stored pattern has been modified from that seen in the previous post.  When a user taps on an FSR, the Arduino calculates and stores the time of maximum pressure rather than using the time the leading edge of the tap passed the pressure threshold as a tap time.  Tap time is based off an absolute start time, that of the first tap.  Input taps must fall within a small window of time centered on the corresponding pattern time.  This window grows as the time from the start point increases, giving the user more flexibility toward the end of the sequence.  Pressure is similarly compared but a different error rate used and every tap pressure compared rather than those after the first.   The algorithm is visualized in Figure 2.  Taps are first recognized when the pressure crosses the threshold (orange circle) and the max pressure thereafter is calculated (yellow circle).  The tap time is recorded when max pressure is reached.  When comparing times or pressures, the blue lines are the length/size of the corresponding tap in the stored pattern and the green line is the window the input tap must fall within based on the preset error rates.  The window grows with the magnitude of the metric.

Figure 2 - Algorithm comparing input against a stored pattern


Although we haven’t started extensive testing, we have found three problems, two with this algorithm.  The first is the use of a linked list to store the taps.  This data structure requires input to be given in the same order every time, which eliminates the possibility of a password  multiple simultaneous taps because they may be ordered differently in the list each time.  The first problem with the algorithm is the use of a tap time that marks the time elapsed from the start of input to that tap.  We chose this method rather than storing the times between taps because it forces the user to maintain the same input temp each time rather than being able to compress and extend the pattern to the limits of the error window.  The difficulty of maintaining the same tempo, even when entered twice in thirty seconds, is becoming more and more apparent and might lead us to the conclusion that the pressure of taps and the relative times in between taps is more important than the tempo.  The third problem relates to the pressure comparison.  The error window is proportional to the “size” of the tap pressure.  It is easier to match a hard tap (large window) than a soft one (small window).  This problem might be overcome in part by comparing pressure based on three increments (soft, medium, hard) but trouble arises when a tap is at the threshold in between those categorizations.