!blog - corey menscher

Pilotwiings: Reality is my final project for Networked Objects. The goal of the project is to provide an alternate control mechanism for flying an indoor remote-controlled airplane using the accelerometers and buttons of a Wii remote. The wiimote connects to a computer over bluetooth, and its accelerometer values and buttons presses are captured by a custom Processing application (using the WRJ4P5 library) . This application then sends a series of digits as an encapsulated message to an Arduino over USB. The Arduino parses the message and flashes a series of IR emitters to control the plane.

Throttle is controlled by tilting the wiimote up and down, and turning is accomplished by rotating it let and right. Additionally, the wiimote button “A” cuts the throttle off, while the trigger button “B” bring the throttle to full. (To see a video of the UI of the Processing app in action, see my previous post.

The largest challenge by far has been hacking the Palm Z’s infrared control protocol. The Palm Z controller emits a series of pulsed IR light to communicate with the plane. By researching and talking to other R/C hackers, I determined that the Palm Z uses a 17-bit “message” comprised of the following:

Message Format: SS ChCh ThThTh RuRuRu TrTr ChkChkChkChk St

SS = Start Bit

Ch = Channel declaration

Th = Throttle value (0 - 15)

Ru = Rudder value = (0 - 7)

Tr = Rudder trim value

Chk = Checksum

St = Stop Bit
Example:

“SS001110000001110” = Channel A, Full Throttle, No Rudder/Trim

There are three “channels” defined by a 175, 130, 100ms delay between each “message”. However, I was unable to determine the exact timing for each bit value. For example, the developer I spoke to claimed that a “true” bit was represented by the IR emitter being on for 7ms and off 6ms, and a “false” bit was represented by the IR emitter being on for 13ms and off for 11ms. However, when I attempted to measure the values myself, I found this to definitely not be the case. Unfortunately, when I used an oscilloscope I was unable to determine the exact timings myself (they tended to vary across messages), so I will need to do more research to get it to work. This may include contacting the manufacturer.

I ran into issues getting the Arudino to flash the IR emitter with the proper timings.  I would often find that the IR emitters would either flash too quickly or slowly for the desired bit.  This may be alleviated by optimizing the code.

My PilotWiings: Reality project’s interface is complete. It displays the wiimote orientation and control settings for the PalmZ. Flight commands will be transmitted via serial communication to an Arduino microcontroller that will interpret the controls and translate them to the 17 bit IR messages that the PalmZ expects. It will then broadcast the commands via an array of IR LEDs, allowing the PalmZ to be flown via wiimote!

Blip.TV Link

For our “sensor” assignment, we were required to either record sensor readings to a web-based database or we could read information from a web service and represent it in a physical computing object. My partner Estee Wah and I decided to do the latter by grabbing traffic “incident” information for NYC and representing the current status in a unique way. We made a poster that depicts a road running to the horizon, with a cityscape in the distance.

Each of the four road lines are three dimensional translucent paper with a white LED behind them. The LEDs are then flashed in sequence to simulate movement (via an Arduino). As the number of traffic incidents increases, the delay between the LEDs flashing increases, slowing the perceived movement…as if one is in slow traffic.

Roady is programmed by grabbing a single <incident> tag from a PHP script that gathers XML traffic data via a customized RSS fee from Yahoo. Each <litem> node that Yahoo returns is one incident, so we simply count the number of items to get our traffic scaling factor.

Our first XPort assignment was to create a physical client for a networked Pong game. Anything would work as long as you could make the virtual paddle move left and right. My idea was to use a urinal, to allow players to urinate on two sensors to move left or right. (Yes it’s been done before.) I found a kids “training” urinal, which made for an easy-to–hack controller. My original intention was to use force-sensitive resistors (FSR’s) to trigger left/right movement, and they worked well in testing. However, I was unable to complete a working controller. Here’s what I learned:

• FSR’s are extremely fragile (I broke four and ran out of replacements)
• You can’t use the terminal “screen” command to listen in on serial communication between an Arduino and an XPort. If you do, the commands will never be received by the XPort!
• Vinyl tape stuck to plastic is not particularly watertight.

So my Lantronix XPort device is now soldered to a breakout board, and I am communicating with it via serial, web, and telnet. My biggest hurdle was getting the XPort to talk to my usb-to-serial board. I had the TX/RX pins flipped. I used my arduino to test it out, and apparently the labelled TX/RX pins become their opposites when the ATMEGA chip is removed.  Whodathunkit? Once I figured that out, though, it was relatively smooth sailing. Well, it also took me a while to figure out that Lantronix hardwired the telnet port to be 9999 instead of the standard 23.  But then it turned out that this is just the config port, and you CAN change it via the “endpoint configuration” field.  So I made it use port 23 after all.

One thing that has come in handy is that Apple has equipped all of their macs with auto-sensing ethernet ports. What this means is that any ethernet cable can be used to connect a mac directly to any ethernet device…no crossover cable is needed. So instead of waiting for ITS to give me an authorized IP address, I created a subnet between my ethernet jack and the XPort so they can talk to one another. The XPort can’t see the internet in this configuration, but it’s fine for initial testing and development. I am going to explore the possibility of using Internet Connection Sharing to make things even easier on me. If the XPort can use my mac’s wireless connection to talk to the internet, I won’t be limited to the few RJ-45 jacks we have here on the floor.

This is my creation for our first assignment in Networked Objects. It’s a shaker using lentil beans, a plastic container, vibration sensors, and an arduino mini + breadboard. Shaking the device triggers an animation of my macbook’s desktop shaking. It’s just an 11 frame loop of screenshots I altered to make it look like it’s shaking. The desktop itself does not shake. The effect is pretty good when using Processing’s “present” runtime mode.

Most of the issues I encountered were related to the vibration sensors I purchased from Parallax.com. These are plastic piezoelectric sensors. I am using 5.1v zener diodes to filter the voltage spikes generated by the piezos. A 1MΩ resistor pulls the input pin to ground, giving me a nice range to work with. It tooks a while (and a lot of bugging Tim Twyllman) to figure out how to get useful values out of the sensors, but I think the final result is prett good.

This was also my first experience with an Arduino Mini. It’s an amazing little device, but I did not own a USB-to-serial breakout board and had to borrow one. The positive is that the whole device fits on a small breadboard that is adhered to the container’s top…but it sure doesn’t leave a lot of room to insall components. It may be hard to see from the video, but the side with the analog inputs is a mess of zener diodes and resistors. I had to be creative with positioning the connections, as well as figuring out good places to connect the sensors to ground. But in the end, it works pretty well!