Published: April 19, 2018 By

Testing the device ink view of the Flatirons

Alex Lubar reads the anemometer measurements while Wilson Hughes flies a drone at Â鶹Ãâ·Ñ°æÏÂÔØBoulder South Campus.

Domino’s, UPS, Amazon, and the United States military are just a few examples of institutions interested in using drones as automated delivery systems for financial, logistical, and environmental reasons.

Drones save on employee costs, and they utilize otherwise unused airspace. They are far greener than loading everything into a car and driving it to its destination across a densely crowded city.

But when drones start to encounter powerful gales with no pilot to guide them, they need a system to help them avoid these dangers.

This was the pitch that Jeppesen, a Boeing company, gave us when they hired our Senior Design team for the Micro-Weather for UAV Operations project.

The Colorado-based company tasked us with designing a system to avoid inclement weather and direct a drone into safer conditions, while at the same time adding supplementary data to the world’s most advanced forecasts.

Our team was excited to be chosen for the project and work with Matthew Hendrian and Anna-Lisa Mautes of Jeppesen. Our enthusiasm turned to intimidation, though, when our first discussion consisted of weather forecasts, data processing, flight optimization, and something called HRRR. We spent the first month of our project researching what each of these topics were, then determining whether or not we had the ability to achieve a working system involving each one.

Because we couldn’t directly measure the wind speeds from the drone, we had to use linear algebra and trigonometry tilt angle of the drone to infer the values of the wind speeds buffeting the drone.

Knowing what we had to do, though, was a big step from being able to do it. The High-Resolution Rapid-Refresh (HRRR) model forecast is encoded in a data format called GRIB, a method of data packaging designed for the gigantic sets of data required by weather forecasts to do modelling. After learning what HRRR was, we had to learn how to decode it into usable data.

Part of the project was to be able to operate many drones on the same system, so we had to use a service called LoRaWAN Cloud for the drones to be able to work together while in the air. In order to alter the internal operations of the drones, we had to interact with the autopilot software on the drone, called ArduPilot, both through another program (we ended up using QGroundControl to test the drone) and through its internal code. Throughout the course of the project, the team coded in four different programming languages.

The Jeppeson team group photo.

Team 21, from left to right: Hanwen Zhao, Mahdi Ghanei, Alex Lubar, Wilson Hughes, Joe Parnell, and Hamza Albar.

The Jeppeson team group photo.

Because we couldn’t directly measure the wind speeds from the drone, we had to use linear algebra and trigonometry tilt angle of the drone to infer the values of the wind speeds buffeting the drone. It turns out that going into the project, the only thing we already knew how to do was how to learn something new.

Our team started the school year barely knowing each other and unsure of how to navigate this project, but got lucky with a dedicated team and an engaging project.

With the help of many people both inside and out of the Senior Design program, and the guidance of our project director, Dr. Marina Vance, we have succeeded in many of our goals.

Eight months later, we are presenting about our accomplishments at AUVSI XPotential Technology Conference in Denver. We are proud in our accomplishments in automatic drone weather detection and avoidance.

Engaging with our clients at Jeppesen gave us the opportunity to have professional experience to guide us into our careers with confidence.We are proud of our achievements, and are grateful for this exceptional experience.

Ìý

The Jeppeson team group photo.

A group photo of the team and their sponsor, Jeppesen, following a final Flight Demo.

Ìý

Ìý