Guided Parafoil System

This project will develop a system for the successful deployment of a small parafoil from a ‘can’ in space or near-space environments using wireless technologies. The wireless communication, command, and control system will be used to initiate parafoil deployment, and to wirelessly provide critical high altitude, low Reynolds number flow measurements from sensors on the parafoil. The system will be tested as part of the University of Idaho Near Space Engineering (Idaho RISE) high altitude balloon program. Applications of this work will eventually be incorporated into the TechEdSat collaborative nano-satellite project underway between the University of Idaho, San Jose State University, University of California at Riverside, and the NASA Ames Research Center in Mountain View, California.

Background
NASA wants to develop an inexpensive on-demand capability to return samples from the International Space Station (ISS). The Small Payload Quick Return (SPQR) system is being developed by NASA Ames Research Center. The SPQR concept relies on a 3-stage method of returning payloads, after being stored until need and loaded on-board the ISS Deorbit, by means of a unique drag system called an Exo-Brake to de-orbit a small spacecraft payload using atmospheric drag instead of rocket thrusters to reduce speed for atmospheric re-entry. The three stages are:

Team GPS is interested only with Stage 3.
 * Stage 1: Erection of the Exo-Brake and descent from 350 to 100 km.
 * Stage 2: Deployment of the Tube Deployed Re-entry System (TDRV) from 100 km to 10 km.
 * Stage 3: Deployment of the autonomous, GPS guided parafoil from 10 km to ground/retrieval.

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

Mechnical
Figure 3 shows the block diagram of the snowflake system. The PCTCU will be constructed by use of a 3d printer and will contain the parafoil and the control system. In addition, a new controller frame has been designed that will hold the electronics and servos.

After comparisons of multiple servos the Vigor VSD-22YMB. The servos meet all the desired specifications for the project. Lastly, the parafoil for the project has been

Electrical
Figure 4 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 all board will turn on. Three pressure sensors are used for redundancy sake.



Figure 5 is the proposed set-up for connecting the Mega Pro with Iridium and the XBee radio modules. This system was initially created by Gabe Pearhill during a internship at NASA. The Mega Pro board was selected due to the high amount 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. It has been proposed to work on implementing the Iridium 9603 modem instead. 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 reach more distant ones. 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 go with XBee Series 2 due to the functionality of ZigBee protocol and the flexibility that it will have for future NASA projects.

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

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.

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


Document Archive
Team Guided Parafoil System Project Uploads