For our final project, our team built a touch screen controlled Etch-A-Sketch we call Touch-A-Sketch.
The Touch-A-Sketch is the first of its kind that allows users to draw on the touchscreen and sketches the drawing on the Etch-A-Sketch by controlling the knobs on either corner of the toy. There are four main components that make up the Touch-A-Sketch. A PIC32 microcontroller, two stepper motors, a resistive touch screen, and an Etch-A-Sketch. The PIC32 reads coordinate inputs from the touch screen in real time in order to map the required speed and rotation to the knobs of the Etch-A-Sketch.
Overall, we believe that this project was a good fit as a final project due to the complexity and the necessary culmination of many different components. With many components that needed to be interfaced, we undoubtedly leveraged what we have learned throughout the semester and applied it in various forms in our Final Project.
High Level Design
In the process of choosing a final project, we brainstormed several ideas before settling on the Touch-A-Sketch concept. We wanted a project that any user could understand and be excited about using. Almost everyone has used an Etch-A-Sketch before and has experienced the difficulty in drawing pictures with it. We took it upon ourselves to bring the Etch-A-Sketch to the 21st century with a touch screen attachment.
In order to take the user input from the touch screen and feed the motors relevant data, a mapping between the touch screen and stepper motor units need to be established. The possible range of x and y coordinates are mapped to a certain amount of rotations of the corresponding stepper motor; i.e. touching across the entirety of the x-axis on the touch screen should rotate the left motor such that a line is drawn all the away across the x-axis of the Etch-A-Sketch. The speed of the motors also need to be taken into account. If the user draws anything but a straight line, the two motors need to turn at different speeds. In theory, the speed ratio of the two motors should be dependent on the slope of the line drawn. If the two motors always moved at constant speed, steep lines would not look straight.
The logical structure of the program consists of one thread and two ISRs. The thread is used to determine if there is a valid touch on the screen, reads the input, and then adds the point read to a buffer array for the motors to read. This buffer array is used as a sort of schedule for the motors to follow. It is not possible for our system to keep up with fast drawers, so the buffer allows the Touch-A-Sketch to still draw accurately at the expense of a delay. The two ISRs are used for motor control, one for each stepper motor. Depending on the change between the current x coordinate and the last x coordinate in the buffer, the motor rotates a certain amount calculated from our mapping. One motor will always move at the same speed while our second motor’s speed will change to fit the ratio of the slope of the line being drawn.
As far as hardware, the stepper motors and resistive touch screen have their advantages and disadvantages. The stepper motors rotate at a reasonable speed, but cannot draw at the same rate as an artist would do a quick sketch. The lower speed potential is balanced with a higher torque potential. The force required to turn the knobs on the Etch-A-Sketch is not trivial, as such high torque is important to successful drawing. The resistive touch screen is actually accurate enough to detect even small movements of the user. The range along the x-coordinate is 887 units; across a distance of only a few inches, this allowed for accurate readings of touch positions. Since the touch screen is resistive, we can also detect pressure on the screen, giving us the ability to detect valid touches. Some downsides to the touch screen includes the difficulty in setup and its fragility. It took a considerable amount of time to get the touch screen working as intended. We also ended up ordering three touch screens because the first two had malfunctions. When it comes to software limitations, the timers used in the ISRs determined the speed that the motors could turn. Depending on the slope of the line drawn, the motor’s turning speed was capped by the timer count for the ISRs.
As mentioned previously, the Touch-A-Sketch is the first of its kind. Despite using patented products like the stepper motors and the Etch-A-Sketch, to our knowledge and some research, using a touchscreen as an input to draw on the Etch-A-Sketch has never been implemented elsewhere. While there are numerous other projects that utilize the Etch-A-Sketch, almost all of them use a computer as the source of input. Thus, the Touch-A-Sketch violates no current patents.
The resistive touch screen has two resistive axis, x and y. Four output connections correspond to the positive and negative sides of each axis. Since we didn’t have a datasheet for the touch screen, we first determined which leads were for the x-axis and which leads were for the y-axis using a multimeter. Since the x-axis was longer, we knew to expect more resistance on that axis. We were able to measure 617 ohms across the x-axis and 354 ohms across the y-axis. While the touch screen only had four outputs, each lead was split into two. For this reason we used an 8-pin flat flex connector in order to interface with the small board. In order to attach to the small board, we soldered leads onto the pin connections of the connector. Since there were 8 pins but only four outputs, two pins were connected to the same output of the touch screen. Due to this, we were able to solder two connected pins together and then soldered leads on. This ensured a strong connection.
For this project, we used two 1.8 degree stepper motors. We were able to find these available to us in lab. We chose to use stepper motors since they could provide high torque to turn knobs as well as provide more accuracy with their small step degree. The stepper motors we used had six leads. Two were connected to power and the other four controlled the orientation of the magnet turning the motor. For one motor we were able to use the datasheet we found online. Since we were not able to find a datasheet for the other motor, we used a multimeter to check connectivity and determine the correct sequence of pulses for the motor to rotate.
We considered a few different options to connect the motors to the knobs of the etch a sketch. One option was to drill into the knob however this option could potentially harm the Etch-A-Sketch. We also considered not mounting the motors directly on the etch a sketch by using a belt system. This option was eliminated due to possible slipping. Our final options were either using a shaft coupler or using velcro. The motor shaft was measured to be 1/4” diameter and the shaft of the etch a sketch was 3/16” diameter. Finding an appropriate coupler proved to be quite difficult since the part was consistently out of stock or extremely expensive. We settled on using velcro to mount the motors since this was the most achievable option as well as easiest to implement. We attached a knob to each of the motor shafts. The hook side of the velcro was attached to the top of the knobs on the motors. We then put the loop side of the velcro on the Etch-A-Sketch knobs. While there is a little give in motor movement before the Etch-A-Sketch actually moves, it is not significant enough to be seen on the drawing screen.
After we we had an interface for the motors and the Etch-A-Sketch, we built a platform for the motors to rest on. This was made out of plywood. Holes were drilled where the knobs needed to be as well as where the corners of the motors were for mounting. We also added a stabilizing leg on one side. Two legs were not needed since most of the motors weight sat on the knobs themselves. We found that while it was easy to attach and detach the motors, it could be difficult to directly center them on the knobs. The full mount is pictured below.
In order to control the pulses and protect the motors, we used ULN2003 Darlington Transistor Array Chips. These work by allowing a smaller current from the microcontroller to control a larger load like our two stepper motors since the transistor array has a high current gain. While running the motors with chips we noticed they were heating up quite a bit. This is because they are only rated for 500mA on each pin. Each motor drew 500mA to 800mA while moving. When stopped and being held at a position (constantly sending the same pulse) each motor could draw up tp 1.3 A. This high draw is most likely due to the high holding torque created. In order to avoid burning the chips, we first changed the code to not send pulses when the motor needed to stopped. We also built our own heat sinks. This was done but cutting thin pieces of aluminum into rectangles and then folding up the sides to easier dissipate heat generated by the chips. These were attached to the chips using heat sink grease.
The resistive touch screen has four output pins used to poll the readings. Two pins correspond to the X direction and two pins correspond to the Y direction. In order to record a point in one direction, the positive and negative leads of that direction must be set to power and ground respectively. This way when a touch occurs, the axis splits into two parts, becoming a voltage divider. When one axis is being read, the other is set to input, or Hi-Z. One of these inputs is an analog input, allowing the PIC32 to read from the ADC. The ADC value changes based on the location of the touch since the two sides of the axis that will make up the voltage divider will change. An image of this is pictured below.
In order to correctly poll the ADC, we referenced the touch screen Arduino library. While the Arduino library polls for points one after the other, we found that we were not able to do this since. The ADC did not have enough time to settle between readings, therefore the data we received was not correct. We then changed the code to only read one axis every loop. At the end of the thread, the ADC would be set up for whatever axis was not read. This way the ADC had ample time to settle after changing pins from inputs to outputs.
In order to determine if a point was valid, i.e. the screen was touched, we added a third option to the loop, that checks to see if the touch screen wis being pushed. This extra check is necessary because when the screen is not being touched, it still recorded a voltage in a range on the left side of the screen. We first considered making it a dead zone since the area was quite small. If a coordinate was read there, it would not be recorded. However we soon noticed that whenever a user lifted their finger off of the screen, extraneous marks were made on the outside of that area randomly. Instead of further expanding this dead zone, we decided to check for a touch to determine if a coordinate was valid. This means that if the screen is being touched, a new coordinate will be recorded every three loops. The calculations for the touchscreen were based off of the touch sceen reference sheet as well as the Arduino touch screen library. We found that the value of rtouch, the calculated variable, fell between 40 and 10,000 if there was an actual touch. While this seems like a very large range, when not being touched the screen read rtouch as around 15,000 and above. We included a lower bound of 40 to compensate for setting rtouch to 1 in case of dividing by zero.
While implementing the touch sensing, we repeatedly ran into issues with the display resetting, appearing to have shorted. We discovered that the order we were checking the coordinates in (x, y, then touch) was causing a quick short when switching inputs, outputs, powers, and grounds. In order to mitigate this, we switched the order we checked values in, starting from y, then x, and finally touch. The x and y coordinates needed to come before the touch sensing because they were needed in the touch calculations. Below is an image of a succesful picture drawn on the touch screen and mapped to the TFT display used for debugging.
In order for the touch screen to read values properly and detect touch, three ADC channels were required. In order to set this up we referenced Bruce Land’s Read ADC File. This sets up the ADC in autoscan mode. This means that the ADC will scan all ADC pins unless told which pins to skip. Since we only needed three ADCs, the parameter was written to skip all pins except those three.
In order to control the motors, our first step was to have them move in either direction. This is done by sending a series of sequential pulses to energize the magnet controlling the rotation of the motors shaft. When we first began running the motor, only one lead was energized at any given time. The pulses were sent cyclically in order to achieve a rotating motion. We later began overlapping energized leads to achieve a higher a torque. This means that every other step, two neighboring leads would be energized. In order to rotate the motors in different directions, the pulses must merely be sent in the opposite direction.
Once we were able to move both motors in either direction, we started to fine tune the movements of the motors to control the Etch-A-Sketch. To achieve maximum efficiency and speed versatility, we placed each motor’s control signal in an individual interrupt service routine (ISR) with distinct timers: Motor 1, which controls the Y axis knob and uses timer 3, and Motor 2, which controls the X axis knob and uses timer 4. Within each ISR, the code first decides which direction to move, which will be discussed in the calculation section below, up / !up for the Y motor and left / !left for the X motor. Once the direction is set, the motor then enters a switch statement that determines which control signal to send to each individual motor. Each time the program enters a motor ISR, the control signal (determined by mstate and m2state) is changed by the switch statement to allow the PIC to send the right control signal to the motors for it to turn.
To determine the correct number of pulses to send, in other words, the number of steps the motor needs to take, calculations are needed to translate coordinates from the input of the touchscreen. Once valid points are entered in the touch screen buffer, the motor will then calculate the necessary steps to take in the X direction. To make the calculation straightforward and clear, we never change timer 4, which controls motor2 (the X-axis motor). By setting the X motor ISR timer constant at 27500 with a prescaler of 16 (which translates to .011 second ISR) , the number of steps needed to draw the X axis across the entire Etch-A-Sketch remains constant at 1900 steps (1300 across Y axis). The number of steps required to draw across the screen significantly changes with ISR timer speed due to slippage at faster speeds. Thus, to calculate the number of steps needed in the x direction, we simply take the new x coordinate value from the touchscreen, subtract it from the previous x coordinate value to get dx. Once dx is computed, we then divide dx by 887 (the x_coordinate range of the touch screen in the x direction), and multiply the result by 1900 to determine the number of steps needed to take by m2, the motor drawing in the x direction.
Initially, we tried to use the same method to calculate the number of steps in the Y direction:
However, since the range of resistance on each axis isn’t equal, one step calculated in the x direction would not equal the same distance calculated in the Y direction. We also realized that only calculating the number of steps required to move did not guarantee that the motors would stop at the same time. Due to this, we also began scaling the speed of the Y ISR. This was done using the slope, or dy/dx. The ratio of Y counter to X counter needed to be the inverse of slope since a shorter counter time meant the motor would rotate faster. We multiplied the standard X ISR counter, 27500, in order to get the correct speed.
When testing this, the two motors were still not stopping together. We next tested the number of steps it took for each motor to make one rotation at different speeds. We discovered that at faster speeds it took more steps for one rotation. Possibly because more slipping occurred. We also measured the speed it took for one rotation. The relationship between steps and speed was also not linear, making calculations very difficult. We also measured the length of time for one rotation at different speeds. Luckily the relationship was linear, 0.8 seconds for every 5000 counts of the ISR timer.
Thus, we resorted to only calculating numStepsX, let the Y motor use the same counter (numStepsX) but scale the Y timer counter using the ratio of dx and dy. The theory was that if the X motor moved the correct number of steps, and the Y motor speed was scaled to X, then based on the slope, when the X motor was done, the Y motor should be in the correct position. We determined the necessary speed needed to turn the Y motor so that not only will it cover the desired distance for dy but also end exactly the same time as the X motor using the same numStepsX. This resulted in the need to catch the cases where either dx or dy were 0. The only time the calculation for numStepsY is calculated is when dx is zero, in which x and y motors must stop turning at different times (since x motor doesn’t turn). We added a case to the code that determines which direction a motor must turn that was a wait state where the motor would not move. In order to calculate the Y ISR counter time, we multiplied they X ISR time, 27500, by dx/dy and then multiply by 10/8. We multiply by 10/8 because based on earlier mapping, we calculated that one step of the X motor is equivalent to 10/8 steps of the Y motor. Thus in order for the time to be correct, we also must multiply the time by this value when only Y has to move.
Once each motor reaches the next point and stops turning, another valid new point (if any exist) will be extracted and the whole process will start again.
Results of the Design
The final product ended up looking slightly different than anticipated, but still functioned effectively how we planned it to. One of the biggest differences between theoretical and experimental factors was the motor steps and speed. We originally thought that the number of steps needed to rotate the motor a certain distance was independent of the motor speed; the opposite ended up being true. Depending on the speed of the motor, there may or may not be some slippage of the motor shaft. At high speeds, more steps are needed in order to rotate the motor the same distance in low speeds. The relationship between number of steps needed for exactly on rotation and motor speed were not linear, so we graphed the relationship, shown below:
|ISR Count||Steps for 1 Rotation||Time for 1 Rotation (secs)|
Some other additions include placing paper over the touch screen and drawing a picture on it with pen. This lets us easily compare what the user draws versus what is etched on the Etch-A-Sketch. This also helps the user see what they are drawing as they draw as opposed to having to imagine what has been drawn already. Comparisons were not perfect one to one clones of each other, but the pen drawing over the touch screen is very close to what appears on the Etch-A-Sketch nonetheless. Images can be seen in the gallery, below are some videos of the Touch-A-Sketch in action:
The Touch-A-Sketch is very easy to use, although non-trivial to set up. The velcro makes it easy to detach the motors, shake the Etch-A-Sketch to erase the previous drawing, and reattach the motors. To begin, the etcher must start at the bottom left hand corner of the Etch-A-Sketch and the user must start drawing from the bottom left of the touch screen. Aside from that, there’s little complications. The user may lift up the pen at any time and then continue drawing as long as the continuation is close enough to where the pen was lifted.
Overall, we built a product that not only allowed us to apply knowledge accumulated in the past, but also undoubtedly put a smile on all of our faces. Despite the fun, this project truly tested our knowledge when designing the hardware, programming the PIC32, and interfacing all the necessary components so that the Touch-A-Sketch can perform. Aside from using the Peripheral library, Protothreads and the TFT library, all developed code within the final product was completely original; no reverse engineering was done for the entirety of the project. The end product turned out decently well. Due to the accuracy of the touchscreen and the resilience of the program, we were able to translate drawings with minor distortions the majority of the time. However, due to the motor constraints and the use of velcro as our connection between the motors and the Etch-A-Sketch knobs, the drawing can become distorted. Since we have a low bound for speed, the Y axis sometimes goes faster than calculated. The velcro can also take away from perfect accuracy. In the future, the connection of the Etch a Sketch and the motors can be made more robust with shaft couplers. We hope to submit our project for to various publications such as Circuit Cellar or Wired next semester.
Throughout the development of our final project, we upheld the IEEE Code of Ethics. We built the hardware and software with the safety of the user as our top priority. Due to this, we chose took measures to ensure that the electronics we used were safe, such as adding heat sinks to not only mitigate potential burns from hot equipment. We reused components and utilized scrap materials in order to have sustainable development practices. Throughout the project, we have been honest and realistic in all claims and data made within. All claims have been based on the data that we collected and results that we saw while running our system. We embarked on this project with the goal to increase our understanding on knowledge of using a microcontroller system. We believe that we have increased our technical knowledge throughout this process and aimed to improve society’s understanding of the combination of conventional and emerging technologies. We welcome any criticism of our technical work in hopes of improving the system. We appreciate all of the available documentation online that has helped guide us throughout the design process. We have cited all sources and references that we used. We firmly believe that we have held up all points in the IEEE Code of Ethics.