Wildlife radio telemetry is a very important tool for tracking the movement and behaviour of virtually any animal attached with a transmitter. The reason why scientists want to track these animals is to gather behavioural and movement data of any animal attached with a transmitter. There are two main methods to tracking animals in this way, GPS tracking as well as very high frequency tracking. But the use of VHF radio tags is becoming the standard due to their low cost and the exponentially growing pool of VHF-tagged specimens. This ensures that the VHF technology, and in turn, our work on this project will be used at the benefit of biologists and mechanical engineers by being able to more quickly gather transmitted data to the conventional method of having to use a handheld receiver.

While an overall positive tracking method, there are some problems with VHF. One of the problems with this approach to data gathering is the cost required to go and search for these VHF signals. Currently, the main way to gather the data from these VHF tags requires someone to go out into the areas where animals have been tagged and use either handheld scanners or scanners attached to cars if the area permits vehicles.

Our sponsor, Dr. Michael Shafer and his team have spent the last three years working on integrating a VHF receiver to an unmanned aerial vehicle, also known as a drone. They are currently being funded by a grant from the National Science Foundation to help develop a drone with the ability to track wildlife. Their goal is to decrease the cost of having to locate these animals by using the drone, which can perform a more rapid, efficient, and complete scan of an area when compared to a human.

The way our client currently gathers data is to first go out into the field in the general area in which the tagged animal he is looking for is located. He will then use his laptop and open up Mission Planner, an open source flight planning software where he plots the route the drone will be taking. He then opens a program he created himself that connects with the drone so that he can send the correct configuration file to the drone to match the data he is collecting as well as receive status updates from the drone. The drone will then fly its path, collect the data, and then return to the starting point where Dr. Shafer will collect it and then return to his office to process the new data.

There are some specific problems with this workflow that we would like to solve. Having to use two separate applications requires constant swapping to ensure maximum benefit from both pieces of software. The custom application developed by Dr. Shafer has a very slow launch time and can take up to five minutes to initially load. How the drone configuration is handled, this could result in an error causing the drone to crash while losing all gathered data and potentially damaging valuable hardware. Our solution to this involves taking all the preflight software and moving it into the flight planner. This will take care of startup times and reduce required startup programs to one.

The initial concept for this project was written by our sponsor in the form of a Capstone project proposal which can be found here.

In terms of requirements for this product, our client has been very clear. He currently uses his own MATLAB programs to aid him in pre-proccessing data and ensuring that the drone is setup correctly. He would like us to mimic this functionality in an open source flight planning software. We have decided that modifying QGroundControl best fits our and our client's needs. If you would like to know more about how we came to this conclusion, feel free to read our Technical Feasability document located in the archive tab on this website.

With QGroundControl, our client would like to add some specific functionality: first he would like to be able to create configuration files with with the UI, this means that we will have to develop a form that he can fill out to creat this file. He would also like to be able to save these files onto the computer so that he can select them for reuse without having to fill out all of the information again. Along with this he would like the ability to be able to send this configuration to the drone.

Dr. Shafer would also like a terminal setup so that he can see heartbeat messages from the drone while it is in flight. There is also a need for an FTP system setup so that he is also able to download the flight data after the drone has landed.

These are our requirements as of now, although we are aware that further along in the development cycle things may change and we will edit this site to keep up to date with any and all changes.

With the problem provided, our team needed to find a way to reduce the amount of time of our client’s setup and consolidate the pre-flight steps into one program. The solution we are planning involves remaking the configuration software of our client’s MATLAB code in QGroundControl so that our client’s total setup time will be significantly less. Our solution will also address QGroundControl’s nonexistent status message display by using the modified GUI to display these messages.

Our Solution will provide these key features: Complete configuration management in QGroundControl. No MATLAB required for drone flight planning. Ability to communicate with the drone to upload configuration files and download flight data. A Graphical User Interface (GUI) to manage the creation of configuration files and how status messages are displayed.

Our system will use data from the drone, mostly flight data and status messages to let the client know the status of the drone and provide useful results through the flight data. It will also use data from the user such as the manually input configuration data, start/stop commands, and a manually inputted flight path. This allows our client to be able to use QGroundControl for setting up the drone for data collection. Our system will generate a configuration file based on the user input. This file is used to control the functionality of the VHF antenna located on the drone. With the implementation of these functions, our client will no longer need to use MATLAB in addition to his flight planning software for pre-processing data. This in turn means that he will only need to use QGroundControl when out in the field as it will now possesses all the functionality of the MATLAB code as well as some quality of life changes to QGroundControl.

As of May 2020, we have finished development and have handed off the software to our client.