MEDIA DIALECTICS TITLE FIGHT uses battling toy robots as a display mechanism for the occurence of opposing terms as they appear in media sources. Participants can choose selected key words to battle against each other such as Faith vs. Reason, Choice vs. Life, Democrat vs. Republican etc. Each keyword has several terms associated with it which, along with the keyword, are searched for in news RSS feeds from multiple sources. A higher frequency of the keyword's occurence will result in a more aggressive robot but does not guarantee a win. The winning robot, and therefore term, is determined only by the successful "decapitation" of the opponent robot. Results of all fights are stored on a server and are accessible via internet to any interested party.

 

 

after presenting my ideas I am hoping to make the following additions. Mode selection which allows the user to choose whether she is battling one RSS feed vs another, one word against another word on the same RSS feed or a manual selection mode in which the keyword is manually dialed in. Also, I want to make the button which begins the fight turn off when the pic is notaccepting further changes.

Basic idea:

a set of rock em sock em robots sits atop a pedestal. On the pedestal are two LCD screens, each with an associated knob, and a large button. When the device is turned on, it connects to the stage server and runs gets a list of keywords from it(this way the words can be updated easily). It parses these words into an array. By turning the knobs, the user scrolls through the keywords which appear on the LCD screens. When the user has chosen a suitable pair of keywords, she presses the button. The device then connects to the stage server again, this time running a CGI script which connects to RSS feeds and determines the frequency of terms which are associated with the keywords. It sends this information back to the device and 4 solenoids which operate the arms of the rock em sock ems are turned on and off to make them fight. When one of them has its block knocked off, the device connects to yet another CGI on stage which writes the result to a file.

Unexpected obstacles:

 

1. For some reason, the XPort has difficulty connecting to the stage.itp.nyu.edu server which it does not have with any other server. This is problematic as I need to use stage to run my CGIs. After incredible frustration with this and thanks to Tom Igoe's perserverance, it has been revealed that the XPort will connect to stage effectively if the flush mode is set to 00.

2. The solenoids which I am planning to use are a. difficult to mount on the rock em sock ems and b. not powerful enough. The important thing we learn about solenoids is: they have exponential power curves and a solenoid which may be capable of exerting hundreds of pounds of force when fully extended may only be able to exert a couple of ounces when it is half an inch away from being fully extended. My solenoids are roughly 1/16 of an inch away from the power threshold they need to be to overcome the springs in the rock em sock ems. I am solving this problem with rubber bands.

3.XPort too slow. when I tried to read the keywords off of a plain html page, I couldn't get anything. I eventually solved this problem by delivering the keywords at the end of a cgi script which prints nothing for a million times through a loop.

4. PicBasic Pro can't handle string variables. The result is the 750 lines of largely repetitive code I needed to make my PIC do what I had thought was a fairly simple set of tasks. While I was doing this, I had a small revelation, though. When I figured out that PicBasic wouldn't handle my strings, my first response was to abstract to a higher level and reference the whole list of string arrays with another array. This, of course, failed. I then tried to build an even higher level of array which, of course, also failed. I realized that I was doing something roughly equivalent to the development of many religions. Adding one thing which I couldn't understand on top of another thing I couldn't understand until I had thoroughly removed myself from the understanding I was attempting to gain. Must be a natural tactic of human psyche.

5. Measure first! I've had to expand the plywood platform for this device three times because of my shortsightedness.

6. Emergent complexity. By the time I hooked everything up. It was extremely difficult to isolate or fix any problems because of the sheer number of wires and lines of code I was dealing with. Putting some of the wiring inside of the physical platform turned out to be a bad idea as it became less accessible as a result. and some of my connections got destroyed in the relocation.

7. Mechanical disaster. Rock em sock ems seem to work so well when they are used as prescribed. I never could have guessed that they would be so hard to make function automatically. They have a real tendency to get jammed up and stuck in each other arms. It's also very difficult to make them knock each others blocks off.

 

 

Additional system design:

One central 18F452 feeds instructions to three 18F252 chips which run the two LCDs and the solenoids which make the robots punch. the robots are wired so that they no longer conduct 5V to both the master pic and the robot pic when they have been separated from the torso. The two LCDs read out their keywords in reverse order so that if the knobs are turned to the same angle, the LCDs will display dialectically opposed keywords.

 

Conclusion:

this is a work in progress. The basic concept is working nicely. The device connects reliably, is straightforward in use and makes the robots fight (though not as spectacularly as I had hoped.I would like to continue to develop it but it currently has some bugs and shortcomings. Making the robots' fighting visually more exciting is a top priority. This will mostly require a new algorithm for the punching triggers and a lot of work on the mechanics. I couldn't have guessed that this old toy would have such precise tolerances. One of my solenoids is off center by a couple of millimeters and it barely works as a result. Also I would like to develop a large public website for not only retrieving information about past fights but checking ones own keywords and possibly adding additional keywords to the list.

Mostly for now I have this to say... The robots do not beat on each other as much as I would like. But they have beaten on me more than I would have ever thought possible.

code for main 18F452 PIC

code for LCD twin drivers

code for robot control

Perl scripts

circuit diagram

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Prev Home