Aurora Flight Sciences Co-op
My second co-op was at Aurora Flight Sciences in Cambridge MA at their Research and Design Center (RDC). Aurora is an aerospace company leading the charge in automating aircraft as well as developing experimental aircraft concepts. I worked at Aurora full time for six months January - July 2017 and then two months part time after. It was an fulfilling experience and it was great to get exposure to an aerospace company where I could start to learn some ins-and-outs of the industry.
The primary program I supported was AACUS - Autonomous Aerial Cargo / Utility System. The goal of the project was to retrofit conventional helicopters with autonomous systems for cargo delivers. My role in the project was in software, developing post processing tools in Python to analyze flight and simulation data to help identify bugs and anomalies.
There were existing tools that I refactored as they were outdated. The two main tools that I made were one that plotted the aircraft tracks and other flight features in a Google Maps readable format (KML), and one that procedurally created PDFs that displayed information on variables in the program. The main flight software used ROS for communication, and so the post processing tools also had to be able to decipher the messages and extract the data.
AACUS
The system uses an RC aircraft engine to drive a large brushless motor, producing electricity that is then fed to the batteries and the motors.
I first conducted a trade study on the most efficient and viable means of transferring power from the engine to the generator (a large DC motor acted as the generator). The trade study focused mainly on gears, direct coupling, flat belts, and timing belts.
After conducting the trade study, I supported test stand development, predominately for characterizing the gas engine. I specced out torque, force, and rotational sensors to measure the power output of the engine, while under load from a specific propeller. From these measurements we could establish a power curve for the mostly unknown generator, and could then validate our assumptions of the system. I also designed and fabricated a few interface plates for mounting the sensors and engine on the test stand.
The KML Parser was the first program I built, it’s able to create Google Earth files that allow for easy viewing the aircraft tracks. It’s able to plot features such as waypoints, flight tracks, projected flight paths, No Fly Zones (NFZs) and Safe Air Volumes (SAVs), among others. I also developed a framework that allows for easy and modular expansion, allowing another programmer to add more data without much hassle. The framework consists of function modules that create the different features, allowing for them to be used for more than just the components they were designed for. This program took about two and a half months to finish, with most of the time being used to learn the file structure of the saved data file from simulations, and learning the KML syntax.
The image on the left is sample output from the program, using simulated and modified flight data (modified for viewing purposes). The aircraft waypoints, flight path, NFZ and LZ is shown.
After completing the KML Parser, I began development on the Report Generator, which generated automatic reports on the status of simulated and actual flight tests. There was an older version of the Report Generator in existence, but it was not kept up, and did not work with the current code architecture. The majority of the first month of this project was sorting through the existing code, and understanding what it was doing. The first thing I knew I wanted to do was to remove the graphs that were hardcoded in, and develop a system for procedurally generated plots.
I developed a system that would be able to take in the data streams, and compile plots and tables, allowing for easy creation of new plots using only a few lines of code. The program automatically compiled the graphs and tables into different PDF categories, allowing for developers to pick which section they were interested in seeing easily. This program also called the KML Parser automatically to generate Google Earth files. Additionally I added a module system where future developers can add new code files into a specific folder, and gather more data without having to access the main program (gather more data as the flight software develops).
The image on the right is example output from the program, showing the first page of the Mission Manager pdf report (note that the data has been replaced with inaccurate numbers to remove any sensitive data). This particular section looks for and plots state changes of variables, and records the time that the event occurred and where. This is used to identify bugs in the code and why they may have happened. The program auto creates a table and graph for each variable. It also has the capability to plot 2D and 3D flight paths.
I also worked on maintaining software test builds, using Jenkins to run nightly builds and simulations. Once the Report Generator was finished, I compiled it to run with ROS, and was able to call it after each simulation in Jenkins, to automatically create reports on each simulation run nightly. I also worked with SVN for version control, and would periodically pull changes from trunk to make sure my code still worked in the system.
Example output from the Report Generator for the Mission Manager report type. The data has been modified from it's original form to show the capabilities of the system and remove sensitive data
Vertical Lift SBIR
One of the other projects I supported in limited capacity was the Vertical Lift by Series Hybrid Electric SBIR program. The goal of the project was to create a hybrid electric hex-copter, to benefit from the high energy density of hydrocarbon based fuel, while using electric motors for the simplicity and their high-fidelity control.
The system uses an RC aircraft engine to drive a large brushless motor, producing electricity that is then fed to the batteries and the motors.
I first conducted a trade study on the most efficient and viable means of transferring power from the engine to the generator (a large DC motor acted as the generator). The trade study focused mainly on gears, direct coupling, flat belts, and timing belts.
After conducting the trade study, I supported test stand development, predominately for characterizing the gas engine. I specced out torque, force, and rotational sensors to measure the power output of the engine, while under load from a specific propeller. From these measurements we could establish a power curve for the mostly unknown generator, and could then validate our assumptions of the system. I also designed and fabricated a few interface plates for mounting the sensors and engine on the test stand.