The goal for this project was to create a hovercraft and controller set that could be used to play a team game. Project specifications mandated that our hovercraft needed to be tele-operated not only by our own controller, but also by any other controller present during game play. Likewise, our controller needed to be able to control all of the other hovercrafts developed for this class, and we were encouraged to make the operator look foolish while controlling the hovercraft.
As the project fell during an election year, our game had a political theme. The components of the game were as follows:
The rules were simple: during game play, there would be four LOBBYISTs and six PACs active in the political arena. Players were divided into two teams (Red team and Blue team), with each team consisting of three PACs. The teams has 218 seconds to try to pair with as many LOBBYISTs as possible, and when a successful pair occurred, the teams would proceed to bribe members of Congress to vote in their favor (i.e. push as many ping pong balls as possible into that team's goal). Because there was an imbalance between the number of LOBBYISTs and the number of PACs present during game play, there was a constant opportunity for the loyalty of the LOBBYISTs to shift from one team to another. As a result, the game had the ability to turn into a knock-down, drag-out battle for control between the two teams.
We decided to go with a turtle theme for our hovercraft and controller. (Though a turtle isn’t necessarily related to this year’s political theme, it probably wouldn’t take a stretch of the imagination to find a connection.) Both the controller and the hovercraft are described in more detail below.
Our controller consists of three pieces: two turtle flippers, which the user straps to their arms, and a helmet. To control the hovercraft, the user must to “swim” with the flippers in certain sequences. For example, to drive straight, the user swims with both flippers at once. To turn right, they only swim with their left flipper. Likewise, to turn left, they only swim with their right flipper. Finally, to reverse, they must hit the red X’s on the helmet. In addition to these inputs, users also have a braking option available, as well as a number selection dial and a pairing button, which they can use to select and pair with their desired hovercraft. The following is a full list of the sensing modalities and status indicators we used on our controller:
Our hovercraft is constantly waiting for new data to come in wirelessly via Xbee. Whenever new data arrives, our hovercraft parses it according to the class-standard communication protocol. Then, it uses the extracted data to determine what to do. For example, whenever a controller pairs with our hovercraft, the lift fan turns on, which in turn inflates the hovercraft’s skirt. When new control commands come in, the hovercraft parses the data packet and decides which peripherals to alter. The hovercraft can respond to commands by moving forward or backward, turning right or left, and braking (i.e. turning off the propellers and deflating the skirt). The following is a full list of peripherals that our hovercraft alters based off of incoming data:
