Our task was to build a soccer-playing hovercraft (the “PLAYER”) and a controller (the “COACH”) that could remotely control the hovercraft’s actions. In addition to physically constructing both parts, a major challenge was to design and implement a communication system that would allow our PLAYER and COACH to talk to each other and the playing field.
PLAYER Structure
We decided to model our PLAYER hovercraft after a circular UFO shape. The uniformly rounded curves made our PLAYER structurally robust, able to take hard impacts without damage. A clear plastic dome attached above the main body of the PLAYER served as a housing for the thrust motor and propeller, rudders, and XBee board. Below the body was a circular skirt with small holes cut in it. We used a smaller circular piece of cardboard to pull up the center of the skirt, giving the inflated skirt a donut-like shape and creating a small pocket of air under the hovercraft.
Most of the other components were mounted just below the PLAYER body (covered by the skirt when assembled). We used a servo to control the rudders and two servos to controller our “kickers”, small flaps that would rotate out from the body to kick the ball. We also used a servo to open and close holes to vent air in the front of the PLAYER, functioning as a reverse thrust. Two NiMH batteries, by far the heaviest components on our hovercraft, were also mounted under the body, and were placed in locations that we found empirically to be optimal for balance.
COACH Design
The COACH was made up of a few components - an XBee board for communicating with the player, the internal components from a Wii Nunchuk for user input, and a battery to power the COACH. All of this was housed in a large Diet Coke can piggy bank in honor of our illustrious professor and his iconic Diet Coke habit. We cut a hole in the bottom of the can and mounted the XBee board there to minimize any adverse effects to the communications signal as a result of being in a metal container. A few more holes were cut in the top surface for the Nunchuk buttons and joystick, and a 4-digit 7-segment LED. The battery, E128, and the rest of the circuitry were contained entirely within the can.
With the finished product, users could control the motion of the player by simply tilting the can. A forward tilt would increase forward thrust, sideways tilts would induce turning, and a backwards tilt would make the player go in reverse. Shaking the can would cause the player to kick. The joystick would be used for PLAYER select/team select or tag out location select, depending on whether the COACH is already paired, and the buttons would be used for initiating pairing or tag out.
Communications
In total, we used three PICs for the PLAYER and one E128 for the COACH. On the PLAYER, one PIC was used to communicate with the LiFKIM and control the servos, one was used to talk to the XBee, and the last one controlled the LED lights. Separate from the class communications protocol, we came up with our own protocol to facilitate transfer of data between the LiFKIM and XBee PICs. The XBee PIC would then relay status information to the XBee on the COACH.
On the COACH side, we programmed the E128 to sample Nunchuk data periodically. Each time the coach was to send a control packet to the PLAYER, it would first query the Nunchuk data to get information on speed, direction, kicking, etc., and then relay the information to the player XBee.
PLAYER Structure
We decided to model our PLAYER hovercraft after a circular UFO shape. The uniformly rounded curves made our PLAYER structurally robust, able to take hard impacts without damage. A clear plastic dome attached above the main body of the PLAYER served as a housing for the thrust motor and propeller, rudders, and XBee board. Below the body was a circular skirt with small holes cut in it. We used a smaller circular piece of cardboard to pull up the center of the skirt, giving the inflated skirt a donut-like shape and creating a small pocket of air under the hovercraft.
Most of the other components were mounted just below the PLAYER body (covered by the skirt when assembled). We used a servo to control the rudders and two servos to controller our “kickers”, small flaps that would rotate out from the body to kick the ball. We also used a servo to open and close holes to vent air in the front of the PLAYER, functioning as a reverse thrust. Two NiMH batteries, by far the heaviest components on our hovercraft, were also mounted under the body, and were placed in locations that we found empirically to be optimal for balance.
COACH Design
The COACH was made up of a few components - an XBee board for communicating with the player, the internal components from a Wii Nunchuk for user input, and a battery to power the COACH. All of this was housed in a large Diet Coke can piggy bank in honor of our illustrious professor and his iconic Diet Coke habit. We cut a hole in the bottom of the can and mounted the XBee board there to minimize any adverse effects to the communications signal as a result of being in a metal container. A few more holes were cut in the top surface for the Nunchuk buttons and joystick, and a 4-digit 7-segment LED. The battery, E128, and the rest of the circuitry were contained entirely within the can.
With the finished product, users could control the motion of the player by simply tilting the can. A forward tilt would increase forward thrust, sideways tilts would induce turning, and a backwards tilt would make the player go in reverse. Shaking the can would cause the player to kick. The joystick would be used for PLAYER select/team select or tag out location select, depending on whether the COACH is already paired, and the buttons would be used for initiating pairing or tag out.
Communications
In total, we used three PICs for the PLAYER and one E128 for the COACH. On the PLAYER, one PIC was used to communicate with the LiFKIM and control the servos, one was used to talk to the XBee, and the last one controlled the LED lights. Separate from the class communications protocol, we came up with our own protocol to facilitate transfer of data between the LiFKIM and XBee PICs. The XBee PIC would then relay status information to the XBee on the COACH.
On the COACH side, we programmed the E128 to sample Nunchuk data periodically. Each time the coach was to send a control packet to the PLAYER, it would first query the Nunchuk data to get information on speed, direction, kicking, etc., and then relay the information to the player XBee.
project_logbook.pdf | |
File Size: | 216 kb |
File Type: |