Mini Design Exercise 02

Kinetic Data Sculpture

Overview

Using the technical skills we’ve developed over the past three weeks, design and prototype a kinetic, sculptural visualization of a remote data stream. Legibility is NOT a requirement for this project. The goal here is to play with form and consider alternative implementations of the physical->digital->physical communication pipeline.

Requirements

  1. Final project is due at the end of class.
  2. Using the simple materials at hand, design a kinetic sculpture that changes its motion based on a remote, external, physical input.
  3. System must use two computers that speak to each other over a network
  4. One computer must pull in sensor data (either through arduino or the computer’s microphone)
  5. The other computer must control the motion of your physical design.
  6. Take a short video of the sculpture and post it to the blog.

Network Communication

The Network

The OSI model.

The layers of our common networking system are dense, complicated and not worth digging into at this time.

Addressing

IP Address

Each connected computer or microcontroller in a given network is considered a “device” or “host“. Each device in a given network will have an IP address. The IP address can be assigned by the device itself (setting a Static IP) or the address can be given to the device by a router using a process called DHCP. DHCP is most common in large wifi networks and is probably what your laptop is using now. We call this “dynamic.”

When communicating with an application on a different computer, you’ll need to know that computer’s IP address. If both computers are on the same network (same router or same large institutional network like CMU), connecting shouldn’t be a problem.

Networks almost always regulate how their devices access the internet. This means that directly communicating with a device outside of your immediate network can be tricky.

For most applications in this class, you’ll be working with devices on the same router. To make sure you have a clear communication path between devices, check the IP address on each. You can check this by typing ifconfig in the command line. Look for an inet address that is not 127.0.0.1 (which is your ‘localhost’ address, used for talking to other applications on the same device). The inet address may have an adddress such as 10.0.0.104 or 192.168.1.56. Communication shouldn’t be a problem if both devices are on the same subnet, which means the first 4 numbers of the IP address. Keep in mind, this only holds true if both devices are on the same network; so if Kim is in Indiana and his router gives him an IP of 192.168.1.56 and Pat is in Oregon and her router gives her an IP of 192.168.1.26, that doesn’t mean they can communicate, since their routers are on different networks (assuming no VPN, etc).

Ports

If you imagine that and IP address is like a device’s street address, the Port is like a given application’s apartment number within the device. When setting up a networking path on two applications, the listening application will need to declare which port it is listening to. This is usually a 4 or 5 digit number 12345 or 5555, etc. The sending application will also need to declare, along with the IP address, which port in the destination device its packets are intended to reach.

Port numbers less than 1000 are generally reserved and should not be used in your application. You should be aware of some specific ports, like 80 (which is the default port for HTTP) and 22 (which is reserved for SSH).

Protocols

UDP

User Datagram Protocol is a “transport level” protocol we often use for streaming continuous data. UDP is low latency and it does not require that the sender of UDP receive confirmation of receipt from the receiver. This means that UDP messages can get lost and nobody will know. We use UDP for streaming continuous information (people tracking, continuous sensor data, etc) because we want to get that information as soon as possible and we don’t care if packets are lost along the way because another packet will be coming right behind it.

UDP Drop Example

OSC

Open Sound Control is an “application level” protocol that sits on top of UDP and allows users to send formatted, human-readable messages. An example of an OSC message may be /sensors/A/value 54.2145 or /heartbeat "I'm alive" 20170206 0.15. We often use OSC to stream sensor data between applications, as it is easier to read and route than plain UDP. OSC does have some overhead, so if you need to send a ton of data and bandwidth is an issue, you may want to develop a protocol based on straight UDP.

Test It!

  1. In Processing, install the oscP5 package.
  2. Open the oscP5sendReceive example (file>examples>contributed libraries>oscP5>oscP5sendReceived)
  3. Find your IP address (on macOs, hold the option key while clicking the wifi icon)
  4. Give your IP address to a friend, get an IP address from a friend.
  5. on line 26 of the example, myRemoteLocation = new NetAddress("127.0.0.1",12000); change 127.0.0.1 to your friend’s IP address.
  6. Run the example.
  7. Modify the messages and protocol that you send each other.

Sample Code From Class

TCP

Transmission Control Protocol is the “transport level” protocol on which HTTP runs. TCP is slower than UDP because it requires a confirmation of receipt for each message. We use TCP for sending information that MUST reach its destination. For example if we want to send updates from our FitBit to a server every 10 minutes, we would use a protocol based on TCP because if one of those FitBit update packets didn’t arrive, our system might fail. We usually do not use TCP for streaming continuous data.

At Home OSC Exercise

Overview

Build a closed system with a partner in which two computers speak to each other using OSC.

Requirements
– One computer must read a sensor.
– Send the sensor data to the other computer.
– The other computer must use that data to control a physical output.
– Post a video of your system to the blog.

Transistors + Motors

Transistors & Actuators

Transistors

Since you shouldn’t (and usually can’t) power high-draw devices using the Arduino, you should power them via an external power supply. But what if you want to control when they receive power? You can do that with a Transistor.

Transistors are essentially switches, except they are switched open and closed with electricity instead of a mechanical action. They exist in two main forms (at least with what we’ll be using): BJTs (Bipolar Junction Transistor) and MOSFETs (Metal-Oxide Semiconductor Field-Effect Transistor).

This example shows a high-power LED being powered by a 5V power source, but being controlled by a Transistor hooked up to a microcontroller. When the control voltage goes HIGH, the electricity is allowed to pass through. When it goes LOW, no electricity can pass through the transistor, so the LED can’t turn on.


There are two types of BJTs — NPNs and PNPs.

In diagrams, the arrows for both are on the Emitters. On an NPN, the arrow is NOT POINTING IN. On a PNP, the arrow DOES POINT IN.

On an NPN transistor, the Emitter is connected to Ground, Collector is connected to the Current source you want to pass through, and the Base is connected to the Current source you want to use to control the Transistor. In PNP transistors, the Emitter and Collector are switched.


MOSFETs are very similar, except their pins are named Source, Drain, and Gate. Additionally, the two types are N-Channel and P-Channel.

In diagrams, the arrows are always on the Gate. On N-Channel MOSFETS, the arrow points IN, and on P-Channels it points OUT.

In an N-Channel MOSFET, the Source is connected to ground, the Drain is connected to your high-powered circuit, and the Gate is connected to the control to switch the MOSFET on or off. In P-Channel MOSFETS, the Source and Drain are switched.

DC Motors

DC Motors are a very simple type of motor that turns at varying speeds depending on how much voltage is supplied.

They are exteremely simple to use. Simply connect one wire to power, and the other wire to ground to make the motor spin one way. Flip the wires around to make it spin the other way. You can determine what Voltage to use by looking at the motor’s datsheet.


These motors, for example, have a suggested Voltage of 4.5V DC, and will pull 250mA of current at max load.

Exercise 2.1: Using a Transistor to Control a DC Motor

  1. Connect your motor to a Power Supply, and give it 4.5V to see it spin. Flip the wires around the other way to see it spin backwards
  2. Design (draw or make in Fritzing) and build a circuit using an N-Channel MOSFET to power that motor via a Power Supply, and control it via an Arduino (you should use the Blink example as a starting point)

Servos

Servos are a little more complicated than regular DC motors. While generally not as strong, you can control the exact speed at which a servo turns, as well as the direction and position it turns to.

To do this, Servos have three wires: Ground, Power, and Control. The colors vary on different servos, but for the most part, red is usually power, black/brown is usually ground, and white/yellow is usually control.

Servos have some limitations. Most servo motors cannot rotate continuously; cheaper servos can have as little as 90° of rotation. Some servos, however, are known as continuous rotation, and can rotate in full circle indefinitely.

Exact control of a hobby servo is accomplished by sending a series of pulses to the device over the control line. We usually don’t generate our own pulses (they’re difficult to keep track of), and instead rely on existing libraries that have all of the potential commands already written.

Exercise 2.2: Controlling a Servo with a Potentiometer

  1. Connect a servo to your Arduino like so:

  1. Open the example code, File > Examples > Servo > Sweep, and upload it to your Arduino
  2. Attach a Potentiometer to your system, and use it to control the exact positioning of the Servo (make use of the map() command)

Sources:

Joshua Noble’s Circuit Diagram Symbols – Programming Interactivity
Tom Igoe’s Understanding Electricity
Sparkfun’s Voltage, Current, Resistance, and Ohm’s Law, How to Read a Schematic, Motors and Selecting the Right One, and Hobby Servo Tutorial
ITP’s Electricity: the Basics
cmuphyscomp’s physcomp-examples
Oscar Liang’s How to Use MOSFET — Beginner’s Tutorial

In-Class Exercise 01 – Alex, MacKenzie, Soo Jin

RGB Play

Team: Alex Reed, MacKenzie Cherban, Soo Jin Sohn

This project uses a range of sensors to manipulate the output of an RGB LED. Users are able to manipulate the color and brightness of the LED separately. We explored ultrasonic (unsuccessfully), rotary, flex and pressure sensors, mapping their value to the brightness of the LED. Using manipulation of the keyboard, users are able to switch between the three color values, RGB, by pressing “R” for red, “G” for green, and “B” for blue.

Phys-Digi-Phys: 007 Team – Ammani | Lumi | Nitesh

Keeping the Jewels Safe (007 Style)

The purpose of this device is to sound an alarm when someone gets close to the jewels. An ultrasonic sensor is used to sense when someone is approaching. The LEDs simulate the alternating red and blue of the police and the speed of the LEDS is determined by the proximity of the person to the sensor. The closer a person gets, the quicker the lights alternate. Once the person crosses a threshold (gets too close to the jewels), an alarm (which has a catchy tune) is set off. To switch the alarm off, a tilt sensor is used.

Components Used:

  1. Sensors
    1. Ultrasonic Sensor
    2. Tilt Sensor
  2. Actuators
    1. 4 LEDs
    2. Speaker