The week 6 lab is an introduction to DC motors and transistors.  Our midterm project will incorporate a motor, so this lab (as well as week 7) will help us determine which type of motor to use and how to set up our circuit.

First, we set up the circuit with a potentiometer, a transistor, a small DC motor, and an additional power supply for the motor.  You can control both the direction and the speed of a DC motor.  Direction is controlled by which lead is connected to power — to reverse the direction, just reverse the polarity.  Speed is controlled by voltage — to achieve a slower speed, reduce the voltage, for a faster speed, increase the voltage.  In this lab, we will use the potentiometer to control the speed of the DC motor.

Here are a couple pictures of the circuit setup:

Because the DC motor receives power from a separate power supply that is greater than the 5v supplied by the Arduino, it’s necessary to include a transistor which acts like a switch.  The transistor has three legs: the base (which is connected to the Arduino output), the collector (connected to the high-current load), and the emitter (connected to ground).  One final component is a diode on the connector leg.  When the DC motor stops spinning, some current will come back in the reverse direction of the current flow.  The diode prevents this back voltage from reaching (and harming) the transistor.

Now that the circuit is complete, we write some code for the Arduino (no Processing in this lab) to move the motor.  The first program makes the motor spin, pause, repeat.  Here’s a video: DCMotor_StartAndStop_Wk6Lab_121105

The second program uses the potentiometer to control the speed of the motor.  Here’s a video of that:DCMotor_PotControls_LabWk6

This little DC motor spins surprisingly fast.  I had attached a little paper flag to better visualize the movement and it flew off immediately.  I had to replace it with a piece of very sticky tape.

The week 5 lab for Physical Computing was on serial duplex, an expansion of last week’s lab on serial communication.  This lab took me a long time to complete, I think because of the amount of code there was to understand and replicate.

In this lab, we set up a circuit with two analog inputs and one digital input.  I used a FSR, a photocell, and a button.  The first step was to simply send and read the data in the serial monitor.  We programmed the Arduino to send the data from one sensor in many different formats — including raw binary, ASCII encoded binary, ASCII encoded decimal, hexadecimal, and octal.  Here is a picture of my circuit setup and a screenshot of the serial monitor:

Circuit Setup for Week 5 Lab – Serial Duplex

Data in Many Formats

The next step in the lab was to put together the code to send the values of all three inputs instead of just one and figure out which value corresponds to which sensor.  This lab covers both the punctuation method and the call-and-response (handshake) method.

Punctuation Method: The first part uses the punctuation method which means that each set of data (in this case, one reading from each of three sensors) ends with a specific type of punctuation to indicate that’s the end, this data set is now complete. We wrote the Arduino code that reads the value from each sensor, prints the sensor value, then prints a comma after the first two sensor readings.  For the final sensor, we use Serial.println instead of Serial.print so that we get a carriage return and a linefeed at the end.  The result is three numbers separated by commas on each line and we know that the first value corresponds to the analog sensor in A0 (the photocell), the second value corresponds to the analog sensor in A1 (the FSR), and the third value corresponds to the switch.  Next we had to write the Processing code to receive and read the values.  (Eventually, we’ll use this information to draw a ball and make it move!)

Similar to the first serial communication lab, we have to import Processing’s serial library at the top of the code and make a global variable which will hold the serial port (in my case this is always 4).  We add a new line of code in setup: myPort.bufferUntil(‘\n’);  This line says wait to call serialEvent until the ASCII newline byte comes into the serial buffer.  ’\n’ means “newline” and the ASCII value for that is 10.  We get “newline” after the third sensor value has been read (that’s why we used Serial.println) so what this means is that the bytes will be read into the buffer until a linefeed is sent, then serial.Event will be called.

In serial.Event the sensor readings come in and are put in a string, then the string is split at the commas and the values are converted to integers.  Then we use a for loop to print out the sensor number and corresponding value.  Here’s a screenshot of Processing receiving the information from the sensors:

Processing Reads the Sensors!

What’s exciting is that now we have a bunch of integers that we can use to make something — like a ball that moves around.  To do this, we created some variables (xpos and ypos) and then assigned the sensor values to them.  (There’s a video at the end of this post.)

Call-and-Response Method: Next, we modified the code (both Arduino and Processing) so that Processing has to request new data when it’s done reading the data it has.  For Arduino, we added a method called establishContact() which sends out a message until it gets a byte of data.  Here’s a screenshot of the serial monitor after adjusting the code — it prints out “hello” until you type something into the box and hit “send”, at which point the sensor values are returned:

Hello!

In Processing, we create a new global variable called firstContact.  This determines whether or not Arduino has sent anything.  Processing will listen until it gets something from Arduino.  Once firstContact becomes true, then Processing will split the string at the commas and convert them to integers (just like in the punctuation method) and then print the sensor numbers and values.  After this unit of data has been parsed, we tell processing to write to the serial port which sends a request back to the microcontroller asking for more data.  And, again, we can use this information to make a ball and move it around.  This is a quicktime video of me controlling the ball with the photocell, FSR, and button.  The movement is erratic to say the least.  SerialDuplex_Wk5Lab_SensorsControlBall_121026

The results of using the punctuation method and the call-and-response method are the same in this lab — the format of the printed values and the movement of the ball look the same.  Although the code is complex, and I can’t say that I completely and fully understand it entirely, conceptually, I like the call-and-response method better.  Since the two devices are in communication with each other, it makes sense for this to go in both directions.  And it seems cleaner to send data one unit at a time when the receiving program is ready rather than just sending information continually and hoping that the receiving program can keep up.