OpenUAS Project

Objective:



Create a new, affordable, fixed-wing, small (approx. 4-foot wingspan, catapult-launchable) UAS that is specifically designed to be a) a reconfigurable platform for system health management experiments; b) an accessible, open-source educational module for undergraduates or advanced grade-school student clubs. The body will be designed to receive changeable sensors, run an FPGA on-board with adequate cooling, and be more configurable than previous UAS to enable a much broader-ranging set of flight tests that include FPGA-based system health management.

Requirements:



  • The components will be entirely COTS (Commercial Off-The-Shelf components) and 3D-printable so that others can easily produce the UAS with publicly-available machines and parts.

  • The designs will be entirely open-source and freely-available (via github). The design will include complete instructions for manufacture and assembly as well as any accompanying files, e.g., CAD files for 3D printing.

  • All parts of the aircraft and its design will be well-documented in LaTeX so that they look professional, can be easily modified with free software, are easily version-controlled with git, and are readable on a variety of platforms for many years to come.

  • The power system will be all-electric (no gas or flammable components). The batteries will be chosen to maximize flight time to allow more interesting experiments. The batteries will be able to be changed out to extend the life of the vehicle, rather than previous designs that fuse batteries into the fuselage.

  • The UAS will be small enough to be catapult-launched, so no runway reservations are required for test flights.

  • The fuselage will be sized and shaped to hold a Parallella board (credit-card-sized) FPGA with adequate cooling so that it does not overheat.

  • There will be a capacity to add and re-configure on-board sensors for different missions.

  • The documentation will be accompanied by education modules, suggesting fun experiments students at different levels could use the UAS to complete.

  • Wherever possible, the design will opt for low-cost options to maximize accessibility of the project to students, hobbyists, and research groups. The design may include choices for buying a more expensive part for better performance or a less expensive part that will be a nice cost-saving alternative.

  • The objective is not to push the bounds of innovative aircraft design. The team will utilize tried-and-tested math, algorithms, software, development practices, and designs (such as wing designs from the publicly-available database at UIUC) to achieve a reliable, reconfigurable, and robust UAS. The novelty of the project comes from the set of requirements above (e.g., COTS/3D-printable, open-source, reconfigurable).

Team:



The UAS project will be completed by a group of seven undergraduates at ISU.

While the design will be a collaborative effort completed by the team as a whole, individual members serve as “specialists” whose contributions to the team include bringing to the collaboration the ramifications of design choices on their special sub-system. For example, the power system/battery specialist will help ensure that the team has a good understanding of the COTS battery options, and then will check that the team understands the consequences to the battery each time a design decision is made by the team. This is meant to mitigate the possibility for situations such as the team getting excited about a certain payload that would make the design too heavy or too power-hungry for the available batteries to power.


The entire team will work together to complete the project, however all team members might not be experts in all areas of aircraft design. It is important for each team member to be willing to learn, teach others, and ask questions to ensure the team as a whole has thought through the design. Specialists should know their one area well.
The team will collaborate using revision control with github and documentation with LaTeX, while upholding safety requirements of ISU laboratory spaces, and good documentation practices.

Specialists’ Areas:



  • Accessibility Specialist This specialist checks that the design is in alignment with its goals and objectives as both an experimental platform and an education module. Checks include that the overall design satisfies its requirements as stated above, and that the documentation is complete and accessible to broad audiences.

  • Power System/Battery Specialist This specialist checks that there are batteries available that a) fit in the aircraft and b) provide sufficient power to achieve its goals. Checks include that the team accounts for all sub-systems that draw on the battery, that the aircraft is wired reasonably in a way that enables easy repair, and that the design proceeds within the goal of maximizing flight time. Other checks include that the team remembers to log battery usage and charge during test flights to follow best practices for battery health management and safe storage of batteries in fire bags in appropriate environmental conditions.

  • Aircraft Shell Specialist This specialist double-checks that the team has a complete picture of the trade-offs and consequences between choosing the shape of each sub-component and the materials/manufacturing process that would allow that shape/weight. For example, there is a trade-off between what is easy to foam cut vs 3D print vs fabric-cover and each of these shell-covering choices come with different consequences in terms of their weight, the pressures they can withstand, and their cost.

  • Autopilot and On-Board Software Specialists (2 people) These two specialists are responsible for evaluating autopilot software, or making sure the team considers whether modifications or new software needs to be created. The team will need to choose a suitable flight computer and ensure all sub-systems can be controlled accurately by the software setup; this includes providing real-time guarantees. These specialists will also check that the target system health management framework can be supported.

  • Sensors and Actuators Specialist This specialist checks that the team has a good understanding of the sensors available, their impacts on the aircraft, and how they feed into the control system. Also, this specialist checks the trade-offs between which and how many control surfaces are actuated, and how they should be actuated, including mechanical vs digital trade-offs.

  • CAD specialist This specialist ensures the team makes a wise choice regarding the CAD design software, documents the designs well, and follows best-practices for utilization of CAD from checking aerodynamics to validation to input for the 3D printer.

Logistics:



  • The team meets as a whole, in the lab, once per week at 5pm on Wednesdays. Regular meetings will be held on all weeks class is in session during the 2017-2018 school year. During each meeting the team will report on their progress and we will discuss both completed items and next-steps for the week ahead.

  • Each member of the team will register for independent study credits; members can choose the number of credits (up to 3 per semester) depending on their individual programs and needs.

  • The goal timeline would be to complete the design, up through flight testing and experimentation with different proposed education modules, before April, 2018. The team will set their milestones during the initial planning phase.