FHSAE Next Generation Engine Configuration

This project will develop a knowledge base around the engine from a 2008 Honda CRF150R engine. The goal of this project is to reverse engineer this engine for future repackaging

Background
The Formula Hybrid team at the University of Idaho is in need of a new engine configuration to remain competitive for future competitions. To incorporate the electric motor and maximize engine displacement, a new engine must be designed that has separate engine cylinders. This will require research of an engine with comparable features and design.

Mechanical

 * Design, build, and test a canister with a deployment system for a small parafoil
 * Design a system that reliably inflates and provides rigidity to parafoil ‘gores’ at high altitude
 * Select a winch with optimum locking capacity

Electrical

 * Develop a wireless system to transmit commands to open canister and deploy parafoil.
 * Use Xbee Series 2 radio module to wirelessly collect data from and transmit via the Iridium satellite network down to the ground.
 * Replace altitude switch with a smaller pressure switch.

Computer Science

 * Develop a Graphical User Interface (GUI) to present the diagnostic data downlinked from the capsule and to uplink commands to the capsule
 * Assist Electrical Engineers in embedded system programming
 * Adapt/modify algorithms to guide capsule to the target location

Specifications
The tables below contain the specification matrices for the ME, EE and CS groups.

Note: 1 = highest priority, 2 = lowest priority

Mechanical




Figure 3 illustrates the Mechanical Engineering Hardware for the system. The three systems are the parafoil, the Payload Containment and Thermal Control Unit (PCTCU), and the control system as illustrated in figure 4. The parafoil will be re-designed with the consideration of stiffness, inflation, and sensors. The two types of sensors used for the parafoil are temperature sensors and pressure sensors. The success of the parafoil after deployment is determinant on the inflation system and the rigidity of the parafoil itself. The PCTCU will be used as our canister that will contain our packaged parafoil and the control system. The PCTCU diameter is 13.81 cm, and a height of 17.4 cm.

When selecting the servo, the aspects of servo torque, size, mass, operative voltage, gear metal type, and transit speed were used to determine the required servo. Commercially available servos were compared as illustrated in table 4. The best winch servo is Vigor VSD-22YMB where it can deliver the most torque while maintaining six cycles of rotation.



Deployment System



 * Uses easily attainable CO2 Cartridges
 * Uses minimal moving parts
 * Proven field use:
 * Similar systems used on high-altitude balloons, amateur rocketry, and UAV’s
 * Peregrine IDS
 * Sentinel CO2 Deployment System
 * Rouse-tech CD3

Electrical
Figure 5 to the right depicts of the electrical hardware side of the system. Many aspects of this system are re-used from both VAST and NASA. Data collected from the wireless sensors is packaged and transmitted to the ground via the Iridium Satellite Network. In addition when the Xbee Series 2 radio module is within range of the ground station it wirelessly transmits data without having to go through Iridium.

A new pressure switch system will be built. The purpose of the system is to allow the XBee sensors to turn on at a certain altitude in order to conserve power throughout flight. When the balloon reaches an altitude of 50,000 feet the board will turn on. Three pressure sensors are used for the sake of redundancy.



Figure 6 is the proposed set-up for connecting the Mega Pro with Iridium and the XBee radio modules. This system was initially designed by Gabriel Pearhill during a internship at NASA Ames. The Mega Pro board was selected due to the high number of Digital and Analog I/O pins that the board contains. The current set-up includes a system that is currently compatible for the Iridium 9602 modem. The team is also considering implementing the Iridium 9603 modem. Both are very similar in specifications with the major difference being size and the size of the pin connectors. However, this set-up should still be compatible with the Mega Pro and only minor changes will be needed.

Each XBee radio module has pressure and temperature sensors. These sensors will be placed in strategic locations on the capsule and if possible, on the parafoil itself. The gyroscope will be located in the capsule itself.

XBee Radio Modules
There are currently two types of XBee modules which are Series 1 and Series 2. In addition, both series have a standard and a PRO version that adds more functionality to the radio module. These radio modules are used to wirelessly transmit data between radio modules.

XBee Series 1 uses the 802.15.4 standard and can be set up in such configurations as Single Peer, Multi-Peer and Broadcast. Series 2 uses ZigBee, which is a specification for a suite of high-level communication protocols used to create personal area networks built from small, low-power digital radios. ZigBee is based on an IEEE 802.15 standard. Though its low power consumption limits transmission distances to 10-100 meters line-of-sight, depending on power output and environmental characteristics, ZigBee devices can transmit data over long distances by passing data through a mesh network of intermediate devices to enhance its effective range. ZigBee has a defined rate of 250 kbit/s, best suited for intermittent data transmissions from a sensor or input device.

For our project we have decided to work with XBee Series 2 due to the functionality of ZigBee protocol and the flexibility that it will have for future NASA projects.

Table 5 below shows a quick comparison between various flavors of XBee radio modules.

PCB Design
For the project a PCB was designed to the pcb104 standards (89.4 mm x 95.0 mm). The PCB houses a Teensy 3.1 microcontroller, digital pressure/temperature sensors, IMU, XBee series 2 radio module, Arduino GPS breakout board, micro SD card mount, Iridium 9603 modem and voltage regulators for powering the board and its components. The board was designed with free software called Diptrace and fabricated by Advanced PCB.

Computer Science
Our current software design has several components:
 * Email parser - Prepares information by tokenizing data fields received via email messages.
 * Data table - Structure which stores parsed data for easy retrieval.
 * GUI - Flat, clean, non-convoluted design, implemented in HTML5 for platform compatibility.

The Iridium modem used in our design only supports email communication. Emails with a specific data format will be sent from Iridium to the specified Gmail inbox, either upon request or regular intervals. The specific data payload is yet to be determined, and will be based on further analysis of sensor data requirements. The Email Parser will scan and tokenize data retrieved using the Gmail API, and then store the formatted data into the Data Table. The GUI will be implemented to retrieve from the Data Table, depending on desired output requirements.

The current GUI design goal is to make a clean and usable interface. It will be optimized for mobile devices, but will support desktop browsing. Current prototypes were built in Android Studio. It is excellent for rapid prototyping: One can quickly see a GUI coming together, but the IDE runs very slowly on available workstations. The team developing the Kickshot game had similar issues with Android Studio, and rewrote their code using a tool called PandaJS, which incorporated javascript, HTML5, and css. Learning from their experience, we plan move to HTML5.

Design Failure Mode Effects Analysis
This table represent our current DFMEA model.

Mechanical Engineering

 * The Iridium 9603 data modems have a mechanical failure during vibration tests, so we should look into other modems to use for Iridium communication.
 * We have an Iridium 9602 modem. The Iridium 9603 is too small to survive the vibration tests when connected to the board, but it is smaller and more efficient than the Iridium 9602. We will likely look into remedying this mechanical failure if we decide to use a similar Iridium modem for the final product.
 * Techniques for deploying, and inflating the parafoil.
 * These techniques will probably include a method for stiffening the parafoil.
 * We will have to run tests on our deployment and inflation system in low pressure atmospheric conditions, so finding a vacuum test chamber will be imperative.
 * Vacuum test chamber must be large enough to house the parafoil and its capsule.

Electrical Engineering

 * Miniaturization of the system.
 * By incorporating the sensor boards with the microcontroller.
 * Snowflake currently uses a diaphragm based altitude switch, but we want to use a pressure switch instead to reduce the required size for the electronic subsystems.
 * We will need to find a vacuum test chamber to calibrate the pressure sensors (probably the same chamber we will be using for the parafoil tests).
 * Eventually we will want to shift from XBee-Series 1 to XBee-Series 2 sensors to increase the distance that the sensors can be placed from each other.
 * The current system is based on XBee series 1 chip. We want to switch to the Series 2 chips which utilize a ZigBee network for communication.
 * How accurate of a pressure measurement is required to replace the altitude switch.

Computer Science

 * Language preferences: Java vs Python for graphics.
 * Look into using Gmail Application Programming Interface (API).
 * For parsing diagnostic data downlinked from the capsule.
 * For creating commands to send to the capsule.

Team Members


Final Deliverables

 * Final Report
 * Final Presentation
 * Downloadable Wikipage and Resources

Document Archive
Team Guided Parafoil System Project Uploads