Spent yesterday compiling a list of tactics for accessing data. Will post full results as today unfolds….

Connecting a chuck to an Arduino

Just give me the code!

The solution I am working on is based upon code and examples from:

Code:

TodBot — code example and developer of the physical adaptor I am using.  This is a great  resource — so you may want to start there if you are stuck

growdown

Windmeadow Labs

Hardware
the adapter I am using can be found at sparkfun

High Level Map
Chuck speak I2C — a form of serial communication. You need 2 libraries to make this code work. The first is wire.h — which ships with Arduino. The second is some form of the wiiChuck libraries that others are developing. I have pulled two pieces of code from the above sites to create my solution.

There is nothing particularly novel about this stage — I just moved the power code block from Todbot over to the library from growdown. The samples I found seemed to have this missing.

I am cleaning code but this bundle is working for me. Set your serial monitor to 19200 to see the data in the Arduino environment.

On Friday, May 1 at 7:30pm., the New Media option at the School of Image Arts (Ryerson University) in association with the Kodak Lecture Series will be hosting a talk by interactive installation artist Camille Utterback.

Camille Utterback is an internationally acclaimed artist whose
interactive installations engage participants in a dynamic process of
kinesthetic discovery and play. Utterback’s work explores the
aesthetic and experimental possibilities of linking computational
systems to human movement and gesture. By creating installations that
use video tracking software to respond to a users body, she creates a
visceral connection between the real and the virtual. Her work focuses
attention on the continued relevance and richness of the body in our
increasingly mediated world.

WHEN: Friday May 1, 2009, 7:30pm
WHERE: Library Building, Room 72 (350 Victoria Street at Gould Street)
FREE: Arrive early for guaranteed seating

Visit www.ryersonlectures.ca

Jump to Camille’s Site.

Grab the sample code.

To complete this exercise, you will need to be able to find your machine’s IP. If you are unsure how to do that on a lab computer, check here.

Using the Server:

The server broadcasts sensor values to all connected clients.  This is a simple starting point for building distributed haptic experiences.  This code could be used in other contexts as well. 

Start by setting up the Arduino and Sensor.  Upload Arduino code – simple_SensorForServer.pde and connect and analog sensor (I am using a 1k pot) to analog input pin 0 (zero).  Next connect an Led to PWM pin 11.  Adjusting the sensor should alter the brightness of the LED.

Next, start the server by running the Processing sketch entitled  simple_teleServer.pde.  Sensor data should be picked up immediately.  Adjust the sensor again — a rectangle in the upper right of the server window should change colors.

Now, connect some clients.  

The client (simple_teleClient.pde) is slightly easier than the server to set-up.  All you need to do is set the server’s IP inside the client sketch and launch it. 

To do this, find the IP of the machine upon which you are running the server (see above if you are unsure about how to do this — it is for Tiger not Leopard — but should be clear enough).  Once you have the IP, you have to make a change in the client sketch.  The original line will look something like this:

  teleClient = new Client(this,”127.0.0.1″,12345);

Change the “127.0.0.1″  to your Server’s IP (put the IP in quotes).  

Now, launch the client.  If you connect, the server will display you on its screen.

You should also try this with an Arduino on the client side.  To do this you will  need to set up an LED as you did above.  Again, nothing facny — just insert it directly onto your Arduino. Flat side to ground, other leg to PIN 11.

Upload the code simple_valueOutput.pde to your client Arduino.    This code receives data from the client and converts it into LED brightness. 

You should be able to control both LEDs from the single sensor.

This post will cover a set up for communicating between two Arduinos with Xbee radios.  it is not the only solution but it is a start.  I will also describe how to organize a piece that enables a remote Arduino to communicates with processing via xBees.

I am assuming that you have configured your radios to talk to each other.

Connections for Serial Communication

When communicating between Arduinos with Xbees we need a different circuit than we used to configure the radio.  If you removed your Arduino chip to configure the radios you will need to replace it for the following to work.  Make sure you put the chip in the right way — notched end goes towards the edge of the board (I think that makes sense looking at the board, let me know).

The circuit is simple.  Power the xBee with 3.3V from the Arduino.  Next, for serial communication you need to connect two wires.  Connect Arduino RX (PIN 0) to xBee TX (labeled Dout on the xBee breakout board).  Connect Arduino Tx (PIN 1) to xBee Rx (labeled Din on the xBee breakout board).  If you have your xBee and Arduino facing the same ways as I do, your communication wires will cross over each other.  That is what you want.  (NOTE: this is different that the wiring used to configure the XBees).

Arduino talking to Xbee

Radio Connections Close-up!

A NOTE ON CODING

Important: You will need to disconnect one end of the serial communication wires you just connected EACH time you change the code in your Arduino.  Once the code uploads you can RECONNECT the serial communication wires.

The Whole System

Here is an example that uses xBee radios as a communication bridge between two Arduinos.  You will need:

• 2 xBee radios
• 2 Arduinos
• 2 LEDs
• 1 button (switch)
• wires, and some 1k and 10k resistors.
• sample CODE.

The system requires the sending radio to have the serial communication connections above as well as a digital switch (button) connected to PIN 2 and an LED connected to PIN 3. The receiving side has an xBee connected as above and an LED connected to the receiving Arduino on PIN 2.

Send Circuits

Recieve Circuits

When working this system will sense button presses, turn on the local LED and send a message via xBees to the remote Arduino. The remote Arduino receives the message and reflects the button state with its LED.

This is a one way system. I will post a two-way system later today.

Ya, But I want to Talk to Processing

If you want to talk to processing from a remote arduino then you have two choices.  Once use the system above — and receive serial from an arduino connected to the computer.

OR

Set up a slightly different system.  I think this is an easier solution — but you may disagree.  Use xBees to replace the cable you are using for communication. (NOTE: you will still need the cable to program your arduino — this is for once you have code in place.  Using radios to code is another story).

The system should be developed and debugged with the programming cable first with radios introduced at the end.  So I will assume you have some code that allows your arduino to talk to processing already — maybe a sensor reading or similar.

Once that is working, remove the programming cable and connect an xBee to your Arduino as above in THIS post.  At the computer side where processing is running connect an xBee as if you were about to configure it (ie with a FTDI breakout or a dechipped Arduino).

If you tell processing to look at the port where you just connected an xBee you should be receiving data — just as you were with the cable.

I need more HELP!

As always this is coved in Tom Igoe’s Making Things Talk.

Download PDF

Online Web Page:

Your documentation should be presented online as a part of your growing webpage / portfolio. So text, image and video should be embedded together in one place.

Feel free to use Vimeo or YouTube to create embedded videos for your web page. More visibility is always a good thing. However, do make sure you keep a high-quality copy of your video documentation for your archives (useful for presentations, off-line viewing, submissions, etc). We would appreciate if you tagged your videos with “Ryerson New Media”, in an effort to create a pool of works made at the school.

Text

Your web page should include two descriptions.

1) Project description – from a conceptual perspective, this text is idea driven and allows you to give voice to what drove you to make the work.

2) Technical description — addresses the inner workings, reveals details about relationships that might not be obvious by simply watching the piece in action. This description should include size, materials, space requirements, platforms.

Video

A 2 – 3 min video that tells the story of experiencing the work. This NOT a rock video, it is not cut to beat, it does not have a sound track UNLESS the piece has sound (see also voice over below). You want high quality images that show the audience what the piece is about. You should use a tripod and when necessary additional lights. Shoot LONG takes – you want people to understand the work.

As this is a story – you should shoot it like a narrative.

A minimal shot list includes:

• Title & Credits
  You should make sure you have a shot at the beginning with your project’s title, and a shot with credits at the end of the video (your name, date, school, etc)

• Establishing shot:
  – start wide, let the whole experience be visible in the frame. Let us look at the elements.

• Medium shot:
  – if this work is interactive, then have an “actor” come into the work and interact. Have them do what they are supposed to do. You may to choose to start this shot with someone in the frame. Make sure we understand this in relations to the first shot. Don’t go all Tarantino on your audience.
  - if the work is autonomous then move in and let the piece “perform”
  - you may want more than one angle of this action

• Close Up shots:
  - shoot close-ups of interactions – are there handheld interfaces? Is there a kiosk, an object? Get a close up of it in use and on its own.

• Medium Shot:
  - End with a medium shot – once we have seen what the layers are let us see the whole thing again. It allows us to integrate the information.

Technical Shots:

Include technical shots only as they are necessary for understanding the work.

If the technology is integral to the piece – as in an aesthetic or functional element then include them with the above video. If the piece is trying to conceal the technology then it may be better to have a technical video separate from the experience document.

This layer is usually more valuable for juries and organizations that want to see aspects of process. This is a judgment call – there are not hard and fast rules. Keep in mind that some people are deeply turned off by inner working videos. Giving an elegant pathway around this layer is wise.

Voice Over OR Title Slides

The work will often determine which is the correct approach. This is partly a judgment call – partly a functional issue. It is often more efficient to describe in spoken word. Text will force you to be more concise. Voice over with a sound piece really doesn’t work (I speak from experience here).

If you do opt for voice over – make a copy with only the sound inherent to the piece and a copy with your voice over. You may wish at some point to show the video without your dialog.

USE someone other than yourself to do the voice – IF at all possible write a script and have someone else read it. You will be grateful you did this in 5 years (months, weeks).

Stills

You should have high quality stills for print media (catalog, advert, the newspaper). These stills should be long shots (wide, establishing), medium shots and close ups. These are tripod held, lit shots, NOT frame grabs from your video – even if your video is HD – they are not frame grabs.

Most of the info in this post is discussed in depth by Tom Igoe in Making Things Talk, pages 193 – 206.

Configuring a radio for a simple network involves three steps: (1) assigning the radio a network (ID), (2) assigning the radio individual (MY) address, (3) assigning the radio a destination (DL,DH) or receiver.

Assign a Network Identity (ID)

The network ID identifies, or determines which radios can speak to each other.  Only radios with the same ID can communicate.  In most cases all of the radios in a single project will have the same ID.

Given that our radios are shared – you should always set the ID parameter for your project.

Assign an Individual identity (MY)

The MY address is the address of an individual radio. MY addresses are unique and each radio in your project should be assigned its own MY.

If two radios have the same MY then they will both receive all of the messages directed to that MY address.

Assign a Destination (DL, DH)

The destination parameter defines which radios will receive your message.  The destination is defined by 2 numbers DL – destination low, and DH- destination high.  For the most part you should set DH to 0.

You then set the DL value to match another radios MY.  All radios with DL // MY pairings will have a directional link (from DL to MY).

In their simplest mode xBee radios are a lot like telephones.  You have to tell your device which radio you want to call.  When configured manually each radio is only able to send messages to other radios on the same network (ID) with matching DL // MY parameters.

If you want to send and receive messages between two radios, set their MY and DL identically.  That way they will be able to talk to and hear each other.

Broadcasting Messages

When you set a radio’s DL parameter to ‘ffff’ (it is a hex number) it is in broadcast mode. When put into this mode, radios can send messages to all other devices on the network (ID) regardless of MY // DL pairings.

Settings for our Games

For the exercises we did these last two weeks the radios were configured as follows:

ID 3332
MY 0
DL  0
DH 0

It is worth considering how the rules of the various games would be relaxed or constrained by different settings.

Configuring the Radios

There are several methods for configuring the xBee radio.  If you own a PC or have a dual-boot Mac then you can use the manufacturer’s X-CTU software.  (All the Mac laptops are dual boot.  Some do not yet have the software – but we will correct that.)  On any machine you can use Tom Igoe’s Processing terminal program.  You can do this through terminal or any serial interface (including the Arduino environment).  You can even do it through Arduino code and reset a radio on the fly – useful if you need to send messages to different devices but don’t want to broadcast.  This last stage can be considered an advanced topic for this class – there are examples in the text – I won’t go too far into them.

Using X-CTU

This is the easiest way to configure the radios.  It is also the only way to upgrade their firmware.  You will not usually need to do firmware upgrades on school equipment – so I will return to that matter elsewhere.

RESTART one of the hybrid computing laptops and boot it up at a PC.  Connect a radio following any of the methods described in wiring an xBee.  Note you must connect before you launch the software on a Mac.  Don’t have a PC to test.  Launch the X-CTU software – icon should be on the Desktop.

The default screen is the PC settings tab.  There is a large menu for COM port setup.  Select the visible port (on a PC COM is for communication – it is a term carried over from the olden days.  COM ports are often aliased USB ports on current machines).  Confirm that serial settings are: Baud – 9600, Flow Control – none, DataBits – 8, Parity – none, stop bits – 1 (these are all defined in my serial notes on blackboard).

Next, click the Modem Configuration Tab.  Under model parameters and firmware on the left click Read.  A huge number of Settings appear – these were read from the radio itself.  You need to set the ID, MY, and DL, DH options under the first menu – Networking and Security.

To edit any value click on it and form box appears.  Reset to the value of choice.

Write this data to memory after you have changed all of your parameters by clicking Write.  It is beside Read in the menu near the top.

Repeat this for all of your radios.

Using Processing

Download and launch Tom Igoes xBee-terminal for Processing.  This system is less verbose than the X-CTU system above but it is more than functional.  As it is effectively a hack – you need to do a little more legwork. As I only have single boot Mac machine this is my usual process.

When you run this code the first time, you will need to set the serial port – just as we have been doing all term.  Check the serial.list() array and select your port.

When you run this code you will get a simple terminal screen.  It lists the port, what you are typing, and what you Receive from the radio.  Check the text pages 198 – 206 for numerous variations and many more details.

These radios follow historic modem commands.  Modems used to be programmed with a series of commands that were prefixed with AT.  All settings and actions below have AT as a prefix.

To begin, you must put the radio in Command Mode (default mode is communcate).  In the following, type the characters between <> not the <> themselves.  The ‘\r’ means return.  The radio will default back to communication mode within 10 sec of no input.  So you may have to type +++ a few times during you session with this method.

<+++>

the Radio should send OK – if it doesn’t, check your wiring.   Don’t TYPE return!!  just +++ and then wait.

Type:

<ATID\r>

xBee will return the current ID setting, small case works too — <atid\r> will give same response.

Similarly you can check and other setting MY, DL, DH by prefacing with AT.

<ATMY\r>
<ATDL\r>
<ATDH\r>

To change a setting type AT then the setting ID then the value of the attribute.  So to change the network we need to reset ID.  We would set the ID to 1111 with the following:

<ATID1111\r>

typed without spaces.  Confirm that you entered the value with

<ATID\r>

now save your changes by writing (WR) to the xBee.

<ATWR\r>

Always save after you make a change!  You can double check by disconnecting and then reconnecting the radio and querying its values as above.

Using a generic Serial InterFace

The biggest challenge to using a generic serial interface is the fact that xBees do not send new-line commands at ends of statements.  This means everything from the radio will appear to overwrite itself on screen (we saw this during our games).

If you get comfortable with the patterns with the Processing interface then this isn’t an issue.  I would not use this method until you have configured a few radios with the above methods – it can be confusing.

The process is the same as above – but with really garbled feedback – hence Tom’s decision to write the terminal software.

This post is an overview of some of the strategies for making electrical connections with equipment in our labs.  The start simple and become more complex.
!!!!REMEMBER XBEES ARE 3.3V DEVICES!!!

Strategy 1: xbee explorer

Available online and in the cabinet.

These are as easy as plugging in the radio and attaching the USB cable.  These boards supply the needed 3.3V automatically.  Look for the thin white outline on the board for orientation of the radio –  the “top” of the radio should face away from the cable connection.

If you solder header pins to the main board it can be attached to a breadboard — and then to your arduino.  As shown it can make direct connections to any software with serial capabilities.

Strategy 2: RS232-USB Breakout Boards

Available online (rs-232, xbee board) and in the cabinet.

This strategy is similar to the xbee explorer board above — but now split into two boards.  The right board carries the radio, the left board handles communication protocols (it can be used with lots of devices other than xbees too!).

Because you have two boards you now need to make power and serial connections — not just snap in the radio.  Grounds (green on left, black on right) for each board must be connected to the ground bus (blue rail on breadboard).  Power (3.3V) for the radio is brought from the RS232 breakout board to the radio via the yellow wire (details below).

Serial connections go from Rx of RS232 to Tx of xbee and vice versa.  The xbee boards label Rx as Din and Tx as Dout.  This is called crossing over (look at ends of blue and white wires above).  it may help to think of connecting ears (Rx) to voice (Tx) when speaking — but, then again maybe it won’t.

POWER — is 3.3V!

You need to be more aware of voltages with this strategy.  The RS232-USB board on the left can supply 5V

and 3.3V.  Power connect should go from the SECOND pin (yellow #2 below) on the RS-232 board to pin one (1) of the xbee breakout board. Pin 1 carries 5V — so you need to double check before connecting the USB cable.

Strategy 3: Use Your Arduino Board

For this strategy you must remove your micro-controller chip — you can then use the Arduino board as if it were an RS232 breakout board.  Removing the chip straight forward (if you don’t have a chip puller, a screwdriver can be used to gently lift it out)– just go slow and be patient.  Remember to note the orientation of your chip — the notch faces the outside of the board.  You will want to re-place the chip in the same orientation.

As in the breakout board strategy (#2) above — you need to make 4 connections: 3.3V, ground (gnd), Rx adn Tx.  In this case the Rx and Tx lines do not cross over (look carefully at the ends of the white and blue wires).

3.3 volt power can be obtained from the board (detail below).   The radio is wired as above.

Full release: cindyporemba_pressrelease