• Kevin EngelGPS Lead, All-Around Support
  • Lucas MulkeyOn board Sensors and Code Lead, BT Communication Support
  • William FraneyFiltration Lead
  • Aaron PetersonMotors and Hardware Lead
  • Michael JohnsonGUI and BT Communication Lead
  • Nathan FerrisFiltration Researcher, GPS Support
  • Kelsey MooreControls Lead and Webmaster
  • Doctor Phillip JonesAdvisor
  • Doctor Nicola EliaAdvisor

MicroCART is an ongoing research project for developing and implementing an unmanned aerial vehicle. This year, our goals were to add additional functionality to the indoor system as well as work on moving toward an outdoor system. Added functionality included automatic take-off, automatic landing, following a path on a screen, and following an omni-directional robot.

The current objective of the team is to create a system that could work outdoors. The vehicle would use a small FPGA Board with bluetooth, sonar, GPS, and an IMU device. The software related to the vehicle consists of a Kalman Filter, the PID controller, and the interfacing between the different sensors.

The design of our project is intended to be used for demonstrations of embedded systems and controls integration on an autonomous flying vehicle. It also adds to the continued research and development of autonomous flight vehicles. The intention is to continue improving its ability to fly with the least amount of human interaction as possible.

For this reason, the intended users for the initial setup and understanding are those trained for the system. The interface requires the ability to program the FPGA board from the code design computer, debugging and fixing the quadcopter code and hardware when something doesn't go accordingly, and a list of commands currently used for flight. After the quad flies stably and the initial setup is complete the average American population should be able to use the GUI to control the quadcopter.

The goal for the project is to enable the quad-helicopter to fly autonomously in a pseudo-outdoor environment that is very different from where the quad-helicopter currently flies for all of its testing. The test environment will be located indoors where wind is negligible and the climate is controlled. Tests will take place in a three dimensional grid defined by the IR camera system that is about 27 m3 , with a thin carpet landing surface. It will be able to operate in temperatures between 40oF to 90oF; the operating environment will contain no obstacles. The only obstacles for it to not fly completely outdoors is the pseudo-GPS and a lack of account for wind speeds.

The quadcopter has many functional abilities and interactions. The quadcopter can be controlled manually by two different manual controllers, a RX controller and a USB controller connected to the base station. To use the RX controller you would just disconnect the FPGA board. To fly with the USB controller you would click on the manual control box located on the GUI.

The quad also has a working PID control system, a new motor signal-mixer, and a bluetooth communication system. The bluetooth communication allows the user to send information from the base station computer to the board mounted on the quadcopter. The PID system keeps the quadcopter in a stable hover when a throttle is inputted. The motor signal-mixer is the replacement for the GU 344 and translates the PWMs into an input the ESCs can read.

The quadcopter is also able to use the old GUI and flight system from 2013. In order to use this functionality, you would need to remove the bumpers, legs, and FPGA board from the quad. You would also need to reconnect the GU 344 to the proper motors and connect the RX controller to an FPGA board located at the current base station. Once those are connected, you bring up the old GUI and turn on the camera system to fly the quad. You can use the drawing function to fly the quad in a specific formation.

An important non-functional requirement we implemented is an easy way to shut down the motors as a safety precaution for those observing and flying the quadcopter. Safety, while not specifically required for the project to work, is a good non-functional requirement to have in order to make the project usable and demonstrable in a normal setting. Another non-functional requirement is to have an easy to use GUI. The system redesign doesn't need a GUI at all, but providing one will allow users with less experience to control the quadcopter more easily.