And this is the end...

First, as usual, some pictures. Being rather shortsighted, we didn't take a lot of videos, but we have tons--dozens--of pictures. Below are a few highlights:

The final circuitry. We didn't show this on Demo Day because the pressure data was accurate but not that interesting, and our GUI was only programmed for a simplified output for our testing purposes- i.e. whether there was no/low/high pressure applied. The accelerometer data gave cool-looking results, though, and since we only had less than 1.5 minutes for the demo portion of our presentation (we found we couldn't summarize the technical stuff quickly enough, there was so much to explain :( gah, sorry!!!), we figured we could just wire up the accelerometers on a separate breadboard and demo with them. From experience, we tend to greatly respect Murphy's Law- in other words, the more circuit you have, the more things can go catastrophically wrong........... and on the night before Demo Day, we had a lot of weird circuit issues which might have been related to the pressure sensors, and our primary concern was avoiding showing a completely non-functional device.

The completed inserts! The sensors are located in the areas corresponding to the big toes, the balls of the feet, and the ball of the heel. We foolishly forgot to take a picture of the actual wiring of the inserts before I sewed them shut, but the ribbon wire just branches out (2 wires per sensor- 1 to the pin, 1 to ground). The final thickness of each insert was 8 mm!

The accelerometer on the toe. 

We made this insert size 10 so that Winslow could wear it :)

...and it fits perfectly!

HOW IT WORKS

The gait sensor measures the orientation of each foot as well as the pressure distribution across the sole of each foot as a function of time. The physician prescribes the use of these custom shoe inserts for a set length of time or during a certain activity—e.g. throughout the course of one full day.

Once the insert is placed in their shoe, the patient switches the connected device on, wears the wire-connected device on a belt clip, and lets it record data throughout the time prescribed as they go about their regular activities. Upon completion of the prescribed time interval or activity, the patient switches the device off and brings the insert with them to the next office visit. The physician can then remove the SD card enclosed in the device and read the data into the provided graphical user interface (GUI) to observe the patient’s gait pattern.

This is is a tiny fragment of testing where I demonstrated the working pressure sensors to Winslow via iPhone video while working on this outside of class... we also foolishly forgot to take a more formal demo video before we dismantled things to return the parts. Sorry, that was just lack of thinking on our part :( Also, on the day before demo we could only get the sensors working occasionally, and to this day we don't know why. The pressure sensors worked well when they did decide to work, though... and they also happened to work when I tried them after demos were done. That figures. Anyway, there was a nice linear response to pressure applied, as the data sheet from Flexpoint promised, when I tried having a couple friends (of known mass, haha) stand on the sensors.

This is the demo of the MATLAB GUI that Winslow made... the time reads in seconds here, and in future iterations it will play back the data at a rate that the user specifies (so it can play as fast/slow as desired). The dots corresponded to no/low/high pressure applied at the time of this demo shot.

The final material cost per insert (including base, outer covering, thread, bend sensors, wiring, and accelerometers) came out to roughly $17. We recognize that there are a multitude of other costs, both direct and indirect, to consider (the microcontroller or other hardware that will ultimately be used, testing, manufacturing, labor, approval by appropriate panels and authorities, etc.), and we also need to consider the additional cost of ramping up the number of sensors per insole. However, when we consider that cost with scale-up in mind, we think the relatively low material cost is a promising indicator of the device's potential. Certainly we don't anticipate this device reaching the $4,995++ price tags on competing devices and systems.

Things we could have done better:

• We could have requested additional samples from Flexpoint to get a better idea of the final hardware , but we decided not to due to time constraints and, well, general courtesy.
• The GUI could have had more features, but its development was also constrained by time.
• We should have taken more videos as we developed and built our prototype.
• We should have done more research on what material would be best for the insert base. (Thinner, less intrusive, lighter, allow wireless transmission)
• The device could and should have been smaller! Maybe with a smaller battery pack and a different SD shield/breakout board.
• We could have built a protective case to house the circuit boards and batteries. 
• We could have created additional feedback systems for informing the user that the batteries are low or if the memory space is running out.
• Ultimately, the bend sensors will also constrain our design: once you make them small enough and pack them close enough together, the bend sensors won't actually all bend in a region that is compressed--at least, not in the ways we expect. We think this constraint will not have a bearing on the final design of our product, however, because we are not aiming for the level of resolution offered by the competitors' products. A lower resolution would be sufficient to observe the gait patterns that physicians are really interested in. (The exact minimum density to observe these patterns using our sensors of choice is unknown, though, and requires some additional testing.)
• We would like to develop this further so that data transmittal is wireless--whether it be via an online method so that the physician receives the data directly from the device (eliminating the need for physical data storage) or just wirelessly to the recording unit worn on the belt clip. This would eliminate the wires that currently lead from the inserts to the Arduino and make the inserts almost completely unnoticeable!

All in all, we had a lot of fun learning how to work with the Arduino and developing the different aspects of our device, all the way from initial research to physical realization! It was a crash course in everything from Arduino programming to product design for me, and I learned a lot from Winslow, too.

I was personally really inspired throughout the semester as I looked up things that other people were doing with this microcontroller, both in and out of this class--to the point where I'm currently considering buying one for my younger brother to play around with as well. It's an amazing way to get first-hand experience in programming and physical computing, and both of us are glad we got the chance to take this class! Much, much, MUCH thanks to Dr. Bogen for overseeing our work and teaching this course!

Functional block diagram and other fun things!

Winslow made this lovely block diagram for our device!

In one of my favorite colors, sea-foam green! Muahaha.

The gait sensor remains on standby until the user indicates that they are ready to use the device through pressing a pushbutton. Once the pushbutton is depressed, the microcontroller turns on the red LED to indicate that it is calibration to calculate the zero values for the accelerometer readings in the X and Y directions for a straight foot orientation. Once the calibration is complete, the LED turns off and the SD card reader will respond to the Arduino indicating that it is ready to start logging information. Afterwards, the microcontroller will start logging the sensor outputs.  

Firstly, a total of 4 analog signals from the X and Y acceleration readings (2 accelerometers) are captured by the integrated ADC converter found on the Arduino board used here. Secondly, each pressure sensor output is separately converted into a pseudo-analog signal through a RC circuit created with a 0.1 uF capacitor and variable resistance from the bend sensors. Each of the six pressure sensors signals are appended to the captured analog signals from the accelerometers. Then this combined data string is then written onto the SDHC 8 Gb card through the SD card shield. The SD card then replies that the recording was successful, and this process repeats every 300 milliseconds. 

After the trial duration has ended, the user inputs another button press and the microcontroller stops logging data. This SD card can then be removed from the device and placed into a card reader for a computer to read. A Matlab GUI, which is our software component, then reads the text file generated on the SD card and shows the changing orientations of the feet based on the accelerometer readings and the changing pressure distribution on the bottom of the feet through the pressure sensors with respect to time.

We should probably provide a specification list as well... here are some tables for your perusal:

Specification	Value, Value range, or quality relating to specification.	Comments about or rationale for specification
Battery Life	24-48 hours	Patients will generally need to record a maximum of one full day of activity. Physician replaces battery; 48 hours preferred in case of longer desired recording times.
Foot sole pressure distribution mapping	v Variable-resistance bend sensor specifications (by Flexpoint Sensor Systems, Inc.) v 6 used (3 for left foot, 3 for right foot) v resolution minimum 1° of bend, 0.1° ideal v resistance range 5kΩ-14kΩ*	*Sensor areas can be custom-fit to insert as needed. Resistance range adjustable by manufacturer; may need different ranges depending user weight. The provided values are just the values of the standard sensors that they sent us in the sample lot. Sensors arranged length-wise across insert surface so that they are bent during compression of the insert base by the curvature of the foot.
Foot orientation tracking	v Triple-axis accelerometer breakout board specifications (by Analog Devices) v 1 accelerometer used per foot v resolution of 30°	Unfortunately, appears to be a previous iteration of current board being offered (ADXL335), but specifications should be identical. New accelerometer will be used in revised designs.
Long-term data logging on removable media	SD card, 2 GB or SDHC card, 8 GB	2 GB minimum, 8 GB ideal. We found that 2 GB would be sufficient to record roughly 24 hours worth of data, but considering the relatively low additional cost of upgrading and the possibility of multiple recording sessions, we find that 8 GB would be a good option.

Feature-benefit table:

We think these features should be sufficient to address the major needs of physicians and podiatrists who are interested in monitoring gait patterns: in general, they want to know the heel- and toe-off patterns over time (the pressure distribution in these regions as the patient takes steps) and the use of "high" vs. "low" gear propulsion (which metatarsal heads--1st and 2nd, or 2nd through 5th--are being used to generate most of the propulsion during gait). These simple measurements would easily be captured by our device, and focusing on addressing the most-needed features would reduce the final costs (materials, software development, testing, etc.).

Final project update!

Long time no post......

Since we last posted, we got a LOT of new components and did a lot of initial testing:

(Instagram edition!)

SD/microSD shield + accelerometer 1 

SD breakout board + accelerometer 2 

Lilypad! We may or may not use it, but since this device has to be portable, we will probably turn to this eventually.

Attempting to combine the RCtime setup from Lab 2 with the accelerometer (it didn't work... we decided to use the analog pins on the Arduino in the end)

Dual accelerometer testing!

Dual accelerometer + piezoelectric sensor testing! We decided to try using the piezoelectric sensor as a switch for the time being, but we are considering other options to better fulfill the sensing needs of this device as well.

Insoles version 1!

Our device in progress

Winslow wrote all of this :( 

At least the quality of our blog photos is somewhat improving.

More importantly, though, we thought we should update you a little on where we're heading with this project and explain where this device fits in... in the context of the current market and such.

DEVICE NEED

We want to address a medical condition that is both a symptom of underlying disease and a problem in itself. Abnormal walking behavior, or gait, is a consequence of distal sensory and motor loss due to nerve damage, or neuropathy. Distal nerve damage is specifically called peripheral neuropathy, which, statistically speaking, is primarily attributable to conditions such as the following: 

     1. Diabetes mellitus (diabetes)- Progression of diabetes is marked by high blood sugar levels, which degrade the myelin sheaths of nerve cells over time; furthermore, diabetes causes chronic kidney disease and failure, which also contributes to irreversible peripheral nerve cell damage (Krishnan and Arun, 2009).
     2. Alcoholism- Chronic alcohol abuse is strongly correlated with the incidence of chronic liver disease, which has been found to be directly associated with distal sensory loss related to peripheral neuropathy (Chaudhry et al., 1999). 

Abnormal gait patterns are also seen in children and adults with autism-spectrum disorders (Shetreat-Klein et al., 2012). Even children who exhibit abnormal gait habits without any underlying medical condition eventually develop postural and gait deformities that introduce medical and, later, social problems; these cases are also difficult to identify because researchers found that children can consciously modify their walking behavior in clinical settings (Armand and Watelain, 2007; Pendharkar et al, 2008; and Wren, 2004).

Gait abnormality is a medical condition in and of itself, but due to the above associations, it can also be considered an indicator of serious underlying issues or future concerns that mandate early identification and treatment. Severe cases of damage due to the long-term effects of gait problems are major reasons for lower extremity amputations. In 2011, 65,700 lower-limb amputations were carried out on diabetes patients alone because of complications due to nerve damage (Centers for Disease Control and Prevention [CDC], 2011)! 

Beginning in 1989, medical literature reviews acknowledged that early identification and preventative treatment of patients at risk could reduce amputation rates in large clinical centers by as much as 85%; in the two decades since, several technologies have been presented in the literature as accurate quantitative diagnostic tools, but none has been widely implemented for clinical purposes (Bild et al.).

The common initial method of diagnosis for peripheral neuropathy is still a subjective pressure test using a monofilament rod and a vibration test using a tuning fork that require some significant existing damage for a positive result (National Institutes of Health [NIH], 2009). In other words, first they prod your foot in various places with a pin, and then they hold a tuning fork to it to see what frequencies you can feel. Subsequent screens involve nerve conduction studies or expensive blood work (NIH, 2009). 

What about detection methods for abnormal (but non-pathological) gait habits that could result in deformity later on? We found that no device that fulfills this need has been commercialized. There is a clear gap in both the market and the literature for a quantitative diagnostic tool that answers all of the concerns described above while being low-cost and convenient to use. A pressure-sensing device that monitors the sole of the foot could detect minor gait abnormalities that would help diagnose underlying neuropathy. It could also direct otherwise healthy patients to corrective therapy for harmful gait habits; this type of device could thus fill a current gap in diagnostics.

We figure we should should probably also give an idea of how large our target population is. 

If you add up the segments of the population with

• diabetes (both types 1 and 2), 
• children ages 10 to 15 (a major risk group for skeletal deformities and gait dysfunction, since this is the time they go through their final growth spurts), and 
• patients with chronic liver and kidney disease, alcoholism, and other related high-risk conditions for neuropathy,

and subtract accordingly to account for the estimated segments that have combinations of these conditions, we find that the target population could range between 50 and 60 million individuals.

The population would use our device at home or wherever their usual daily schedule takes them, since that is the type of monitoring we are trying to achieve. Generally speaking, they would not require others to help them in the use of the device, since they simply turn it on and off with the push of a button.

ALTERNATIVE DEVICES AND TECHNOLOGIES

What about current alternative devices? If there are alternative devices out there, why are clinics still using pins and tuning forks? Sometimes such simple diagnoses are "good enough" for a quick clinical screen, but what about the children with potentially harmful gait habits but no neuropathy or other pathologies? How can we tell if their habits cause potential harm in the long run (indicated by causing significant changes in the pressure distribution in their feet), especially if they tend to consciously change their behaviors when they are in the clinic?

We found three major competing devices and technologies:

1. TekScan F-Scan system. This is a system very similar in concept to the device we have in mind: TekScan offers both stationary and wearable (portable) versions of their system, and these generate high-resolution pressure data for the soles of the wearer's feet. For reference, one insert contains 960 sensors. These system packages are priced on the order of $4,995 each. TekScan specializes in both the pressure/force-sensing sensors themselves and the application of these sensors to consumer products. 
2. Sensor Products, Inc. (SPI) pressure-sensitive film. This is a precision-engineered film 4-8 mm thick that develops gradients of color based on pressure distribution. TekScan has a similar system that they also offer for diagnostic use. SPI markets themselves as "tactile pressure experts," with collaborations with companies such as Fujifilm to develop a variety of precision films (their core technology) for pressure analysis.
   The problem with the film products is that they give no data with respect to time, which we are interested in. We only see the final color distribution (which is mapped to a pressure distribution using the accompanying software and scanning package). If there were unexpected bumps or other accidents that caused a "spike" of pressure on the film somewhere, we would have a hard time telling if it was due to their actual gait or if it is just an irrelevant artifact.
   Furthermore, these films have problems with temperature and humidity sensitivity: SPI's film in particular has a maximum temperature cap of about 95 degrees Fahrenheit and a humidity cap of 90%. However when people wear shoes for extended periods of time, the local temperature in the shoe can reach up to 115 degrees and experience 100% humidity. Special coatings or casings that do not interfere with pressure exertion on the film itself would be required for these films.
3. RsScan Lab, Ltd. This company develops systems similar to TekScan's piezoelectric crystal-based product line, with more emphasis on a very high density of sensors on flat portable mats. Their 2m x 1m mat boasts over 16,000 sensors. The cost of these devices is consequently higher, on the order of $8,000 to $15,000 for a mat and the accompanying hardware and software. RsScan Lat differs from TekScan in the breadth of their offerings: currently their primary product is the Footscan system, and they do not manufacture and distribute sensors the way TekScan does. They do offer a downstream product: they manufacture custom inserts for users who provide them with Footscan data. 
4. MIT Media lab. In 2002, a group at the Media Lab released a paper detailing a pressure and orientation sensor shoe very similar to the insert system we are developing. However, the final product was hardware-heavy (it had a large hardware component sticking out the back of the shoe), and we did not like the fact that the wearer could not wear his/her shoes of choice. Furthermore, it would be inconvenient to wear the shoes they developed in public while the user goes about their daily activities, which is necessary for the kind of monitoring that we have in mind. 

Essentially, the biggest hindrances presented by the options available now are wearability and price.

In terms of desired outcome, our insert will be very thin--definitely less than 1 cm thick--and seek to be as unnoticeable as possible to both the wearer and people around them. Then data could be recorded as they go about their usual routine (or, if desired, during a specific athletic activity, etc.) and more accurately reflect their behavior than a brief walking or running test in a clinic (this is especially useful for diagnosing children, in this case). We want these inserts to be low-cost enough when scaled-up so that clinics could have many pairs in various sizes at their disposal (we're aiming for <$100/pair in the end).

Sorry this post has been so long so far! We just have a lot of progress to catch you up on, haha...

Reverse Engineering

While we're at it (sorry!), here is a breakdown of one of the major competing devices in the market today:

F-SCAN SYSTEM BY TEKSCAN, INC.

Tekscan has created a variety of force sensors and pressure mapping applications including the F-Scan System, an in-shoe plantar pressure analysis device. This system offers both wireless and wired recording of pressure mapping of the feet. Data is logged into a separate compartment worn at the waist or transmitted via a RF signal to a computer with a receiver. This pressure mapping data is then analyzed and visually shown on custom computer software developed by Tekscan. 

We could not get a physical device to take apart because these systems cost approximately $4,995 each. Instead, we looked for patents related to the device to get an idea of what was inside.

This technology is referenced in US 7,758,523 B2 patent created by Kineteks Corporation for a shoe insert apparatus that can function remotely. Transmitters are placed in the lower portion of the sole insert in a cavity located under the arch of the foot. The holding cavity could be molded into an arch support, which would then contain a circuit board. This circuit board contains a battery for power, the transmitter for sending RF signals to a receiver, a receiver to receive RF signals from a remote transmitter or from the transmitter located on the same circuit board, a sampling circuit to test the signals from the force sensors, and a conversion circuit to convert the signals to be suitable to be sent through a RF signal. Data logging capability through integrated memory may also be included in the final design. 

Force sensors are placed almost symmetrically along the transverse and longitudinal axes of the foot with respect to the transmitter cavity. Additional sensors are placed with particular attention to the metatarsophalageal joint supports and the first toe.

Figure 1. Patent and product images for competing device from TekScan. Left: Depiction of the top view of the device stipulated in Patent US 7,758,523 B21. As mentioned it depicts the position of the cavity insert and the force sensors to be used with the device. Middle: Depiction of the F-Scan System data analysis for a case study of diabetic ulcer treatment using this system2. Right: Data analysis of the movement of the foot coupled with pressure distribution mapping of the RSscan system3. 

This technology seems to be integrated not only into Tekscan's F-Scan System but also in RSscan International's RSscan products. They both offer very similar functionality, but RSscan demonstrates a more advanced user interface with additional data analysis capabilities. In addition, the F-Scan System uses their own force sensors that they have developed and are selling separately as well. The F-Scan System seems to fit into TekScan's business strategy quite well: with many of their systems, they are  essentially developing applications for their own sensors. They have a market advantage in many respects by doing so, too, since they control the quality and supply of the systems' main components--a clear form of vertical integration. While we don't have that kind of capability, we find through the online reviews of numerous F-Scan users (easily found via Google) that it is considered to be feature-heavy to a fault in some cases: it is designed to satisfy a wide range of needs, but this in turn raises the unit cost, and physicians in podiatry clinics remark that they only use the most basic functions. If we could develop a device that focuses only on all of the most commonly used features of products like the F-Scan, we could significantly reduce the cost to physicians (and therefore, generally, patients).

Our device will use a similar technology with a wired system using force sensors at similar locations emphasizing the first toe, the metatarsophalageal joint supports, and the heel. This pressure mapping data is routed to a central device worn at the hip and processed into a data string to be incorporated into a text file on a SD card. These processed signals are then uploaded onto a computer to be analyzed for both pressure distribution mapping with respect to time and foot orientation as the foot moves through space with respect to time. We thought that the incorporation of the circuitry into the arch would be nice, but that would mean we also need alternative versions for, say, people who are flat-footed, for comfort reasons. Thus we decided to just incorporate all of the circuitry into the belt-clipped portion of our system.

In addition, cost is a major parameter that we want to address in our own device: having such a product priced at $4,995 makes this kind of system rather impractical for smaller-scale clinical use. As such, we found that it is mostly reserved for athletes at the Olympic level and large podiatry clinics. We would like to design one with lower-cost but high-performance sensors that would allow many pairs to be available at a time, even in small clinical settings.

References:

Armand, S., and Watelain, E. (2007). Linking clinical measurements and kinematics gait patterns of toe walking using fuzzy decision trees. Gait and Posture, 25 (3):p.475-484.

Arlett, J. (n.d.). Case study: Diabetic ulcer treated with f-scan. Retrieved from  http://www.tekscan.com/diabetic-ulcer-charcot-foot

Bild, D.E., Selby, J.V., Sinnock, P., Browner, W.S., Braveman, P., Showstack, J.A. (1989). Lower-Extremity Amputation in People with Diabetes: Epidemiology and Prevention. Diabetes Care, 12, 24-31.

Center for Chronic Disease Prevention and Health Promotion. (2011) Diabetes Fact Sheet: national estimates and general information diabetes and prediabetes in the United States, 2011. Atlanta, GA: Centers for Disease Control and Prevention.

Chaudhry, V., Corse, A.M., O'Brian, R., Cornblath,D.R., Klein, A.S., and Thuluvath, P.J. (1999). Autonomic and Peripheral (sensorimotor) Neuropathy in Chronic Liver Disease: A Clinical and Electrophysiologic Study. Hepatology, 29.6, 1698-703.

 Clinics: Orthopedic surgeons, orthopedic technicians, podiatry. (2012, May 04). Retrieved from http://www.rsscan.com/

Collings, T. D., & Younker, J. R. United States Patent, (2010). Remote sensing shoe insert apparatus, method and system (US 7,758,523 B2)

Elliott, M.T., Ma, X., and Brett, P.N. (2009). A smart sensing platform for the classification of ambulatory patterns. Proceedings of the Institution of Mechanical Engineers, part H: Journal of Engineering in Medicne. DOI: 10.1243/09544119JEIM523

Krishnhan, K. and Arun, M. (2009). Neurological complications of chronic kidney disease. Nature Reviews Neurology, 5, 542-551.

Low, D.C. and Dixon, S.J. (2010). Footscan pressure insoles: Accuracy and reliability of force and pressure measurements in running. Gait and Posture, 32 (4): 664-666.

Morris, S.J. and Paradiso, J.A. A compact wearable sensor package for clinical gait monitoring. Offspring Vol. 1, No. 1, pp. 7-15.

National Institutes of Health. National Institute of Diabetes and Digestive and Kidney Diseases. (2009). Diabetic Neuropathies: The Nerve Damage of Diabetes. National Diabetes InformationClearinghouse (NDIC), Accessed 1 May 2012. <http://diabetes.niddk.nih.gov/dm/pubs/neuropathies/>.

National Institutes of Health. National Institute of Diabetes and Digestive and Kidney Diseases. (2011).

Chronic Kidney Disease and Kidney Failure: Fact Sheet. Research Portfolio Online Reporting Tools. Accessed 1 May 2012. <http://report.nih.gov/nihfactsheets/ViewFactSheet.aspx?csid=34>

National Institutes of Health. National Institute on Alcohol Abuse and Alcoholism (2012). Fact sheet for the general public. Accessed 1 May 2012. <http://www.niaaa.nih.gov/FAQs/General-English/Pages/default.aspx>

Pendharkar, G., Lai, D.T.H., and Begg, R.K. (2008). Detecting Idiopathic Toe-Walking gait pattern form normal gait pattern using heel accelerometry data and Support Vector Machines. 30^th Annual International IEEE EMBS Conference, 4920-4923.

RsScan Lab, Ltd. Footscan^R Advanced Pressure Measurement Systems: Systems. Retrieved May 1, 2012, from: http://www.rsscan.co.uk/systems.php

Sensor Products, Inc. (2012). Fujifilm Prescale Tactile Pressure Indicating Sensor Film. Retrieved April 22, 2012, from: http://www.sensorprod.com/static/lamination.php

Shetreat-Klein, M., Shinnar, S., and Rapin, I. (2012). Abnormalities of joint mobility and gait in children with autism spectrum disorders. Brain and Development, doi:10.1016/j.braindev.2012.02.005.

TekScan, Inc. (2007). PreScale^TM Digital Analysis Systems. Retrieved April 18, 2012, from: http://www.tekscan.com/prescale-digital-analysis-system

United States Census Bureau. (2010). 2010 Census Data. Accessed 1 May 2012. < http://2010.census.gov/2010 census/data/>

Valmassy, R. (1996)  Clinical Biomechanics of the Lower Extremities, Missouri  Mosby. Pp 249, 250.

Wren, T. (2004). Gastrocnemiussoleus lengths in cerebral palsy equinus gait-differences between children with and without static contracture and effects of gastrocnemius recession. Journal of Biomechanics, 37(9): 1321-7.

Challenge Labs!

IR Remote Challenge Lab!

The components:

Processing Lab

Code for the Arduino:

void setup() {

Serial.begin(9600);

}

void loop() {

Serial.println(analogRead(A0));

delay(10);

}

// Graphing sketch

// This program takes ASCII-encoded strings

// from the serial port at 9600 baud and graphs them. It expects 

values in the

// range 0 to 1023, followed by a newline, or newline and 

carriage return

// This example code is in the public domain.

import processing.serial.*;

Serial myPort;  // The serial port

int xPos = 1;  // horizontal position of the graph

void setup () {

// set the window size:

size(400, 300); 

// List all the available serial ports

println(Serial.list());

myPort = new Serial(this, Serial.list()[1], 9600);

character:

myPort.bufferUntil('\n');

// set inital background:background(0);

}

void draw () {

// everything happens in the serialEvent()

}

void serialEvent (Serial myPort) {

// get the ASCII string:

String inString = myPort.readStringUntil('\n');

if (inString != null) {

// trim off any whitespace:

inString = trim(inString);

// convert to an int and map to the screen height:

float inByte = float(inString);

inByte = map(inByte, 0, 1023, 0, height);

// draw the line:

stroke(127,34,255);

line(xPos, height, xPos, height - inByte);

// at the edge of the screen, go back to the beginning:

if (xPos >= width) {

xPos = 0;

background(0);

}

else {

// increment the horizontal position:

xPos++;

}

}

}

And the color mixing code for the Arduino:

const int redPin = A0; // sensor to control red color

const int greenPin = A1; // sensor to control green color

const int bluePin = A2; // sensor to control blue color

void setup()

{

Serial.begin(9600);

}

void loop()

{

Serial.print(analogRead(redPin));

Serial.print(",");

Serial.print(analogRead(greenPin));

Serial.print(",");

Serial.println(analogRead(bluePin));

And finally, more code for Processing to run:

import processing.serial.*;

float redValue = 0;  // red value

float greenValue = 0;  // green value

float blueValue = 0;  // blue value

Serial myPort;

void setup() {

size(200, 200);

println(Serial.list());

myPort = new Serial(this, Serial.list()[1], 9600);

// don't generate a serialEvent() unless you get a newline 

character:

myPort.bufferUntil('\n');

}

void draw() {

// set the background color with the color values:

background(redValue, greenValue, blueValue);

}

void serialEvent(Serial myPort) {

String inString = myPort.readStringUntil('\n');

if (inString != null) {

// trim off any whitespace:

inString = trim(inString);

// split the string on the commas and convert the

// resulting substrings into an integer array:

float[] colors = float(split(inString, ","));

// if the array has at least three elements, you know

// you got the whole thing.  Put the numbers in the

// color variables:

if (colors.length >=3) {

// map them to the range 0-255:

redValue = map(colors[0], 0, 1023, 0, 255);

greenValue = map(colors[1], 0, 1023, 0, 255);

blueValue = map(colors[2], 0, 1023, 0, 255);

}

}

We found that each potentiometer "controls" the amount of one primary color (red, green, or blue) present in the Processing display window. By turning them in various combinations, we could produce every color from black to white to periwinkle blue and auburn red. I think we had the most fun with this challenge lab, if only because could think of a lot of interesting and fun potential applications and it was relatively straightforward to implement (doesn't it feel nice when you run things and they all work the first time?). ^^

Lab 4 Exercises

Hi world,

Long time, no post (kind of...)! Here are Lab 4 exercises...


Storing in non-volatile memory.


One approach:


#include <EEPROM.h>

int readvalue;
int command;
int input;
int buffer;
int address = 0;
int valueArray[] = {255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255}; // Used only for testing code

void setup() {
Serial.begin(9600);
}

void loop() {
command = Serial.read();

if (command == 'w')
{
Serial.print("What would you like to store in address #");
Serial.print(address);
Serial.println("?");
Serial.flush();
input = Serial.read();
//Serial.println(input);
while (input == -1) {
if(Serial.available()>0){
delay(15);
buffer = 0;
input = 0;
 
while(Serial.available()>0){
buffer = Serial.read();
input = input*10 + (buffer-'0');
}
}
}

EEPROM.write(address,input);
valueArray[address] = input;
Serial.println(address);
Serial.println(input);
Serial.println("Okay!");
address++;
if (address == 512)
{
  address = 0;
}
}

if (command == 'r') {

readvalue = 0;
for (int i = 0; readvalue != 255; i++) {
readvalue = EEPROM.read(i);
//readvalue = valueArray[i];

if (readvalue != 255){
Serial.println(readvalue);
}
else if (readvalue == 255)
{
 Serial.println("The address #");
 Serial.print(i);
 Serial.println(" is empty");
}
}
}

This one doesn't have a clear-all feature :(

And another approach (arguably superior, haha):


#include <EEPROM.h>

int buffer = 0;
int value = 0;
byte valueByte;
int address = 1;
int counterAddress = 0;
int keyPress = 0;
//int valueArray[] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; // Used only for testing code

void setup(){
Serial.begin(9600);
Serial.println("Start:");
}

void loop(){
keyPress = 0;
if(Serial.available()>0){
delay(5);
keyPress = Serial.read();
if(keyPress == 'w'){
Serial.print("Enter number to address ");
Serial.println(address);
while(1){
if(Serial.available()>0){
delay(15);
value = 0;
valueByte = 0;
while(Serial.available()>0){
buffer = Serial.read();
value = value*10 + (buffer-'0');
}
       
valueByte = byte(value);
Serial.print("saving ");
Serial.print(value);
Serial.print(" at ");
Serial.println(address);
//valueArray[address] = value; // Used only for testing code
EEPROM.write(address, valueByte); // EEPROM writing
address++;
EEPROM.write(counterAddress, byte(address));
break;
}
}
//Serial.println("Out of loop"); // Used for testing only
}
 
else if(keyPress == 'r'){
Serial.println("Reading all values in EEPROM array:");
for(int i=1;i<EEPROM.read(counterAddress);i++){
Serial.print(i);
Serial.print(" ");
//Serial.println(valueArray[i]); // Used only for testing
Serial.println(int(EEPROM.read(i)));
}
}
 
 else if(keyPress == 'q'){
 Serial.println("Do you want to reset the addresses? (y/n)");
 while(1){
 if(Serial.available()>0){
 delay(5);
 keyPress = Serial.read();
 if(keyPress == 'y'){
 address = 1;
 EEPROM.write(counterAddress,byte(0));
 break;
 }

if(keyPress == 'n'){
break;
}
}
}
}
 
else{
Serial.println("Unrecognized Key");
}
}
}

...........

And here's Winslow's massive code for the data-logger portion of the lab @_@...........

Build a data-logger.

#include <EEPROM.h>

int sensorPin = 3;

unsigned long time;

unsigned long startTime;

unsigned long endTime;

unsigned long testDuration = 180000;

unsigned long takeSample = 15000;

int counter = 0;

int value = 0;

byte valueByte;

int address = 1;

int counterAddress = 0;

int keyPress = 0;

int valueArray[] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; // Used only for testing code

void setup(){

  Serial.begin(9600);

  Serial.println("Start:");

  Serial.println("Press w to record data or Press r to read data.");

}

void loop(){

  keyPress = 0;

  if(Serial.available()>0){

    delay(5);

    keyPress = Serial.read();

    if(keyPress == 'w'){

      startTime = millis();

      time = startTime;

      endTime = time + testDuration;

      while(time<=endTime){

        time = millis();

        if(time>=(counter*takeSample+startTime)){

          value = RCtime(sensorPin);

          valueByte = byte(value);

          Serial.print("saving "); 

          Serial.print(int(valueByte)); 

          Serial.print(" at "); 

          Serial.println(address);

          valueArray[address] = valueByte; // Used only for testing code

//          EEPROM.write(address, valueByte); // EEPROM writing

          address++;

          counter++;

//          EEPROM.write(counterAddress, byte(address));

          valueArray[0] = address; // Used only for testing code

        }

      }

      Serial.println("Finished Testing!"); // Used for testing only

    }

    else if(keyPress == 'r'){

      Serial.println("Reading all values from previous test:");

      for(int i=1;i<valueArray[0];i++){ // In actual code i<EEPROM.read(counterAddress)

        Serial.print(i);

        Serial.print(" ");

        Serial.println(int(valueArray[i])); // Used only for testing

//        Serial.println(EEPROM.read(i));

      }

    }

    else if(keyPress == 'q'){

      Serial.println("Do you want to reset the data? (y/n)");

      while(1){

        if(Serial.available()>0){

          delay(5);

          keyPress = Serial.read();

          if(keyPress == 'y'){

            address = 1;

            //EEPROM.write(counterAddress,byte(0));

            valueArray[0] = 0; // Used for testing code

            break;

          }

          if(keyPress == 'n'){

            break;

          }

        }

      }

    }

    else{

      Serial.println("Unrecognized Key");

    }

  }

}

long RCtime(int sensPin){

long result = 0;

pinMode(sensPin, OUTPUT); // make pin OUTPUT

digitalWrite(sensPin, HIGH); // make pin HIGH to discharge capacitor - study the schematic

delay(1); // wait a ms to make sure cap is discharged

pinMode(sensPin, INPUT); // turn pin into an input and time till pin goes low

digitalWrite(sensPin, LOW); // turn pullups off - or it won't work

while(digitalRead(sensPin)){ // wait for pin to go low

result++;

}

return result; // report results

}

.
.
.
.
.


And then, fun with servos:
.
.
.
.
.


unsigned long time;
unsigned int pulseTime = 1500;
unsigned int currentPulse = 1500;
unsigned long waitTime = 20000;
unsigned long stamp;
int servoPin = 6;
int buffer;
int modSub;

void setup(){
  Serial.begin(9600);
  pinMode(servoPin, OUTPUT);
  digitalWrite(servoPin, LOW);
  Serial.println("Start:");
  Serial.println("Enter pulse time in microseconds:");
}

void loop(){
  if(Serial.available()>0){
    delay(15);
    buffer = 0;
    currentPulse = pulseTime;
    pulseTime= 0;
    while(Serial.available()>0){
      buffer = Serial.read();
      pulseTime = pulseTime*10 + (buffer-'0');
    }
    if(pulseTime%10!=0){
      modSub = pulseTime%10;
      pulseTime -= modSub;
    }
    Serial.print("Pulse time is ");
    Serial.println(pulseTime);
  }
  if(micros() >= stamp+waitTime){
    stamp = micros();
    if(currentPulse!=pulseTime){
      if(currentPulse<pulseTime){
        currentPulse+=10;
      }
      if(currentPulse>pulseTime){
        currentPulse-=10;
      }
    }
    digitalWrite(servoPin, HIGH);
    delayMicroseconds(currentPulse);
    digitalWrite(servoPin, LOW);
    delay(10);
  }





.
.
.
.
.



unsigned int pulseTime = 1000;
unsigned long waitTime = 20000;
unsigned long waitTimeChange = 100;
unsigned long stamp;
unsigned long stampChange;
int servoPin = 6;
int buffer;
int changer;

void setup(){
  Serial.begin(9600);
  pinMode(servoPin, OUTPUT);
  digitalWrite(servoPin, LOW);
  Serial.println("Start:");
  Serial.println("Enter rotation speed in milliseconds:");
}

void loop(){
  if(Serial.available()>0){
    delay(15);
    waitTimeChange= 0;
    while(Serial.available()>0){
      buffer = Serial.read();
      waitTimeChange = waitTimeChange*10 + (buffer-'0');
    }
    if(waitTimeChange < 20){
      waitTimeChange = 20;
    }
    if(waitTimeChange > 1000){
      waitTimeChange = 1000;
    }
    Serial.print("Wait time between rotations is ");
    Serial.println(waitTimeChange);
  }
  if(pulseTime == 1000){
    changer = 0;
  }
  if(pulseTime == 2000){
    changer = 1;
  }
  if(micros() >= stamp+waitTime){
    stamp = micros();
    if(millis() >= stampChange+waitTimeChange){
      stampChange = millis();
      if(changer==0){
        pulseTime++;
      }
      if(changer==1){
        pulseTime--;
      }
    }
    digitalWrite(servoPin, HIGH);
    delayMicroseconds(pulseTime);
    digitalWrite(servoPin, LOW);
    delay(10);
  }
}