Archive for the ‘Networked Objects’ Category
This post is a summary of working with the data logging aspect of this project.
- Tom suggested 2 options to me for how I would record the RFID tags so that I could correlate them to URLs later. There was the DOS ON chip, which would write text files to a micro SD card; and the VDIP chip, which would write text files to a USB thumb drive. He directed me to Steven Litt for the former and John Dimatos for the latter, and since John had a spare VDIP which he very generously lent me, I started out trying that first.
- Initial experiments with the VDIP by itself proved successful, both with hardware serial and software serial. There was existing code on the Arduino playground here and also code from someone who tried to use th VDIP with software serial. With John’s help I got it to work with AF Soft Serial – it was writing numbers to text files automatically.
- As mentioned in the RFID post, trying to get the two to work together straight away proved unsuccessful. When I spilt the processes and tried to learn how to better control use of the VDIP, I ran into some massive weirdness. After several consultations with Tom, and hours of experimenting with different USB drives (including have to buy 2 brand new ones, to have ‘control’ drives) I learnt the following important things:
a) Format is very important. In my experimentations, I screwed up my Imation thumb drive, and had to reformat it. I did so, in Mac format, thinking nothing of it. Thereafter, all hell broke loose. The VDIP wouldn’t recognise it, wouldn’t write to it, wouldn’t read what was on it. I borrowed thumb drives from a couple of classmates, and saw variations of weirdness. It would appear to have written a file, but the name of the file was garbled, and when I clicked on it on the computer in Finder, it disappeared. On hindsight their drives may have been in Mac format too, since both were Mac users.
b) The more times you reformat a thumb drive, the more sluggishly it runs on the VDIP. This is what I noticed. I still don’t know why, it just does. After reformatting 2 of my thumb drives (in Microsoft FAT 16 format) and noticing the change, I bought a new thumb drive (yet another!) and kept it as a control, new, never-reformatted drive.
- In between VDIP dramas, I did explore the DOS On option. That turned out even worse. Of those wasted 2 days I will say little, except I had real difficulty controlling it. Rather annoying, since the DOS On was $45 to the VDIP’s $25. Since I did buy one though, I intend to give it another go in the summer holidays.
This post is a summary of working with the RFID aspect of this project.
- I started out by testing the RFID reader and tags I had bought. I soldered the reader to the breakout board, making it that much easier/neater to use. I followed the example in Tom’s book to check that the reader worked and to get the IDs of the 2 tags I had. So far, so good.
- I’m using a VDIP chip to write tag IDs into text files on a USB thumb drive. Problem: RFID reader needs RX, VDIP also needs RX (and TX); Arduino of course only has one RX and one TX. What to do? After asking Tom Gerhardt and having him warn me off software serial, I had a look at some VDIP info John Dimatos had sent me (he’s using the VDIP in one of his projects too) and saw that someone had successfully used AF Soft Serial to control the VDIP.
- The test in Tom’s book is for getting tag IDs using Processing. I need to get the IDs into Arduino so that I can write them to the thumb drive via the VDIP. This part was a bit trickier, since I wasn’t being systematic enough at this point and tried to get the hardware Serial to read the tags and pass them straight into the VDIP using AF Soft Serial, which wasn’t working. For starters, the tag IDs were coming out funny – every other number was being dropped, for some reason. Spent too much time banging my head on this particular wall before deciding I needed to split up the processes. Also, rather than doing a straight read, maybe passing the tag ID into a string instead might work better.
- Attempting to get the tag IDs in Arduino was proving odder/more frustrating than I thought. I know every tag should start with a 2 and end with a 13, a 10 and finally close with a 3. To sum up, I was expecting a string of 15 things, but when I ran that, I kept getting a 0 and a 15 that shouldn’t have been there, and the numbers I was expecting would get displaced into the next line. Ad infinitum. Eventually when I expanded the string to 17 things, it stopped displacing numbers. But I still don’t know what the null (0) and that extra number (that was sometimes 15 and sometimes 16) were about.
Being in Cabinets of Wonder has made me think a lot about curated experiences – museums, arts festivals, and the like. Influenced also by my Art and the Brain class, I started out wanting to make a device that you would use in an art museum like the MoMA, where if you saw a painting that you liked, you could scan it with a device (that could perhaps be integrated into existing audio tour devices). At the end of your visit, the IDs of the paintings that you took interest in would be collated, and you would be emailed with neuroaesthetic information/ideas that related to the works that you responded strongly to.
This led into thinking specifically about the ITP Show, and about conversations I’ve had in the past with people about how overwhelming the sheer volume of work is and how hard it is to keep track sometimes of the work you like, for revisiting at a later stage. A central topic of our Cabinets of Wonder classes is how many museums (like the AMNH) are currently very much concerned with how to expand the museum beyond its physical building. I decided then that I would like to try my hand at extending the experience of the Show beyond what happens on the floor for two days each semester.
At present, coverage of the Show – its projects and the students who make them – is scattered across the intertubes in newspaper articles, tech blogs, sites like Boing Boing and Makezine and the personal websites of visitors who visit the show and respond to the things they see. These sites provide feedback on the projects (from the authors of the article; and on many sites, comments from readers), but are not comprehensive in the information about the projects and their makers. The ITP website has thorough information, but no allowance for response. I would like to see a site that is a combination of both – something that serves as a source of information for visitors who wish to further explore the Show content after they’ve left the floor, and a place where students could go and see comments visitors have made about their projects and even photos that people may have taken and wish to share/publish as part of this repository.
In order to do this, I have to capture the focus of visitors, to direct them to this off-site place that will serve them by providing them with the information they seek, and in so doing encourage them to give feedback on what they saw, which benefits us. I plan to do this by making a portable device that a visitor to the Show carries around with them and uses to collect information on projects that they like, that they want to look up later.
I’m thinking of using RFID, and at the moment I think the tags will be on the projects and the reader will be with the user. This is simply for practical fiscal purposes, as buying 100 RFID tags at $2 a pop may be expensive; but making 100 devices that would cost at least $30 each is impossible (for this grad student, anyway!).
For this ‘sensorbase’ assignment, we had to either set up sensors to capture data that would be logged; or we could use an existing source of data and present that physically.
I worked with Corey on this; and initially we had wanted to set up sensors at the lifts on the 4th floor as well as the door to the stairwell, so that we could compare how often people used lifts as opposed to the stairs. We changed our minds for a few reasons. 1) We found out that this particular exercise had already been done, and for this class, too. 2) Although ‘slogging’ was new to us, we’d worked with sensors often enough and thought we might try doing something different. So we decided to visualise existing data instead.
We wanted a display that was physical but unobtrusive, something that could just sit, but was dynamic. We played with the idea of temperature data, but decided to do traffic data in the end, as that was less commonly used than weather data. We had a very strong image of a road, so that’s what our display ended up being – a road with lines that pulsed with a light sequence that was quicker or slower depending on what the current traffic conditions in Mahattan were. We hoped it would simulate the lines flashing by as you drive along the highway, and we put a city skyline in the horizon to give it urban context.
To get traffic information, we used a PHP script to scrape XML data from the RSS feed of the Yahoo traffic page set for Manhattan. We counted each incident by looking for the < item > tag that precedes and translated the number of incidents into a speed for our LED sequence.
The PHP and Arduino codes are here and the photos are below.
Our assignment for how to use the Xport involved making a controller that we could use to play Pong on the network together. I wanted to a controller that encouraged movement, rather than something one could sit statically and use. I decided to make controllers that you could insert into each shoe, so that in order to move your paddle left and right, you had to hop from one foot to the other.
I used two force-sensitive resistors – the big square ones – and sandwiched them between two shoe inserts. I thought about putting the FSR on a piece of cardboard and then the shoe insert on top, but from past experience I knew that they’re incredibly sensitive, so the more padding the better. I placed the FSRs at the top of the inserts so that they would be activated by the balls of ones feet, rather than the heels. Good way to develop calf muscles. Heh.
Learning from past experience, I didn’t solder the FSRs but used wire wrap instead, which worked perfectly. The thinness of the wire was a bit fiddly though, given the length needed to connect the shoe inserts to the breadboard while giving enough slack to allow for movement. I also wire wrapped the ends of the wires to headers that stuck nicely into the breadboard.
Thanks to Tom’s book, and the fact that he constructed the game code and we didn’t have to (thank gourd!) the assignment was incredibly manageable. There was already code in the book for controllers using FSRs so all I had to do was modify that. Amazingly, I got it to work.
Here is the code, and below are photos of my controller as well as photos from class where we all played pong together. Good times.