To build a self-propelled water craft and a human interface controller (the “Helm”) capable of wirelessly controlling the water craft.
The goal of the game was for each team’s boat to fill a bucket with water in the opposing team’s base. Whichever team filled the opponent’s base with the most water in 5 minutes was declared the winner. Only one base was active at any given time which means each team was required to switch back and forth between offense and defense.
- 4 weeks to complete the project
- Project budget of $150
- 3-person team
- A class-standard bumper was required on each boat
- Lingo: boat = watercraft, controller = Helm
- A switch to disable all propulsion and water delivery systems on each boat
- Each engagement lasted five minutes on a playing field shown in Figure 20 below
- Network handshaking: for a particular engagement, one boat and one controller (may be of different teams) had to both read an iButton to determine their appropriate data link relationship
- Boat/controller interoperability: each team’s controller had to be able to communicate with any of the team’s watercrafts
- Multi-agent network: the course teaching staff could communicate with any boat to issue Start, Stand Down, and Stop commands
- Operate in field shown in Figure 1 below
- Design Approach
Per the project specifications, the helmsperson’s actions “…should be inventive and interesting for the audience to watch.” In addition, the actions should make the helmsperson “look and feel foolish.” To accomplish these specifications and our primary Helm feature of simplicity, we decided to design a Nintendo-like Power Glove in which the helmsperson would use solely the Power Glove to control the boat. Moreover, the state of the game would be displayed on an object on top of the forearm next to the Power Glove. We decided to separate the navigation and special action functionalities into separate sensors.
Helm Design: Navigation
The user controlled the boat by waving a hand through the air. Pitching the hand controlled the throttle: downward pitch moved the boat forward while upward pitch moved the boat backward. Rolling the hand turned the boat: right roll steered the boat right and vice versa. The user could also combine these actions in any way to turn while going forward or turn while going backward.
To navigate the boat (control speed and direction), we implemented a three-axis accelerometer from the course lab's shop, as shown below in Figure 2.
- Because the accelerometer provided three sources of data (i.e. the three axes), we decided to use it to control both speed and direction. The accelerometer was mounted on the Power Glove for the helmsperson’s right hand. However, this provided a challenge at first for us because an accelerometer produces space-fixed measures of gravity, and we desired body-fixed angles. To overcome this challenge, we used a body-fixed rotation matrix to find the body-fixed angles from a particular orientation of the accelerometer. Right-handed, orthogonal reference frames A and B are initially aligned with each other, and B is subjected to rotation θb z then rotation φb x.
Helm Design: Water Delivery
The user controlled the cannon simply by clenching his or her fist. When the hand was flat, the cannon would be off. As the user made a tighter fist, more power was transferred to the cannon to blast water out of the hose. In this way, the user controlled how far the cannon shot water.
To accomplish the project specification requiring a sensing modality for water delivery and special actions, we implemented a flex sensor as shown below in Figure 3.
- Helm Design: Special Action
Figure 4 below shows the readout on our helm. The two buttons at the bottom triggered special actions on the boat. Any boat could have up to two binary special actions. Teams implemented special actions such as horns, sirens, and boosts.
- Helm Design: Gameplay
While the Helm waited to read an iButton, the yellow LED was on. After reading an iButton, the yellow LED turned off and the team color LED (red or blue) turned on in addition to the watercraft number being displayed on the double digit 7-segment LED display. When an Engagement Start command was received, the green LED turned on and the active goal LED blinked at 5 Hz. When a Stand Down command was received, the yellow LED blinked at 5 Hz for 10 seconds; the green and team color LEDs remained on and the active goal LED continued to blink at 5 Hz. When an Engagement Over command was received, only the small red LED was on until a hard reset command was received, which resulted in the Helm waiting for a new iButton.
If the team affiliation was red and the active goal was also red, then only the large red LED blinked. If the team affiliation was red and the active goal was blue, then the large red LED turned on and the large blue LED blinked at 5 Hz.
Helm Design: Materials
To mount the accelerometer onto a glove, we cut a hole in a thin, lightweight black glove between the pinky and ring finger on the opposite side of the palm. For the flex sensor, we cut part of the middle finger material on the opposite side of the palm; as the helmsperson clenched his/her fist, the flex sensor bended from 0° to roughly 90° for a full range of variable resistance. To mount the gameplay LEDs and team number display, we used two soccer shin guards and sewed them together, sandwiching the wires operating the LEDs. See Figure 5 below for a photo of the Helm.
- To keep the large number of wires in one bunch emanating from the Helm to the bag carrying the circuit boards, E128 microcontroller, and 7.2-V battery, we used plastic tube to encase them. An elastic band cut from the shin guards was used to keep the shin guards securely on the helmsperson’s forearm during an Engagement.
The watercraft was designed to be stable, fast, and agile. Two motor-driven propellers were mounted within foam pontoons that form the bulk of the craft. Twin motors allowed the craft to turn in place and also to achieve a high top speed. The two pontoons were bridged by a series of ½- in wooden dowels that support the main electronics (housed inside a small Tupperware container). The electronics contained LEDs to indicate team color and game state. However, since the LEDs were not especially visible during the day, a wooden dowel mast at the rear of the craft allowed the user to hang a blue or red flag adorned with the craft’s number. A 500-GPH Bilge Pump was mounted near the rear of the craft and a ¾-in tube was connected to a ½-in nozzle near the front of the craft to arc water into the air in front of the craft.
A classic staple of video games is a turbo mode, thus we decided to implement a turbo mode on our boat. Whenever the user activated special 1, the boat would get a 25% speed boost and travel in a straight line for 2 seconds. This was extremely useful for going from one side of the pond to the other. After the turbo was activated, it could not be used again for 5 seconds in order to prevent damage to the motors.
ZigBee Software Design
Both the craft and helm used similar software design for interacting with the ZigBee modules. They transferred bytes along a 9600-baud asynchronous line using an interrupt service routine (ISR). The ISR stored each byte into a large receive buffer and kept track of the index of the last byte stored. If the byte matched the ZigBee Start Byte, then the ISR also noted the index of the Start Byte.
The main program loop constantly checked to see if a new Start Byte had been received. If so, the main program waited for the next two bytes (Length MSB and LSB) and checked that these bytes matched what was expected. If there was an error, the program ignored the Start Byte and returned to its last place in the main program. If there was no error, the main program waited for the remainder of the message to be received and then processed it. At the start of this ISR, a copy of the Start Byte index was made so that if another Start Byte was received by the ISR, the processing routine would still reference the first Start Byte.
A/D pin 3 on the E128 was used as an input pin for the voltage from the flex sensor. For the lower nibble of the Special Actions byte corresponding to the water delivery power level, we needed to output a value ranging from 0 to 15 (0x*0 to 0x*F). To accomplish this, we empirically found the A/D low and high values from the flex sensor: the low value was 268 and the high value was 475. After observing the output from bending the flex sensor in the Power Glove, we decided to change the high value to 350 to control the output more tightly for better PWM control of the water delivery system. After creating software to create floor (268) and ceiling (350) values of the A/D values, we mapped the A/D values to a value between 0 and 15. This value was sent wirelessly as the lower nibble of the Special Actions byte for PWM control of the water delivery system.
To map the tilt and pitch angles to values ranging from 0 to 15, we first divided the tilt angle by 0.5π; we divided the pitch angle by (3π/8). Next, we multiplied both the tilt and pitch angles by 7, then added 8 to each of them (the neutral point for each nibble). The part of the result after the decimal point was ignored by declaring each nibble as an “int” variable type. To account for the direction nibble being the upper nibble, we multiplied its value by 16. We added the speed and direction nibbles to form the navigation byte, which we sent wirelessly to the watercraft for appropriate use in motor PWM and direction control.
We used two high-speed DC motors and small, three-bladed propellers designed to run at high RPM. We had initially selected slightly larger propellers, but in testing found that these drew over 3A of current when running at 5V in water. This was well over the peak-power output from the motors and also risked burning out the motors. Switching to the smaller propellers reduced the current draw to 1.7A which was safer and produced similar thrust.
The motors were housed individually inside PVC tubing and were connected by universal couplers to the propeller shafts. Brass bearing sleeves covered the shafts and small Masonite circles inserted inside the PVC supported the sleeves which exited the PVC through a small hole in one end. All joints in the PVC were sealed carefully to make the motor housing as water tight as possible. Sitting in the foam pontoons, the motor assemblies were exposed to only small amounts of water near the end opposite the motors; however, we made waterproofing sensitive areas a top priority from the start.
Our boat implemented a turbo special action. In normal operating conditions, the drive motors were limited to a maximum PWM duty cycle of 75% to limit their power consumption. However, on activating the turbo special, both motors were set to 100% duty cycle and the craft moved forward at a higher speed for two seconds. We limited turbo activation to once every five seconds to reduce the chance of motor overheating.
The electronics container was protected from water with only three external access points. The main power switch and iButton reader were inserted through cut-outs in the container top and were easily accessible. Power lines for the LEDs, motors, and pump emanate through a small tube that was covered with cellophane wrap to protect against water while still allowing for easy access. All holes in the container were sealed carefully with glue.
Electrical: Helm Power Consumption Spec
To fulfill the project specification of the Helm having sufficient battery capacity for 8 hours of continuous operation, we measured the current through the battery’s leads (one 7.2-V NiCad battery rated at 1900 mA-hr) for 10 minutes and measured its average current to be roughly 49 mA.
This measurement gave us a theoretical operating time of 1900mA*Hr / 49mA = 38.8 hours, which was well above the 8-hour requirement outlined in the specifications.
- Electrical: Helm Display
To show the helmsperson the current state of an engagement, we placed five LEDs on the Helm: a set of small green, yellow, and red LEDs to describe the engagement status, and large blue and red LEDs to show the team affiliation and active goal. See Figures 4 and 5 to see these LEDs. We placed a relatively standard 3.3-kΩ resistor in series with each of these five LEDs. In addition, we placed a double-digit 7-segment LED display on the Helm. We placed a 220-Ω resistor in series with each of the double-digit 7-segment LED display’s LEDs to have a fairly high current for brightness purposes. Each of the LEDs has a forward voltage drop of 2.0 V. In addition to our added resistors, the E128 protection board has a 1k series resistance per pin. Thus, our calculated current through the 7-segment LEDs was 2.5 mA. The calculated current through the five display LEDs was 0.7 mA, which was enough to see the LEDs, but also kept the power consumption very low.
The double-digit 7-segment LED display was common anode (one anode per digit). Digit 2 was considered to be the digit next to the decimal point while Digit 1 was considered to be the digit in the tens place.
Electrical: Boat's Main PIC micro-controller
The Main PIC communicated with the ZigBee board and controlled the pump uni-directionally through PWM, which was level-shifted to 5V. The Pump drew up to 2.5A, which could easily be supplied by the TLE H-Bridge. The Main PIC gave commands to the Left and Right PICs through eight individual I/O lines connected directly to these PICs. Four lines per PIC gave 3-bit speed resolution and one direction bit. While this method used a large number of I/O, we had sufficient ports available and it was simple to implement and troubleshoot. The Main PIC also controlled red, blue, and yellow LEDs. The resistors were sized by experimentally measuring the current at which the LED stops growing brighter and then calibrating this current (and the LED drop-off voltage) for the 3.3-V PIC.
Electrical: Boat's Secondary PIC micro-controllers
The Left and Right PICs had four input lines from the Main PIC; each of the secondary PICs drove one of the drive motors bi-directionally. Both the PWM and direction lines were level-shifted to 5V to work with the TLE H-Bridge driver.
The motors drew roughly 4.5A stall current at 5V, which was below the 6A maximum for the TLE 5206-2. Also, when tested in water, they drew 1.7A continuous, which was well below the 5A maximum for the driver.
All software for the Helm was written in C for the E128 microcontroller.
All software for the boat was written in Assembly Language for the PICs.
We completed all intermediate deadlines and the project on time. Though we spent close to $250, or roughly $100 over the maximum allowed budget, we used quality components while still seeking great value.
During the public demonstration, our boat and controller had the longest battery lives. In addition, we allowed several young children to operate our boat; every child quickly and easily controlled the boat with precision.
I learned a tremendous amount of information during the course and project in the areas of micro-controller communication, communication protocols, and user interface design.
See Figures 6 and 7 below for photos of our final boat and Helm.