Left Shark: An RC Controller-Hovercraft Pair
with Alex Nathan Khan, Drew Bell, and Helena Scutt. Completed for Stanford’s ME 218C Smart Product Design Practice course in Spring 2017.
Project Guidelines (ME 218C )
The goal of our ME 218C project was to create a unique hovercraft along with a controller that can switch between commanding our own and any other team's hovercraft. This required that the entire class develop and implement a shared communication protocol such that commands to and from each controller or hovercraft are always understood correctly.
Each team participated in a game with two other teams, where the goal was to herd as many mini-hovercrafts into a capture zone in two minutes. In the final round, all users must pair with another team's hovercraft and continue to herd as many targets as they can.
Our team's hovercraft and controller were inspired by none other than Katy Perry's 2015 Superbowl half-time show, and naturally dubbed Left Shark. The user controls the hovercraft by wearing and tilting a modified inner tube housing all electronics. The hovercraft took the form of a swimming shark, complete with an LED-lit chomping mouth and swimming tail to indicicate successful pairing. For our project, I was responsible for the mechanical, electrical, and software design of the inner tube controller.
Mechanical Design
Our controller was designed as a wearable inner tube which turned tilting into direction commands for the hovercraft. The goal was to have all electronics be fully integrated within the tube. Towards that goal, I designed removable module was designed that housed all core electronics. Embedded circuits such as buttons and the hovercraft-selection cup connected to the module via Molex. The main components of this design are:
the inner tube itself
the electronics module
the hovercraft selection cup
the 3D printed conch shell for pairing'
The inner tube was stuffed with fiberfill and modified with suspenders to allow the user to wear it around their waist. Our initial plan was to mount the electronics externally on a regularly inflated inner tube because we were unsure if a stuffed inner tube could support the weight of the mounted electronics. In the end, with fiberfill and sections of foam core support, the structural stability of the inner tube was not a problem. We mounted "Brake" and "Chomp" buttons into the handles of the inner tube so the user could easily perform these actions while tilting to steer the craft.
To select which hovercraft to pair with, I designed a modified red Solo cup with three slots in which the user inserted a tiny palm tree (made of a chopstick and some pool noodle foam). The frame of the selection mechanism consisted of two concentric frosted acrylic disks, each with three holes joined using plastic straws. Limit switches were glued to the lower acrylic platform such that the switch was pressed when a chopstick was inserted into the slot. The straws served as guides to ensure the stick remained aligned when inserted. This frame was fit into a red solo cup, which also housed an RGB LED strip that illuminated when the controller paired with a hovercraft.
To initiate pairing, the user blew into 3D printed conch shell housing a microphone and signal processing circuitry. To create this, I got an .STL file for the surface scan of a conch shell from an open source CAD library edited the model in Blender to make the piece hollow and create a lid (note: working with .STLs is nearly impossible in SolidWorks with realistic scans - feature recognition is not your friend). A 75% scale resin model was printed using a FormLabs 3D printer and Velcro was used to attach the shell to the left strap, inspired by a clip-on walkie talkie.
I designed the main electronics module to be as lightweight and self-contained as possible, since it needed to be supported by the inner tube and easily removable. The module was constructed from laser-cut foam core. The front face of module box was left open to keep the electronics easily accessible when the module was removed. To further increase ease of access, the top plate of the module was attached using high-strength magnets rather than permanent adhesives. This came in incredibly handy when debugging electronics and wiring the signal & power lines. Molex connectors were used to connect the inner tube-embedded circuits to the module. The top plate of the module housed the power switch, two indicator LEDs, and a custom 16 LED IMU display.
Electrical Design
The main electrical functions required by the controller were tilt sensing, sound sensing, button & switch inputs, LED indication, and radio communication. Each of these systems were either housed completely or directly wired to electronics module, which contained a Tiva Launchpad for system logic and all power distribution. Based on project handout, the schematics label the hover craft as DOG (Device Of Guidance) and the controller as FARMER (Floating Animal Rescue Mechano-Electrical Remote). All circuits in the controller were laid out and soldered onto perfboards after breadboard protoypying.
Power for the controller was provided by a single 7.2V NiCd battery. Two voltage regulators were used to segment this power into a 3.3V supply for sensor logic and 5V supply for powering the Tiva and indicator LEDs. A separate 9V battery was used to supply power to the RGB LED strip within hovercraft select cup.
For tilt sensing, a simple 3-axis analog accelerometer (ADXL335) was used to translate tilt along two independent dimensions into two analog voltage signals. These signals were filtered and amplified before being processed by the Tiva's built-in ADC and scaled to determine the inner tube's forward/back and left/right tilt.
A microphone was mounted within the conch shell and used to pick up the user blowing into the shell to initiate pairing. The signal was filtered, amplified, passed through a peak-detector circuit to extract the volume level, and run through a Schmitt trigger to create a digital signal. The filtering and amplification was tuned carefully such that ambient noises did not register as an attempt to pair with the hovercraft. Since the circuit needed to be housed in a limited space, an efficient layout was key.
For radio communication to and from the hover craft, an XBee transceiver was wired to the UARTs lines of the Tiva. A pull-up resistor was used to ensure the RX line of the Xbee remained high.
To display IMU data from the hovercraft, we opted to use an array of 16 LEDs to visualize spin rate of our hovercraft. If the hovercraft was not spinning, the green LEDs in the center of the display were illuminated. If the bot was spinning counterclockwise, the left LEDs would incrementally illuminate proportional to the spin rate. Likewise, the right LEDs would illuminate during clockwise rotation. Two daisy chained shift registers were used to individually control each LED.
Three roller switches were used to detect if the user had placed the palm tree in Slot 1, 2, or 3, which correspond to hovercraft 1, 2, and 3 respectively.
An RGB LED strip was used to indicate the controller's pair status with either hovercraft number 1, 2, or 3, illuminating a different color for each. Three power MOSFETs were used to control current through the R,G, and B lines of the strip, which was powered via 9V battery.
Software Design
Our controller operated primarily on a 3-state flat state machine called FARMER_FSM, which managed the information passing between various software modules. This top service interfaced with RX and TX communication services, and various auxiliary services including the IMU LED display, accelerometer, and microphone services. On initialization, the controller would wait to pair with a hovercraft. When the user initiated pairing by selecting their craft and blowing into the conch shell, the controller would send out a pair request over radio communication the the selected hovercraft. If it received the appropriate response, the controller would then be paired with the hovercraft and the user could begin piloting.
Communication between the Tiva and XBee was performed via UARTs standard protocol. The messages sent out from the XBee to the receiver on the hovercraft also followed a class standard communication protocol which all groups agreed upon to allow full interoperability between all hovercrafts and controllers.
