The next generation sketching device
Our idea for our final project is, at its core, a wireless electronic Etch-a-Sketch. We will put potentiometers in the place of knobs and use the voltages they output to control the position of a drawing implement. The decision of whether to draw on the computer or to hook it up to a physical drawing system has not yet been made. We will also attach an accelerometer to check if the device is being shaken, and in the case where it is being shaken, the current drawing will be deleted, giving both of the primary functions of the regular etch-a-sketch. Where our project will get special will be where we start implementing non-standard features, like the ability to save, a lower shaking threshold where the picture becomes blurry, and a button which can toggle through a selection of colors for the graph.
Our project consisted of 5 major parts: two hand controllers reading in data about their angular position and acceleration, an Arduino for each controller which processes that data using an Adafruit library for calculating pitch, the Arduino then sends the angle and acceleration data as a String to another Arduino, that receiving Arduino parses the string and sends the parsed data into Matlab, and finally Matlab uses that data to make a plot which acts as a GUI.
The hand controllers are made from 9 degree-of-freedom sensors inside of 3-D printed cases. The sensors contain a gyroscope, an accelerometer and a magnetometer, which we didn't use. They output raw data of the effects of gravitational and magnetic fields on them, and their rate of rotation. They also require the use of a clock, of which the Leonardo has only one, and this necessitated our using one Arduino per sensor rather than a single one for both.
Next, each transmitter Arduino takes the raw data from the sensors and uses our customized library, which is in the attached files, to determine the angle at which the sensor is tilted and the z-acceleration. We took a standard library off of the Adafruit website and supplemented it in our Arduino code to give us the functionality we were looking for. The biggest change we made to the library’s calculated value was making the angle go strictly from -90 to 90 and if one turned past the 90-degree threshold, the value would stay at 90 rather than reverse direction and start decreasing. We accomplished this by realizing that our -90 and 90 positions had a z-acceleration of 0 and any position beyond that would have a negative z-acceleration. We then mapped that value from 0 to 50 instead of from -90 to 90 to give us smoother drawing for when we eventually plot it on Matlab. One other major change we made was we multiplied the z-acceleration by 100 and cast it to an int in order for it to be easier to transmit. We took those values for z-acceleration and angular position and turned them into a comma separated value inside of a String. This String is the value that we transmit to the other Arduino via XBees, where it is going to be parsed and sent to Matlab.
When the receiver Arduino picks up the signal from the transmitting one, it parses the String as a series of single characters, splitting it up by the comma and interpreting dashes as negatives. Each character that we read in was processed using the Serial.Available() and other methods of the Serial class and we kept track of the state of the current input using a variety of fields in our Arduino code. When the Arduino reaches the end of the stream, it packages the angular position and z-acceleration into another String as a comma separated value and sends them to Matlab for some final processing and printing the plot.
Matlab does the final wiring together of the separate parts of the project, taking in strings from the two receiver Arduinos and parsing them each to separate the angular position and z-acceleration. It then plots the two angular positions on a graph and checks to see if the z-acceleration of the right controller is great enough to count as it being shaken, which clears the plot if true.