Drone Mission Planning Software

Drone Mission Planning Software is a project to design and develop a graphical user interface for drone mission/flight planning. The goal is to be able to upload a flight plan, created using a graphical user interface on a computer, using XBee hardware modules (connected to the source computer and another attached to a drone) and XAPI.

Problem Definition
To design and develop a graphical user interface for drone mission/flight planning. The graphical user interface needs to allow 3-dimensional presentation in a user-friendly manner. The software also needs to monitor underway missions. This includes updating way points, aborting flights, allowing manual override. Our goal is develop this software in order for it to be expanded by future plugins.

Background
This project began with the work of a group of University of Idaho Freshman attempting to implement Brandon Ortiz's XAPI micro-controller service manager in order to send commands remotely to a drone. Upon starting our work, we were tasked with needing to modify the current drone in order to produce stable flight and build upon the previously built chat program used to send messages from a computer over a serial connection.

Deliverables

 * 1) Stable drone design and documentation
 * 2) Defined XAPI command structure for drone command processing
 * 3) A graphical user interface for mission planning

Drone
The drone design's major requirement that needed to be met was to achieve stable and reliable flight.

By analyzing the drone, it was determined that its center of gravity was not directly centered on the drone, which resulted in drifting during flight. To remedy this issue, a "part holder" was designed to be mounted on the underside of the drone to hold all the motor controls, which moved the center of gravity to the center of the drone.



After further refinement, a series of drone parts were created and 3D printed. Some of these parts include micro-controller mounts, landing struts, a revised parts bin, and battery holders. The following is a PDF document with the most up-to-date part drawings.



XAPI
To satisfy one of our major requirements, we run the XAPI on each Arduino in the communications system.

XAPI (developed by Brandon Ortiz) is, put simply, a micro-controller service manager that communicates, both internally and externally, using TUN packets. When communicating externally, the XAPI ships the TUN packet using the XBee hardware by embedding the TUN packet in a XBee packet.

Each service available with the API use XAPI to communicate, using XAPI as the core that each service "latches" to. For instance, if a chat service wanted to display a message on a attached LCD screen, the following steps would be carried out:
 * 1) Chat service creates a LOCAL LCD TUN packet
 * 2) Chat service passes the newly created packet to the XAPI core
 * 3) XAPI places the packet in its internal packet buffer
 * 4) The LCD service latch queries XAPI for any packets designated for the LCD service
 * 5) LCD service grabs LOCAL LCD TUN packet
 * 6) LCD service processes and displays the packet

To satisfy our project's requirements, we need to design a Flight Control service that will be able to handle any instruction packets and translate them to instructions that can be given to the drone's ight computer. In addition to this, there is a requirement for a Mission Plan service that will store and execute flight plan's designed by the user and sent to the drone.

Communications
Our communications system, as depicted in the graphic below, requires two-way communication between the computer (including the attached Arduino) and the Arduino located on the drone. This system will take an instruction created on the computer, send it over serial to the connected Arduino, pass it to XAPI, XAPI will ship it over XBee to the Arduino on the drone, and a flight control service will execute the instruction.



With the communications model in place, we also developed a installation protocol for sending a mission plan from the home Arduino to the Arduino on the drone. The protocol uses a ACK/NACK system that will wait for a ACK after sending a mission plan packet. This allows us to ensure that we are not flooding the receiver Arduino, the order of instructions is maintained, and can verify the integrity of the data by using a checksum value with the end install packet. The following is a diagram to depict this process:



Graphical User Interface
The graphical user interface must satisfy several requirements:
 * 1) Must be user-friendly
 * 2) Allow 3-dimensional mission planning
 * 3) Allow upload of flight plan to drone
 * 4) Allow manual override

Given these requirements we were able to design a general design for the graphical user interface (GUI), as shown below. This GUI is split into several sections that convey different information, that in some cases can be adjusted.




 * 1) Light-blue: Flight control section, shows drone component status, manual override
 * 2) Yellow: Readings from on-board instruments
 * 3) Light-red: Mechanism to develop flight plan
 * 4) Light-green: Communications terminal to see all sent and received packets

The following is the first version of the Mission Planning software graphical user interface:

Document Archive
Initial Client Interview Transcript:

Detailed Design Review: