balloonBot: video sensing final, spring 2006
Unidentified Chasing Object (BalloonBot)
// Description \\
The BalloonBot was an investigation into wireless communication, networked interaction, video streaming, video sensing, tele-presence, and autonomous behavior.
// Goal \\
Our goal was to create a floating body that would carry a wireless camera, stream video over the internet, navigate based on video tracking and be controlled by remote users interacting with the internet video stream.
// Radio Frequency Receive and Transmit \\
The SparkFun Mini RF (MiRF) module was our first choice for radio frequency communication to the control the navigation of the balloon. After experimenting with the modules however, we realized the MiRF was not as easy to use nor as reliable as we had first hoped.
The PIC code for initializing the state of the transceiver and setting it to transmit or receive was difficult to fully understand, but was nicely hidden in subroutines. Aside for the initialization code, the MiRFs were easy to setup and initiate communication, however, instead of standard serial communication the bits are “shifted” in and out.
Setting up the up the MiRFs in the breadboard was simple enough, but required a 3 volt regulator, which required slightly different wiring than our usual 5 volt 7850. We first tried running the PIC chip at 5 volts and the MiRF at 3.3 volts and found problems with the communication between the PIC and the MiRF. We then ran both at 3.3 volts we had no problem, but then found problems triggering the H-bridge motor controllers expecting at 5 volts.
In hindsight I feel that we could have gotten the MiRF, PIC, and H-bridges to work together with less effort, but we unknowingly a bad H-bridge and a new Microcode Studio software upgrade working against us.
The MiRFs also seemed very touchy, one moment they would to be working and the next they wouldn’t. Other students using the same MiRFs experienced similar problems in addition to the unexpected ease of “frying” the modules.
Our experiences with the Sparkfun MiRFs lead us to quickly look for an alternative to communicate to the BalloonBot. The Easy Radio RF transceiver turned out to be a great solution for our simple serial to RF requirements.
The Easy Radio RF transceiver sent and received standard serial protocol just as easy as connecting a PIC to a computer. It also handled our power issues with an internal voltage regulator that could work between 1.9 and 5 volts. The configuration code was just simple AT commands to set the baud rate, RF frequency, and whether to transmit or receive.
// Motor Control , Circuit Programming / Design \\
Our motor control of the balloon used two small DC motors mounted horizontally for forward/reverse and left/right movements, and two small DC motors mounted vertically for up/down movements. We used two H-bridges, one to control each set of motors. Setting the correct pins high or low on the H-bridges allowed us to control the direction of each motor’s rotation. Serial input from the Easy Radio would tell the PIC which motors to turn in which direction. We mapped ASCII characters to control multiple motors so key strokes could determine the direction and movement of the blimp.
// Video Sensing and Serial Control \\
Mounted on the BalloonBot’s gondola would be a small wireless video camera. The output of the camera’s receiver would be fed into a computer running a video tracking application written in JAVA using VxP. The application would analyze the incoming video for a specific color and draw a bounding rectangle around that color. Based on the rectangle’s size and location the application would determine which direction the balloon should move in and send a serial control command to the RF transmitter.
//Java Server/Client And Interactive Video Streaming \\
To allow users to remotely control the blimp over the internet we would open a JAVA server socket thread on the video tracking application. A JAVA client application would connect to the video tracking application and tell the tracking application what color the BalloonBot should be tracking or what direction the bot should move.
For the users to see what the BalloonBot was seeing we needed to stream the video from the wireless camera over the. Rather than using a separate video streaming application we simply saved each frame being analyzed by the video tracking application to a JPEG on the hard drive. The image would be over written with each new frame. The remote client would continuously reload that same image seeing it change as though it were streaming video. The frame rate was impressively 12 to 15 frames per second with little delay.
We specifically choose Processing to write out client application because it easily allow the user to click on the streaming video image and get the RGB value of the pixel they clicked on. This RGB value would then be sent back to the video tracking application server and change the color being tracked by the BalloonBot.
// Make it float \\
Our main concern in designing our BalloonBot was weight. We ordered a Mylar blimp rated to lift 3.75 ounces, or 105 grams. Everything we chose to use was based on weight. The four mini dc motors weighted 1/4 ounce each, which was over a quarter of the weight. We investigated lithium-polymer batteries, which were designed to provide a lot of power and weigh very little. A 3.7 volt 1050mAh lithium-polymer battery weighted 18 grams.
We used one small perf-board, big enough to hold the electronics, batteries, and camera. The motors were mounted using very light wood sticks and wire. The heaviest part of the system would be the camera and it’s 9 volt battery.
The 9 volt battery itself weighted 45 grams. At just over 115grams the Mylar blimp floated all the equipment at head level. It was beautiful for about 10 minutes, then the blimp hit a spike in the ceiling and popped. The humanity.
Realizing just how delicate Mylar was we quickly began looking for balloons with large amounts of lift. We found a 3-foot red latex helium balloon. The balloon lifted the gondola and camera with no problem; in fact we had to let some of the helium out and ballast to achieve neutral buoyancy.
The latex balloon seemed to have more lift and greater durability than the Mylar blimp, however was harder to control because turning left or right sent the balloon into a spin. Because of a blimp’s elongated shape it has more horizontal drag and spins less freely, a balloon on the other hand is round with no drag. Also, latex begins to degrade as soon as they are filled, over time they loose their helium and are more likely to pop if refilled, a new balloon was need every two days.
// Conclusion \\
The radio frequency communication, video tracking and interactive streaming video all seemed to work as well as we had hoped. I would like to move the JAVA server and the streaming video to an online server rather than having users connect directly to the computer running the video tracking application.
Although the red balloon was cute and reminded everyone of the French movie “The Red Balloon” it would not be my choice for making a blimp that is to be navigated. It did float majestically though the ITP lounge, but was not able to maintain shot very long after tracking without spinning. Future attempts will be made with actual blimp-shaped blimps.
Sparkfun Electronics: http://www.sparkfun.com/
Low Power Radio Solutions: http://www.lprs.co.uk/
West Coast Blimps & Electronics: http://j.piri.home.mchsi.com/
Battery Space: http://www.batteryspace.com/
Spy Pirate: http://www.spypirate.com/
Heather Dewey-Hagborg: http://deweyhagborg.com/
Autonomous Light Air Vessels: http://people.artcenter.edu/~berk/alavs/